Open source SSO for CMMC identification and authentication

Which IA practices an identity provider must satisfy, and how to configure each

This table maps each CMMC Level 2 identification and authentication practice to the function an identity provider must perform, the NIST SP 800-171A objectives an assessor tests, and the Keycloak or authentik configuration that supports it. Read it as a checklist of what the identity provider can prove and what still needs endpoint, certificate or process evidence. The main takeaway is that identity configuration covers most of the IA family but not device identification on its own.

Which self-hosted identity platforms fit a CUI enclave

Four identity platforms are commonly considered for SSO inside a CUI enclave, and each one carries a different license, feature split and support model. The choice affects which CMMC identification and authentication practices you can evidence without relying on a paid tier or an unsupported configuration. Confirm each point below in writing with the vendor and your assessor before you commit.

How the identity provider fits inside the CUI enclave

Evidence assessors ask for from the identity layer

This table lists the artifacts an assessor is likely to request from a self-hosted identity provider for IA.L2-3.5.1 through IA.L2-3.5.4, and which component produces each one. Read each row as a question to answer before the assessment: can you export this artifact today, and does it show the final configuration rather than a draft? Assessors score a requirement as MET only when evidence is in final form, so treat every export as a dated snapshot tied to a change record.

What an identity provider alone does not satisfy

A self-hosted identity provider covers the authentication path for applications that speak SAML or OIDC. The assessment objectives for IA.L2-3.5.1 through IA.L2-3.5.4 also reach devices, local logins, legacy systems, shared accounts and vendor access, and each of those needs its own control and evidence inside the CUI enclave.

Questions buyers ask before hiring help with CMMC SSO

What to confirm with your assessor and contracting officer before you build

How an SSO rollout for CMMC proceeds in phases

The sequence moves from defining the CUI enclave and its accounts to a tested identity provider, enforced MFA and replay-resistant authentication, federated applications, and a pre-assessment review of evidence in final form.

1. Scope the CUI enclave and applications

   Start by defining which systems store, process or transmit CUI and which identities can reach them. Your team and the integration partner list every application in the enclave, note whether each supports SAML, OpenID Connect or only local login, and record the network paths between enclave and corporate networks. The step closes with a signed scope statement that names the systems in the assessment boundary, so every later control has a defined target.

2. Inventory accounts, groups and devices

   Build an inventory of user accounts, service and process accounts, privileged roles, and the devices allowed to authenticate into the enclave. Identify which accounts are privileged, which are shared or non-person, and where each identity currently lives, such as Active Directory, local directories or spreadsheets. The output is a reconciled identity register that maps each account to an owner, a role and a directory source, which becomes the baseline for IA.L2-3.5.1 and the privileged account list used for IA.L2-3.5.3.

3. Deploy the identity provider in a non-production environment

   Install the chosen identity provider, such as Keycloak, authentik or ZITADEL, inside the enclave's infrastructure, not in a shared external tenant. Decide the database platform, confirm it is one of the supported production databases for the product, and set the high availability design, including whether a synchronously replicated database is available across the nodes. Document the install method, version pinning and the upgrade approach, such as manual operator approval for Keycloak. The step closes when a non-production instance starts, survives a node restart in a test, and reports health metrics to your monitoring.

4. Configure MFA and replay-resistant factors

   Configure the authentication flows that cover privileged local and network access and non-privileged network access. Enable multifactor authentication for each path, and select replay-resistant factors such as FIDO2 or WebAuthn passkeys where the product supports them, with TOTP only where the assessment team accepts it. Confirm enrollment, recovery and token reset procedures, and document which factor each account class uses. The step closes with a test matrix that shows a login attempt for each account class and factor, with the result recorded.

5. Federate applications and enforce access

   Connect each enclave application to the identity provider over the agreed protocol, and remove or disable local accounts that duplicate central identities. Bind application access to groups or roles rather than individual grants, and block direct logins that bypass the identity provider where the application allows it. Applications that cannot use SAML or OpenID Connect need a documented compensating path, such as a proxy or a jump host, and an owner who accepts the residual risk. The step closes when each in-scope application passes a login test through the identity provider and a disabled-account test.

6. Collect evidence in final form

   Export and retain the artifacts that show each requirement is operating: configuration exports, realm or policy settings, MFA enrollment reports, audit logs of authentication events, the account inventory and the test records. Store them as final, dated and signed versions under change control, because the assessment treats draft evidence as insufficient. Map each artifact to the matching assessment objective for IA.L2-3.5.1 through IA.L2-3.5.4 so reviewers can find it. The step closes with an evidence index that the control owner has reviewed.

7. Run a pre-assessment review

   Before any formal assessment, walk through the requirements against the NIST SP 800-171A objectives with an internal reviewer who did not build the system. Check each objective for a configured control, an operating record and a final-form artifact, and log gaps in a plan of action with owners. Confirm with your assessor or the assessment body which evidence formats they accept. DeployOpen prepares systems and evidence for review but does not issue assessment results. The step closes when the gap log is empty or each open item has an accepted plan and owner.

Where to read the control text and the current CMMC status

This sequence points the team to the authoritative control text and the current program status before any design decision is made, so the identity provider is scoped against requirements that are final and dated. Each step ends with a written record that the team can trace back to a source.

1. Read the NIST SP 800-171 Rev. 2 requirement text

   The compliance lead and the identity architect read the Identification and Authentication family in NIST SP 800-171 Rev. 2, focusing on requirements 3.5.1 through 3.5.4. This is the control language that CMMC Level 2 incorporates, so it defines what the identity provider must support. Done when the team has a one-page list of each requirement in its own words, with the identity-related duties it creates.

2. Map requirements to assessment objectives

   Next, the same team reads NIST SP 800-171A, which breaks each requirement into the points an assessor checks. Requirement 3.5.3 has separate objectives for privileged local access, privileged network access and non-privileged network access, so the design must address each one. Done when every objective has a named owner and a candidate piece of evidence, such as a configuration export or an access log.

3. Confirm the program rule and CMMC levels

   The compliance lead reads the CMMC Program rule in 32 CFR Part 170 to confirm that Level 2 is NIST SP 800-171 Rev. 2 for controlled unclassified information and how the requirement identifiers are formatted. The rule also governs scoring, plans of action and how assessments are conducted. Done when the team has recorded which sections apply to its contracts and which assessment path its sponsor expects.

4. Check the current program status with the DoW CIO

   The compliance lead checks the DoW CIO About CMMC page for the current implementation status, because that page is maintained by the program office. The team should confirm with its contracting officer which requirements apply to current solicitations. Done when the team has a dated note stating the implementation status it checked and the person who confirmed it.

5. Review the 13 July 2026 Department of War release

   The compliance lead reads the Department of War release of 13 July 2026, which suspended Phase II and started a review. The release states that Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place, which affects what evidence the team must keep now. Done when the team has listed which obligations are active today and which timelines are on hold.

6. Record conflicts between sources for counsel

   The team compares the DoW CIO statements with the eCFR text, because the regulation text may still show the original phase schedule while the program office describes a different status. Where sources disagree, the team does not pick one silently. Done when a short memo lists each conflict, the source for each side and the question sent to counsel or the contracting officer.

7. Set the scope baseline for the identity design

   With the requirement, objective and status records in hand, the architect defines which accounts, applications and networks the identity provider will serve inside the CUI enclave. This baseline becomes the reference for every later design choice. Done when the scope statement is signed by the compliance lead and the identity owner, and it cites the source documents by title and access date.