The Identification and Authentication family is one of the most important parts of a CMMC Level 2 because every other control family assumes you already know who is accessing the environment, how they authenticated, and whether that authentication can be trusted.

If this family is weak, the rest of the environment becomes much harder to defend. Access Control depends on authenticated sessions. Audit and Accountability depends on being able to tie activity to a unique identity. System and Communications Protection depends in part on how authentication traffic is protected. In other words, if Identification and Authentication is misconfigured, problems tend to cascade into other parts of the assessment.

In Microsoft 365 GCC High, six of the eleven Identification and Authentication controls are largely supported by the platform. The remaining five require explicit tenant configuration. One of those five, 3.5.3 multifactor authentication, is especially important because it is a critical practice that cannot sit on a POA&M at the time of assessment. If MFA is not fully implemented where required, you are not assessment-ready.

This is Part 5 of the NIST 800-171 GCC High Configuration Guide. It assumes you already have a functioning GCC High tenant, understand the shared responsibility model, and are implementing against NIST 800-171  Rev. 2.

IA family overview

The Identification and Authentication family includes eleven controls, all focused on how users, processes, and devices are identified and authenticated before they are allowed to interact with the environment.

At a high level, the family breaks down into two categories. Six controls are largely supported by the platform because Microsoft Entra ID, Windows Hello for Business, and the broader GCC High identity stack already establish a secure identity foundation. The remaining five depend on what you configure in the tenant, especially around MFA, inactive accounts, password policy, and temporary password handling.

In practice, this means the family is split between platform capability and tenant responsibility. Microsoft gives you the identity system. Your organization still has to decide how strongly that system is enforced.

IA controls and CMMC scope

Before getting into individual controls, it helps to be clear about scope. The Identification and Authentication family applies to every asset inside your CMMC assessment boundary. If a system, user, process, or device is in scope, the way it is identified and authenticated is also in scope.

That matters especially in enclave architectures. An enclave can reduce the overall number of systems and users subject to full CMMC implementation, but it does not reduce the strength required inside that boundary. If you are using an enclave approach, IA controls still need to be fully implemented for every person, device, and workload inside the enclave, and authentication into the enclave itself needs to be defensible.

What GCC High configures by default

Several IA controls are largely satisfied by the underlying platform architecture. That does not mean they should be ignored. It means your task is less about configuration and more about understanding how the platform works, documenting it clearly, and collecting evidence that shows your tenant is actually using those built-in capabilities.

3.5.1 Identify system users, processes, and devices

This control requires the environment to identify users, processes acting on behalf of users, and devices that access the system.

In GCC High, Microsoft Entra ID provides that foundation out of the box. Each user is assigned a unique user object and UPN. Applications and services are represented through service principals and managed identities. Devices enrolled in Entra ID and Intune also receive unique identifiers. That means the platform can distinguish a human user from an application identity and from a managed device, which is exactly what the control is trying to establish.

What tends to cause trouble here is not the Microsoft platform itself. It is how organizations use it. Shared accounts, generic admin accounts, undocumented service principals, and unmanaged personal devices can all undermine what would otherwise be a strong platform-provided control.

The evidence for this control usually comes from your Entra user directory, enterprise applications, and registered devices list. Your SSP should also explain how identities are assigned and how shared credentials are prohibited.

3.5.2 Authenticate users, processes, and devices

This control focuses on authentication, not just identification. The requirement is that users, processes, and devices must prove their identities before being granted access.

GCC High satisfies much of this through Entra ID’s authentication stack. Users authenticate through modern identity protocols, applications authenticate through app registrations and service principals, and devices authenticate through Entra registration or join. There is no anonymous access path to core Microsoft 365 services such as Exchange Online, SharePoint Online, or Teams.

The most important nuance here is that while the baseline platform authenticates access, you still need to make sure your tenant is not allowing weaker paths that bypass modern controls. Legacy authentication protocols, embedded credentials in applications, and unmanaged device access are the places assessors most often probe.

Evidence usually includes sign-in logs, enterprise application configuration, and device compliance data.

3.5.4 Employ replay-resistant authentication

This control requires authentication mechanisms that are resistant to replay attacks. In other words, if an attacker captures part of the authentication exchange, they should not be able to reuse it to gain access later.

Entra ID’s modern authentication model supports this by design. OAuth 2.0 and OpenID Connect use time-bound tokens, nonce values, and other mechanisms that make replay more difficult. FIDO2 security keys and Windows Hello for Business strengthen this further by relying on device-bound cryptographic challenge-response rather than reusable secrets.

In most GCC High environments, the platform does the technical heavy lifting here. Your responsibility is to document the mechanism and make sure you are not reintroducing weaker authentication patterns through hybrid identity or legacy protocols.

