MFA for CMMC: How to Actually Satisfy IA.L2-3.5.3

IA.L2-3.5.3 is one sentence with three obligations packed inside: “Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.” Most shops satisfy one of the three, wave at the second, and discover the third during a readiness review. On macOS the distance between “we have MFA” and “we meet 3.5.3” is almost always the local-access piece, so let’s parse the requirement the way an assessor will.

The three buckets, and what counts as a factor

The 800-171A objectives split exactly as the sentence reads: MFA implemented for local access to privileged accounts; for network access to privileged accounts; and for network access to non-privileged accounts. Local access means authenticating directly to the machine in front of you; network access means authenticating across a network to a system or service. Factors are the classic three - something you know, something you have, something you are - and multifactor means two different categories for the same authentication event. Two passwords are one factor twice. A password at the FileVault preboot screen followed by the same password at login is still one factor.

Notice what the requirement does not demand: MFA for local access to non-privileged accounts. A standard user logging into their own Mac locally with a password is not, by itself, a 3.5.3 failure. This asymmetry is the single most useful fact for designing a Mac implementation that is both compliant and livable.

The answers that do not survive follow-up

“We have FileVault” is an encryption answer to an authentication question. “We use Touch ID” describes a convenience mechanism that substitutes for the password at unlock; password or fingerprint is one factor per event, not two. “We have MFA on email” covers one cloud service, not the requirement. “Admins have a separate username and password” is separation of duties, not a second factor. Each of these describes something worth having; none of them is multifactor authentication for the access category being assessed.

Network access: where most of the requirement is actually won

For both privileged and non-privileged network access, the workable pattern is the same: put your identity provider in front of everything that reaches CUI, and enforce MFA there with no exceptions for administrators. In a GCC High shop that means Entra ID conditional access requiring MFA (or better, phishing-resistant methods) for all users on all apps, including the admin portals; VPN and any remote access terminate against the same IdP. Document the policy export, not a screenshot, as your evidence. If a service inside your boundary cannot sit behind the IdP, either it does not touch CUI or it needs its own MFA story in the SSP.

Local privileged access: the Mac-specific part

This is the bucket that separates Mac programs. Default macOS login is single-factor, so a privileged account logging in locally needs a second factor at (or structurally around) that login. Three implementations actually work in the field.

Smart cards. macOS supports PIV/CAC smart cards natively, including MDM-enforced mandatory smart-card login and the option to pair the card requirement to specific accounts. Card plus PIN is textbook something-you-have plus something-you-know, it is the pattern DoD-adjacent assessors recognize instantly, and hardware-backed FIDO2 security keys ride the same native support for platform authentication. For a small fleet, a pair of YubiKeys per admin is the cheapest defensible answer in the catalog.

Platform SSO with hardware-bound keys. Platform SSO for macOS (GA since August 2025) can register a Secure Enclave–backed key so that unlocking the Mac performs phishing-resistant authentication against Entra: the key is something you have (bound to that hardware), the password or biometric that releases it is the second element, and the sign-in event is logged centrally, which neatly produces your evidence. For shops already in GCC High this is the most operationally elegant answer.

Architectural containment. Some shops instead eliminate routine local privileged access: standard-user daily drivers, admin rights granted just-in-time through the MDM with ticket-logged elevation, and true administrative work performed through network paths that sit behind IdP MFA. This can satisfy the intent and often improves 3.1.5/3.1.6 posture simultaneously, but it lives or dies on discipline: one standing local admin account outside the scheme and the assessor is back to asking how that login gets its second factor. If you run this pattern, write it up explicitly as your 3.5.3 implementation rather than hoping the topic does not come up.

Whichever you choose, kill the classic failure first: the shared local “IT admin” account with a password on a wiki. It fails 3.5.3, 3.1.1, and 3.3.2 in one move, and every Mac shop has had one at some point.

Documenting it

Your SSP statement for 3.5.3 should answer the three buckets separately and name mechanisms: which IdP policy enforces MFA for network access (and that admins are inside it), what provides the second factor for local privileged login on macOS (smart card profile, Platform SSO registration, or the containment scheme), and where the enforcement evidence lives (conditional access policy export, MDM profile, sign-in logs). Assessors sample; make the sample boring. The management plane that deploys all of this is covered in the ABM + MDM guide, and the account hygiene it depends on shows up throughout the macOS cornerstone.

Educational content, not legal or assessment advice. Platform capabilities cited from Apple and Microsoft documentation, July 2026.