CMMC 2.0 assessments under the Defense Federal Acquisition Regulation Supplement (DFARS) clause 252.204-7021 are now mandatory for contractors handling Controlled Unclassified Information (CUI) on covered defense contracts. Level 2, which maps directly to the 110 practices in NIST SP 800-171 Rev 2, has been the standard most small and mid-tier defense industrial base (DIB) contractors are assessed against since formal triennial assessments began rolling out in late 2024. For many, the Identity and Authentication practices have emerged as the most consistently under-documented domain.
This article focuses specifically on what CMMC 2.0 Level 2 requires in the Access Control (AC) and Identification and Authentication (IA) domains as they relate to personnel identity verification — what your security program needs to document, what C3PAO assessors examine, and where the common gaps are found.
How CMMC 2.0 Level 2 Structures Identity Requirements
CMMC 2.0 Level 2 comprises 110 practices drawn directly from NIST SP 800-171 Rev 2, organized into 14 domains. The domains most relevant to identity verification are Access Control (AC) and Identification and Authentication (IA), along with Personnel Security (PS) practices that govern how contractor employees are vetted before receiving access to CUI environments.
Within the IA domain, the practice numbering in CMMC uses the format IA.L2-3.5.x, reflecting the source control family 3.5 in NIST SP 800-171. The practices span identity establishment, authentication mechanisms, cryptographic protection of authenticators, and the management of privileged accounts. Critically, these practices do not distinguish between your permanent workforce and the cleared subcontractors or temporary personnel who also access CUI systems — all identities accessing in-scope systems must satisfy the same requirements.
Practice IA.L2-3.5.1 requires identifying information system users, processes acting on behalf of users, and devices. Practice IA.L2-3.5.2 requires authenticating those identities before allowing access to organizational systems. These two practices are foundational — every subsequent IA practice builds on the assumption that each identity accessing a CUI system has been uniquely established and is not shared.
What C3PAO Assessors Examine in the IA Domain
Under the CMMC Assessment Process (CAP) documentation, Third-Party Assessment Organization (C3PAO) assessors are required to validate each practice through a combination of examining documentation, interviewing personnel, and testing the implemented mechanisms. For the IA domain, documentation review is typically the first step — and it is where most findings originate.
Assessors commonly request the following documentation categories for IA practices:
- Identity provisioning records showing when each user account was created, what access level was assigned, and what identity proofing occurred before provisioning
- Authenticator management policy and evidence of enforcement — particularly for multi-factor authentication (MFA) requirements under IA.L2-3.5.3
- Privileged access management records distinguishing standard and administrative accounts, mapped to individual named users (not shared credentials)
- Evidence of periodic access reviews — typically documented as quarterly or semi-annual account revalidation records
- Termination and transfer deprovisioning records, demonstrating timely revocation (practice AC.L2-3.1.1 cross-references here via timely system access removal)
Consider a scenario familiar to mid-tier defense contractors: a 180-person engineering services firm supporting a large DoD prime was assessed by a C3PAO in early 2025. Their MFA implementation was technically sound — all staff used hardware tokens for VPN and email access. The finding came from identity proofing gaps: they had no documented process for verifying that each account corresponded to a verified individual. Three accounts in the CUI enclave belonged to subcontractors whose identity documentation had not been checked against government-issued ID at onboarding. The assessors scored IA.L2-3.5.1 as "Not Met" — not because authentication was broken, but because the initial identity establishment was not documented.
We are not suggesting that MFA implementation is unimportant — it clearly is. The point is that identity proofing documentation upstream of authentication is equally scrutinized, and it is the element that organizations frequently treat as assumed rather than formally documented.
Access Control Flow-Down: Where Prime and Sub Responsibility Intersects
DFARS 252.204-7021 requires primes to flow down CMMC requirements to subcontractors who handle CUI. This creates a responsibility chain where the prime's CMMC assessment status does not insulate them from subcontractor gaps — assessors reviewing the prime's supply chain will ask how the prime verifies that subcontractors meeting CUI access requirements are in fact assessed or self-attested at the appropriate level.
For AC.L1-3.1.1 (Limit system access to authorized users), the practice requires that access be limited to authorized users, processes, and devices. When a subcontractor's employee accesses the prime's CUI system, that employee's identity must be provisioned through a process that the prime can document and defend. Ad hoc provisioning — adding a sub's engineer without a formal identity verification step — creates a gap the prime owns.
Federal Acquisition Regulation (FAR) 52.204-21 applies to contractors with any federal contract and requires basic safeguarding of covered contractor information systems. DFARS 252.204-7012 extends this to CUI handling requirements with specific incident reporting timelines. Both flow down, meaning subcontractors handling CUI are bound regardless of whether their prime contracts explicitly restates the requirement in the subcontract terms.
For more detail on managing identity verification across the subcontractor chain, see our article on managing subcontractor identity risk as a prime contractor.
Authenticator Management: The IA.L2-3.5.3 and IA.L2-3.5.10 Evidence Gap
Multi-factor authentication under IA.L2-3.5.3 requires MFA for access to organizational systems containing CUI. The practice does not prescribe specific authenticator types, but NIST SP 800-63B (Digital Identity Guidelines, Authentication and Lifecycle Management) informs the implementation guidance. Level 2 assessors expect to see phishing-resistant MFA — hardware security keys (FIDO2/WebAuthn) or PIV-compatible tokens — for privileged access. Software OTP (time-based one-time password apps) is generally accepted for standard user access but may generate observations regarding phishing risk.
IA.L2-3.5.10 requires that cryptographically-protected passwords be used where passwords are employed as authenticators. This is frequently misunderstood as only a system configuration requirement. Assessors also examine whether passwords are stored with appropriate hashing (bcrypt, Argon2, or PBKDF2 at NIST-recommended parameters) and whether the organization has a documented policy prohibiting plaintext password storage.
The evidence burden for both practices is significant. Documentation typically includes: a current authenticator management policy, configuration screenshots from identity provider (IdP) settings, a list of accounts with their assigned authenticator types, and for IA.L2-3.5.10, evidence of password storage configuration (database schema documentation, system security plan (SSP) excerpts, or vendor FedRAMP security package references if using a cloud IdP).
System Security Plan Alignment and Assessment Preparation
The SSP is the primary artifact C3PAO assessors review before any on-site or remote assessment activity. NIST SP 800-171A provides the assessment procedures that C3PAOs follow. For the IA domain, the SSP must describe — with specificity — how each practice is implemented, not just assert that it is met.
A common SSP weakness in the IA domain is describing controls at the technology level without connecting them to the people and process dimensions. An SSP that says "MFA is enforced via Azure Active Directory conditional access policies" addresses the technology dimension. To fully satisfy assessors, it also needs to describe how new users are identity-proofed before accounts are created, how accounts are reviewed periodically, and how terminations are processed — because IA practice implementation spans all three dimensions.
For contractors preparing for their first Level 2 C3PAO assessment, the sequence that reduces rework is: (1) inventory all identities with CUI system access — including service accounts, contractor personnel, and subcontractor users; (2) document the identity proofing process for each identity type; (3) map each account to a uniquely verified individual; (4) produce access review records demonstrating the review cadence. This sequence aligns with how assessors step through the IA domain.
For broader context on how NIST SP 800-53 IA controls relate to contractor identity requirements across multiple frameworks, see our guide on the NIST SP 800-53 IA control family for federal contractors. For information on how identity controls integrate with FedRAMP-scoped cloud environments supporting contractor programs, see our article on defining the FedRAMP authorization boundary.
A Note on CMMC Level 3 and Advanced Requirements
CMMC Level 3, currently in final rulemaking, maps to a subset of NIST SP 800-172 practices layered on top of Level 2. The advanced practices in the IA domain under Level 3 include requirements for privileged account monitoring that goes beyond basic MFA — specifically, requirements tied to behavioral analytics and session monitoring for privileged users. While Level 3 affects a smaller segment of the DIB (primarily those supporting the most sensitive DoD programs), organizations on that trajectory should design their Level 2 identity infrastructure with Level 3 compatibility in mind: unique privileged account separation, session logging, and identity governance structures are all less expensive to architect in at Level 2 than to retrofit at Level 3 assessment.
Organizations that treat CMMC identity requirements as a compliance checkbox rather than a security architecture decision will face both assessment findings and operational security gaps. The IA domain practices exist because shared credentials and unverified identities in CUI environments represent genuine risk — a lesson the DIB learned through incidents that predated the CMMC program.