Third-party VPN access can turn a narrow support request into broad network reach. That raises lateral-movement risk, audit scope, and offboarding work.
A defensible model ties each vendor identity to one approved resource. It also requires a verified device or session, a maintenance window, and full activity records.
For Vendor/Contractor Access: VPN vs ZT Broker, VPN fits tightly controlled legacy use cases. A Zero Trust broker is safer for most modern systems. It grants time-bound access to one application or session, not the network.
Choose the control by resource type, vendor risk, lifecycle needs, and support effort.
Choose access by resource and vendor risk
A vendor should receive the smallest connection that completes the approved job. A virtual private network, or VPN, creates an encrypted path into a network.
That path can help with old systems. Still, it resembles giving a repair contractor the building entrance key. They may only need one locked equipment room.
A Zero Trust broker checks the person, device, requested resource, and policy. It then connects the vendor only to the approved app or session.
The vendor does not gain general network reach after passing multi-factor authentication. MFA proves a login event. It does not prove every reachable system is safe to access.
Start with the target resource
Browser-based private apps usually fit a broker well. SSH and RDP work often need privileged access management, called PAM.
PAM can store credentials, record sessions, and limit commands. Think of PAM as a key cabinet with a camera. It records who checked out the key and how they used it.
Databases, file shares, SaaS admin consoles, and industrial systems need separate designs. One control for every protocol may look simple on a diagram.
It can still leave gaps. Some protocols cannot support the policy you planned.
Score the access request
Score each request by privilege, data sensitivity, device trust, connection frequency, and misuse impact. A known vendor can still create high risk.
A contractor changing payroll settings from an unmanaged laptop is high risk. Their company name does not reduce that risk.
- Low risk: A named contractor needs a private web portal for 30 days from a device meeting policy.
- Medium risk: A support vendor needs RDP access during scheduled maintenance windows.
- High risk: A supplier needs production database or OT engineering access from an unmanaged endpoint.
Decision rule: Use a broker when access can target one named application or session. Use PAM or a bastion host when privileged protocols need recording or command control. Allow a segmented VPN only when a documented technical limit blocks those patterns.
Cost follows this split. An existing VPN may seem cheaper at first.
Its real cost includes firewall rules, account cleanup, incident review, help desk resets, and audit evidence. Those tasks grow with each external user.
For a startup with fewer than 10 external users, a hardened VPN can be sensible in the short term. This applies when one stable legacy system needs support.
For larger vendor groups, manual access work often costs more than the VPN license.
Remove broad VPN reach from vendor support
Vendor VPN accounts become dangerous when login access opens routes beyond the approved task. MFA verifies a login event. It does not stop host scans, lateral movement, or use outside approved hours.
The National Institute of Standards and Technology defines Zero Trust Architecture as removing trust based on network location. NIST Special Publication 800-207 supports resource-level access decisions.
An internal network should not become trusted space merely because a user entered through VPN.
Find hidden network exposure
Review VPN routes, split-tunnel rules, firewall objects, DNS visibility, and old support groups. A vendor may reach a subnet through a rule made years ago.
That rule may have supported one server. The business owner may not know it remains open.
The most common error is calling a vendor account temporary, then leaving it active indefinitely. Another common failure is sharing one account across vendor employees.
Both practices destroy accountability. The audit trail cannot identify the actual person.
Treat vendor devices as unknown
A contractor device may lack endpoint detection, current patches, encrypted storage, or a managed certificate. Device posture checks selected signals before access begins.
Those signals can include an endpoint agent, operating system version, and disk encryption. They are not a moral judgment about the supplier.
They are a risk check. Think of them as checking a technician's safety gear before factory entry.
For high-risk sessions, deny unmanaged devices or force an isolated browser or remote desktop. This limits what an unknown endpoint can reach.
Model the real attack paths
A compromised third party can enter through stolen credentials or malicious browser extensions. Shared passwords and breached supplier identity systems also create entry paths.
The Cybersecurity and Infrastructure Security Agency and the National Security Agency urge firms to reduce remote-access exposure. They also stress protection for identity systems.
One common case involves a software vendor with a shared VPN account. An employee passes it to a subcontractor.
When that subcontractor leaves, nobody removes access. Named identities, sponsor approval, and automatic expiry make this risk visible.
Define the zero trust broker correctly
A Zero Trust broker links a verified identity to one approved resource under policy. It decides before the connection reaches the target.
Think of it as a security desk. The desk checks the visitor, work order, room, time slot, and badge.
It then opens one door. It does not unlock the whole building.
This definition matters because a broker is not simply another name for Zero Trust Network Access, or ZTNA. ZTNA often describes a delivery pattern that uses a broker.
The broker can work with identity systems, device checks, PAM, SIEM tools, and policy points. A product name alone cannot fix weak approval rules.
| Control | Typical scope | Vendor use | Session evidence |
|---|
| VPN | Network routes | Legacy protocol access | Usually connection logs |
| ZTNA broker | Named app or service | Private web apps and supported clients | Policy and session events |
| PAM | Privileged session | SSH, RDP, database administration | Recording and command logs |
| Bastion host | Controlled jump point | Legacy administration | Depends on hardening |
| Reverse proxy | Inbound web traffic | Web publishing and inspection | HTTP-focused logs |
A reverse proxy handles web traffic and can inspect HTTP requests. A bastion host is a hardened jump system.
PAM manages privileged credentials and sessions. These controls can support a broker-led design.
None replaces the others in every case.
Use standards as a design test
NIST Special Publication 800-207A applies Zero Trust ideas to cloud-native systems. The Federal Zero Trust Strategy also guides stronger access controls.
That strategy followed Executive Order 14028. It covers identity, devices, networks, applications, and data.
These documents offer useful design tests for private U.S. firms. They help teams ask whether each control protects the actual resource.
John Kindervag introduced a core idea. Never trust a user merely because of network location.
Google BeyondCorp made identity-aware access more familiar. Cloudflare, Zscaler, Palo Alto Networks, and Okta can support this pattern.
Match the broker pattern to each system
The right third-party control depends on protocol and potential session harm. A browser app and an industrial controller both support remote access.
Their safety needs differ sharply. Treating them alike creates avoidable risk.
For private web apps, an identity-aware proxy can enforce single sign-on and phishing-resistant MFA. It can also check device posture and app-level rights.
For SaaS administration, use role-specific admin rights and step-up authentication. Keep admin accounts separate from normal email accounts.
Use PAM for SSH and RDP work
SSH and RDP give direct control of servers. Use just-in-time access, credential vaulting, and recorded sessions.
Where tools allow it, limit clipboard use and restrict commands. A just-in-time grant should last between 1 and 8 hours for normal support.
It should not last weeks. Short grants reduce exposure after work ends.
Over 12 years, I have seen a repeated pattern. Teams add MFA to vendor VPN access, yet cannot explain production server changes.
PAM closes that evidence gap. It records the administrative session and links it to one named person.
Handle data services with care
Database clients and file shares may not fit browser-based ZTNA paths. Use database roles, approved client paths, and query limits where available.
Use file-transfer scanning and download controls. Watermark remote desktops when screenshots or copied data create material risk.
A file transfer should face malware and sensitive-data checks before reaching production storage. That sounds simple, but large engineering files can break inspection.
Vendor tools can also fail during inspection. Test the full job flow before blocking transfers.
Isolate OT and ICS access
Operational technology, or OT, runs physical processes. Examples include manufacturing lines, utilities, and building controls.
Industrial control systems may depend on old protocols, fixed IP settings, or low latency. A poorly planned access change can affect safety or production.
OT access needs a separate risk review. Network reach that seems harmless in IT can disrupt physical equipment.
Third-party access path by resource
Private web app
ZTNA broker
SSO + posture
SSH or RDP
PAM + broker
Record session
Database or files
Protocol gateway
Inspect transfer
OT or ICS
Jump host
Window + review
Identity proofing → sponsor approval → time-bound policy → controlled session → SIEM evidence → automatic expiry
In one OT support case, I saw broad remote routing. The team reduced it to a named jump host and maintenance window.
The vendor could no longer reach adjacent engineering systems. Support continued through recorded sessions.
Govern the full third-party lifecycle
Secure vendor access starts with a business owner and ends with verified removal. Technology cannot fix accounts without sponsors, end dates, or resource records.
Each request should name the external person and vendor company. It should also name the internal sponsor and business purpose.
Include the target resource, privilege level, start date, and end date. The sponsor should confirm work remains necessary before renewal.
Procurement can share contract dates. System owners must approve technical access.
Make individual identity mandatory
Give each contractor an individual identity. Federated guest identity can work with suppliers that have mature identity controls.
Local external identities may be safer for smaller suppliers. Remove shared accounts unless an emergency system makes them unavoidable.
Identity proofing should occur before granting access. Do not wait for the first incident.
Require phishing-resistant authentication for privileged access. Challenge sessions when device or location risk changes.
Grant access only when needed
Just-in-time access means privilege exists only during an approved work window. Tie each grant to a service ticket or approved change record.
Automatic expiry should not depend on an administrator's memory. The system should remove access when the window ends.
Review high-risk entitlements every 30 to 90 days. The period depends on the system and contract.
Low-risk short engagements may need no review. Their access may end before a review cycle starts.
The useful measure is automatically revoked expired access. Counting review emails does not show real risk reduction.
Preserve evidence for investigations
Send authentication results and policy decisions to the SIEM. Also send session times, privilege changes, transfer events, and denials.
Good evidence answers four questions. Who connected, what they reached, how long they stayed, and what approval allowed it.
For regulated firms, this supports FedRAMP and common audit expectations. Recording and monitoring must follow contracts, privacy notices, labor rules, and state law.
Tell vendors before recording sessions. Limit who can access recordings.
Control sessions and migrate in phases
Replacing vendor VPN access without ownership and expiry moves the same risk elsewhere. Start with access discovery, then move resource groups in order.
First, list vendor accounts, VPN groups, firewall rules, systems, protocols, sponsors, and contract end dates. Flag dormant accounts, generic accounts, unknown owners, and broad routes.
This list creates a baseline for risk reduction and return on investment. It also reveals which access paths have no business owner.
Apply controls after login
High-risk sessions need more than MFA. Record privileged SSH and RDP activity where lawful.
Restrict port forwarding, scan file transfers, limit clipboard use, and watermark sensitive remote desktops. These controls resemble supervised key checkout.
They document use and limit what can leave the room. They also help investigators reconstruct a risky session.
Do not record everything blindly. Start with production administration, regulated data, OT systems, and SaaS super-admin roles.
Searchable recordings and structured logs can cut investigation time. Complete evidence can reduce work from days to between a few hours and one business day.
Run a controlled hybrid period
Pilot broker access with private web apps and SaaS admin work. Include standard support sessions with known owners.
Keep a reduced VPN path for unsupported legacy workflows. Remove broad routes and tie every exception to a ticket and time limit.
Many guides omit one operational problem. A vendor may need a laptop, legacy client, and emergency support method that same week.
Test all three paths with the vendor before retiring VPN. A broker that blocks an urgent patch window loses trust quickly.
Measure exposure, not migration volume
Track removed permanent vendor accounts and median time for approved access. Track automatically expired access and recorded privileged sessions.
Also track removed network segments and investigation time. These measures show risk and labor reduction better than migrated VPN users.
A practical target removes between 70% and 90% of standing vendor access. Focus on systems that support identity-aware or PAM-controlled access.
If you miss that target, inspect the exception list. It may show real legacy limits or weak system ownership.
A Zero Trust broker is not the immediate replacement when vendors support legacy OT or ICS equipment. It may also fail with latency-sensitive protocols or systems lacking modern identity controls. Use segmented VPN with PAM or a hardened bastion host. Set strict time limits, monitoring, and a phased modernization plan. Do not make an exception permanent without an owner and review date.
In cloud and hybrid environments, the access path matters as much as policy. A VPN concentrator may send traffic through a central data center.
That can add latency before traffic reaches a cloud workload. It can also create a bottleneck during maintenance windows.
A broker can place connectors near private apps or cloud workloads. It should publish only the required service.
The design still needs redundant connectors, tested failover, and clear DNS routing. Test real workflows before declaring migration complete.
Test large diagnostic uploads, RDP screen refreshes, SSH automation, and cross-region support. An approved vendor who cannot connect will seek an unapproved workaround.
Questions & answers
Should vendors keep using VPN access?
Vendors should keep VPN access only for documented legacy or protocol limits. Segment it to required systems, add PAM or a bastion host, and set strict expiry.
Is a zero trust broker enough for RDP access?
A broker alone is often not enough for high-risk RDP access. Add PAM when you need recordings, credential vaulting, or controls during sessions.
How long should contractor access last?
Normal support access should last between 1 and 8 hours. High-risk entitlements should be reviewed every 30 to 90 days when longer access is unavoidable.
What evidence should auditors expect for vendor access?
Auditors should see a named identity, sponsor approval, target resource, access window, and session records. The evidence should show who connected and what policy allowed access.
Choose the narrowest path with provable control
Use a Zero Trust broker for private web apps and supported client services. Pair it with PAM for SSH, RDP, and other privileged work.
Keep segmented VPN only for documented exceptions. Give every exception an owner, time limit, monitoring plan, and modernization date.
The strongest business case is measurable. Remove standing access, reduce reachable network segments, and cut investigation time with complete evidence.
Further reading
If you want to learn more about this topic, these sources may interest you:
