Multifactor Authentication

The C2M2 ACCESS-2.D requirement mandates multifactor authentication implementation across both IT and operational technology environments. Unlike typical enterprise MFA deployments focused solely on IT systems, this requirement explicitly extends protection to OT assets — the industrial control systems, SCADA networks, and field devices that operate critical infrastructure.

Your organizational policy must define which systems require MFA, acceptable authentication factors, and any risk-based exceptions. Energy sector organizations face unique challenges implementing MFA in OT environments where legacy systems may lack modern authentication capabilities and operational continuity takes precedence over security controls.

This guide provides practical implementation steps, common audit findings, and a structured approach to achieving compliance while maintaining operational reliability.

Regulatory text

The C2M2 v2.1 ACCESS-2.D requirement states: "Multifactor authentication is implemented for access to IT and OT assets based on organizational policy."

This language grants organizations flexibility to define MFA scope through policy while establishing the baseline expectation that both IT and OT environments require protection. The phrase "based on organizational policy" means you must document your MFA implementation decisions, risk assessments, and any compensating controls for systems that cannot support modern authentication methods.

Who This Applies To

This requirement applies to:

• Energy sector organizations implementing C2M2
• Critical infrastructure operators with OT environments
• Any entity with industrial control systems requiring cybersecurity maturity assessment
• Organizations pursuing MIL2 maturity level compliance

Operational contexts requiring special attention:

• Control rooms with shared workstations
• Field technician access to remote sites
• Emergency response scenarios requiring rapid access
• Legacy OT systems without native MFA support
• Third-party vendor access to critical systems

Implementation Requirements

1. Develop Your MFA Policy

Create a comprehensive policy documenting:

• Systems and access types requiring MFA
• Approved authentication factors (something you know, have, or are)
• Risk-based criteria for MFA enforcement
• Exception request and approval process
• Emergency bypass procedures

Your policy must explicitly address both IT and OT environments. Many organizations make the mistake of copying enterprise IT policies without considering OT operational constraints.

2. Inventory Access Points

Document all access paths to IT and OT assets:

• Direct console access
• Remote desktop connections
• VPN access
• Web-based management interfaces
• API and programmatic access
• Maintenance laptops and portable media
• Third-party support connections

3. Select Appropriate MFA Methods

For IT environments:

• Hardware tokens (FIDO2, smart cards)
• Software tokens (authenticator apps)
• SMS/voice (discouraged but acceptable for lower-risk access)
• Biometric factors

For OT environments, consider:

• Physical token solutions that work offline
• Certificate-based authentication for system-to-system communication
• Time-based one-time passwords (TOTP) for air-gapped networks
• Proximity cards combined with PINs for control room access

4. Address OT-Specific Challenges

Legacy OT systems often lack native MFA support. Implement compensating controls:

• Jump servers with MFA protecting legacy system access
• Network segmentation limiting direct access
• Session recording and monitoring
• Physical security controls for local access
• Privileged access management (PAM) solutions

5. Implement Phased Rollout

Deploy MFA systematically:

• Start with highest-privilege accounts
• Extend to remote access paths
• Cover critical OT systems
• Address remaining systems based on risk assessment
• Monitor and adjust based on operational impact

Required Evidence and Artifacts

Maintain these documents for audit:

1. MFA Policy Document - Signed and dated, covering both IT and OT
2. System Inventory - Listing MFA implementation status for each asset
3. Risk Assessment - Documenting systems without MFA and compensating controls
4. Implementation Evidence - Screenshots, configuration files, or attestations
5. Exception Register - Approved exceptions with business justification
6. Training Records - User education on MFA usage
7. Incident Reports - Any MFA-related access issues or bypasses

Common Audit Questions and Issues

Auditors typically focus on:

Coverage Completeness

• "Show me your inventory of systems requiring MFA"
• "How do you ensure new systems receive MFA configuration?"
• "What percentage of privileged accounts use MFA?"

Policy Alignment

• "Where does your policy address OT system authentication?"
• "How do you handle emergency access scenarios?"
• "Show me your exception approval process"

Implementation Quality

• "What factors constitute your MFA implementation?"
• "How do you prevent MFA bypass through alternate access paths?"
• "Demonstrate MFA enforcement for remote access"

