The Identification and Authentication Domain: verifying who and what reaches the environment

What the Identification and Authentication Domain Is For

The Identification and Authentication domain establishes how the CMMC environment knows who and what is trying to reach it. Identification answers the question of who is claiming access. Authentication answers the question of whether that claim is true. Together, the eleven requirements in the domain define the verification layer that every other access decision in the framework depends on.

The practitioner reading of IA is that it cannot be evaluated in isolation from Access Control. AC decides what identities are permitted to do. IA decides whether the identity claim is credible. A strong AC implementation operating against a weak IA foundation produces a compliance posture that breaks the first time an attacker acquires legitimate credentials. A strong IA foundation operating against weak AC permits authenticated access beyond what should be authorized. The two domains are evaluated together in practice because they protect the same assets against different kinds of failure.

For defense contractors preparing for CMMC Level 2 assessment, the IA domain is the area where most technical remediation work concentrates. Multi-factor authentication deployment, password policy alignment, identifier lifecycle management, and cryptographic protection of credentials all carry implementation complexity that the other administrative controls do not. The domain rewards early engagement because the technical work takes time to deploy, test, and validate across the full assessment scope.

The Structure of the 11 Controls

The eleven IA requirements organize into three clusters that reflect the different concerns within the domain.

The first cluster covers identification and core authentication. These four controls (3.5.1 through 3.5.4) establish the foundational requirement that users, processes, and devices are identified before access is granted, that the identity claims are authenticated, and that the authentication mechanisms meet strength requirements for multi-factor and replay-resistant behavior. This cluster is where most of the technical remediation work in the domain concentrates.

The second cluster covers identifier lifecycle. These two controls (3.5.5 and 3.5.6) address how identifiers are managed over time, including the reuse of identifiers after accounts are retired and the disabling of identifiers that have been inactive. The lifecycle cluster is small but important, because weaknesses here produce authorization gaps that neither AC nor the rest of IA can compensate for.

The third cluster covers password and credential protection. These five controls (3.5.7 through 3.5.11) govern how credentials are formed, stored, transmitted, and displayed. Password complexity, reuse prohibition, temporary password handling, cryptographic protection, and authentication feedback obscuring each address a different attack surface through which credentials can be weakened or exposed.

The first cluster establishes who is reaching the environment and whether the claim can be trusted. Identification is the easier half of the pair because it is mostly administrative. Authentication is the harder half because it carries technical and operational complexity that scales with the size of the environment.

IA.L2-3.5.1Identification

The organization must identify system users, processes acting on behalf of users, and devices. The control has three subjects. Users are the straightforward case. Processes acting on behalf of users address service accounts, automated agents, and API contexts. Devices address the identification of the equipment that connects to the environment. Findings often involve gaps in the process and device dimensions, because contractors focus on user identification and assume the other two are implicit in the systems they already operate.

IA.L2-3.5.2Authentication

The organization must authenticate the identities of users, processes, or devices as a prerequisite to allowing access to organizational systems. The control requires that every identity claim be verified before access is granted. The verification mechanism must be appropriate to the claimed identity. User authentication requires credential verification. Device authentication requires device-specific verification such as certificates. Process authentication requires machine-to-machine credentials managed under the same discipline as user credentials. The implementation must cover every access path, including ones that might otherwise be treated as implicitly trusted.

IA.L2-3.5.3Multifactor Authentication

Multi-factor authentication must be used for local and network access to privileged accounts and for network access to non-privileged accounts. This is one of the most discussed controls in the CMMC Level 2 set because it carries both high implementation complexity and significant operational impact. The requirement distinguishes between privileged and non-privileged accounts, between local and network access, and between the factor types that satisfy the multi-factor definition. The implementation must address FIPS validation of cryptographic components, the interaction with removable media restrictions under Media Protection, and the practical realities of manufacturing environments where hardware authenticators compete with other operational constraints. A separate practitioner analysis in the MFA implementation white paper addresses the specific conflicts and implementation patterns in depth.

IA.L2-3.5.4Replay-Resistant Authentication

Replay-resistant authentication mechanisms must be employed for network access to privileged and non-privileged accounts. The requirement addresses a specific attack pattern in which captured authentication traffic is replayed to gain access. Modern authentication protocols such as Kerberos and TLS-protected authentication channels satisfy this requirement through mechanisms such as time-based tokens, nonces, and session-specific challenge-response handshakes. Findings in this area typically involve legacy authentication paths that predate modern protocols or fallback mechanisms that permit weaker authentication when the primary mechanism is unavailable.

