03.05.03: Multi-Factor Authentication

To meet the 03.05.03: multi-factor authentication requirement, you must enforce MFA for the system access paths that can reach Controlled Unclassified Information (CUI), then prove it works with configuration evidence and access logs. Operationalize it by scoping “CUI access,” selecting phishing-resistant factors where feasible, enforcing MFA centrally (SSO/VPN/admin), and continuously collecting evidence for assessments. ¹

Key takeaways:

• Scope MFA around paths to CUI (interactive login, remote access, privileged access, and key administrative consoles).
• Make MFA enforceable and measurable via centralized identity, conditional access rules, and audit logs.
• Keep assessor-ready evidence: policies, configurations, user/account inventories, and authentication events. ¹

03.05.03 sits in the NIST SP 800-171 access control and identity space: it expects you to reduce account takeover risk by requiring more than one factor to authenticate where it matters. For most federal contractors and nonfederal organizations handling CUI, MFA becomes a gating control for the routes attackers use most: remote access, web-based email/SSO, cloud admin consoles, and privileged operations.

A CCO or GRC lead usually gets stuck in two places: (1) defining exactly which systems and users are “in scope” because they can access CUI, and (2) producing evidence that MFA is consistently enforced instead of “available.” The fastest path is to treat MFA as an enforceable control with three outputs: a clear scope statement, centralized technical enforcement, and recurring evidence collection mapped to the requirement.

This page gives you requirement-level implementation guidance you can hand to IAM, IT, and security operations, with the artifacts auditors ask for and the failure modes that trigger findings. All regulatory references here are to NIST SP 800-171 Rev. 3. ¹

Regulatory text

Requirement: “NIST SP 800-171 Rev. 3 requirement 03.05.03 (Multi-Factor Authentication).” ¹

Operator meaning: You must require two or more authentication factors for access to systems handling CUI (or that provide a path to CUI), and you must be able to demonstrate enforcement through configuration and logs. Treat “MFA” as “cannot complete sign-in without satisfying an additional factor,” not “user may enroll a second factor.”

Primary source references:

• NIST SP 800-171 Rev. 3 ¹
• NIST SP 800-171 Rev. 3 landing page ¹

Plain-English interpretation (what the requirement really demands)

You need MFA wherever a compromised password would give an attacker meaningful access. In a NIST SP 800-171 context, that typically includes:

• Interactive access to endpoints or servers that store/process CUI.
• Remote access paths that can reach CUI environments (VPN, VDI, ZTNA, remote admin tools).
• Privileged access (domain admin, cloud tenant admin, hypervisor admin, security tooling admin).
• SSO/IdP sign-in if the IdP grants access to CUI applications.

A practical interpretation that assessors accept: “If you can use a credential to reach CUI, MFA must be enforced on that authentication flow, and we can show proof.”

Who it applies to

Entities: Federal contractors and other nonfederal organizations that handle CUI in nonfederal systems. ¹

Operational context (who inside your org):

• Workforce users (employees, contractors) with CUI access.
• Privileged admins (IT, security, DevOps) even if they do not routinely view CUI, because their roles can grant access.
• Third parties with interactive or administrative access into your environment (MSPs, IR retainers, consultants). “Third party” access paths are often the weakest link, so put them in-scope when their accounts can reach CUI systems.

Systems in scope (typical):

• Identity provider (IdP), SSO portals, and directory services.
• Email systems used for CUI workflows (if applicable to your boundary).
• VPN/remote access gateways.
• Cloud consoles for CUI workloads.
• Administrative interfaces for EDR, SIEM, backups, and virtualization if those tools can modify or exfiltrate CUI systems.

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

Use this sequence to move from “MFA exists” to “MFA is an enforced control with evidence.”

Step 1: Define “CUI access paths” (scope statement you can defend)

1. List CUI repositories and processing systems (apps, file shares, collaboration platforms, ticketing, code repos if relevant).
2. Identify authentication entry points to those systems:
   • IdP/SSO
   • Direct app logins
   • VPN/ZTNA/VDI
   • Admin consoles and jump hosts
