The Role of MFA in CMMC, NIS2, and IEC 62443 Compliance

As digital transformation accelerates across industrial, energy, and critical infrastructure sectors, the role of identity and access management (IAM) has become central in both network security and regulatory compliance. For CISOs, IT directors, and network engineers guiding organizations through complex control system environments, understanding how Multi-Factor Authentication (MFA) intersects with regulatory frameworks like CMMC, NIS2, and IEC 62443 is no longer just prudent—it’s imperative.

Unlike perimeter security or simple air-gapping, modern compliance regimes explicitly require layered identity measures to forestall credential-based attacks and lateral movement. This post explores the technical and architectural reasons why, with a particular focus on MFA’s place in contemporary compliance standards for industrial and critical environments.

Historical Context: From Passwords to MFA

The Password Era

Historically, access to both IT and OT systems was governed by password-based authentication. Admin credentials on control systems, shared accounts, and default settings often persisted for years. The limitations became evident rapidly: passwords can be intercepted (over the wire or at rest), guessed, cracked via brute force, or phished.

The Need for Something Stronger

The escalation from mere inconvenience to existential risk became clear with notable incidents: the Stuxnet worm’s path through weakly guarded HMIs in 2010, and subsequent ransomware events that exploited default or compromised credentials. The introduction of 2FA (two-factor authentication) and, later, more mature MFA in enterprise products provided some relief, but the OT world lagged due to legacy architectures and operational concerns.

The Rise of MFA

MFA isn't new. Time-based one-time-password (TOTP) algorithms, hardware tokens (RSA SecurID, for example), and challenge-response systems existed since the late 1980s. What changed was their integration into mainstream platforms—especially in critical sectors subject to regulatory oversight.

Multi-Factor Authentication: A Technical Perspective

What is MFA?

MFA requires users to authenticate using at least two (preferably more) different "factors" from:

• Something you know: Passwords, PINs

• Something you have: Hardware token, smartphone, smart card

• Something you are: Biometrics

The primary objective is to eliminate single points of failure. For an attacker, compromising one factor should not be sufficient.

Implementation Pitfalls in Industrial Networks

Unlike modern cloud-native apps, industrial networks typically feature legacy PLCs, HMIs, and SCADA workstations, many lacking native support for MFA. Retrofit strategies include jump hosts (bastion servers), RDP or SSH gateways that enforce MFA before access to sensitive segments. These require careful network architecture, as introducing a single MFA point before a shared jump host can itself become an attractive target.

MFA in CMMC, NIS2, and IEC 62443: Technical Requirements and Guidance

CMMC (Cybersecurity Maturity Model Certification)

CMMC, formalized by the US Department of Defense in 2020, now underpins cyber assurance for defense contractors. CMMC 2.0 consolidates previous requirements and is explicit about privileged access management.

• Level 2 / Level 3 Requirements: MFA must be employed for all users accessing systems housing Controlled Unclassified Information (CUI). This means not just external (VPN) access, but also for internal privileged accounts and admin functions—regardless of whether the endpoint is IT or OT.

• Technical Implications: For organizations with OT networks connected directly or indirectly to business IT, integrating directory services (like AD with MFA) and ensuring that all privileged access, especially remote, routes through an MFA mechanism is necessary. Solutions vary: Azure AD, Okta, or on-premises AD FS with hardware tokens. For air-gapped OT, "offline capable" local MFA via physical tokens may be needed.

NIS2 (EU Network & Information Security Directive v2)

NIS2, adopted by the EU in 2022, broadens the scope of sectors and imposes objective-based security requirements—notably around identity and access management.

• Article 21: Enforces “policies on user access management and the use of strong authentication solutions, in particular for remote access”. While not prescribing technologies, NIS2 aligns with ENISA guidelines and generally implies MFA as the state-of-the-art.

• Technical Implications: All remote (and a growing subset of local) OT/IT access points must incorporate MFA. Practically, this requires federation between IT/OT directories where feasible, or the isolation of sensitive OT via dedicated gateways. Since member states must enforce this via national law, the details will vary, but the expectation is clear.

