BLOG

By David Chernitzky, Co-Founder and CEO, Armour Cybersecurity  |  Serving organizations across Canada, the US, and beyond  |  Last updated August 20, 2026

Quick answer: Remote access to corporate networks and OT environments has multiplied over the past several years and has rarely been rationalized after the fact. Most organizations have multiple VPN solutions deployed by different business units, vendor-specific remote access tools for each major vendor relationship, and direct remote desktop exposure on servers that was intended to be temporary. Each of these pathways is a potential entry point for an attacker who compromises the associated credentials or exploits a vulnerability in the remote access software itself. A remote access security review inventories every pathway, evaluates the controls applied to each, and produces a consolidated, defensible architecture that the organization can actually monitor and govern.

Key Takeaways

• Most organizations cannot enumerate all of their remote access pathways. Multiple VPN solutions, vendor-specific tools, direct RDP exposure, cloud-based access platforms, and legacy dial-up or cellular connections deployed before current standards existed have accumulated without a comprehensive inventory. An attacker does not need to find the most secure pathway into the network; they need to find any pathway.
• Vendor remote access is the most undercontrolled category of remote access in most organizations. Employee VPN access is typically managed through the IT team with consistent standards for MFA, logging, and session controls. Vendor access is often managed by the business unit that owns the vendor relationship, using whatever access method the vendor requires, with inconsistent security controls and no systematic review of whether the access is still needed or appropriately scoped.
• MFA is the single highest-impact control for remote access security. The majority of remote access-based breaches involve compromised credentials: a username and password obtained through phishing, credential stuffing, or purchase from criminal marketplaces. MFA prevents compromised credentials from being used for remote access without the attacker also having access to the second factor. Organizations that enforce MFA across all remote access pathways are significantly more resistant to credential-based remote access attacks than those that do not.
• Session logging is the detective control that makes remote access governable. Without logs that record who accessed what through which remote access pathway during each session, the organization cannot investigate a suspected compromise, cannot demonstrate to auditors that access was appropriate, and cannot identify vendor sessions that exceeded their authorized scope. Session logs at minimum should capture the source IP, the authenticated identity, the duration of the session, and the systems accessed.
• Remote access security is directly connected to network segmentation. A VPN connection that places the remote user or vendor directly into the corporate network without any restriction on what they can reach from that position gives the attacker who compromises those credentials unrestricted lateral movement. Remote access architecture should place remote connections into a restricted zone that enforces least-privilege access to only the specific systems the remote user or vendor needs to reach.

The Remote Access Inventory Problem

Remote access infrastructure accumulates over time because different business units, IT teams, and operational groups make independent decisions about how to enable the access they need. The corporate IT team deploys a VPN solution for employee remote work. A business unit that needs a specific application deploys its own cloud-based access platform because the corporate VPN has latency issues. The OT team deploys vendor-specific remote access solutions because the major equipment vendors require their own tools for maintenance access. A server administrator exposes RDP on a specific server to allow emergency access during an incident and never closes the exposure after the incident is resolved. Each of these decisions is made in isolation, documented inconsistently, and never rationalized against a comprehensive remote access policy.

The result is a remote access landscape that the organization cannot fully describe. The IT team knows about the corporate VPN but may not know about the business unit platform. The OT team knows about the vendor tools but may not have documented all the vendor relationships that have active access. The server administrator who exposed RDP may have left the organization. An attacker who discovers any one of these pathways and compromises the associated credentials has access to the network without needing to exploit a vulnerability in a network device or application. This is the same undocumented sprawl that a network architecture review is built to surface, and remote access is consistently one of the largest categories of hidden pathways it finds.

What Secure Remote Access Architecture Requires

Comprehensive inventory as the starting point

Securing remote access begins with knowing what remote access pathways exist. A remote access inventory documents every pathway through which external parties can reach the internal network or OT environment: VPN solutions (corporate and business unit), cloud-based access platforms, direct RDP or SSH exposure on internet-facing systems, vendor-specific remote access tools, web application portals that provide access to internal systems, and any legacy pathways such as dial-up or cellular connections that may still be active from earlier technology generations. The inventory includes who has access through each pathway, what they can reach, what authentication is required, and when the access was last reviewed.

Most organizations discover during the inventory process that they have more remote access pathways than they knew about. This is not a failure of the IT team; it is the expected result of years of access being enabled by different groups for different purposes without a systematic registry. The inventory is the prerequisite for rationalization: determining which pathways are still needed, which can be consolidated into the standard corporate solution, and which can be decommissioned because the use case they were created for no longer exists.

MFA enforcement across all pathways

Multi-factor authentication (MFA) is the most impactful single control for remote access security. It prevents compromised username and password credentials from being used for remote access without the attacker also having access to the MFA second factor, which in most implementations is a time-based one-time password generated by an authenticator app or delivered by push notification to a registered device. The attacker who has a compromised credential from a phishing campaign or a credential dump is stopped at the MFA prompt because they do not have the second factor.

MFA enforcement is not universal even in organizations that have deployed MFA solutions. Employee VPN access may enforce MFA while vendor access through a separate tool does not. A cloud-based access platform deployed by a business unit may use weaker MFA (SMS-based codes that are vulnerable to SIM swapping) while the corporate VPN uses an authenticator app. Legacy remote access pathways may not support modern MFA methods at all. A remote access security review identifies every pathway where MFA is not enforced or where the MFA implementation is weaker than the organization’s security standard and produces a remediation plan for achieving consistent MFA coverage.

Session logging and monitoring

Session logging records what happens during each remote access session: who authenticated, from which source IP, through which pathway, at what time, for how long, and what systems they accessed or commands they executed. For employee VPN access, session logs are typically retained by the VPN solution and the systems accessed. For vendor remote access, session logging requires deliberate configuration: vendor tools may not log sessions by default, and the organization may need to deploy a privileged access workstation (PAW) or session recording solution that captures vendor sessions regardless of the tool the vendor uses.

Session monitoring adds a detective layer on top of session logging. Monitoring that alerts on sessions outside normal business hours, sessions that access systems beyond the vendor’s typical scope, sessions from unusual geographic locations, and sessions that generate unusually high data volumes provides early warning of compromised vendor credentials being used for unauthorized access. This monitoring is not possible without the session logs that record the activity; the log collection and the monitoring capability must be designed together.

Least-privilege access zones for remote connections

VPN architecture that places remote users directly into the full corporate network gives a compromised remote access credential unrestricted lateral movement. A more secure architecture places remote connections into a restricted zone that allows access only to the specific systems the remote user needs to reach, enforced by firewall rules that permit traffic from the remote access zone to specific destinations rather than to the entire internal network. Employee VPN access is restricted to the systems the employee needs for their job function. Vendor access is restricted to the specific systems the vendor supports and the specific protocols required for that support. This is network segmentation applied to remote connections: the remote access zone is just another segment whose boundary has to be designed and enforced.

For OT vendor access, this architecture is particularly important. A vendor who needs remote access to a specific PLC for maintenance should reach that PLC through a jump host in the OT DMZ, not through a VPN tunnel that places them on the corporate IT network from which they could potentially reach any system the IT/OT boundary permits. The jump host is the only system the vendor can access from their VPN connection; from the jump host, they can access only the specific OT systems their session is authorized for; and the jump host records everything that happens during the session. The stricter controls that OT and ICS environments require apply directly to vendor remote access into those environments.

Armour Cybersecurity reviews and redesigns remote access architecture as part of its network protection engagement, producing a consolidated, least-privilege remote access design that the organization can implement and govern.

Frequently Asked Questions

Is a VPN sufficient for secure remote access?

A VPN is a transport security mechanism: it encrypts the traffic between the remote user and the corporate network. It is not, by itself, a complete remote access security solution. The security of a VPN-based remote access architecture depends on the authentication controls applied to VPN connections (whether MFA is enforced), the network access controls that govern what a connected user can reach from the VPN (whether the connection places them in a restricted zone or the full corporate network), the logging and monitoring of VPN sessions, the patch management of the VPN infrastructure itself, and the governance of who has VPN access and whether that access is reviewed and revoked when it is no longer needed. A VPN with strong authentication, least-privilege network access, comprehensive logging, and regular credential and access review is a strong remote access control. A VPN with weak authentication, broad network access, minimal logging, and no credential review is a pathway an attacker can walk through with compromised credentials.

What happened in the Colonial Pipeline attack and what does it mean for remote access security?

The Colonial Pipeline ransomware attack in May 2021 led to a six-day precautionary shutdown of a major US fuel pipeline serving the East Coast, resulting in fuel shortages and a ransom payment of approximately $4.4 million. The initial access vector, according to the investigation, was a compromised VPN account: an attacker used a leaked username and password to authenticate to a legacy VPN profile that was not in active use but had not been decommissioned. MFA was not enabled on that VPN profile. The attacker used this access to deploy DarkSide ransomware that encrypted Colonial Pipeline’s corporate IT systems. The OT pipeline operations were not directly infected; the company proactively shut them down as a precaution because it could not be certain the ransomware would not spread. The incident illustrates the combined risk of undecommissioned remote access credentials, absent MFA enforcement on legacy remote access pathways, and inadequate network segmentation and visibility between IT and OT environments.

How do we govern vendor remote access without creating operational friction?

Vendor remote access governance does not require vendors to use inconvenient tools or accept degraded access compared to what they currently have. It requires that the access be inventoried, authenticated consistently with MFA, logged comprehensively, restricted to the systems the vendor actually needs to reach, and reviewed periodically to confirm it is still needed. Most major vendors already support MFA authentication and can work with a jump host architecture that provides equivalent access capability with better logging and access control than their previous direct VPN pathway. The friction in transitioning vendors to a more controlled access model typically comes from the internal process of identifying all vendor relationships, getting vendor cooperation in updating their access methods, and establishing the review and approval process for access requests. A structured vendor access registry with defined onboarding and offboarding procedures manages this process without creating ongoing operational friction.

What controls should we require for vendors who access OT systems?

Vendors who access OT systems require a higher standard of access control than vendors who access IT systems, because the consequences of a compromised vendor credential reaching an OT environment include potential operational disruption and safety risk. The minimum control set for OT vendor access includes: a dedicated vendor access zone separate from both the IT network and the OT environment, with a jump host that provides proxied access to OT systems; MFA authentication for access to the vendor access zone; session recording that captures every command or action taken during the session; time-limited access that is enabled when the maintenance session begins and disabled when it ends, rather than persistent always-on access; restriction to the specific OT systems the vendor is authorized to access; and a pre-access approval process that requires the OT operations team to authorize each vendor session before it begins. These controls are more stringent than typical IT vendor access controls, which is appropriate given the higher consequences of an OT security incident.

How often should we audit who has remote access to our systems?

Remote access credentials and permissions should be reviewed at minimum quarterly and immediately following any personnel change, vendor contract change, or project completion that changes who needs access. Quarterly reviews catch access that has accumulated beyond its intended scope, credentials for former employees or vendors that were not revoked during offboarding, and access pathways that are no longer in use but remain active. The review should compare the current list of active credentials and permissions against the current list of personnel and vendor relationships with active needs, revoking any access that does not have a current business justification. Immediate review triggered by personnel or vendor changes catches the highest-risk access overhang: a former employee’s VPN credentials or a vendor whose contract has ended both represent access that should be revoked the day the relationship ends, not at the next quarterly review cycle.

The Bottom Line

Remote access is the pathway attackers reach for first, because they do not need the most secure door, only any door that is unlocked. In most organizations there are more doors than anyone has counted: multiple VPNs, per-vendor tools, forgotten RDP exposures, and legacy profiles that were never decommissioned. Colonial Pipeline is the reference case, an inactive VPN account with no MFA, and it shut down a national fuel pipeline. Securing remote access is a sequence: inventory every pathway, enforce MFA everywhere without exception, log and monitor every session, and place every remote connection into a least-privilege zone rather than the full network, with OT vendor access held to the higher standard of a jump host, session recording, time-limited access, and per-session approval. Vendor access deserves the same scrutiny as employee access, and usually more, because it is the least governed. Armour Cybersecurity inventories, rationalizes, and redesigns remote access as part of its network protection engagement, producing a consolidated architecture the organization can actually monitor and govern.