TL;DR: Zero trust changes remote access from network-based trust to session-based verification, with MFA, approval workflows, scoped access, automatic termination, and session logging reducing the blast radius of compromised credentials and limiting third-party movement, according to Admin By Request.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Admin By Request's blog post: Zero trust remote access replaces standing network trust with per-session verification, scoped access, and audit logging.
Why it matters: This matters because remote access remains a common path for contractors, vendors, and administrators, and identity teams need controls that constrain what access can do after it is granted.
Context
Remote access security fails when organisations treat network presence as proof of trust. The stronger model is to separate authentication, authorisation, session duration, and logging so each decision is explicit rather than inherited from the network path. Zero Trust Identity Guide
That shift matters across NHI, human, and third-party access because the same old assumption keeps breaking: if a connection exists, the caller must be safe to move around. Zero trust replaces that shortcut with scoping, time limits, and verification at the point of use.
For identity programmes, the core governance question is not whether a user can connect, but what that session is allowed to reach, how long it lasts, and what evidence remains after it ends. That is the real control boundary.
Key questions
Q: How should teams reduce the blast radius of compromised remote access credentials?
A: Reduce blast radius by replacing shared remote credentials with per-user or per-service accounts, enforcing MFA, limiting sessions with least privilege, and removing standing access through just-in-time elevation. Rotate passwords, API keys, and tokens quickly after suspected compromise, segment remote entry points, and bind access to device, source, or time conditions so one stolen secret cannot open broad connectivity.
Q: Why do persistent remote connections create more risk than just-in-time access?
A: Persistent remote connections keep an always-on authentication path open, so a stolen password, token, or certificate can be reused without a fresh approval step. Just-in-time access narrows exposure by granting remote connectivity only for a defined task and time window, then revoking it, which limits replay, lateral movement, and unattended misuse.
Q: How do session logs differ from connection logs in remote access governance?
A: Session logs record what happened inside an active remote session, such as commands, file transfers, privilege changes, and timestamps. Connection logs record the network event that established or ended access, such as source, destination, protocol, and authentication outcome. Governance needs both because connection logs show access, while session logs show use.
Q: What should teams do first when third-party remote access is too broad?
A: Start by inventorying every third-party account, VPN, shared credential, and vendor tunnel that creates standing access paths, then map each one to a named owner, approved business purpose, and specific target systems. Remove blanket network reach where possible, replace it with least-privilege access, and require time-bound approval plus session logging for any remaining remote access.
Technical breakdown
Per-session identity verification in remote access
Traditional remote access often front-loads trust at login and then lets the session continue with whatever access was already granted. Under a zero trust model, authentication answers only one question: who is initiating the session right now. Authorisation is then applied separately to the request, the target system, and the time window. That distinction matters because a valid login is not the same as authorised movement inside the environment. Session-based control also makes approval workflows meaningful, because the approval is tied to a narrow act rather than a broad network position.
Practical implication: Treat authentication and authorisation as separate controls and require per-session approval for sensitive remote access.
Why standing remote connections expand blast radius
A persistent remote connection is a standing trust relationship that remains useful to an attacker long after its original purpose ends. If credentials are stolen, the attacker inherits the same broad connectivity the legitimate user had, especially in VPN-style models that place the user on the network rather than limiting them to a specific target. Zero trust reduces that risk by giving access only to a named system for a bounded task. When the task ends, the pathway disappears, which sharply narrows what a compromised session can reach. See the Remote Access Identity Guide.
Practical implication: Replace persistent remote connections with time-bound, system-scoped access paths.
Session logging as evidence, not just connection history
Connection logs show that access occurred, but they do not explain what happened after entry. Session-level logging records systems touched, actions taken, and duration, which makes the audit trail useful for incident response and compliance review. Session recording goes further by preserving the actual activity in sensitive sessions. In remote access governance, that is the difference between proving that a door opened and understanding what was done inside the room. Without that evidence, approval workflows and access scoping are harder to verify after the fact.
Practical implication: Log session activity, not just connection events, and retain recordings for high-risk access paths.
Threat narrative
Attacker objective: The attacker wants to turn a valid remote session into broader internal access that outlives the original purpose of the connection.
- Entry occurs when an attacker uses compromised remote access credentials to reach a legitimate session boundary rather than a hard perimeter.
- Credential abuse matters because standing access or broad network placement lets the attacker inherit privileges that were intended for a trusted user or vendor.
- Impact follows when the session has no tight scope or expiry, allowing the attacker to move beyond the original task and use the connection for wider access.
Breaches seen in the wild
- SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Remote access trust has to be redefined at the session level. The old assumption was that successful login established a durable trust relationship. That assumption fails when access is remote, temporary, and shared across employees, vendors, and contractors. The practical consequence is that governance has to move from network membership to explicit session scope.
Standing access is the vulnerability, not remote access itself. Organisations often focus on whether the connection method is VPN or browser-based, but the real issue is whether the session can outlive the task that justified it. A session that remains broadly usable after approval creates unnecessary privilege persistence, and that is what attackers exploit.
Session evidence is now an identity control, not just an audit feature. Logging that captures only the start and end of a connection is too thin for modern remote access governance. Teams need evidence of what the session reached and what actions occurred so that approval, scope, and accountability can be tested after the fact.
Zero trust turns remote access into a lifecycle problem. Access grant, active session, termination, and post-session evidence are now one governance chain. That means remote access cannot be managed as a point-in-time event; it has to be governed as an identity lifecycle with explicit expiry and traceability.
Third-party access needs a narrower trust model than employee access. Vendors and contractors often have legitimate reasons to connect, but their access should not imply lateral reach into the broader environment. The governance gap is not vendor intent, it is the assumption that a valid connection should behave like a local presence.
From our research library:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
- Read next: Zero Trust Identity Guide
What this signals
Session-bound trust is becoming the new baseline for remote access. Programmes that still depend on persistent connectivity will keep overestimating how much access a compromise really needs. The shift is toward access that expires with the task, not access that survives the login.
Identity teams should expect remote access governance to merge with lifecycle control. Approval, scoping, termination, and evidence are no longer separate concerns. They form one operating model, and programmes that cannot tie those pieces together will struggle to prove least privilege in practice.
Zero trust changes the question from who connected to what the session could reach. That is the operational difference practitioners need to design for, especially where vendors and contractors are involved. The control plane has to limit reach before the session begins and leave evidence after it ends. remote access governance
For practitioners
- Audit standing remote connections Inventory persistent VPNs, saved tunnels, and always-on vendor paths, then classify which ones still have a current business justification.
- Scope access to the target system Restrict each remote session to the named endpoint or application needed for the task, rather than the wider network.
- Require approval before session start Gate sensitive remote access behind a documented approval workflow so access is granted only for the specific request.
- Log what the session actually did Capture session-level activity, not just connection metadata, and retain recordings where incident response or compliance needs evidence.
- Separate vendor access from internal reach Use a dedicated third-party access path that prevents contractors and suppliers from drifting beyond the approved system and time window.
Key takeaways
- Remote access risk is driven less by the transport method than by whether the session inherits standing trust after authentication.
- The article’s central governance theme is that scoped, time-bound access reduces the usefulness of stolen credentials and narrows third-party reach.
- Session-level logging and automatic termination turn remote access into an identity control that can be audited after the fact.
Related NHI Mgmt Group resources: Zero Trust Identity Guide · Remote Access Identity Guide · Remote Access Policy Template
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 addresses the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Remote access becomes overprivileged when sessions inherit broad standing trust beyond the task. |
| NHI-01 — Improper Offboarding | Session-based access removes the offboarding burden created by persistent third-party connections. | |
| Recommendation — Restrict remote access so each session only reaches the approved system and expires when the task ends. Eliminate standing remote access paths that remain usable after the vendor or task has ended. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The post centres on explicit entitlement scoping for remote sessions rather than inherited network trust. |
| Recommendation — Apply session-level authorisation so remote access is limited to the exact system and time window required. | ||
| NIST Zero Trust (SP 800-207) | Verify Explicitly — Verify Explicitly | Zero trust architecture is the governing model for replacing perimeter trust with per-session verification. |
| Recommendation — Verify each remote session explicitly before granting access and do not rely on prior network presence. | ||
| CIS Controls v8 | CIS-5 — Account Management | Persistent remote access depends on account lifecycle discipline and removal of dormant or unnecessary access. |
| Recommendation — Review and remove unused remote access accounts and standing vendor pathways on a defined schedule. | ||
Key terms
- Zero Trust: A security model that assumes no identity, human or non-human, should be trusted by default, even inside a network perimeter. Every access request must be verified, authorised, and continuously validated.
- Just-in-Time (JIT) Access: Just-in-Time (JIT) Access grants permissions only when needed and removes them after use. In IAM and PAM, it reduces standing privilege by issuing time-bound access based on approval, context, or policy, limiting exposure for humans, service accounts, and non-human identities while improving auditability and control.
- Session-Level Logging: Session-level logging is the recording of activity that occurs within a live user or system session. It captures actions such as commands, clicks, privilege changes, and file access, rather than only the start and end of the connection, which makes it useful for auditing, incident investigation, and access accountability.
- Standing Access: Standing access is persistent privilege that remains available without fresh approval or contextual checks. In NHI environments, standing access usually appears as long-lived tokens, reusable service accounts, or broad roles attached to automation. It is convenient operationally, but it expands risk when conditions change or secrets leak.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on November 4, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org