IEC 62443 (Industrial Communication Networks—Network and System Security)

IEC 62443 is the canonical global standard for OT security, with a modular series of documents addressing various aspects of industrial control system (ICS) lifecycle and architecture.

• IEC 62443-3-3 (System Security Requirements and Security Levels): Specifically, SR 1.4 (“Use of strong authentication mechanisms”) and SR 1.2 (“User identification and authentication”) set explicit requirements for the use of either multi-factor authentication or other “robust” authentication solutions for administrator and remote access.

• Technical Implications: To achieve SL3 (“restricted to authorized personnel”) and above, MFA is de facto mandatory for critical OT assets and for any remote administration, including engineering workstations and jump servers. Integration complexity is high—legacy vendors occasionally provide proprietary solutions, and cross-compatibility (e.g., between AD, LDAP, and device-native capabilities) is nontrivial.

Network Architecture Considerations

Where to Place MFA

• Perimeter (Remote Access): All VPNs and inter-site links must enforce MFA, with fail-closed policies to prevent bypass.

• Between IT/OT Zones: For hybrid or converged environments, user access crossing zone boundaries should traverse a security gateway that imposes MFA (e.g., jump servers, PAM solutions).

• Local OT Access: In environments with mobile vendors or contractors, deploying MFA locally is challenging but possible via badged tokens or portable authenticators.

PAM and MFA Integration

Privileged Access Management (PAM) solutions often provide built-in MFA, session recording, and access brokering for OT systems. Requiring all admin login—whether from IT or on-site—via the PAM gateway simplifies compliance while enhancing granularity and auditability. However, beware of introducing bottlenecks or single points of failure.

IT/OT Collaboration and Process Challenges

Why MFA Deployments Fail in ICS Environments

MFA rollouts fail most commonly when operational constraints are underestimated:

• Reliability: OT systems cannot tolerate authentication outages. MFA solutions should provide local fallback or offline modes.

• Legacy Compatibility: Some PLCs/HMIs cannot natively support MFA. Solutions involve proxying access through compliant intermediaries.

• User Acceptance: Engineers often resist complicating emergency access procedures. Pre-configured break-glass workflows with strict audit are necessary.

The Role of Governance

Implementing MFA must be more than a technical checkbox. Robust policy, regular MFA effectiveness testing, and understanding exception processes (e.g., who has justified, logged bypass rights) determine whether compliance will hold up during audits or incident forensics.

Beyond Compliance: Security Outcomes and Limitations

While adoption of MFA increases audit confidence and materially reduces the risk of credential-based attacks, it is not a panacea. Phishing-resistant MFA (such as FIDO2/WebAuthn) is rapidly becoming the baseline as attackers increasingly defeat SMS codes and TOTP apps. Furthermore, hardware-in-the-loop attacks, supply chain threats, and “bypass” attacks on authentication flows require a layered architectural response (network segmentation, anomaly detection, least privilege enforcement).

Conclusion

MFA’s integration into compliance frameworks like CMMC, NIS2, and IEC 62443 represents the hard-learned lessons of the past decade: identity is the new perimeter, and authentication cannot rely on passwords alone. For operators, engineers, and security leaders, robust MFA strategies are both an organizational necessity and a technical challenge, particularly within the constraints and realities of industrial networks. Honesty about what works, what breaks, and what can be realistically achieved in the near term is essential to building both secure and compliant environments.

Takeaways:

• MFA is now a non-negotiable in most regimes relevant to industrial and critical infrastructure operators.

• Integration in OT is possible, but requires careful design and recognition of operational realities—especially around reliability, legacy support, and emergency access.

• Approach compliance as a living, evolving program: the standards will continue to rise.

Further Reading and References

• CMMC Official Documentation

• NIS2 Directive Text

• IEC 62443-3-3 Standard

• CISA Guidance on MFA

• US-CERT Strategic Guidance