3.5.5 Prevent reuse of identifiers

This control is concerned with preventing identifiers from being reused too quickly, particularly in ways that could create confusion or accidental overlap between old and new identities.

Entra ID helps here because object IDs are globally unique and not recycled. Deleted users remain in the soft-delete state for a retention period, which prevents immediate reuse of UPNs during that window. Devices and service principals follow similar uniqueness logic.

The important operational piece is that your account lifecycle procedure should define how terminated identifiers are handled and how long your organization waits before reusing aliases or usernames. Even if the platform provides technical protection, assessors still want to see that your process is intentional and documented.

3.5.10 Store and transmit only cryptographically protected passwords

This control requires that passwords be protected both at rest and in transit.

GCC High supports this at the platform level. Passwords in Entra ID are stored as cryptographic hashes rather than plaintext, and authentication traffic is protected by TLS 1.2 or higher. In hybrid environments, password hash synchronization also transmits protected values rather than raw passwords.

Where organizations get into trouble is usually not in the Microsoft cloud, but in hybrid identity, SMTP relay, or legacy on-premises systems that still allow weaker password handling. Your documentation should distinguish clearly between what Microsoft protects and what still depends on your own architecture.

3.5.11 Obscure feedback of authentication information

This requirement is straightforward. Password fields and authentication responses should not expose sensitive input or give attackers unnecessary information about whether a username is valid.

The Microsoft sign-in experience already supports this. Password input is obscured, and Smart Lockout messaging is designed to avoid confirming whether an account exists. FIDO2 and Windows Hello for Business also avoid exposing password material in the sign-in experience.

Your main job here is to make sure any custom applications that rely on Entra ID follow the same conventions. A strong Microsoft sign-in page does not help if a custom front end echoes passwords or reveals account existence during failed sign-in attempts.

The five IA controls you must configure yourself

This is the part of the family where most real implementation work happens. GCC High gives you the identity platform, but your organization still has to decide how aggressively it will enforce authentication requirements and how well those decisions are documented.

3.5.3 Use multifactor authentication

This is the most important control in the family and one of the most important controls in the entire framework. It requires MFA for network access to privileged and non-privileged accounts, and for local access to privileged accounts.

The biggest mistake organizations make is assuming Microsoft’s broader MFA direction applies automatically to GCC High. It does not. If you do not explicitly configure MFA enforcement in your GCC High tenant, you may have users who are registered for MFA but not actually required to use it.

The first step is to understand your current state.

From there, you need to do three things. First, define the authentication methods you actually allow, such as Microsoft Authenticator with number matching and FIDO2 security keys for privileged users. Second, create Conditional Access policies that require MFA for all users and stronger, phishing-resistant MFA for admins. Third, address the part many teams overlook: local privileged access. Conditional Access only covers cloud sign-ins. If administrators can log on locally to privileged systems, you need a defensible MFA mechanism there too, such as Windows Hello for Business, smart cards, or privileged workstations.

You should also configure MFA registration policies so users are forced to enroll, while explicitly excluding and documenting your break-glass accounts.

Assessors look closely at this control because it is easy to sound compliant without actually being compliant. MFA registration is not the same as MFA enforcement. Security Defaults are not the same as universal Conditional Access coverage. Break-glass accounts cannot just exist silently in the background. They need documented procedures, testing, and justification.

3.5.6 Disable identifiers after inactivity

This control requires you to define an inactivity threshold and disable identifiers once that threshold is reached.

Entra ID does not do this automatically for you, so you need to decide how your organization will enforce it. Some organizations use Access Reviews through Entra ID Governance. Others automate account disablement through PowerShell. Smaller teams sometimes use a monthly manual review process, but that is only defensible if it is documented and actually performed on schedule.

A common threshold is 35 days, which aligns well with common federal expectations and is usually easier to defend than something much longer. What matters most is that the SSP defines the threshold explicitly and that your evidence shows the process is being followed consistently.

Where teams get caught is usually not in the script itself, but in the surrounding process. Break-glass accounts need to be intentionally excluded and documented. Service accounts need justification. And if the process exists only in a policy document but no one has actually run it in months, it will not hold up well under assessment.

3.5.7 Enforce minimum password complexity

This control requires your organization to define and enforce password complexity requirements.

In GCC High, password policy enforcement depends on whether your environment is cloud-only or hybrid. In cloud-only environments, Entra ID Password Protection and related authentication settings are your main tools. In hybrid environments, the effective password policy may still be enforced on-premises through Active Directory Group Policy, which means a weak on-prem policy can undermine what appears to be a stronger Entra posture.

