TL;DR: VPNs, jump hosts, scattered credentials, and patchwork logs are slowing remote work while widening exposure, and browser-based, app-scoped access with policy, vaulted credentials, and audit creates a tighter control layer for users and admins, according to Delinea. The governance question is not convenience versus security, but whether access is still being granted at the right boundary.
At a glance
What this is: This is an analysis of browser-based remote access that narrows sessions to specific applications, servers, and portals while preserving policy, identity, vaulting, and audit control.
Why it matters: It matters because IAM teams have to govern remote access as a privilege boundary, not just a connectivity problem, across human users, admins, and third-party access paths.
By the numbers:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- Only 5.7% of organisations have full visibility into their service accounts.
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
👉 Read Delinea's analysis of browser-based privileged remote access
Context
Remote access is not just a networking issue. When every session depends on VPNs, jump hosts, scattered credentials, and manual approvals, the organisation ends up governing connectivity instead of governing the application or privilege that matters.
For IAM and PAM teams, the real question is whether remote access is scoped to the task or still effectively opening the network. App-scoped access can reduce exposure, but only if policy, identity, vaulting, and audit are enforced together rather than treated as separate controls.
Key questions
Q: How should security teams scope remote access without exposing the broader network?
A: Security teams should broker access to the application, server, or portal itself rather than the surrounding network. The practical test is whether a user can complete the task without gaining routable access to unrelated systems. If network exposure is broader than the job requires, the access model is too permissive and should be redesigned around session-level control.
Q: Why do VPN-based remote access models still create privilege risk?
A: VPNs often turn identity decisions into network decisions, which makes it easier for users to reach more than they need. Even when downstream permissions exist, the reachable surface is already expanded. That increases the chance of lateral movement, overexposure, and audit ambiguity. App-scoped access reduces that risk by limiting what is reachable before the session begins.
Q: What breaks when privileged remote sessions are not time-bound?
A: Without time bounds, privileged access becomes standing privilege with a nicer interface. That means approvals, vaulting, and logging may exist, but the entitlement itself remains reusable and harder to govern. The result is weaker accountability and more opportunities for misuse. Time limits matter because they force access to expire with the task rather than with the user.
Q: Who is accountable when a vendor or partner uses remote administrative access?
A: The organisation granting the access remains accountable for how it is scoped, approved, recorded, and revoked. Third-party access should not be treated as an exception to governance. It should be treated as a higher-risk use of the same controls, with strict expiration, searchable audit evidence, and explicit lifecycle offboarding when the relationship changes.
Technical breakdown
Browser-mediated remote sessions and scoped application delivery
Browser-mediated remote access works by terminating the user session at a control plane, then brokering the actual connection to a server, remote application, or private web app inside the customer environment. The user sees an approved target list rather than a routable network segment. This is materially different from classic VPN access, which expands network reach and relies on downstream permissions to contain risk. By publishing only the application or session target, the platform can attach policy, approval, and audit at launch time instead of after the connection is already broad. The security value comes from reducing the accessible surface before the session starts.
Practical implication: treat the launch target as the control point and remove any path that turns app access into broad network reach.
Vaulted credential injection and zero standing privilege
When credentials are injected from a vault instead of exposed to the user, the session can be authenticated without disclosing the underlying secret to the workstation. That changes the trust model from shared access to brokered access, especially for admins. Approval gates and session expiry reinforce zero standing privilege by ensuring access exists only for the task window, not as a persistent entitlement. This pattern works best when the vault, policy engine, and audit trail are aligned, because otherwise the organisation may still have standing access hidden behind a convenient interface.
Practical implication: require time-bound approval and vaulted injection for privileged sessions that would otherwise rely on persistent credentials.
Collections, least privilege, and auditable remote administration
Collections group remote applications, web consoles, and private portals by role or team so users see only the tools relevant to their work. That is a governance mechanism, not just a user interface choice, because it lets access be assigned at a collection level rather than individually for every session. In practice, this simplifies recertification, reduces ad hoc exceptions, and makes audit records easier to interpret. The architectural win is that identity policy is applied before the user reaches the target, which keeps privilege from spreading through an oversized remote desktop.
Practical implication: use grouped entitlements for remote app catalogs so access reviews and audit evidence stay intelligible.
NHI Mgmt Group analysis
App-scoped remote access is a privilege boundary, not a convenience layer. The article’s core shift is away from network-first access and toward access that is attached to a specific application or administrative task. That matters because the old model treats the network as the thing to open and then hopes downstream controls will contain the damage. For IAM and PAM programmes, that is the wrong control plane. The practitioner conclusion is that remote access should be governed at the session and target level, not at the network edge.
Zero standing privilege becomes practical only when access is both time-bound and brokered. The combination of approvals, vaulted credentials, and automatic session termination turns privileged remote access into a task-scoped event rather than a reusable entitlement. That is the governance distinction that matters. The implication is that access governance, vaulting, and session control cannot be separated into different operational teams if the result is still persistent privilege in disguise.
Identity blast radius: remote access should be designed to shrink the number of reachable systems before the session begins. Once users can only see approved targets, the organisation reduces the chance that a single credential or session can be used to pivot laterally across broader infrastructure. That is especially important for admins and third parties, where the cost of overexposure is highest. The practitioner conclusion is that the catalogue of reachable apps is itself a security control.
Remote access governance now spans human, third-party, and workload-adjacent use cases. The article shows the same access pattern extending to vendors, partners, web portals, OT consoles, and administrative tools. That broadens the governance burden from a single user population to multiple identity types with different risk profiles. The implication is that access policy, audit, and lifecycle controls need one governance model, not separate exceptions for each class of session.
Visibility is the differentiator between controlled access and merely hidden access. A browser front end does not create security by itself. What changes the risk posture is whether every launch, approval, injected secret, and session record is searchable and reviewable. The practitioner conclusion is that remote access redesign should be measured by audit quality and entitlement scope, not by how little friction the user feels.
From our research:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 52 NHI Breaches Analysis shows how quickly overexposed credentials turn into incident paths when access is not tightly scoped.
What this signals
Remote access sprawl is increasingly an identity problem, not a connectivity problem. Programmes that continue to treat VPNs and jump hosts as the primary control point will struggle to prove least privilege or produce clean access evidence. The stronger pattern is to make the application or session the boundary and to measure how much reachable surface each privilege actually creates.
Identity blast radius is the right lens for evaluating browser-based access redesigns. If a user, admin, or third party can only reach the target needed for the task, the organisation has reduced the number of systems exposed to a single session compromise. That is a governance outcome as much as an architectural one.
For IAM and PAM teams, the next step is to connect app-scoped access with lifecycle controls and review evidence. The access model is only as strong as its revocation path, and time-bound approvals matter more when vendors, admins, and internal users share the same remote access fabric.
For practitioners
- Map remote access to application scope, not network scope. Inventory every privileged remote path that still depends on VPN access or jump hosts, then redesign those paths so users open only the server, application, or portal they actually need. Remove broad network reach where the use case can be expressed as a task-scoped target.
- Enforce vaulted credential injection for privileged sessions. Require credentials to remain in the vault and be injected into the session, rather than exposed on the endpoint or reused across tools. Pair that with approval and expiry controls so privileged access is temporary and attributable.
- Group remote targets into governed collections. Use role-based collections for remote applications and private web apps so access reviews can be performed at the collection level instead of per ad hoc target. This makes recertification cleaner and reduces one-off exceptions that accumulate into privilege creep.
- Audit session termination and log completeness. Verify that session closure actually tears down active connections and that approvals, launches, and administrative actions are retained in searchable logs. If a session can outlive the browser flow, the governance model is incomplete.
Key takeaways
- Remote access should be governed as an application privilege, not as a network entitlement.
- App-scoped sessions reduce exposure only when vaulting, approvals, and audit are enforced together.
- Collections and time limits make remote access reviewable, but only if session closure actually ends the privilege.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Remote access depends on credential handling and scoped privilege. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access and approvals align with remote session governance. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust limits the reachable surface of remote sessions. |
Audit privileged session flows for excessive standing access and broker credentials only for approved tasks.
Key terms
- Privileged Remote Access: Privileged remote access is a controlled way to reach administrative systems, applications, or portals without exposing the broader network. It brokers the session through policy, identity, and audit controls so the user can perform a task while the organisation retains visibility and limits privilege.
- Zero Standing Privilege: Zero standing privilege means access is not kept permanently available. Privileges are granted only when needed, for a specific task, and then removed or allowed to expire. In remote access programmes, this reduces persistent admin exposure and makes approval, vaulting, and session closure part of one control chain.
- Identity Blast Radius: Identity blast radius is the amount of systems, data, or functionality a single identity can reach if its access is misused. It is a practical way to measure whether an access model is tightly scoped or overly broad. Smaller blast radius means fewer lateral movement opportunities and cleaner governance boundaries.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
This post draws on content published by Delinea: Open the application, not the network. Read the original.
Published by the NHIMG editorial team on 2025-12-11.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org