Common audit findings:

1. Incomplete Coverage - MFA implemented for IT but not OT systems
2. Weak Second Factors - Over-reliance on SMS despite known vulnerabilities
3. Policy Gaps - Missing OT considerations or exception procedures
4. Bypass Paths - Local console access lacking MFA protection
5. Third-Party Gaps - Vendor support access without MFA enforcement

Implementation Mistakes to Avoid

1. IT-Centric Approach

Don't copy enterprise IT authentication directly to OT. Industrial environments require solutions that:

• Function during network outages
• Allow rapid emergency access
• Support technicians wearing safety equipment
• Work with legacy protocols and interfaces

2. All-or-Nothing Deployment

Attempting to enable MFA everywhere simultaneously causes operational disruption. Use risk-based prioritization and phased implementation.

3. Inadequate Exception Handling

Some systems genuinely cannot support MFA. Document these cases thoroughly with:

• Technical limitations preventing MFA
• Compensating controls implemented
• Risk acceptance by appropriate authority
• Review schedule for reassessment

4. Ignoring User Experience

OT operators work under time pressure. MFA methods must:

• Allow authentication while wearing gloves
• Function in harsh environments
• Provide rapid authentication for emergency response
• Include clear failure recovery procedures

5. Weak Administrative Controls

Technical MFA implementation fails without supporting processes:

• Token lifecycle management
• Lost token procedures
• Temporary access protocols
• Regular access reviews

Risk and Enforcement Context

While C2M2 operates as a maturity model rather than a prescriptive regulation, MFA implementation directly impacts:

• NERC CIP compliance for bulk electric systems
• TSA Security Directives for pipeline operators
• Insurance coverage and premiums
• Incident response capabilities
• Third-party risk assessments

Organizations without proper MFA face increased risk of:

• Unauthorized access to critical infrastructure
• Lateral movement following initial compromise
• Insider threat exploitation
• Compliance findings in sector-specific audits

Execution Plan

Immediate Priority Actions

• Form MFA implementation team including IT, OT, and operations representatives
• Document current authentication methods across all systems
• Identify highest-risk access paths (remote access, privileged accounts, critical OT)
• Draft initial MFA policy covering both IT and OT environments
• Begin procurement process for MFA solutions compatible with your environment

Near-Term Implementation

• Deploy MFA for all remote access methods
• Implement MFA for privileged IT accounts
• Pilot MFA solutions for critical OT systems
• Establish exception handling process
• Train help desk on MFA support procedures
• Create emergency access protocols

Ongoing Maturation

• Extend MFA to remaining systems based on risk assessment
• Implement continuous monitoring for MFA bypass attempts
• Conduct quarterly access reviews
• Update policy based on operational experience
• Plan for technology refresh of systems incompatible with MFA
• Measure and report MFA adoption metrics

Frequently Asked Questions

Can we use SMS-based MFA for OT systems given their isolation from internet access?

SMS presents risks even in isolated environments. Consider hardware tokens or TOTP solutions that work offline. If SMS is your only option, document it as a compensating control and plan migration to stronger factors.

How do we handle shared operator workstations in control rooms where multiple users need rapid access?

Implement fast user switching with individual MFA tokens, proximity card + PIN combinations, or consider session-based MFA where authentication persists for defined operational periods with appropriate monitoring.

What constitutes acceptable MFA for legacy OT systems that can't be modified?

Use jump servers or PAM solutions with MFA to broker access. The MFA occurs at the intermediate system, providing documented protection even when the end system lacks native support.

Our emergency response procedures conflict with MFA requirements. How do we balance security with operational safety?

Document break-glass procedures allowing MFA bypass under defined emergency conditions. Include compensating controls like video recording, dual authorization, immediate alerting, and post-incident review requirements.

Do service accounts and system-to-system communications require MFA?

The requirement focuses on human access to IT and OT assets. However, implement certificate-based authentication or API keys with appropriate rotation for automated access, documenting your approach in policy.

How frequently should we review MFA implementation and exceptions?

Conduct quarterly reviews of exceptions and annual reassessment of overall MFA architecture. Technology improvements may enable MFA on previously incompatible systems.