A stolen VPN password. An exposed RDP port. A cloud portal with single-factor login. These are the three most common entry points for remote access breaches. Multi-Factor Authentication (MFA) closes all three by requiring a second verification factor that an attacker cannot steal remotely. Understanding how to deploy MFA well across each path, and where MFA alone is not enough, can significantly improve your security posture.
Why remote access needs MFA
Remote access gave businesses flexibility, and it gave attackers a front door. Most intrusions still start with a working password, stolen, phished, or reused, and a single factor is all that stands between that password and your network. MFA changes the math: an attacker who has the password still cannot get in without the second factor, which is exactly the part they cannot grab from a phishing page or a credential dump.
CISA is explicit that phishing-resistant MFA is the gold standard and that any MFA beats none, because it stops the credential-replay attacks behind most intrusions (CISA, Multifactor Authentication). That matters more in operational technology (OT) than almost anywhere else: a single reused credential can bridge a corporate inbox to a control-system workstation, and from there the blast radius is physical.
Compliance follows the same logic. NIST SP 800-171 control 3.5.3 requires MFA for local and network access to privileged accounts, and for network access to non-privileged accounts (NIST SP 800-171 Rev. 2). CMMC inherits that requirement directly. So the same step that blocks a credential-replay attack also produces the evidence an assessor wants to see.
The RDP Problem in OT
RDP deserves its own section because it is one of the most abused entry points into industrial networks. When an RDP port is reachable from the internet, attackers find it within hours through automated scanning, then brute-force or replay stolen credentials. Threat reporting consistently lists exposed RDP among the most common initial access vectors for ransomware, and CISA's guidance on securing remote access calls out direct RDP exposure as a practice to eliminate (CISA, Guide to Securing Remote Access Software).
The stakes are higher in OT than in IT. NIST SP 800-82, the authoritative guide to OT security, stresses that remote access into control-system environments must be tightly controlled, brokered through a hardened intermediary, and never exposed directly to untrusted networks (NIST SP 800-82 Rev. 3). An attacker who lands on an engineering workstation through an open RDP port is one step away from a human-machine interface (HMI) or a programmable logic controller, where the consequences are physical, not just data loss.
Best Practices for RDP Security
- Eliminate Inbound RDP Exposure: No control-system host should accept RDP directly from the internet, or even from the corporate network without brokering. Remove the inbound path entirely rather than relying on a password to defend it.
- Use Network Level Authentication (NLA) with TLS: NLA forces authentication before a session is established, and TLS protects the channel. Both should be negotiated by default.
- Broker RDP Through an Identity-Aware Gateway: Instead of opening ports, route RDP through a gateway that authenticates the user, applies MFA, enforces least privilege, and records the session centrally.
- Layer MFA on Top: Even a brokered connection should require a second factor, ideally phishing-resistant, before a session is granted.
- Patch and Monitor: Keep RDP services current and review session logs for anomalies.
MFA for VPNs
A VPN without MFA is a single stolen password away from full network access, which is why VPN gateways are a favorite target. Adding MFA fixes the front door, and the rollout is straightforward if you stage it. Start by checking that your gateway supports the MFA you want, then pick phishing-resistant factors over SMS or one-time codes wherever the gateway allows it. Deploy to a pilot group first so you catch the awkward cases before they hit everyone, and tell users plainly why the extra step exists, the prompt that arrives when they did not just log in is the one that saves them.
The Limits of VPN Plus MFA
VPN plus MFA authenticates the user at the front door, then often grants broad network reach once inside. That flat access is the problem: a compromised endpoint, a session hijack, or a stolen token can turn a single authenticated VPN session into lateral movement across the environment. NIST's zero trust architecture guidance frames the fix directly: authenticate every request, grant access per-resource rather than per-network, and assume the network is already hostile (NIST SP 800-207, Zero Trust Architecture). In practice that means moving from a VPN that exposes a network segment to a model where each connection is brokered, scoped to a single resource, and continuously verified. For OT, this is the difference between a vendor reaching one HMI for one maintenance window and that same vendor being able to scan the entire plant network.
MFA for cloud portals
Cloud portals are the easiest path to protect and the easiest to get wrong, because the controls are usually one toggle away. Turn on the provider's built-in MFA everywhere, then close the back doors: disable legacy authentication paths that bypass it, since those are what attackers actually probe. Route sign-in through an identity provider so you enforce one consistent, phishing-resistant policy across every service instead of configuring each portal by hand. Then watch the access logs for the sign-in that does not fit, an unfamiliar location or an impossible travel time often surfaces a compromised account before anything else does.
How This Maps to Compliance
The controls above are not just good hygiene; they are explicit requirements. NIST SP 800-171 places MFA squarely in its Identification and Authentication (IA) family, requiring MFA for privileged accounts and for network access to systems that handle controlled unclassified information. CMMC inherits these IA controls directly, so an OT environment that brokers RDP, enforces MFA, and scopes access per-resource is also building toward its compliance evidence. CISA's remote-access and MFA guidance and NIST SP 800-82's OT-specific direction round out the picture: eliminate direct exposure, broker through identity, and verify continuously.
Where MFA deployments get stuck
Three things tend to slow a rollout. The first is people: MFA adds a step, and some users will push back, so choose factors that stay out of the way and explain the why rather than just mandating the how. The second is compatibility, and it bites hardest in OT, where legacy assets cannot run an MFA agent at all and have to be protected at the network layer instead, which is the case for brokering access rather than bolting MFA onto every endpoint. The third is cost, and it is the easiest to settle: MFA is cheap next to a single incident, especially one that reaches a physical process.
Conclusion
Deploy MFA on every remote access path: VPN, RDP, and cloud portals. For RDP, the priority is to eliminate inbound exposure entirely and broker access through an identity-aware gateway with NLA and TLS, then add MFA on top. For VPNs, choose a phishing-resistant MFA factor, pilot before full rollout, and recognize that VPN plus MFA still leaves you with flat network access unless you move toward per-resource brokering. For cloud portals, enable built-in provider MFA or integrate with your identity provider. The compliance payoff is immediate: NIST SP 800-171 and CMMC both mandate MFA for remote access to controlled data. The security payoff is larger: a stolen password alone can no longer reach your network, and in OT, that can be the difference between a contained incident and a physical one.
