Framework Evaluation Tool
Articles of CMMC Compliance
Identity Provider Evaluation
Affirmed Identity — July 2026
CMMC Level 3 incorporates all 110 practices of NIST SP 800-171 together with a defined subset of NIST SP 800-172 enhanced practices, spanning personnel, physical, media-protection, and many other domains well beyond any single product. But a smaller number of practices, drawn from the Identification and Authentication, Access Control, Audit and Accountability, and Configuration Management domains, do most of the work of distinguishing an identity provider that merely documents compliance from one that actually sustains it under attack. The question is whether a given identity provider satisfies the substance of those practices, continuously, or only the paperwork.
Identity and Identity Monitoring, from CMMC Level 2 to Level 3
CMMC Level 2 already requires phishing-resistant, replay-resistant multi-factor authentication (Rules One and Two) and audit logs that trace every action to an individual account, protected from the very administrators they audit (Rules Six and Seven). CMMC Level 3 raises the bar: identity-based access control in place of static role assignment (Rule Three), and two rules that separate real continuous assurance from a compliance snapshot, verification of security-critical functions through active penetration testing (Rule Nine, an NIST SP 800-172 enhanced practice), and monitoring of identity, access, audit, and configuration state that is genuinely continuous rather than periodic (Rule Ten).
When evaluating an identity provider, the Level 2 rules test whether basic identity hygiene is in place at all. The Level 3 rules test whether that hygiene is sustained, verified, and monitored continuously, for the life of a session, rather than assumed at login and left unexamined until the next audit.
Submitting that question to your favorite AI agent promptly delivers an answer. It's best done while sitting with heart medications at hand.
Try this prompt with your AI agent of choice, paste it in directly. Fill in your identity provider's product name in place of [identity provider name here] and its website domain address in place of [its website domain here]. For example: “Cisco Identity” at “https://Cisco.com” or “Entra ID” at “https://microsoft.com/”. Copy and paste the Articles of CMMC Compliance after “below this line”, and let the scoring begin.
Only care about identity? Scope the evaluation to identity-only Rules ↓ before copying, so the AI has nothing else to score in its answer.
Your AI Evaluation Prompt
Replace [identity provider name here] with the IdP name and [its website domain here] with the website describing it. For example “Entra ID” and “Microsoft.com”. Then copy the plain text Articles.
A review of the Articles of CMMC Compliance demonstrates that they are vendor-neutral and technology-agnostic, addressing the identity and monitoring principles that matter most when evaluating any identity provider against CMMC Level 2 and Level 3. They are intended to provide an objective framework for evaluating any solution, including our own.
We welcome comments, constructive criticism, and suggestions for improving the framework as the threat landscape and CMMC's phased rollout continue to evolve.
Use AI to Compare Providers
Replace the [identity provider name here] and [its website domain here] with the product name and website to be compared. The Pulse CA + Sentinel and AffirmedId.com defaults can be replaced. Then copy the plain text Articles.
The Articles of CMMC Compliance
Each Rule identifies a specific property a CMMC-conformant identity architecture should exhibit. Some will be fully met by your current identity provider. Some partially. Some not at all. That's normal, and expected.
This is not a pass/fail test. It's a diagnostic. The scoring paints a picture of identity assurance and continuous monitoring, one with shades of gray in most real-world environments. What matters is seeing clearly where coverage is solid, where it's thin, and where the gaps are. You can't close a gap you are unaware of.
Notice that where a Rule is either not met or only partially so, your agent often provides hints as to why and what needs to be done to reach Achieved state.
Each Rule below is tagged with its relevance to identity provider evaluation:
Scope this evaluation
You can't control how an AI agent formats its answer, but you can control what it's asked to score. Narrow the list, the copy button, and the prompt itself to only the identity-relevant Rules, so the response doesn't bury what you care about in Rules that belong to other parts of the architecture.
Showing all Rules. The prompt and copy text below include the full standard.
Rule One — Authentication Must Be Multi-Factor and Phishing-Resistant
Core IdP ResponsibilityCMMC Practice: IA.L2-3.5.3 (CMMC Level 2)
Every account with access to CUI, privileged or not, must be protected by multi-factor authentication in which at least one factor is resistant to phishing and credential replay. A password paired with an SMS code or a push notification a user can approve without scrutiny does not satisfy this rule in substance.
IdP relevance: This is the identity provider's foundational obligation: whether at least one authentication factor is cryptographically bound to a device or key such that it cannot be phished or approved by a distracted user.
Rule Two — Authentication Must Resist Replay
Core IdP ResponsibilityCMMC Practice: IA.L2-3.5.4 (CMMC Level 2)
The authentication mechanisms protecting network access to CUI must be resistant to replay: a captured authentication exchange, whether a token, a one-time code, or a biometric sample, must not be reusable by an attacker to gain access on a later occasion.
IdP relevance: Whether tokens and authentication exchanges are bound to a specific session, device, or cryptographic challenge such that they cannot be lifted and replayed is entirely an identity-provider property.
Rule Three — Access Control Must Be Identity-Based, Not Merely Role-Based
Core IdP ResponsibilityCMMC Practice: IA.L3-3.5.10 (CMMC Level 3)
Access to CUI and CUI-bearing system components must be governed by the verified identity and current state of the requesting party, not solely by a role or group assignment that does not change once granted.
IdP relevance: This is the Level 3 identity provider expectation stated plainly: access decisions driven by current, verified identity state, not a role fixed at provisioning time.
Rule Four — CUI Flow Must Be Controlled by Enforced Authorization
Enterprise-Wide, IdP ContributesCMMC Practice: AC.L3-3.1.3 (CMMC Level 3)
Movement of CUI between systems, users, or network segments must be governed by an authorization decision that is actually enforced at the point of flow, not merely documented in policy or approved in principle at an earlier time.
IdP relevance: The identity provider's authorization engine is one enforcement point among several; data-loss-prevention, network, and application controls share responsibility for enforcing CUI flow enterprise-wide.
Rule Five — External Connections Receive No Implicit Trust
Enterprise-Wide, IdP ContributesCMMC Practice: AC.L3-3.1.20 (CMMC Level 3)
Connections from external systems, whether a partner network, a remote contractor, or a cloud service, must be verified and controlled to the same standard as internal connections. No connection point is granted reduced scrutiny merely because it has connected before or belongs to a known partner.
IdP relevance: The identity provider contributes by re-verifying identity on every external connection rather than granting standing trust after onboarding; network and partner-management controls share the remainder of this obligation.
Rule Six — Audit Logs Must Enable Traceability to Individual Actors
Core IdP ResponsibilityCMMC Practice: AU.L2-3.3.1 / AU.L2-3.3.2 (CMMC Level 2)
Every action taken against a CUI-bearing system must be logged in sufficient detail, and with sufficient identity binding, that it can be traced to the specific individual account that performed it, not merely to a shared account, a service, or a general time window.
IdP relevance: Binding every logged action to a specific, verified individual, rather than a shared account or generic service credential, is a direct identity-provider capability and a common point of quiet failure.
Rule Seven — Audit Information Must Be Protected From Those It Audits
Core IdP ResponsibilityCMMC Practice: AU.L3-3.3.9 (CMMC Level 3)
Audit logs and the tools that manage them must be protected against modification or deletion by the same accounts and systems whose activity those logs record. An administrator who can alter the record of their own actions has defeated the purpose of the record.
IdP relevance: Whether the identity provider's own audit trail of authentication and access events is architecturally separated from the accounts it audits determines whether continuous identity monitoring produces evidence or a story an attacker can rewrite.
Rule Eight — Security Configuration Must Be Enforced and Continuously Verified
Core IdP ResponsibilityCMMC Practice: CM.L2-3.4.2 (CMMC Level 2)
Security configuration baselines must be both established and actively enforced, with ongoing verification that deployed systems remain in the compliant state, not merely configured correctly at the moment of initial deployment.
IdP relevance: For identity purposes, this Rule tests whether the identity provider ingests live device configuration and health signals as an input to authentication decisions, continuously, rather than checking device posture once at enrollment.
Rule Nine — Security-Critical Functions Must Be Verifiable Through Testing
Enterprise-Wide, IdP ContributesCMMC Practice: SI.L3-3.14.7, NIST SP 800-172 enhanced practice (CMMC Level 3)
The correctness of security-critical functions, authentication, access control, audit generation, must be demonstrable through active testing, including penetration testing, rather than asserted on the basis of design documentation alone.
IdP relevance: The identity provider's authentication, access-control, and audit functions are typically the target of this testing; the organization running the test, and acting on its findings, carries the remainder of this enterprise-wide obligation.
Rule Ten — Monitoring Must Be Continuous, Not Periodic
Core IdP ResponsibilityCMMC Practice: Cross-domain obligation defining CMMC Level 3
Monitoring of identity, access, audit, and configuration state must operate continuously, for the duration of an active session or an active deployment, not merely at login, at deployment, or at a scheduled review interval.
IdP relevance: This is the identity provider's most consequential Level 3 obligation: whether identity and device trust are evaluated continuously for the life of a session, or only at the moment of login.
Rule Eleven — Extension to Autonomous and Agentic Processes
Core IdP ResponsibilityCMMC Practice: Applies Rules One through Ten to non-human subjects
Autonomous and agentic processes acting on CUI on behalf of a human principal are subjects in their own right and are therefore subject to Rules One through Ten in the same manner as any human user. An identity provider that issues identity to, or governs sessions for, such processes must additionally ensure traceable origin (every agent traces to a specific, authenticated human principal), bounded inherited authority (an agent's authority over CUI never exceeds its principal's and contracts automatically as the principal's standing changes), and action-level observability (every discrete action against CUI is individually authorized and attributable, not merely the session as a whole).
IdP relevance: Where an identity provider brokers agentic AI access to CUI, this Rule is as central to its function as Rules One, Two, Three, Six, and Ten are for human sessions.
Plain Text Version (for AI Submission)
Copy this block and paste it into your AI prompt after the evaluation question above.
How Does Pulse CA Measure Up?
We built Pulse with these Rules as design requirements, not aspirational goals. Phishing- and replay-resistant dual-assertion authentication, identity-based access decisions in place of static roles, individually traceable and architecturally protected audit logs, and continuous, not periodic, monitoring of identity and device state, these are baked into the architecture, for human and agentic sessions alike.
Ask your AI agent to score us. We're not concerned about the answer.
Request a Demo → Read the Technical BriefPulse CA™ — AffirmedID at affirmedid.com — Copyright © June 2026