Multifactor Authentication

To meet the multifactor authentication requirement, you must enforce MFA for access to in-scope IT and OT assets according to your written policy, with clear coverage rules for privileged access, remote access, and critical systems. Operationalize it by defining scope, selecting approved MFA methods per asset class, enforcing through your identity stack, and retaining proof that MFA is consistently used. ¹

Key takeaways:

• Write and approve an MFA policy that explicitly covers IT and OT access scenarios, then map it to real systems and accounts. ¹
• Enforce MFA through centralized identity where possible, and use compensating controls where OT constraints prevent standard MFA. ¹
• Keep operating evidence (config exports, access logs, exception records, approvals) that proves MFA is active and followed day to day. ¹

“Multifactor authentication” becomes an audit problem when it’s treated as a checkbox (“we have MFA”) instead of an access control standard that is consistently applied, measurable, and provable. In the C2M2 model, the requirement is straightforward: implement MFA for access to IT and OT assets based on organizational policy. That phrasing puts the burden on you to define what “access” means in your environment, which assets are in scope, which roles and pathways require MFA, and what exceptions are permitted. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate the requirement into: (1) a policy with unambiguous coverage rules, (2) technical enforcement points that match those rules, and (3) evidence that ties user access events back to MFA challenges. OT adds a common wrinkle: some consoles, jump hosts, HMIs, or vendor maintenance pathways can’t support modern MFA. You still need a defined operating standard for those cases, including compensating controls and formal exception handling.

This page is written so you can assign owners, drive implementation, and walk into an assessment ready to show both design and operating effectiveness. ¹

Regulatory text

Excerpt (C2M2 ACCESS-2.D, MIL2): “Multifactor authentication is implemented for access to IT and OT assets based on organizational policy.” ¹

What the operator must do:
You must (a) decide and document where MFA is required, (b) implement MFA enforcement for those access paths into IT and OT assets, and (c) be able to demonstrate ongoing use in operations, not only capability in tooling. The “based on organizational policy” clause means assessors will look for a formally approved policy and procedures that drive consistent implementation, plus artifacts that show teams follow them. ¹

Plain-English interpretation (requirement-level)

Implement MFA wherever people (employees, contractors, third parties, service accounts where feasible) access systems that matter, including OT. “Access” includes interactive logins, remote access, administrative interfaces, and management planes. Your policy must tell engineers exactly where MFA is mandatory, what factors are allowed, how enrollment works, and how exceptions are approved and monitored. ¹

Who it applies to

Entities: Energy sector organizations and other critical infrastructure operators using C2M2 to assess cybersecurity maturity within a defined scope. ¹

Operational contexts (typical):

• IT workforce access: SSO, VPN, VDI, SaaS, servers, cloud consoles.
• Privileged access: domain admins, OT admins, hypervisors, network gear, security tools.
• Remote access into OT: jump servers, bastions, remote service gateways, vendor maintenance access.
• On-site OT access: HMI/engineering workstation logons, shared consoles, local serial/terminal access via intermediate systems. ¹

What you actually need to do (step-by-step)

1) Set scope and define “access” for MFA purposes

Create a scoped inventory view that answers:

• Which IT and OT assets are in scope (systems, applications, network zones, management planes)?
• Which access paths exist (SSO, VPN, RDP, SSH, local console, web admin, vendor portal, jump host)?
• Which identities are used (named users, shared accounts, break-glass accounts, third-party accounts)? ¹

Deliverable: “MFA coverage matrix” mapping asset/access path → required MFA control/enforcement point → owner.

2) Write (and get approval for) an MFA policy and procedures

Minimum policy content that tends to satisfy examiners and internal control testers:

