IA.L2-3.5.3

IA.L2-3.5.3: Multifactor Authentication

Require multifactor authentication for privileged and network access.

MFA is where assessors ask very specific questions about your actual setup. Most contractors have MFA for the cloud tenant. Good. But then the assessor digs: what about local admin accounts? What about service accounts? What about legacy on-premises systems? And you discover gaps. This practice builds on the device and user authentication work from IA.L2-3.5.2 and ties into access control enforcement covered in AC.L2-3.1.1.

Family Identification and Authentication
Practice IA.L2-3.5.3
Difficulty Hard
Key evidence MFA policy, identity provider configs, logs showing MFA enforcement, account list

What the assessor is actually evaluating

The assessor is checking two things. One: is MFA actually enabled and being enforced for the accounts that matter? Two: is it covering the places where privileged activity actually happens in your environment?

If you’re mostly cloud-based, they’re checking your identity provider configuration and conditional access policies. If you have on-premises systems, they’re checking how privileged access there is protected. If you have a hybrid environment (most small contractors do), they’re checking both and whether the gaps are known and documented.

When they ask about local accounts or service accounts, they’re not trying to catch you. They’re trying to understand your actual threat surface. If you say “we don’t allow local admin logons, only delegated network access through Kerberos,” that’s clear. If you say “yeah, local admins exist but we manage them with LAPS so it’s fine,” that creates doubt. You need to be able to answer how MFA is enforced or why the account doesn’t need it.

What a realistic SSP definition looks like

Example SSP Language: IA.L2-3.5.3

Practice IA.L2-3.5.3: Multifactor Authentication

Multifactor authentication is required for all privileged account access and all network access to systems containing CUI.

Cloud Access (Azure AD/Microsoft 365): All user accounts in Azure AD are subject to conditional access policies that enforce MFA. Policies require MFA for any login from a new device, from outside the corporate network, or for any account with administrative roles. Administrative accounts require MFA for every login without exception. MFA is enforced via the Microsoft Authenticator app and FIDO2 security keys for highest-risk roles.

On-Premises Access: Privileged accounts requiring on-premises administrative access authenticate through [domain controller / identity provider]. MFA is enforced via [RADIUS server / smart card / third-party MFA solution] for all administrative logons. Non-privileged users do not require MFA for standard network access.

Local Administrative Accounts: Local administrative accounts are not used for interactive logon. Administrative tasks on Windows systems are performed through [delegation method - just-in-time access / privileged access workstations / Kerberos delegation]. This eliminates the need for local account logons and ensures all administrative activity passes through authenticated, audited channels.

Service Accounts: Service accounts used for automated processes (backup, monitoring, scheduled tasks) do not require MFA due to their non-interactive nature. All service accounts are registered in our service account registry with documented purpose and systems accessed. Service account credentials are stored in [credential vault] and accessed through documented processes. Administrative review of service account access occurs quarterly per the Access Control policy.

Remote Access: VPN access requires MFA prior to network access. Users authenticate with username/password and a second factor (authenticator app or hardware token) before the VPN connection is established. The VPN system is configured to reject connections from accounts without MFA enrolled.

All MFA-protected accounts are tracked in our privileged account registry. This registry is reviewed quarterly to ensure MFA enforcement is current and accounts without MFA are documented with business justification.

This is precise because it addresses the gaps. It says clearly: local admin accounts don’t exist for interactive logon. Service accounts are documented with justification. On-premises accounts have a specific MFA mechanism. Cloud accounts have conditional access. The assessor reads this and doesn’t have to hunt for the answer to “what about local accounts?”

How to present your evidence

Evidence checklist
  • MFA policy documentation covering when MFA is required
  • Identity provider configuration showing MFA enforcement (conditional access, smart card, RADIUS, etc.)
  • MFA enrollment status report showing protected accounts
  • Authentication logs (30 days) showing MFA challenges are being triggered

Have these artifacts ready:

  1. MFA Policy documentation. Your written policy covering when MFA is required and what constitutes acceptable MFA. A policy that just says “MFA is required” is fine, but one that spells out specific scenarios is better.

  2. Identity provider configuration. For Azure AD/Entra, pull up conditional access policies. For on-premises, pull up whatever method you use (smart card requirements, RADIUS, etc.). Show the settings that enforce MFA.

  3. MFA enrollment and status. A report showing which accounts are MFA-enrolled and which are not. This could come from your identity provider’s admin portal.

  4. Logs showing MFA is being triggered. Pull authentication logs from the past 30 days showing MFA challenges. This proves active implementation in practice, beyond policy documentation.

  5. Documentation of non-MFA exceptions. If you have service accounts or other accounts that don’t require MFA, document why. “Service account for daily backup at 2 AM, no MFA required due to non-interactive use. Reviewed [date].”

