Security teams should use session-based privileged remote access with strong authentication, least privilege, and full session recording. The goal is to grant access only for the task, expose only approved resources, and retain audit evidence. This reduces standing exposure while preserving operational control, especially for third parties and administrators who do not need broad network access.
Why This Matters for Security Teams
VPNs were built to extend network reach, not to govern privileged work. That distinction matters because vendors and remote administrators rarely need broad subnet access; they need time-bound entry to a specific application, host, or session. When VPNs are used as the primary control, teams often inherit unnecessary lateral movement risk, weak attribution, and overexposed credentials. NHI Management Group’s Ultimate Guide to NHIs notes that 92% of organisations expose NHIs to third parties, which is exactly where remote privileged workflows can become a supply chain problem.
Session-based privileged remote access changes the model from “connect to the network” to “perform an approved action under supervision and logging.” That aligns better with NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10, because it reduces standing access and makes authorization evidence-driven. In practice, many security teams discover the weakness only after a vendor account has been reused for broader access than the original ticket ever justified.
How It Works in Practice
A usable design starts with strong identity proofing, then issues access only for a defined session and objective. The remote user authenticates, the request is approved or policy-evaluated, and the platform brokers access to only the target resource. The session is recorded, commands may be filtered or proxied, and credentials expire when the task ends. That is more defensible than handing out a VPN profile with broad network reach and hoping segmentation will absorb the risk.
Operationally, teams should combine PAM, step-up MFA, device checks, and just-in-time access with per-session controls. Current guidance suggests that approval should be tied to ticket context, asset sensitivity, and time window, not just job title. If a user only needs SSH to one server, they should not receive routable access to an entire environment. If a vendor needs a database export, the platform should expose only that workflow and retain evidence for audit and incident response.
- Use least privilege at the session layer, not only at the account layer.
- Prefer short-lived credentials and automatic revocation over reusable static secrets.
- Record commands, keystrokes, file transfers, and session metadata where legally permitted.
- Apply policy at request time, not as a one-time role assignment.
NHI Management Group’s State of Non-Human Identity Security reports that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which underscores how quickly access sprawl can hide in plain sight. These controls tend to break down in highly dynamic environments where vendors need unpredictable branching access across many hosts because session brokering becomes operationally complex.
Common Variations and Edge Cases
Tighter remote access controls often increase operational friction, so organisations must balance auditability against speed for support and incident work. That tradeoff is real, especially when vendors are debugging production systems across mixed Linux, Windows, SaaS, and cloud consoles. Best practice is evolving, and there is no universal standard for exactly how much command filtering or session recording is sufficient in every context.
One common edge case is emergency access. Break-glass accounts may still be necessary, but they should be heavily monitored, time-boxed, and reviewed immediately after use. Another is contractor access to shared platforms, where session-based controls should be paired with identity lifecycle discipline from the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the Top 10 NHI Issues. For environments with legacy tools, teams may need a staged migration where VPN remains temporarily, but privileged tasks move first into brokered sessions.
Where this guidance becomes weaker is in air-gapped networks, OT systems, or tools that cannot be proxied without breaking functionality. In those cases, teams usually need compensating controls such as jump hosts, strong segmentation, and stricter review of every privileged session rather than broad remote connectivity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers credential rotation and short-lived access for privileged third-party sessions. |
| OWASP Agentic AI Top 10 | Useful where remote access is brokered to autonomous tools or AI-assisted operators. | |
| CSA MAESTRO | Addresses governance patterns for brokered, task-scoped access in complex workflows. | |
| NIST AI RMF | Supports accountable, context-aware authorization and human oversight for remote access. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access management fits session-based privileged remote access. |
Replace reusable remote access secrets with JIT-issued, time-limited credentials and automated revocation.
Related resources from NHI Mgmt Group
- How should security teams use AI to improve privileged access decisions without adding more approval friction?
- How should security teams prove privileged access is compliant without relying on manual audits?
- How should security teams govern access for remote workers without relying on the office perimeter?
- How should security teams secure database access without relying on VPN trust?