• Where MFA is required: at least privileged access, remote access, and critical systems as defined by your organization.
• Approved factors: e.g., authenticator app, FIDO2/security keys, hardware tokens, certificate-based options, or other org-approved methods.
• Enrollment and lifecycle: identity proofing (if applicable), device changes, lost factor handling, re-enrollment.
• Third-party access: how vendors/contractors enroll, minimum factor requirements, and termination timelines tied to offboarding.
• Exceptions: criteria, risk acceptance owner, compensating controls, duration, and review cadence.
• OT-specific constraints: when MFA cannot be implemented directly on an endpoint and must be enforced upstream (jump host/bastion). ¹

This is a requirement you can operationalize quickly with a policy template, but approval history matters. Your evidence should show owner, approver, effective date, and review cadence. ¹

3) Choose enforcement points that match your architecture (IT and OT)

Common enforcement patterns:

• Centralized identity MFA: SSO/MFA at the identity provider for SaaS and internal apps.
• Remote access MFA: MFA for VPN, ZTNA, VDI, and remote desktop gateways.
• Privileged access MFA: MFA at PAM, admin jump boxes, or bastions; MFA to reach management networks.
• OT enforcement: if endpoints cannot do MFA, enforce MFA on the controlled entry point (bastion/jump host) plus tight network segmentation and session logging as compensating controls. ¹

4) Implement and test: “policy to config” mapping

For each MFA-required access path in your matrix:

• Configure conditional access rules (or equivalent) and document the rule intent in plain language.
• Test with real user roles (admin, standard user, vendor) and record expected vs actual results.
• Validate failure modes: blocked logins without MFA, denial for noncompliant devices (if used), and behavior for break-glass accounts.
• Confirm OT workflows: operators can still do their jobs, and emergency access is controlled and logged. ¹

5) Stand up exception handling that doesn’t become a loophole

Exceptions are often where MFA programs fail in audits. Build a lightweight but formal workflow:

• Request → security review → compensating controls → approval by a named risk owner → expiration date → periodic review → closure evidence.
• Track exceptions for OT legacy systems and vendor tools explicitly; don’t hide them in tickets that are hard to retrieve later. ¹

6) Operate and monitor

You need operational “heartbeat” signals:

• MFA enrollment status by population (employees, contractors, third parties).
• Authentication logs showing MFA challenges for in-scope apps and remote access.
• Alerts for MFA bypass events, policy changes, and unusual access patterns (as defined by your security monitoring practice).
• Routine access reviews for privileged users and third-party accounts, tied back to MFA status. ¹

Where Daydream fits naturally: use Daydream to maintain the MFA coverage matrix, link policy controls to system-level enforcement owners, and store recurring evidence (config exports, screenshots, logs, exception approvals) so audit requests don’t turn into a scavenger hunt. ¹

Required evidence and artifacts to retain

Keep evidence that proves both control design and control operation:

Policy and governance

• Approved MFA policy and procedures with owner, approval history, and review cadence. ¹
• Defined scope statement for IT/OT and any boundary decisions. ¹

Technical configuration and enforcement

• Conditional access / MFA rule exports (or screenshots with timestamps) for key apps, VPN/remote access, privileged access entry points. ¹
• System architecture diagrams showing where MFA is enforced for OT access paths (jump host/bastion). ¹

Operating effectiveness

• Authentication logs demonstrating MFA events for sampled users and systems.
• Evidence of periodic monitoring (reports, dashboards, or tickets) showing follow-up on MFA failures/bypass attempts.
• Exception register: approved exceptions, compensating controls, expiration, and re-approval/closure artifacts. ¹

Change management

• Records of changes to MFA policies/rules, including approvals and implementation tickets. ¹

Common exam/audit questions and hangups

Expect reviewers to press on these areas:

1. “Show me your MFA policy and where it is enforced.”
   They will test whether the policy’s words match your actual configuration. ¹

2. “What IT and OT assets are in scope?”
   A vague scope statement leads to inconsistent implementation and weak defensibility. ¹

3. “How do you handle OT systems that can’t support MFA?”
   You need documented compensating controls and a formal exception. ¹

4. “How do you prove MFA is used day to day?”
   Tool screenshots alone rarely satisfy. Provide logs, reports, and sampled access records. ¹

