This practice is where authentication lives. Every user, every process, every device that touches your systems needs to prove who or what it is before you let it in. This isn’t optional in CMMC. For a 15-50 person contractor, this comes down to four things: MFA for all your people, solid password policies, separate admin accounts with their own credentials, and proper handling of service accounts. The assessor will ask you to show this working in real time.
What the assessor is actually evaluating
MFA enforcement across all interactive users. The assessor wants to see Conditional Access policies in Entra ID that require MFA for every user accessing your environment. Not “recommended.” Enforced. They’ll ask you to turn on MFA right now and see what happens. Phishing-resistant MFA (FIDO2 hardware keys like YubiKeys, or Windows Hello for Business) is the gold standard and where everyone should be heading. Some organizations use a mix of authenticator app and hardware keys. The assessor hasn’t specifically been asking about phishing-resistant MFA yet, but you should have it anyway.
Separate admin accounts with their own MFA. If la.jsmith@ is your normal user account, adm.jsmith@ should be your admin account, and both need MFA registered separately. The assessor will verify these exist and that admins don’t work from their regular accounts.
Password complexity and length requirements. Your domain policy or directory service should enforce at least 14 characters, mixed case, numbers, and symbols. The assessor will check group policy or your identity provider settings. Some organizations still enforce 90-day rotation, but more are moving toward the NIST 800-63B model where passwords don’t expire unless compromise is suspected. The assessor cares that you have a documented policy and that you actually follow it. Pick one approach, write it down, and enforce it consistently.
Service account management. If you’re using managed identities in Azure, great. If you’re not, your service accounts need strong passwords (20+ characters minimum) rotated at least annually. The assessor will ask where these are stored and how you rotate them.
Device authentication. Every device accessing your network should be domain-joined or enrolled in Intune. The assessor will check a random device and verify it’s authenticated to your environment.
What a realistic SSP definition looks like
This is how you write it so the assessor knows you have a plan and you’re executing it.
Our organization requires multi-factor authentication (MFA) for all users accessing information systems. MFA is enforced through Conditional Access policies in Entra ID, requiring at least one additional factor beyond passwords (authenticator app, FIDO2 key, or phone-based approval). Where available, we use phishing-resistant MFA methods (FIDO2 hardware keys or Windows Hello for Business). All administrative accounts use separate credentials with their own MFA registrations and cannot be used for routine work. Service accounts using managed identities are configured without passwords; for legacy service accounts, we maintain passwords of at least 20 characters including uppercase, lowercase, numbers, and symbols, rotated at least annually. All devices accessing organizational systems are either domain-joined or enrolled in Intune, requiring certificate-based or credential-based authentication. Password policies enforce a minimum length of 14 characters with complexity requirements. Passwords do not expire on a fixed schedule; they are changed when compromise is suspected, in accordance with NIST SP 800-63B guidance. We verify user, process, and device identity at each login attempt and document MFA enrollment status at least quarterly.
How to present your evidence
Bring these to the assessment room or have them ready to show live.
Conditional Access policies in Entra ID. Screenshot or live demonstration showing policies that require MFA for all users or specific risk profiles. The assessor wants to see the rule, the condition, and the grant control set to “Require multifactor authentication.”
Admin account documentation. A simple spreadsheet showing your admin accounts (adm.jsmith@, adm.rchen@, etc.) separately from user accounts, with MFA enrollment dates and last verification dates.
Password policy screenshots. Group Policy Editor (gpdit) showing domain password requirements, or your identity provider’s password policy settings. Make sure the minimum length field shows 14 or higher.
Service account inventory. For each service account, document when the password was last rotated. If using managed identities, show the configuration in Azure. If not, show that the password meets length requirements (you don’t need to show the password itself).
MFA enrollment records. An export from Entra ID or your authenticator management tool showing every user and whether MFA is enrolled and enforced.
Device enrollment list. From Intune or Active Directory, a list of all devices with their enrollment date and authentication status.
Common failures
MFA is optional or can be skipped. You’ve set up MFA in Entra ID, but the Conditional Access policy doesn’t enforce it. Users see a prompt and can click “Not now.” The assessor will test this and it fails immediately. Your policy must say “Require multifactor authentication” with no exceptions.
Admins work from their regular accounts. You have an admin account adm.jsmith@, but jsmith@ is also an admin. Or worse, you don’t have separate admin accounts at all. The assessor will pull up Active Directory and check group memberships. They’ll see that jsmith@ is in Domain Admins, and you fail this control.
MFA registered but not all users enrolled. You’ve enabled MFA, but only 8 out of 10 users have actually registered an authenticator. The other two use password-only access. The assessor will check Entra ID and see the gap. You need 100% enrollment.
Service account passwords are weak or never rotated. A service account for your backup software has a 12-character password and hasn’t been changed in three years. The assessor asks when it was last rotated, and you don’t know. You fail this.
Device authentication is missing or inconsistent. You have domain-joined Windows machines, but your sales team has personal MacBooks that aren’t enrolled in anything. Those devices have access to your network and email. The assessor will ask about device authentication policy and you can’t explain how those machines are authenticated.
Admin accounts have the same password policy as user accounts. Your admin account adm.jsmith@ uses a 12-character password because that’s your domain policy. Admin accounts should be held to a higher standard, at least 20 characters if they’re not using managed identities.
If you use an MSP or MSSP
Your managed service provider should be handling MFA enforcement, device enrollment, and password policy in your environment. Before the assessment, get evidence from them showing that they’ve configured these controls. Have your MSSP pull the Conditional Access policies, the Intune enrollment report, and the list of admin accounts in your directory. Make sure your contracts with the MSSP spell out who’s responsible for what. The assessor will ask you to explain your shared responsibility model. You need to know which parts of authentication the MSSP owns and which parts you own. If the MSSP drops the call during the assessment, you should still be able to show evidence.
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&A: What the assessor asks and what good answers sound like
This page reflects current CMMC guidance and common assessment findings. Authentication requirements may evolve. For official guidance, consult the CMMC model documentation. Cross-reference AC.L2-3.1.1 for access control that builds on this authentication foundation.