How should security teams implement just-in-time access for third-party users without relying on VPNs?

Security teams should gate third-party access through identity-based policies that grant only the minimum resources needed for a defined time window. Use strong authentication, session controls, monitoring, and audit trails so access is temporary, traceable, and revocable. The goal is to reduce standing privilege while preserving contractor productivity and limiting exposure to sensitive systems.

Why This Matters for Security Teams

Just-in-time access for third-party users is not a convenience feature. It is a control to replace standing privilege with time-bound, identity-bound access that can be reviewed and revoked. For contractors, vendors, and support partners, VPN access often creates broader network reach than the task requires, which makes blast radius hard to predict and audit after the fact. NHI Management Group research shows that 92% of organisations expose NHIs to third parties, which makes external access governance a supply chain issue as much as an identity issue, as discussed in the Ultimate Guide to NHIs.

The core mistake is treating third-party users like internal staff who need persistent network presence. Current guidance instead favors identity-first access with strong authentication, session scoping, and policy enforcement at the application or resource layer, not the perimeter. That approach aligns with the direction of the OWASP Non-Human Identity Top 10 and NIST control expectations for least privilege and account management. In practice, many teams discover their VPN-based contractor model only after a vendor account is reused, overextended, or left active long after the original job ended.

How It Works in Practice

A practical JIT model starts with identity proofing and strong authentication for the third party, then binds access to a specific request, approval, and time window. Rather than granting network access, the organisation issues narrowly scoped entitlements to a defined application, dataset, or admin action. The session should expire automatically, with re-authentication or re-approval required for extension. This is a better fit than a VPN because the access decision is made at the resource boundary, not by placing the user inside the network.

At implementation level, teams typically combine several controls:

• identity federation with conditional access and multifactor authentication
• workflow-based approval for sensitive resources
• time-limited privileges with automatic revocation
• session recording, command logging, and anomaly monitoring
• device posture checks where the risk justifies them
• separate contractor roles that map to task-based access rather than broad job titles

Where possible, use policy engines and centralized entitlement workflows so access is evaluated at request time instead of being pre-assigned. That is consistent with the control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially for access enforcement, auditing, and account lifecycle governance. For teams handling third-party exposure at scale, the visibility issues described in The State of Non-Human Identity Security are a warning sign: if an organisation cannot see who is connected, it cannot safely time-limit what they can do. These controls tend to break down when contractors need broad interactive troubleshooting across legacy systems because the resources were never designed for application-level entitlement boundaries.

Common Variations and Edge Cases

Tighter just-in-time access often increases operational overhead, requiring organisations to balance speed for vendors against stronger control over exposure. That tradeoff becomes especially visible in emergency support, managed services, and legacy environments where direct application-level controls are limited. Best practice is evolving, but there is no universal standard for every contractor scenario yet.

For high-risk access, some organisations replace VPNs with privileged access management portals, ephemeral bastion sessions, or zero trust gateways that proxy only the approved application. Others use short-lived credentials or token exchange rather than standing accounts. The right choice depends on whether the third party needs interactive administration, read-only access, or a single workflow action. If the task is predictable, JIT can be highly granular; if it is open-ended troubleshooting, the approval model must be tighter and monitoring more aggressive.

Watch for edge cases such as shared vendor accounts, break-glass usage, and integrations that depend on static API keys. Those patterns weaken revocation and attribution. The broader lesson from 52 NHI Breaches Analysis is that delayed detection and weak lifecycle control often matter more than the initial grant. Security teams should treat each exception as temporary, documented, and separately reviewed, because third-party access models fail fastest when convenience quietly becomes permanence.

Related resources from NHI Mgmt Group

• How should security teams manage privileged access for vendors and remote users without relying on VPN access?
• How should security teams implement just-in-time access for databases in environments with shared administrative workflows?
• How should security teams implement just-in-time access without leaving standing privilege behind?
• How should security teams implement automated third-party risk mitigation without losing governance control?