In any complex enterprise environment, dozens of third-party vendors have access to your systems on a regular basis — hardware maintenance engineers, software support teams, managed service providers, system integrators. Most organizations have policies governing this access. Far fewer have technical controls that actually enforce those policies and produce an audit trail that would hold up to scrutiny.
The gap between the policy ("vendors may only access designated systems during authorized maintenance windows with a company escort") and the technical reality (vendor VPN credentials that work 24/7 and have never been revoked from engineers who left the vendor two years ago) is where risk lives.
The Problem with VPN-Based Vendor Access
Traditional vendor access via VPN has several fundamental weaknesses:
- Overly broad access: A VPN connection typically provides access to an entire network segment, not just the specific systems the vendor needs
- Persistent credentials: VPN credentials are created for a project and rarely revoked promptly when the project ends or the vendor employee leaves
- No session visibility: You know a VPN was connected. You don't know what systems were accessed, what commands were run, or what data was viewed
- No approval workflow: Access happens without a request/approval cycle, so there's no record of why a vendor accessed a system on a given day
The Bastion Host Architecture
A Bastion Host (also called a jump server or privileged access workstation) sits between external users and internal systems. All third-party access flows through it. The architecture creates a single, monitored, controlled access path.
The core components we implemented:
Session recording
Every session — RDP and SSH — is recorded in full. Screen capture for RDP, keystroke logging for SSH. Sessions are stored with a retention period aligned to our audit requirements. When an auditor asks "what did this vendor do on this system on this date," the answer is a recording, not a recollection.
Just-in-time access provisioning
Vendors don't have persistent access credentials. When a maintenance window is scheduled, a request is raised in the access management system. After approval, time-limited credentials are provisioned — valid for the duration of the maintenance window only. When the window expires, the credentials are automatically revoked. No manual cleanup required.
System-specific access control
Access through the Bastion is scoped to specific target systems. The network virtualization vendor can reach the vSphere management interface. They cannot reach the backup systems, the SIEM, or anything else. Network segmentation enforces this at the infrastructure level — not just in the Bastion's access policy.
MFA for all external access
Every vendor session requires MFA. The MFA token is delivered to the vendor's registered device. This prevents credential sharing and ensures that only the authorized individual is connecting — not a colleague using the approved engineer's credentials.
"You cannot manage what you cannot see. Before the Bastion deployment, we had policies about vendor access. After it, we had visibility into vendor access."
What We Caught in the First Month
The first thirty days of operation were instructive. Session recordings and real-time monitoring revealed:
- Three instances of vendor engineers accessing systems outside their authorized maintenance windows
- One case of a vendor connecting from a different country than the approved engineer's registered location — investigated and found to be a colleague using credentials, not a breach
- Two vendors with access that had not been used in over six months and had no associated active contracts — access revoked
None of these would have been visible under the previous VPN-based model.
Operational Considerations
Availability requirements
The Bastion becomes a critical component in your infrastructure: if it's unavailable, vendors can't perform maintenance. High availability deployment — at minimum active/passive — is non-negotiable. We deployed dual Bastion hosts across separate availability zones with automatic failover.
Internal privileged access
The same architecture that governs vendor access can govern internal privileged access. Domain admins, database administrators, and infrastructure engineers accessing production systems through the Bastion provides the same session recording and access control for internal privileged accounts. This is a natural extension that most organizations implement in a second phase.
Integration with SIEM
Bastion session logs should feed into the SIEM. Access outside approved windows, access to unauthorized systems, sessions running longer than typical for the vendor role — these are correlations that the SIEM can alert on automatically.
Key Takeaways
- VPN-based vendor access provides no visibility and minimal control — it's a starting point, not a solution
- Session recording is the audit capability that justifies the implementation to auditors and regulators
- Just-in-time access provisioning eliminates persistent credentials — implement it from day one
- Network segmentation must enforce access scoping; Bastion policy alone is insufficient
- Feed Bastion logs into the SIEM for automated anomaly detection on vendor sessions