Reading time: 10 minutes
Companies increasingly rely on external parties for essential services, including work that requires access to their network. That can mean creating user accounts for vendor personnel to connect directly to your assets to provide support and maintenance. It can also mean providing privileged access to your network directly to vendor software, hardware, or systems, which comes with the software supply chain risk inherent to connecting to or using third-party systems. Here we’ll focus primarily on providing user access, but both are important to consider for security.
So, how do you set strong vendor remote access policies and enable access in a secure way?
What You’ll Learn
- The core best practices for securing vendor remote access, including least privilege and MFA
- Why VPNs and jump servers create long-term management and security risk
- How Zero Trust, RPAM, and privileged remote access are replacing legacy vendor access methods
- What to look for in a pre-built vendor remote access solution
- OT-specific considerations for vendors connecting to industrial systems
Jump to a Topic
- Vendor Remote Access Best Practices
- Build Secure Remote Access Infrastructure Yourself
- VPN Risks
- Applying Zero Trust Principles to Remote Access
- From Vendor Remote Access to Privileged Remote Access
- Pre-Built Vendor Remote Access Solutions: Why?
- Specific Considerations for OT and Industrial Infrastructure
- Key Takeaways
How Xage secures vendor remote access without VPNs or jump servers
0:00 The Problem: Shared Passwords and Spreadsheet Credentials
1:26 Just-in-Time Access Requests for Vendor Contractors
2:00 Granular Approval Controls for Privileged Access
2:57 Automatic Credential Rotation and Account Disabling
3:59 Session Recording and Controlled Collaboration
Vendor Remote Access Best Practices
Securing vendor remote access starts with least privilege, multi-factor authentication (MFA), and session-level auditing. Vendors should only reach the specific systems they support, never the full network, and every session should be recorded and revocable. Combining these controls with consistent policy across cloud, IT, and OT environments closes the gaps legacy remote access tools leave open.
Enforce Least-Privilege Access Control for Third-Party Users
Cyber attackers often compromise privileged accounts to expand their access in a target environment. This risk increases as more third parties are granted privileged access to business-critical systems. Enabling remote access for third-party vendors while still enforcing the principle of least privilege is a crucial cybersecurity control for your remote access strategy.
Preserve Security Layers Across Cloud, IT, and OT
Be wary of any remote access solution that exposes vulnerable protocols or sensitive resources directly to the internet. Your remote access solution should preserve logical segmentation while enabling secure traversal of multiple network or security layers. This includes utilizing a multi-hop architecture that provides session and protocol termination, and multifactor authentication (MFA) challenges as an option at each layer without added complexity or friction for the remote user.
Require MFA
This one could probably go without saying, but MFA should be required for any vendor or third party connecting to your systems. As noted, having multiple layers of MFA is a strong option to have available, especially for particularly sensitive data or systems.
In-Depth Auditing or Session Recording
Your setup should take an identity-aware approach to activity logging, auditing, and session tracing, even if the participating workloads or devices have distinct identity providers or lack unique user accounts entirely. Ideally you have the capability for over-the-shoulder monitoring of remote sessions and instant revocation of privileges or session termination by an administrator if unacceptable behavior is observed.
Ensure a Unified System for Cloud, Datacenter, and Operational Environments
Managing access and protecting apps and workloads across public and private cloud deployments introduces new challenges. Many organizations face ballooning access management difficulties such as the use of high-risk VPNs, shared service accounts, and the inability to enforce consistent policies across multi-cloud environments.
The challenges grow as companies adopt new software while still relying on legacy private applications and even proprietary desktop apps that now need to be used remotely for business critical tasks. For vendors (and employees) you want a unified way to enable remote access to diverse environments so you don’t end up stitching together multiple solutions.
Build Vendor Remote Access Infrastructure Yourself
Building vendor remote access yourself is possible using a VPN connected to an isolated subnet or industrial jump servers, but both approaches require heavy manual maintenance. Firewall rules, ACLs, and credential rotation must be managed by hand, and gaps in that upkeep are what let a single compromised vendor account reach sensitive systems, as happened in the 2013 Target breach.
There are limitations to building this out yourself, and a lot of capable tools you can buy instead of reinventing the wheel. That said, if you want to build rather than buy, there are a few possible approaches.
Connect a VPN to a Subnet
You can provide a dedicated VPN for vendors which connects to a subnet. If you have multiple vendor staff or contractors each can be assigned their own VM within the subnet. Using firewall rules, ACLs or security groups to ensure that the VM can only access the specific system that vendor will need access to and nothing more—following the zero trust principles of least privilege.
- Make sure routing is disabled so the subnet is actually isolated and not able to connect to other parts of the network.
- Monitor activity using audit logs or, better yet, session recording.
It’s critical that you carefully inventory ACLs, firewall configurations, and other settings to ensure that there are no vectors connecting vendor-accessible systems to other, more sensitive parts of your network to buffer against the very real risk of a third party being compromised. Depending on the complexity of your infrastructure, this can become challenging to manage and secure.
As Target discovered back in 2013, it’s easy to make a mistake. When a hacker obtained login credentials for Target’s HVAC vendor, they were able to use them to access their payment systems. It highlights the importance (and difficulty) of carefully isolating extremely sensitive data like customer payment information from vendor access. Tools like ZTNA can enable the needed access without the manual effort of updating firewall rules or ACLs..
Jump Servers
In the industrial world, using jump servers is a common tactic to avoid direct internet connectivity to OT assets. These proxies can help strengthen security despite weak protocols and also regulate the network traffic entering OT environments, PLCs and other industrial control devices are extremely likely to be running old and potentially vulnerable software.
Users access these operational systems remotely and indirectly by connecting to a jump server via VPN. However, this setup poses substantial management challenges. Each remote user requires a dedicated account on the jump server, leading to the accumulation of hundreds or even thousands of accounts. These accounts often become obsolete quickly—especially those of temporary or former employees—but are rarely deactivated.
Additionally, valid credentials are needed to access critical operational assets like PLCs through the jump servers. These credentials should be rotated regularly, which can be an uphill task involving manual work. Note that the accumulation of dormant or infrequently used accounts makes jump servers a common target for cyber attacks. Attackers attempt to gain broad access to OT systems. Moreover, these jump servers often operate on outdated Windows software, lacking the latest security patches.
VPN Risks
VPNs are inherently risky and are rapidly being replaced with more secure VPN replacement solutions like ZTNA and platforms combining access, PAM, RPAM, and microsegmentation capabilities.” VPNs provide users with legitimate credentials wide and unchecked network access. This makes them prime targets for cyber attackers who often exploit compromised credentials—one of the most common methods for initiating data breaches. According to the 2023 Verizon Cost of a Data Breach Report, stolen credentials were involved in 49% of all reported breaches.
Moreover, the underlying technology of many VPNs, often based on outdated legacy systems, contains numerous vulnerabilities. For example, in the case of the Ivanti VPN, researchers found that it was using open-source code that hadn’t been updated for over two decades.
From Vendor Remote Access to Privileged Remote Access
Vendor remote access and privileged remote access address the same underlying problem: third parties need access without standing, unmonitored privileges. Privileged remote access management (RPAM) applies PAM controls, least privilege, session recording, and credential rotation, specifically to remote vendor and contractor connections, extending Zero Trust from network access into the identity layer.
Zero standing privilege is the practice of removing persistent, always-on access rights and replacing them with access that is granted only when needed and automatically revoked afterward. Gartner analyst Michael Kelley frames this as a core PAM priority: the existence of privileged access carries significant risk, and even with PAM tools in place, the residual risk of users with standing privileges remains high, which is why security and risk management leaders engaged in IAM need a zero standing privileges strategy through a just-in-time model.
Xage Extended Privileged Access Management (XPAM), launched in November 2024, extends this approach to OT users, applications, and assets alongside IT and cloud, closing the same gaps in vendor remote access described above. For vendor and third-party connections specifically, that means just-in-time access instead of standing VPN credentials, session recording, and automatic credential rotation on every session. See how Xage vendor access management and Xage Extended Privileged Access Management (XPAM) apply these controls together.
Applying Zero Trust Principles to Remote Access
Part of the issue with VPNs is they were designed with convenience in mind, not as security tools. Now, zero trust principles are being applied both to local access and remote access. If a device or user on the network must frequently verify its validity, then a remote connection should be treated with as much or more caution. But there’s a lag in adoption because key zero trust principles like least privilege and microsegmentation aren’t built into traditional remote access tools.
That’s changing with the growth of RPAM and universal ZTNA solutions. There are now higher expectations for solutions that provide vendor privileged access management (PAM) for remote third-parties that is as secure as the means of controlling access locally.
Pre-Built Vendor Remote Access Solutions: Why?
Managing firewall rules can quickly spiral into unmanageable territory, leaving gaps in controls that can become a security risk. Solutions like RPAM and ZTNA are built for easy scalability. Further, a good solution will have built-in capabilities for MFA, JIT privileged access control, and easy centralized management that might not be possible or feasible to build in-house.
A good vendor solution will also have important monitoring features like session recording that make it easy to see exactly what a vendor has done in case of an accidental (or malicious) disruption of your systems.
Often, the same solution your employees use for remote access will be a tempting choice for enabling vendor remote access. This can work, but there are some specific features that are extra important for a solution you’re using it to grant outsiders access:
- Automatic timed account deactivation: When you’re granting temporary access to someone outside the organization, you don’t want to have to remember to manually deactivate the account when they’re done.
- Automatic password rotation: Many data breaches start with the attacker logging in using a legitimate username and password that was leaked somehow. Password rotation prevents your third party vendors from leaking usernames and passwords that come back to haunt you.
- Rapid account provisioning and deprovisioning: When you bring in a vendor to handle a problem, you probably want it to go as quickly as possible. If you have to involve multiple teams to update firewall rules and ACLs just to let a vendor in, you lose agility. The ability to quickly create and destroy accounts with zero trust policies attached is a must.
Specific Consideration for OT and Industrial Infrastructure
OT systems use protocols designed originally for closed and separated environments which aren’t secure enough for more interconnected or internet-connected networks. Many industrial protocols (like Modbus and DNP3) weren’t designed for security, leaving them at risk for exploitation by malicious users connected through a VPN. The same dangers exist due to weaknesses in remote protocols (like RDP or SMB) frequently encapsulated in VPN tunnels.
Ransomware attacks such as BlackCat, recently used against several Western European oil terminals, exploit these weak protocols as initial attack vectors into high-value, target-rich OT environments. Firewalls and other network boundaries may help mitigate this exposure. However, these cyber threats can spread unchecked once on the inside through a VPN connection. Industrial organizations must adhere to even higher security standards for their OT remote access.
Key Takeaways
- Least privilege, MFA, and session recording are non-negotiable for any vendor remote access setup
- VPNs and jump servers grant broad, hard-to-audit access and create long-term account and credential sprawl
- Zero Trust principles, including microsegmentation, are increasingly applied to remote as well as local access
- RPAM and privileged remote access extend PAM controls, including zero standing privilege, to vendor and third-party connections
- Pre-built RPAM/ZTNA solutions reduce the operational burden of firewall rules, credential rotation, and account provisioning
- OT environments carry additional risk because legacy protocols were never designed for remote or internet-facing access
Secure Vendor Remote Access with Xage
Xage provides secure remote access while controlling every interaction and session to prevent credential abuse and insider threats, with MFA, least privilege, and more built in.
Frequently Asked Questions
What is vendor remote access?
Vendor remote access is the set of policies and tools that let external vendors, contractors, or third parties connect to an organization’s systems to provide support or maintenance. Secure vendor remote access enforces least privilege, MFA, and session recording so vendor connections do not become an unmonitored path into the network.
What is privileged remote access, and how is it different from vendor remote access?
Privileged remote access applies PAM controls, such as just-in-time access and credential rotation, specifically to remote connections that reach privileged systems or accounts. Vendor remote access is the broader category of any third-party connection; privileged remote access (RPAM) is the subset focused on protecting the highest-risk, privileged access within those connections.
How does RPAM reduce vendor remote access risk?
RPAM (remote privileged access management) removes standing VPN credentials and replaces them with just-in-time access scoped to a specific system and session. It adds layered MFA, full session recording, and automatic credential rotation, so a compromised vendor account cannot be reused for broad or repeated access.
What is zero standing privilege in vendor access?
Zero standing privilege means a vendor account has no persistent access rights between sessions. Access is granted only when a task requires it and is automatically revoked afterward, which removes the always-on credentials that attackers most often target in vendor and third-party breaches.