Assessment room tips

Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.

Q: "How is MFA enforced in your environment?"
Pull up your conditional access policies or MFA configuration. "Any login to Azure AD triggers an MFA challenge. Administrative accounts require it every time. Cloud apps are protected by this policy here."
Q: "What about local admin accounts? How is MFA enforced there?"
This is the gotcha question. Have a clear answer ready. Either: "We don't use local admin accounts for interactive logon. All admin work goes through [method]." Or: "Local admins are managed by LAPS, credentials are stored in [vault], and access is granted through [system] with MFA required before you can retrieve the password." Or "Local accounts exist but are disabled. We use delegated access instead." Pick your model and be able to defend it. Don't fumble here.
Q: "Can you show me the authentication logs to prove MFA is actually being used?"
Pull up your sign-in logs or authentication logs from your identity provider. "Here are the last 30 days of authentications. You can see the MFA challenge for each one. This user logged in three times this week from different devices, MFA triggered each time."

Common failures

MFA is required by policy but not actually enforced. You have a policy that says "MFA is required." But nobody's actually checking. Accounts aren't enrolled. Conditional access policies aren't configured. When the assessor asks for logs, they see logons without MFA challenges. This is a finding. Policy doesn't count. Enforcement does.
MFA is configured for the cloud but not for privileged on-premises access. You have Azure MFA locked down. Good. But your domain controllers don't require MFA for administrative logon. Domain admins can log in with just a password. That's a gap that will get flagged.
Local admin accounts bypass everything. LAPS manages the local admin password. Good. But anybody with access to LAPS can retrieve the password and log in locally without any MFA challenge. If LAPS doesn't feed into an MFA system, you have a problem. You need a process where retrieving the LAPS password requires MFA, or you don't allow local admin logons at all.
MFA is enforced at the identity provider level and logs prove it. Conditional access policies are set. Sign-in logs show every logon triggered a MFA challenge. Non-interactive service accounts are documented with business justification. Assessor asks about MFA, you pull up logs, done.
You have a clear model for administrative access that doesn't rely on local accounts. Maybe it's just-in-time access. Maybe it's privileged access workstations. Maybe it's delegated permissions through the domain. Whatever it is, it's documented, MFA is enforced at the boundary, and it's consistent. The assessor understands the model and doesn't find gaps.
From the assessment room Local admin accounts are an easy gap. When assessors ask "how do you enforce MFA on local accounts," many contractors don't have an answer. Some rely on LAPS to manage local admin passwords, but if LAPS doesn't feed into an MFA system, the account can still be accessed without MFA. Be ready to explain your model: are local admin accounts disabled entirely, do they authenticate through a privileged access system with MFA, or do they require MFA through some other mechanism? Whichever you choose, have it documented and be able to defend it.
Get assessment room tips in your inbox

Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.

If you use an MSP or MSSP

Your MSSP should be the experts on MFA in your environment. They manage identity, directory services, and access control. They should have their own MFA configuration locked down, and they should have built your MFA configuration into your environment during onboarding.

In the assessment room, your MSSP should be able to walk through the conditional access policies, show the configuration, pull the logs, and explain why each policy is there. The contractor can speak to business requirements. The MSSP speaks to technical implementation.

Watch for this: if your MSSP hasn’t documented how they handle MFA for their own privileged access into your environment, that’s a red flag. A good MSSP requires MFA for every access to a customer environment. They should be able to show this.

Before the assessment, have your MSSP walk you through their MFA setup for your specific environment. Make sure you understand the policies, the enrollment process, and what to show the assessor. If the MSSP isn't clear on this themselves, you have a bigger problem. A mature MSSP should be able to present MFA in the assessment without the contractor having to prompt them.

This guidance is based on assessment room experience and reflects one practitioner’s interpretation of CMMC Level 2 requirements. It is not legal or compliance advice. Always consult your compliance team and official CMMC documentation for final guidance.

New practice breakdowns and assessment tips every week. Follow on Substack to stay current as the November 2026 deadline gets closer.

← IA.L2-3.5.4: Replay-Resistant Authentication All Practices IA.L2-3.5.2: Device & User Authentication →