5. “How do third parties authenticate?”
   Reviewers look for equivalent enforcement for vendors/contractors, not a weaker path. ¹

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Policy says “MFA everywhere” but key pathways are excluded in practice	Creates a design/operation mismatch	Write explicit coverage and maintain a coverage matrix tied to owners. 1
OT excluded by default because endpoints are “legacy”	Leaves the highest-consequence environment weak	Enforce MFA at the OT ingress point (bastion/jump host) and document exceptions with compensating controls. 1
Shared accounts remain common in OT	MFA becomes meaningless when identity is not unique	Reduce shared accounts; where unavoidable, add session-level controls and strict approvals tied to named individuals. 1
“Break-glass” accounts bypass MFA without governance	Turns emergency access into a standing backdoor	Require approvals, store credentials securely, log use, and review every invocation. 1
No durable evidence	Audits stall even if MFA is working	Save rule exports, logs, and exception records in a system of record (for example, Daydream). 1

Enforcement context and risk implications

C2M2 is a DOE maturity model and program; it is commonly used for benchmarking and capability improvement in critical infrastructure environments. Your practical risk is not a specific penalty figure from this text; it is failing maturity assessments, failing customer diligence, or being unable to demonstrate a defined standard during audits and internal control testing if MFA is inconsistent, outdated, or undocumented. ²

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Publish a scoped MFA policy and procedures; route for approval with clear ownership. ¹
• Build the MFA coverage matrix for top access paths: remote access, privileged access, and the most critical IT/OT systems. ¹
• Stand up an exception register and require all MFA gaps to be documented there. ¹

Days 31–60 (enforce where you can, document where you can’t)

• Implement MFA on identity provider and remote access pathways first; validate with test cases and retain results.
• Put OT access behind a controlled entry point where feasible; document compensating controls for constrained systems. ¹
• Centralize evidence collection (policy versions, rule exports, sample logs) so you can respond quickly to assessors. ¹

Days 61–90 (prove operating effectiveness)

• Run an internal control test: sample users, privileged roles, and third-party accounts; validate MFA is enforced and log evidence exists.
• Review exceptions: confirm risk owner approvals, expiration dates, and remediation plans.
• Establish a steady operating cadence: periodic reporting, policy review schedule, and change control for MFA rule changes. ¹

Frequently Asked Questions

Does the MFA requirement apply to OT systems that can’t technically support MFA?

You still need MFA “for access” to OT assets, so enforce it at the access path you control (jump host, bastion, remote access gateway) and document any residual gaps as approved exceptions with compensating controls. ¹

What counts as “based on organizational policy” in an assessment?

Assessors will expect a formally approved policy and procedures with defined scope, coverage rules, and exception handling, plus artifacts showing teams follow that standard in operations. ¹

Is MFA required for privileged accounts only, or for all users?

The text ties MFA to access to IT and OT assets per your policy, so your policy must clearly define which populations and access paths require MFA; most programs start with privileged and remote access, then expand by criticality. ¹

How do we handle third-party access for vendors and contractors?

Treat third-party identities as in-scope for the same access paths (remote access, admin interfaces, OT ingress). Require MFA enrollment, document provisioning/offboarding, and retain evidence of MFA enforcement and access logging. ¹

What evidence is most persuasive that MFA is “implemented” rather than just available?

Provide MFA rule/config exports and authentication logs showing MFA challenges for sampled systems and users, plus an exception register that accounts for any known gaps. ¹

Can we meet the requirement if we rely on SMS-based codes?

C2M2 ACCESS-2.D does not prescribe factors in the provided excerpt; your policy should define approved factors based on risk and feasibility, and you should be prepared to justify the choice for critical and privileged access. ¹

What you actually need to do

Use the cited implementation guidance when translating the requirement into day-to-day operating steps. ³

Footnotes

1. Cybersecurity Capability Maturity Model v2.1

2. Cybersecurity Capability Maturity Model v2.1; Source: DOE C2M2 program

3. DOE C2M2 program