3. Identify populations:
   • Users with direct access
   • Admins with indirect access (ability to grant permissions, reset passwords, create tokens)

Output: A one-page MFA scope statement tied to your CUI boundary and access paths. ¹

Step 2: Choose acceptable MFA methods and set minimums

Define what factors you allow and where. Keep it short and enforceable:

• Prefer MFA methods resistant to common phishing and session theft where feasible (for example, hardware keys or platform authenticators) for admin roles and remote access.
• Define exceptions tightly (service accounts, break-glass) and require compensating controls.

Output: MFA standard (methods allowed, where required, exception process). ¹

Step 3: Enforce MFA centrally (avoid per-app drift)

Implement enforcement in the control points that cover the most surface area:

1. IdP / SSO conditional access: require MFA for all in-scope apps and high-risk sign-ins.
2. Remote access gateway: require MFA for VPN/ZTNA/VDI sessions.
3. Privileged access: enforce MFA at privileged role activation or privileged login, not just at the workstation.

Tactical rule: if an application still supports local passwords, either federate it to SSO with MFA or add an MFA layer at the access gateway.

Output: Screenshots/exports of conditional access policies and enforcement settings. ¹

Step 4: Close the “legacy gaps”

Most MFA findings come from a small set of gaps:

• Protocols that bypass MFA (legacy email protocols, older remote management paths).
• Local accounts on servers/endpoints (non-domain accounts) with weak governance.
• Shared accounts used by teams.
• API tokens created without strong controls, then treated as “not interactive.”

Remediation actions:

• Disable or tightly restrict legacy authentication routes that cannot support MFA.
• Replace shared accounts with named accounts plus role-based access.
• For service accounts, use non-interactive authentication patterns and lock down where they can be used.

Output: Exception register and remediation plan for gaps that cannot be fixed immediately. ¹

Step 5: Prove it works (continuous evidence, not a one-time screenshot)

You need operational proof that:

• MFA is required for in-scope populations and entry points.
• MFA challenges occurred.
• Exceptions are approved and reviewed.

Set up recurring evidence pulls from:

• IdP sign-in logs (MFA satisfied, MFA required, failures)
• VPN/ZTNA auth logs (second factor success/failure)
• Privileged access system logs (approvals, step-up auth)

Output: Monthly or quarterly evidence package, consistent format, retained for assessments. ¹

Required evidence and artifacts to retain (assessor-ready)

Keep artifacts that show policy, implementation, and operation:

Evidence type	What to retain	What it proves
Policy/standard	MFA policy + MFA standard (allowed factors, where required, exception process)	Governance and requirements definition 1
Scope	CUI system inventory, data flow/access path map, in-scope user/admin groups	Proper control boundary 1
Configurations	IdP conditional access exports, VPN MFA settings, privileged access configs	MFA is enforced, not optional 1
Logging proof	Sample sign-in events showing MFA required/satisfied; reports of users without MFA enrollment	Ongoing operation and monitoring 1
Exceptions	Break-glass account list, approvals, compensating controls, review notes	Controlled deviations 1
Testing	Access test cases (attempt login without MFA, confirm block), periodic control test results	Control effectiveness 1

If you use Daydream to manage your control library, map 03.05.03 to your MFA policy, your technical enforcement points, and a recurring evidence task so your package is ready when a customer or assessor asks. ¹

Common exam/audit questions and hangups

Expect these, and prepare the proof upfront:

1. “Where exactly is MFA required?”
   Auditors want a crisp scope answer: which systems, which access types, which user populations. Bring the scope statement and group membership exports. ¹

2. “Is MFA enforced or just available?”
   Show conditional access rules and a failed login attempt without the second factor. ¹

3. “How do admins authenticate?”
   Admins are a priority population. Demonstrate step-up MFA for privileged operations and tenant consoles. ¹

4. “What about service accounts and automation?”
   Have a list of non-human accounts, their authentication method, and why MFA is not applicable, plus compensating controls. ¹

5. “What do your logs show?”
   Provide sign-in logs and VPN logs that show MFA events for in-scope access paths. ¹

