How to Implement MFA in Legacy OT Environments Without Breaking Operations

The call for improving authentication in Operational Technology (OT) environments is growing in volume and urgency. Incidents over the past decade—from power grid compromises to ransomware incidents in water facilities—underscore the risks related to weak or absent authentication. In the enterprise IT world, Multi-Factor Authentication (MFA) is (rightly) considered table stakes. But implementing MFA in industrial networks built before the internet was more than a curiosity is a non-trivial problem.

In this article, we’ll take a structured look at the internal realities and constraints of OT environments, the technical and historical context for legacy protocols, and the architectural strategies for adding MFA without causing unplanned downtime or technological breakage. Security is essential—but so is maintaining continuous, safe operations.

OT Reality Check: Constraints Beyond IT

• Safety and Reliability Over Everything: Production often cannot stop for the sake of IT enhancements. Safety risks trump security risks.

• Legacy Protocols and Systems: Many controllers and HMIs run on long-lived platforms—sometimes running 30-year-old operating systems, with communication via protocols like Modbus, DNP3, or raw serial.

• Vendor Lock-in and Supportability: Many legacy OT systems are black boxes, with third-party support agreements that may prohibit unauthorized modifications.

Historical Footnote: Why OT Networks Still Resemble the Past

For much of industrial computing history, networks were inherently trusted—either air-gapped or physically isolated. Authentication, if present, was basic (default credentials, shared passwords), under the assumption that access to the network conferred trust. The addition of IT-OT convergence, remote access demands, and global supply chains have rendered this model obsolete, but the technical underpinnings remain.

Understanding MFA: What, Why, and the OT Challenge

MFA seeks to verify user identity through two or more “factors”: something you know (password), have (token or smartcard), or are (biometrics). In the typical IT context, implementations rely on application-layer protocols—SAML, RADIUS, LDAP, OAuth, or cloud-based services.

In OT, the majority of legacy systems simply aren’t designed for this. HMIs might be accessed via VNC, proprietary clients, or even directly at the panel with no OS-level logon. Protocols like Modbus/TCP, Profinet, or BACnet perform no authentication of their own.

Where Do You “Insert” MFA?

There are generally three insertion points:

• At the network boundary (perimeter): Gateways, jump servers, or remote access portals mediate human connections to the control network.

• At the application layer: Adding authentication wrappers to protocol translators, custom middleware, or enhanced HMI logons.

• Direct device integration: Upgrading or replacing field devices themselves to support modern authentication. Realistically, this is rare in legacy plants.

Pragmatic Steps for Retrofitting MFA in Industrial Networks

1. Start with a Comprehensive Asset and Access Map

Before any technical project, inventory is non-negotiable. Document:

• All remote access entry points (VPNs, RDP gateways, serial-to-IP bridges, etc.)

• Which users and roles require remote/system access

• Network topology and segmentation (historical note: flat architectures were often the norm, but are now a risk factor)

2. Identify Low-Risk Insertion Points for MFA

The highest-leverage point is rarely the PLC itself. Instead, look to:

• Jump servers / Bastion hosts: Centralize access through a gateway server with MFA. Operators authenticate here, then connect to OT assets (via RDP, SSH, or similar).

• Remote Access Solutions: All remote connections (VPNs, remote desktop access) must be fronted with MFA. As of 2023, several major industrial breaches started with compromised single-factor credentials on remote access infrastructure.

• Network Segmentation: Leverage network zoning (per IEC 62443 or NIST 800-82) to isolate sensitive OT assets, reducing legitimate MFA gateway complexity.

3. Leverage Existing Technologies (Carefully)

Historical note: RADIUS, developed in the early 1990s, and TACACS+ remain foundational for authentication on networking gear. Many modern MFA products integrate at this point, even for "dumb" terminal access.

- VPN MFA: Most industrial-strength VPNs (hardware or software) can be integrated with centralized authentication (RADIUS, SAML, etc.), allowing MFA even for legacy client endpoints. - Remote Desktop/Jump Hosts: Microsoft’s NPS (RADIUS) or third-party products can enforce MFA for RDP sessions. - Web-based HMIs and Applications: Where possible, use modern SSO/MFA providers as a wrapper to existing interfaces.

4. Avoid Direct Device-level Intervention Unless Absolutely Necessary

Directly “bolting on” MFA at the device/HMI/PLC is fraught with peril:

• Unsupported firmware modifications void warranties/support.

• Unknown impacts on real-time operation or device crashes.

• Vendor/Certification issues: Safety certifications may become invalid.

If device-level improvements are needed, advocate for upgrades/replacements as part of medium- or long-term planning, not as an urgent quick fix.

5. Test, Validate, and Plan for Fail-Safe Scenarios

A historical note from Stuxnet: When authentication controls are unavailable (e.g., because a domain controller is offline), legacy OT operations can freeze, unpredictably. Always implement fallback scenarios—such as break-glass accounts, offline authentication tokens, or documented procedures for safe failback to open access in emergencies.

Common Pitfalls

• Assuming “checkbox MFA” from the IT world translates seamlessly to OT. Many enterprise MFA solutions are predicated on cloud connectivity or modern OS integrations which simply do not exist in OT.

• Introducing latency or single points of failure. Excessive authentication delays or dependency on external authentication sources can inadvertently cause downtime.

• Weak procedural controls. If operators can simply share “MFA tokens” (e.g., a YubiKey taped to a console), you’ve got theatre, not security.

Recommendations for IT/OT Collaboration

• Establish regular joint reviews of access architecture; map out every jump point or remote connection; and document workflow impacts before any technology change.

• OT engineers must have veto power over changes that could risk life or safety, and security must understand and respect these constraints.

• When in doubt, pilot in a lab replica before rolling out to production. Cross-validate functionality with process owners, safety professionals, and technical staff.

Conclusion: Security Without Disruption

MFA is essential—but never at the cost of operational safety, reliability, or unplanned downtime. Retrofitting MFA into legacy industrial environments is devilishly complex, requiring technical creativity, architectural discipline, and an understanding of why systems are the way they are.

Focus on pragmatic, outside-the-device controls (jump hosts, VPN portals, network segmentation), test exhaustively, and foster real partnership between IT and OT. The road is slow, but the alternative—waiting for an incident—will always be worse.

Further Reading

• NIST SP 800-82: Guide to Industrial Control Systems (ICS) Security

• IEC 62443: Security for Industrial Automation and Control Systems

• US CISA: Securing Remote Access in ICS Environments (cisa.gov)

Final Note

Like most things in infrastructure, the best solutions rarely involve “rip and replace.” Move fast—but don’t break things. The process control engineer who wrote that ladder logic in the ‘90s is still right: If the plant isn’t running, nothing else matters. Build MFA into your architecture with an equal respect for both safety and security.