The second cluster addresses how identifiers are managed over time. Identifiers are created, used, disabled, retired, and sometimes reassigned. Each transition in that lifecycle creates an opportunity for the authorization chain to break if the transition is not controlled.

IA.L2-3.5.5Identifier Reuse

Reuse of identifiers must be prevented for a defined period. The concern is that an identifier associated with a retired user could be assigned to a new user, and any audit records, access grants, or references to the retired identifier would then apply to the new user. The defined period must be documented, and it must be long enough to cover the retention requirements for systems that reference the identifier. A thirty-day reuse restriction does not satisfy the control if audit records are retained for seven years.

IA.L2-3.5.6Identifier Handling

Identifiers must be disabled after a defined period of inactivity. The control addresses identifiers that remain active on systems long after the associated user has stopped using them. An active identifier that no one is watching is an attack surface that no one is defending. The defined inactivity period is an organizational decision that must be documented, and the enforcement must be demonstrated in practice across the full assessment scope. Findings frequently involve systems where the inactivity policy exists at a central identity management layer but specific systems have local accounts that fall outside the central enforcement.

The third cluster addresses how credentials are formed, stored, transmitted, and displayed. The five controls in this cluster each protect against a different credential-related weakness. Together they define the lifecycle of a credential from creation through use to storage.

IA.L2-3.5.7Password Complexity

A minimum password complexity must be enforced, and characters must change when new passwords are created. The control has two components. The complexity requirement addresses the character set and length that passwords must meet. The change-of-characters requirement addresses the reuse of substantial portions of a previous password when a new one is set. Modern password guidance has shifted toward longer passphrases over strict character class requirements, and contractors should align their policies with current NIST password guidance rather than with older composition rules that produced weaker passwords through predictable substitution patterns.

IA.L2-3.5.8Password Reuse

Password reuse must be prohibited for a specified number of generations. The specified number is an organizational decision, typically five or more, and it must be enforced technically rather than through policy alone. The concern is that users cycle through a small set of passwords, and a password that has been replaced can be restored on the next change cycle. The enforcement mechanism must remember enough previous passwords to make the reuse prohibition meaningful.

IA.L2-3.5.9Temporary Passwords

Temporary passwords for system logons must be allowed only with an immediate change to a permanent password. The control addresses initial account provisioning and password reset scenarios where a temporary credential is issued. The temporary credential must expire at first use, forcing the user to set a permanent password before the account becomes operational. Findings often involve help desk procedures that issue temporary passwords without the immediate-change enforcement, leaving accounts with credentials that the help desk still knows.

IA.L2-3.5.10Cryptographically-Protected Passwords

Passwords must be stored and transmitted only in cryptographically protected form. Storage must use salted hashing with algorithms that meet current standards. Transmission must use encrypted channels such as TLS. The control also addresses older authentication protocols that transmit passwords in weakly protected form, which are not permitted even when the external channel is encrypted. FIPS validation of the cryptographic modules is part of the evidence package. This control interacts with the SC domain, which governs the broader cryptographic requirements that IA inherits for credential handling.

IA.L2-3.5.11Obscure Feedback

Feedback of authentication information must be obscured. The control addresses the display of credentials during entry. Password fields must mask the characters being typed. PIN entry on shared displays must prevent shoulder surfing. Error messages must not reveal whether a username exists or whether the password component of the credential was wrong. The obscuring requirement extends across every authentication interface, including web applications, workstation logins, and any custom applications that handle credentials.

Where Identification and Authentication Intersects with Other Domains

IA is one of the most densely connected domains in the framework. Its output is consumed by nearly every domain that makes authorization or accountability decisions.

Access Control depends on IA as its identity source. AC decides what an identity can do. IA decides whether the identity claim is credible. Evaluation of the two domains is always joint in practice, because a failure in either renders the other ineffective.

Audit and Accountability depends on IA for the actor attribution in every audit record. Authentication events themselves become audit records, and the reliability of those records depends on the reliability of the authentication that produced them. The MFA prompts, failed login attempts, and privilege elevations that IA handles are among the most frequently reviewed audit events.