Organizations preparing for CMMC should not simply accept the Microsoft defaults without reviewing them. In practice, assessors expect to see stronger minimum lengths than the old default baseline, along with a banned password list that blocks organization-specific terms and common weak patterns.

The evidence here usually comes from Password Protection settings, relevant Group Policy objects in hybrid environments, and SSP language that clearly states the organization’s minimum password length and complexity expectations.

3.5.8 Prohibit password reuse

This control requires your organization to define how many generations of passwords cannot be reused.

The implementation path again depends on whether you are cloud-only or hybrid. Hybrid environments can usually point to Active Directory password history settings directly. Cloud-only environments are trickier, because Entra ID’s password history behavior is not exposed in the same way traditional AD settings are. That means documentation matters more. You need to explain how the platform prevents reuse, what supplemental controls you have in place, and what your organization defines as acceptable password history protection.

This is one of those controls where assessors often respond poorly to vague language. Saying the platform handles it is not enough. Your SSP should specify the generation count your organization expects and explain how the environment enforces or approximates that requirement.

3.5.9 Require immediate password change for temporary passwords

This control focuses on account provisioning and resets. When a new account is created or a password is reset, the temporary password must require immediate change at first use.

Entra ID supports this natively through the force-change-at-next-sign-in flag, but the technical capability only helps if your provisioning and reset process uses it consistently. That means new user creation, bulk provisioning scripts, admin-driven password resets, and self-service password reset all need to align.

For new accounts and admin resets, the simplest answer is to make sure the force-change setting is always enabled.

The process side matters just as much as the technical side. Temporary passwords should be unique, communicated securely, and governed by a standard procedure. If different admins create accounts in different ways and only some of them apply the force-change flag, that inconsistency is likely to surface during assessment.

What evidence a C3PAO will usually want to see

For the IA family, evidence usually needs to show both platform behavior and tenant-level enforcement. In practical terms, that means screenshots, exports, policy views, and SSP language that all tell the same story.

At minimum, most organizations should expect to collect evidence such as user and device inventories from Entra ID, MFA registration and enforcement reports, Conditional Access exports, sign-in logs, password policy configuration, Access Review configuration or inactive-user review logs, and documentation for temporary password handling. Where a control is primarily platform-provided, the SSP should still describe how GCC High satisfies that requirement and point to supporting Microsoft service trust documentation where relevant.

The most common IA findings in real assessments

The single most common IA issue is incomplete MFA coverage. That can take several forms. Sometimes service accounts are still capable of interactive sign-in without MFA. Sometimes legacy authentication remains open. Sometimes administrators have MFA, but not phishing-resistant MFA. And sometimes the tenant has plenty of users registered for MFA even though policy enforcement is inconsistent.

Another common issue is failing to define inactivity clearly. Organizations say they disable stale accounts, but the SSP never states a specific threshold. That makes the process difficult to test and easy for assessors to challenge.

Password policy controls also cause findings when organizations rely on Microsoft defaults but cannot explain what those defaults are or how they align to the control requirement. The technical setting may exist, but if the organization cannot describe it clearly and show how it is governed, the implementation looks weaker than it should.

Shared accounts are another repeat issue. Even where the platform supports unique identification well, an organization can undermine that strength through generic admin accounts, shared service desk credentials, or loosely managed mailboxes that multiple people use interactively.

Finally, many teams do not document platform-provided controls well enough in the SSP. Assessors rarely accept that Microsoft provides a capability as a complete answer. They want to understand what Microsoft provides, how that capability maps to the control, and how your organization knows it is in use in your environment.

How the IA family supports other control families

Identification and Authentication is deeply connected to the rest of the framework.

Access Control depends on strong authentication because access decisions are only meaningful if the system can trust the identity making the request. Audit and Accountability depends on unique identities because log data loses value quickly if activity cannot be attributed to a specific user or process. Maintenance references MFA for nonlocal maintenance scenarios. System and Communications Protection overlaps with this family where authentication traffic and password handling depend on protected transmission paths.

Because of those dependencies, weaknesses in IA often show up later as findings in other families. That is another reason it makes sense to address this family early.

Get started with NIST 800-171 implementation

Configuring eleven controls is a project. Proving those controls are implemented, still enforced, and supported by current evidence is an ongoing operational task.

Secureframe Defense connects directly to your GCC High environment and continuously monitors the configurations that support the IA family, including MFA enforcement, inactive account handling, password policy settings, and authentication method coverage. When an assessor asks for evidence of 3.5.3 or 3.5.6, the goal is not to start pulling screenshots from half a dozen Microsoft portals. The goal is to already have that evidence organized and ready.

Schedule a demo to see how Secureframe Defense automates CMMC evidence collection across NIST 800-171 control families.