The Scoping Guide handles this through the SPA definition rather than naming identity products specifically. The relevant text from the Security Protection Assets/Security Protection Data section:
"Security Protection Assets provide security functions or capabilities within the OSA's CMMC Assessment Scope."
And from the Security Protection Data definition:
"Security Protection Data is security-relevant information which, if disclosed, could aid an attacker in the compromise of the system. It includes, but is not limited to: configuration data required to operate a security protection asset, log files generated by or ingested by a security protection asset, data related to the configuration or vulnerability status of in-scope assets, and passwords that grant access to the in-scope environment."
How the SPA definition applies to identity
Authentication is a security function. An identity provider that issues authentication credentials — Kerberos tickets, OAuth tokens, SAML assertions, FIDO2 credentials — for access to CUI Assets and SPAs is providing a security capability to the assessment scope. Under the SPA definition, that's a Security Protection Asset.
The same logic applies to:
- MFA services (Duo, Authenticator, RSA) that issue the second factor.
- Conditional access policy engines that gate authentication decisions.
- Privileged Access Management (PAM) tools that broker the credentials used to log into CUI Assets.
- Directory synchronization services (Entra Connect, AD Connect) that propagate identities.
What's documented and assessed
For each identity SPA, the OSA must:
- document it in the asset inventory;
- document its treatment in the SSP;
- include it on the network diagram of the CMMC Assessment Scope.
The Scoping Guide directs that SPAs are "assessed against Level 2 security requirements that are relevant to the capabilities provided." For an identity provider, that maps to the IA family (3.5.x), parts of AC (3.1.x), and audit/accountability practices (3.3.x) covering authentication events.
Architecture is the OSA's call
The Scoping Guide does not prescribe specific identity architectures. How you draw the boundary between an in-scope identity provider and the broader enterprise — native enclave identity, federated identity, hybrid — is the OSA's decision under Use of Enclaves. Whichever architecture you choose, the identity provider serving the CMMC Assessment Scope is in scope as an SPA. The Scoping Guide leaves to you the question of whether other identity infrastructure outside that boundary also gets pulled in by your architecture.
Common scoping mistakes
- Omitting identity from the asset inventory. Even when you correctly identify identity as an SPA, the SSP and inventory must reflect it.
- Forgetting MFA as a separate SPA. If MFA is delivered by a separate vendor or service, it's still an SPA.
- Excluding the directory sync server. Entra Connect / AD Connect typically hold privileged credentials and propagate identities across boundaries. They fit the SPA definition and need SSP treatment.
- Treating identity passwords and tokens as ordinary application data. Per the guide, passwords that grant access to the in-scope environment are Security Protection Data and are protected accordingly.