Configuration Management uses IA as the authorization source for change activity. The right to make a configuration change is an authenticated access right, and the authentication that permits the change is what makes the change attributable.

Personnel Security is the upstream source of most IA provisioning decisions. A new hire record triggers identifier creation under IA. A termination record triggers identifier disabling. The integrity of the IA lifecycle depends on the reliability of the PS events that feed it.

System and Communications Protection provides the cryptographic foundations that IA relies on for credential protection under 3.5.10 and replay resistance under 3.5.4. FIPS validated cryptographic modules, TLS implementations, and protected channels are SC responsibilities that IA inherits for its specific authentication work.

Media Protection intersects with IA through the hardware token question. Hardware authenticators used for MFA are portable devices that also fall under MP considerations for removable media. The MFA implementation white paper addresses this intersection in depth.

Common Implementation Pitfalls

Several patterns come up repeatedly in Identification and Authentication readiness work.

MFA configured with exceptions that swallow the control. Multi-factor authentication is deployed for most users, but specific accounts, specific systems, or specific access paths are excluded. Service accounts, emergency access accounts, legacy system connections, and "temporary" exceptions all accumulate until the MFA coverage has significant gaps. The 3.5.3 requirement is not satisfied by widespread but incomplete deployment. The assessment looks at the exceptions, not at the default coverage.

Device identification missing from the IA picture. User identification is in place, but the device dimension of 3.5.1 is not addressed. The systems cannot distinguish between an authorized device and an unauthorized one carrying authorized credentials, which means the authentication mechanism protects against credential theft but not against credential use from unexpected contexts.

Identifier lifecycle that depends on manual process. The 3.5.6 inactivity disabling is configured for the central identity management system but not for the local accounts on individual systems. The automated enforcement covers most of the environment, and the edges require manual review that does not consistently happen. A full account inventory and periodic reconciliation address this.

Password policies that meet the letter but not the intent of complexity requirements. The policy enforces a complexity rule that users satisfy through predictable substitution patterns that produce weak passwords in practice. Modern password guidance favors longer passphrases over strict complexity rules, and the 3.5.7 implementation should reflect that guidance rather than perpetuating older practices that produced predictable weaknesses.

Temporary passwords that become permanent. Help desk issues a temporary credential, the user accesses the account, and the temporary credential remains valid indefinitely because the immediate-change enforcement in 3.5.9 was never configured. The account effectively has a credential that the help desk also knows, which defeats the purpose of temporary credentials.

Cryptographic protection that does not extend to older protocols. TLS protects most of the credential traffic, but older authentication protocols on legacy systems still transmit credentials in weaker form. The 3.5.10 requirement covers the full environment, not just the modern portions of it. Legacy protocol use frequently survives multiple hardening cycles because the protocols themselves are wrapped in secure channels, and the weakness is only visible through protocol-level inspection.

Authentication error messages that reveal too much. Login failures produce messages that indicate whether the username existed, whether the password was the problem, or whether the account was locked. Attackers use this differential to enumerate valid usernames. The 3.5.11 obscuring requirement extends to the content of authentication feedback, not just to the masking of credential entry.

Where to Start

For an organization new to the IA domain, the first work is the identifier inventory.

The foundational deliverable is a complete list of identifiers in the CMMC assessment scope, including user identifiers, service account identifiers, and device identifiers. The inventory must cover central identity management and local identifiers on individual systems. Without this inventory, the lifecycle controls cannot be applied uniformly and the authentication controls cannot be evaluated against a known set of subjects.

The second deliverable is the MFA deployment plan. This is the single largest implementation effort in the domain, and it benefits from early planning because the operational and technical complexity surfaces during deployment rather than during design. The MFA implementation white paper provides a structured analysis of the conflicts and implementation realities that come up during deployment, including the interactions with media protection, mobile device management, and manufacturing environment constraints.

The third deliverable is the credential protection architecture. How passwords are hashed, how they are transmitted, how temporary credentials are handled, and how authentication feedback is obscured across every interface in the environment. The architecture document is the reference point for the cluster three controls and is valuable even in its initial form because it forces the organization to examine every authentication interface rather than just the primary ones.

With the identifier inventory, MFA plan, and credential protection architecture in place, the remaining IA controls become implementation work against a documented foundation. The evidence for assessment follows from the operational discipline the foundation enables.