Frequent implementation mistakes (and how to avoid them)

• Mistake: MFA on VPN only, but SSO to SaaS with CUI is password-only.
  Fix: require MFA at the IdP for all in-scope apps and enforce federation for apps with CUI. ¹

• Mistake: “MFA enrollment campaign” with no enforcement date or blocking rules.
  Fix: make MFA a condition for access. Track “users without MFA” as a compliance exception. ¹

• Mistake: Exceptions everywhere (shared admin accounts, break-glass accounts used daily).
  Fix: minimize break-glass accounts, restrict them, monitor them, and review their use. Keep a small exception register with explicit approvals. ¹

• Mistake: Logging exists, but nobody can produce it during an assessment.
  Fix: schedule recurring evidence exports and store them in a controlled repository with consistent naming. Daydream can track the evidence request cadence and ownership so it doesn’t depend on one engineer’s memory. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement actions.

Operationally, MFA gaps create predictable failure modes: credential phishing, password spraying, session hijacking, and abuse of third-party remote access. For a NIST SP 800-171 program, those failures translate into CUI exposure risk and assessment findings due to weak access controls. ¹

Practical execution plan (30/60/90-day)

You can run this as an implementation sprint plan. Timeboxes are optional; the deliverables are what matter.

First 30 days (stabilize scope and enforce the biggest choke points)

• Define CUI boundary and list CUI access paths (IdP, VPN, privileged consoles). ¹
• Publish MFA standard: allowed factors, required scenarios, exception criteria. ¹
• Enforce MFA on:
  • IdP/SSO for in-scope apps
  • VPN/ZTNA/VDI
  • Privileged admin sign-ins ¹
• Start evidence collection: export configs and collect sign-in logs for a defined period. ¹

Next 60 days (close gaps and harden admins/third parties)

• Eliminate legacy authentication paths that bypass MFA where feasible. ¹
• Implement privileged access controls: named accounts, role separation, step-up MFA for admin actions. ¹
• Bring third-party access into the same MFA enforcement policies; remove shared accounts. ¹
• Formalize exception register and compensating controls for service accounts and break-glass. ¹

Next 90 days (make it auditable and repeatable)

• Automate recurring evidence pulls (policy snapshots, conditional access exports, MFA event reports). ¹
• Add control testing: documented test cases and remediation workflow for failed tests. ¹
• Integrate into GRC: control owner, review cadence, evidence checklist, and assessment-ready narrative in Daydream or your existing system. ¹

Frequently Asked Questions

Does 03.05.03 require MFA for every single user and system?

It requires MFA for access paths that can reach CUI systems within scope. Start with IdP/SSO, remote access, and privileged access, then expand coverage based on your CUI boundary definition. ¹

Are SMS codes acceptable MFA for 03.05.03?

NIST SP 800-171 Rev. 3 provides the requirement label here, but your implementation choice should be documented in your MFA standard and risk-based for the access path. If you allow SMS, restrict it to lower-risk cases and set stronger methods for admins and remote access. ¹

How do we handle service accounts and automated jobs that cannot complete MFA?

Treat them as exceptions with strict controls: non-interactive authentication, least privilege, tight network scoping, credential rotation, and monitoring. Keep a service account inventory and document why MFA is not applicable for each. ¹

What evidence is most persuasive to an assessor?

Conditional access/VPN configuration exports plus sign-in logs showing MFA required and satisfied for in-scope users. Pair that with a clear scope statement that maps users and systems to the CUI boundary. ¹

We have MFA for VPN, but users can access CUI SaaS directly from the internet. Is that a problem?

Yes, if the SaaS contains CUI and supports direct login. Enforce MFA at the IdP and require federation for the SaaS so MFA cannot be bypassed. ¹

How should we treat third-party support access (MSP, consultants)?

Put third-party accounts under the same MFA enforcement rules as employees, and avoid shared accounts. Document third-party access paths and keep logs showing their MFA events and privileged actions. ¹

Footnotes

1. NIST SP 800-171 Rev. 3