How authentik supports CMMC authentication for defense contractors
A defense contractor that handles controlled unclassified information (CUI) and expects a CMMC Level 2 assessment needs three authentication outcomes: multifactor authentication (MFA) for privileged accounts and network access, replay-resistant authenticators for network sign-in, and passwords that are cryptographically protected in storage and in transit. authentik can support IA.L2-3.5.3, IA.L2-3.5.4 and IA.L2-3.5.10 through configuration of its flows, policies, and authenticator stages, but configuration alone does not make a requirement met. Each requirement is assessed against the objectives in NIST SP 800-171A (June 2018), and a requirement counts as met only when every applicable objective is satisfied with evidence in final form. Note also that the Department of War suspended CMMC Phase II on 13 July 2026, so confirm the current schedule with the DoW CIO before you set your assessment date.
Start by mapping your privileged accounts, since IA.L2-3.5.3 first requires you to identify them. In authentik, that usually means listing the groups that hold administrative roles in the core console, the outposts, and the applications behind them, then attaching an MFA-requiring authentication flow to each. Test local access and network access separately, because the requirement lists them as distinct objectives. For replay-resistant authentication under IA.L2-3.5.4, confirm which authenticator types your users enroll and whether those types are assessed as replay-resistant against your own assessor's reading. For IA.L2-3.5.10, confirm that the PostgreSQL connections, the reverse proxy and every LDAP or RADIUS client carrying credentials are encrypted, and that authentik's password storage settings meet your assessor's expectations. Ask your vendor and your C3PAO to confirm each of these points against your environment.
DeployOpen plans, configures, documents and tests these controls in your infrastructure, and prepares the system security plan, configuration records and evidence that your assessor will review. DeployOpen does not issue CMMC certifications or attestations. Level 2 certification assessments are performed by C3PAOs authorized or accredited by The Cyber AB, and Level 2 self-assessments follow the same NIST SP 800-171A objectives. Where a requirement is not fully met at assessment time, the plan of action and milestones rules decide whether it can be carried forward. IA.L2-3.5.3 carries a higher point value and cannot go on a POA&M, while IA.L2-3.5.4 can, subject to the scoring thresholds in 32 CFR 170.24, which you should review in the eCFR with your counsel.
Which CMMC Level 2 identification and authentication requirements authentik touches
This table compares each CMMC Level 2 identification and authentication requirement in scope against its NIST SP 800-171A assessment objectives, what authentik can enforce for it, and what remains with your team. Read each row as a test an assessor will run, because a requirement is met only when every applicable objective has evidence in final form. The main takeaway is that authentik covers most network sign-in to applications, while local privileged access, privileged account identification and POA&M eligibility need decisions outside the platform.
| Requirement and objective | What authentik provides | What stays outside authentik or needs confirmation |
|---|---|---|
| IA.L2-3.5.3, identify privileged accounts | Group membership and policy bindings can record which users hold administrative roles. | Authentik does not decide who is privileged. Define the admin groups and review membership on a set schedule. |
| IA.L2-3.5.3, MFA for local access to privileged accounts | Not provided for local console or workstation logins. | Use OS or host-level MFA or privileged access tooling. Confirm the scope with your assessor. |
| IA.L2-3.5.3, MFA for network access to privileged accounts | Authentication flows with an MFA stage bound to admin groups can gate OIDC, SAML, proxy and RAC sign-in. | Confirm every admin application uses the flow. Keep flow binding exports and MFA login events as evidence. |
| IA.L2-3.5.3, MFA for network access to non-privileged accounts | The same flow can apply to all users for each application they reach. | VPN, Wi-Fi and firewall clients often use RADIUS or LDAP. Confirm which of these accept the MFA step. |
| IA.L2-3.5.4, replay-resistant network authentication | WebAuthn and passkeys use challenge-response signatures that resist replay. TOTP codes can be reused within their validity window. | Decide which authenticator types each group may use and document the choice. Confirm with your assessor how TOTP is treated. |
| IA.L2-3.5.10, passwords protected in storage | Credentials are stored in PostgreSQL, and password rules are set through policies. | Confirm the password hashing method in the vendor documentation for your version. Protect database volumes and backups. |
| IA.L2-3.5.10, passwords protected in transit | Sign-in runs over the HTTPS endpoint you publish, and LDAP can run over TLS. | Terminate TLS at your reverse proxy with current settings. Use LDAPS or StartTLS for each LDAP client and confirm it. |
| POA&M treatment for these requirements | 3.5.3 is not allowed on a POA&M. 3.5.4 may be placed on one for Conditional Level 2. | 3.5.4 needs at least 88 of 110 points and closeout within 180 days. Confirm 3.5.10 scoring first. |
What authentik evidence assessors can examine
An assessor testing IA.L2-3.5.3, IA.L2-3.5.4 and IA.L2-3.5.10 will look for proof that controls operate, not just that they were configured. The cards below cover the artifacts authentik can produce and the steps that keep them in the final form the CMMC rules require.
Configuration exports
Export the authentik configuration, including flows, stages, policies, providers and applications, and store each export with a date and the authentik version that produced it. Assessors compare these exports against the objectives of NIST SP 800-171A to confirm that MFA stages are bound where you say they are. Re-export after every change so the record matches the running system, and retain prior exports so changes can be traced.
MFA stage bindings
The most direct evidence for IA.L2-3.5.3 is a list showing which authentication stages apply to which applications and groups. Document MFA bindings for local privileged access, network access to privileged accounts and network access to non-privileged accounts as separate rows. Each binding should trace to a named group, so an assessor can match a privileged account to the factor it must use.
Authentication and MFA event logs
Authentication events, including successful logins, failed attempts and MFA challenges, show whether the controls operated over time. Confirm which events your deployment records and where they are forwarded, and test that a sample login produces the expected entry. Enhanced audit logging is an Enterprise feature listed on the authentik pricing page, so confirm with the vendor whether your edition provides the log detail you need before you design the evidence plan around it.
Password policy settings
For IA.L2-3.5.10, assessors check the password rules and the mechanisms that protect stored and transmitted credentials. Export the password policy stages and the password-related settings, and record how the deployment protects credentials in transit and at rest, including the TLS termination point. Password history is listed as an Enterprise feature on the pricing page, so confirm its availability in your edition before you cite it as a control.
Final-form evidence handling
Under 32 CFR 170.17 and 170.24(b), a requirement counts as met only when evidence is in final form, not in draft. Store exports and logs as read-only, dated records with a named owner, and do not edit them after review. Keep the supporting notes that explain each binding in the same final version as the export it describes, so the set reads as one consistent package.
When a POA&M can and cannot cover an authentication gap
IA.L2-3.5.3 cannot go on a POA&M, and IA.L2-3.5.4 can, under narrow conditions. The difference comes from the scoring in 32 CFR 170.24. Missing MFA for privileged or network access under IA.L2-3.5.3 subtracts 5 points if MFA is not implemented for any users and 3 points if it covers only remote and privileged users. Both values exceed 1 point, so 32 CFR 170.21(a)(2) does not allow that requirement on a POA&M. A gap in authentik's MFA enforcement for privileged accounts or network access is therefore a gap you must close before assessment, not a item you can defer. Replay-resistant authentication under IA.L2-3.5.4 is worth 1 point, so it is eligible for a POA&M in a Conditional Level 2 status if the total score is at least 88 of 110 (0.8), with closeout due within 180 days.
Treat that eligibility as a starting point and not a plan. Document the gap in the POA&M with the affected authentik scope: which applications, outposts or flows lack a WebAuthn or other replay-resistant authenticator for privileged or network access, and which compensating controls remain in place, such as MFA by TOTP that you can explain to an assessor as not meeting the objective. Record the authentik version and the configuration state you observed, using exports or screenshots of the relevant stages and policy bindings. Before you rely on the POA&M, confirm that your score meets the threshold using a current scoring worksheet, that the requirement is not hidden inside a broader MFA gap, and that you can state a credible closeout date within 180 days. Tell your assessor the scope you plan to close, and confirm how they treat partial implementation.
Do not treat the POA&M as a way to postpone the decision. Replay-resistant authentication for privileged accounts is also covered by the MFA requirement, so a gap there can change the scoring outcome for IA.L2-3.5.3 if MFA is missing. Confirm the current CMMC phase and assessment path with your contracting officer and assessor, because the Department of War has suspended Phase II and its published guidance on Phase 1 is in flux. This page does not give legal advice, and the treatment of any specific gap is for your assessor and counsel to confirm.
What authentik does not cover for CMMC
authentik can enforce MFA and password settings at the identity layer, but several CMMC Level 2 identification and authentication objectives sit with your organization, your operating systems and your assessor. The cards below separate those gaps so you can assign an owner to each before the assessment.
Identifying privileged accounts
The first objective under IA.L2-3.5.3 asks you to identify privileged accounts. authentik can tag groups and show who holds administrative roles, but it cannot decide which accounts are privileged for your environment. Build a documented list of privileged roles, reconcile it against authentik group membership and your directory, and keep the review dated so an assessor can sample it.
Local console and non-network MFA
authentik enforces MFA on the logins it handles, such as web sign-in and forward auth. Local logons to servers, workstation consoles and hypervisor hosts depend on the operating system and its own authentication stack. Confirm for each system class whether MFA applies to local access, and record where the control is provided by the platform rather than by authentik.
Replay-resistant authenticator choices
IA.L2-3.5.4 requires replay-resistant mechanisms, and the choice of authenticator type determines whether you meet it. TOTP codes can be phished within their validity window, while WebAuthn-based hardware keys and passkeys resist replay. authentik supports several factor types, but deciding which factors apply to which users, and which legacy clients (such as LDAP or RADIUS) are exempt, is a documented organizational decision.
Password storage in directories and clients
IA.L2-3.5.10 covers how passwords are stored and transmitted, but authentik does not control every directory or client that holds credentials. LDAP-bound applications, legacy services and synced directories may keep or pass passwords in forms you have not reviewed. Inventory each place a password is stored or sent, verify its protection independently, and treat password history and any other enterprise-only policy features as items to confirm against your edition.
Enterprise-only controls to price in
Some controls that help with credential management sit in the enterprise license, including password history and privileged access management. The pricing page lists them under Enterprise, separate from the open-source edition. Confirm which features your design depends on before the scope is written, and ask for a written statement of edition-specific coverage in your quote.
Certification, SPRS and affirmations
Certification assessments are performed by authorized or accredited third-party assessors, and SPRS postings and annual affirmations are made by the organization. Neither DeployOpen nor authentik produces the evidence of compliance on your behalf. Confirm the current CMMC phase and assessment requirements with your contracting office and an accredited assessor before you plan the evidence package.
Configuring authentik for the CMMC authentication requirements
This sequence takes an authentik deployment from a supported version to a set of configured controls and collected evidence for IA.L2-3.5.3, IA.L2-3.5.4 and IA.L2-3.5.10. Each step names the output an assessor or internal reviewer can check before the next step begins.
Confirm a supported authentik version
Before any configuration, confirm which authentik release line your organization will run. The authentik security policy lists 2026.5.x and 2026.8.x as the versions receiving security fixes, and the project announces security releases at least 24 hours in advance, so your change process needs a way to receive and apply those notices. Record the chosen version in your system security plan and compare it against the releases page before each change window. The output is a documented version decision with a named owner who watches for security advisories.
Deploy authentik inside the CUI boundary
Place the authentik server, worker and any outposts inside the system boundary that your system security plan defines for CUI. A deployment has a server container (core plus an embedded outpost), a worker container and PostgreSQL, which holds all configuration and data except uploaded files, so every component that stores or transmits authentication data must sit in scope. Confirm with your C3PAO or assessor how the boundary treats hosting providers, and confirm whether your hosting environment meets any cloud requirements that apply to your CUI. The output is a boundary diagram that lists each authentik component and where it runs.
Run PostgreSQL as a managed production database
The authentik Docker Compose guide positions Compose for test setups and small-scale production, and the Kubernetes guide says the PostgreSQL bundled with the Helm chart is for demonstration and test environments. For a CUI deployment, run PostgreSQL as a separately managed service with its own access controls, backups and encryption settings, and document those settings in the boundary. If you are upgrading from a release before 2025.10, note that the 2025.10 release notes say authentik no longer uses Redis and that PostgreSQL connections may rise by roughly 50 percent, so size the database for that load. The output is a production database record that names its host, backup method and connection limits.
Define privileged and non-privileged groups
Create separate groups for privileged accounts, such as administrators of authentik, directory and application roles, and for standard users. IA.L2-3.5.3 requires you to identify privileged accounts before you can show MFA coverage for them, and NIST SP 800-171A assesses that identification as its own objective. Assign each account to exactly one of these groups, remove shared administrator accounts, and restrict who can change group membership. The output is a group inventory that maps each person and service account to a privileged or non-privileged role, with the approver for each change.
Bind MFA stages to every application and network provider
Attach an MFA authenticator stage to the authentication flow for each application and each network-facing provider, including VPN, firewall administration and remote access entries. Require MFA for local and network access to privileged groups, and for network access to non-privileged groups, since IA.L2-3.5.3 calls for these coverage points. Where a protocol such as LDAP or RADIUS cannot prompt for a second factor, document the compensating control and the reason it satisfies the objective, and confirm that approach with your assessor. Test each binding with one account from each group. The output is a coverage matrix listing every provider, the flow it uses, the MFA stage applied, and the test result.
Choose replay-resistant authenticators
IA.L2-3.5.4 calls for replay-resistant authentication for network access to privileged and non-privileged accounts. Prefer authenticators designed to resist replay, such as WebAuthn hardware keys or passkeys, for privileged accounts first, then decide how to handle remaining users. Check which second factors you configure against that requirement, because one-time codes sent by SMS or email are weaker against interception and may not satisfy the objective on their own. Confirm the classification of each authenticator with your assessor. The output is an authenticator decision record for each group, with the reason each choice meets or does not meet the objective.
Set password rules and confirm protected storage
Configure password policies in authentik so that passwords meet your organization's length, complexity and reuse rules, and confirm which of these settings are available in your edition. The authentik pricing page lists password history as an Enterprise-only feature, so check whether your edition includes it before you promise that control. For IA.L2-3.5.10, document that passwords are stored and transmitted only in cryptographically protected form, and verify this with your database and TLS configuration, because NIST SP 800-171A treats storage and transit as two separate objectives. The output is a password policy export and a short write-up that cites the storage and transport settings for each objective.
Configure event retention and export
Set how long authentik keeps authentication and configuration events, and forward them to the log system your boundary already uses. Retention must cover the period your assessor will sample, and the logs must show MFA events, failed logins and changes to group or flow membership. Enhanced audit logging is listed as an Enterprise-only feature on the authentik pricing page, so confirm whether your edition provides the events you need. Restrict who can read and delete the logs. The output is a retention setting, an export destination and a test event that you can find in the destination system.
Collect final evidence for each objective
Gather evidence against each NIST SP 800-171A objective for 3.5.3, 3.5.4 and 3.5.10, and make sure every item is in final form rather than a draft. A requirement counts as MET only when all applicable objectives are satisfied with evidence in final form, so include the coverage matrix, group inventory, authenticator record, password policy export, configuration screenshots and sampled logs. Where a gap remains, note it accurately. Under the scoring rules in 32 CFR 170.24, IA.L2-3.5.3 is weighted above the limit for a POA&M, while IA.L2-3.5.4 may be placed on one under the conditions in 32 CFR 170.21, so confirm your position with your assessor before you rely on a POA&M. The output is an evidence index that maps each objective to its artifact, owner and date of capture.
Where authentik sits inside a CUI environment
authentik sits in the CUI boundary as an identity service, so its placement decides which assets fall under CMMC scope. A deployment has a server container that runs core with an embedded outpost, a worker container for background tasks, and PostgreSQL, which stores all configuration and data except uploaded files. Since the 2025.10 release, authentik no longer uses Redis, so caching, tasks, sessions and WebSocket functions run on PostgreSQL. That makes the database a critical component for both availability and assessment: its backups, access and encryption need the same treatment as the identity service that depends on it. Confirm with your assessor how you will document the database and the host it runs on within your boundary.
CMMC scope follows your system boundary, not the vendor's product list. If authentik authenticates users who reach CUI, the authentik containers, the PostgreSQL instance, the reverse proxy and the hosts beneath them generally belong in the assessed environment, and any cloud service that hosts them needs to be evaluated on its own terms. Under 32 CFR 170.17(c)(5), a contractor may store or process CUI in a cloud service only if that service is FedRAMP Authorized at the Moderate baseline or higher, or meets equivalent requirements. Decide early whether authentik will run in your own data center or in a cloud account, and if it is a cloud account, ask the provider for its FedRAMP status and the specific services in scope.
FIPS-validated cryptography is an item to confirm, not assume. The authentik pricing page lists FIPS compliance for FedRAMP requirements under Enterprise Plus, so a FIPS commitment is part of a commercial agreement and should be requested in writing with the vendor. Ask which cryptographic modules are used in the build you plan to deploy, how they are validated, and whether that validation applies to the TLS termination, password storage and database connections in your design. Record the answers in your system security plan, since the assessor will look for them when reviewing cryptographic protection for stored and transmitted passwords.
Questions contractors ask before hiring help with CMMC authentication
What drives the cost of help with CMMC authentication controls?
The cost follows the written scope, which sets how much work the engagement covers. The main drivers are the number of applications to connect to authentik, the number of networks and access paths that need MFA (local console, VPN, remote administration), how many privileged accounts and groups must be mapped, and whether users come from an existing Active Directory, LDAP directory or other source that needs syncing. Work that recurs includes licensing and hosting. Ask for the quote to split one-time build, evidence preparation and any retainer for ongoing support, and to state which items are excluded. DeployOpen does not publish a price list, so the written scope is the basis for any figure.
How long does a CMMC authentication project take?
Duration depends on the written scope and your environment, not on a fixed template. Timing is shaped by how many systems and networks are in scope, how clean your directory data is, how many privileged accounts need review, change approval windows, and how quickly your team can test MFA with real users. Ask the provider to show the planned sequence, the client actions each phase needs, and the points where your team signs off. Confirm the dates against your own assessment schedule before committing to them.
What does our team need to provide for the engagement?
Plan for named owners on your side before the work starts. You will usually need an executive sponsor, an identity owner who approves group and role design, a network owner for VPN and remote access paths, and an application owner for each system being connected. Provide administrative access to the target environment, a current list of user groups and privileged accounts, and copies of your existing password and MFA policies. Name a contact who can speak with your assessor or C3PAO about evidence, so questions about scope or configuration are answered quickly.
Can we implement CMMC authentication controls ourselves?
Many organizations can, provided they have engineers who can operate identity infrastructure and who understand the assessment objectives they must satisfy. The harder parts are usually not the installation. They are mapping each requirement to a configured control, proving that MFA covers local and network access to privileged accounts, verifying that replay-resistant authenticators are used, and keeping evidence in final form. Check your internal capacity against those tasks, decide who will own the evidence file, and compare that with a fixed-scope engagement that lists exactly what is delivered.
Does the 2025 CMMC schedule change the authentication work?
The technical requirements do not change with the schedule. IA.L2-3.5.3, IA.L2-3.5.4 and IA.L2-3.5.10 still describe the same MFA, replay-resistance and password protection outcomes. What changes is when and how you may be assessed. The Department of War suspended CMMC Phase II on 13 July 2026, while Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. Because the schedule has been moving, confirm your current obligations with your contracting officer and your legal counsel before scoping the work.
Does DeployOpen certify that we comply with CMMC?
No. DeployOpen plans, implements and documents identity controls, and prepares systems and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB. Self-assessments are carried out by your organization. Ask any provider, including DeployOpen, to state in writing which parts of the assessment they support and which parts remain your responsibility or your assessor's.
Does authentik need an Enterprise license for CMMC authentication?
Confirm this against your requirements before scoping. The core authentik code is released under the MIT license, while code in the authentik/enterprise/ directory falls under a separate enterprise license. The pricing page lists some features as Enterprise only, including mTLS client certificate authentication, password history, enhanced audit logging and privileged access management, which may matter for password rules and evidence. Enterprise pricing is listed per user, with an additional charge for external users. Ask for the feature list you need to be checked against the current edition before the quote is written.
What evidence will an assessor ask to see for MFA and password rules?
Assessors check against the assessment objectives in NIST SP 800-171A, so expect to show which accounts are identified as privileged, which access paths enforce MFA, which authenticators are replay-resistant, and how passwords are protected in storage and transit. Typical evidence includes configuration exports, policy screenshots taken from the running system, group membership reports, and authentication logs. Evidence must be in final form, not drafts. Agree the evidence list with your assessor early so the engagement produces what they will actually request.
How the current CMMC schedule affects authentication work now
The Department of War suspended CMMC Phase II on 13 July 2026, which had been scheduled to start 10 November 2026 and would have required Level 2 certification assessments by C3PAOs for applicable contracts. The department also began a 60-day review by a CMMC Reform Task Force. For authentication work, the practical effect is that certification may not be the first external test of your MFA and password controls. Phase I self-assessments, SPRS postings, annual affirmations and the obligations under DFARS 252.204-7012 remain in place, so the controls described on this page still need to be implemented and documented now, whether or not a certification assessment is scheduled.
The requirement text itself is also in flux. NIST withdrew SP 800-171 Rev. 2 on 14 May 2024 when it published Rev. 3, but the CMMC rule still incorporates Rev. 2, and the Department of War said on 13 July 2026 that it will enforce Rev. 2 in the interim. The sources also disagree on the phase schedule. The DoW CIO "About CMMC" page, as of 17 October 2026, describes implementation as paused in Phase 1 and says it may only require self-assessments at Levels 1 and 2. The eCFR text of 32 CFR 170.3(e) still contains the original four-phase schedule. Treat the DoW CIO page and the eCFR as candidates, not as settled guidance, and check the Department of War suspension announcement for the current status before you set dates.
Before you scope an authentik rollout for CMMC, confirm three things in writing: which assessment type applies to your contract, whether Level 2 self-assessment or certification is the current requirement for the work you handle, and which version of NIST SP 800-171 your contracting officer and assessor will use. Ask your assessor how they want MFA and replay-resistant authentication evidence presented, including whether they expect the evidence in final form. Those answers determine whether an open item can go on a POA&M and on what timeline, so settle them before you commit authentik configuration, identity sources and evidence collection to a plan.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted authentik inside your own infrastructure, so the identification and authentication controls run where your CUI systems run. Each engagement starts from a written scope that maps authentik configuration to the CMMC requirements your assessor will test.
How we scope
- Inventory which systems hold or reach CUI and which accounts are privileged before any configuration starts.
- Agree in writing which applications, network access paths and local logons authentik will front, and which stay outside scope.
- Confirm with your C3PAO or internal assessor which evidence form they expect for IA.L2-3.5.3, 3.5.4 and 3.5.10.
- Record in the written scope which requirements are met at delivery and which, if any, are candidates for a POA&M.
How we build
- Deploy authentik in your infrastructure with its PostgreSQL database and worker container configured for the environment you choose.
- Configure MFA enforcement by group and application, separating privileged accounts from non-privileged accounts for network access.
- Set up replay-resistant authenticators for network access and verify the enrollment and recovery flows match the password and MFA rules you agreed.
- Test each configured control against the NIST SP 800-171A objectives in a staging environment before production cutover.
How we hand over
- Deliver configuration documentation that names each authentik setting tied to a specific CMMC requirement ID.
- Provide a test record showing the results for each assessment objective, with evidence captured in final form.
- Walk your administrators through privileged account handling, lockout response and how to export authentication event logs.
- Hand over an open-source operating runbook covering upgrades, backups and the security release process you will follow.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope delivery ends.
- Retainer scope can include reviewing authentik security releases and planning upgrades within your change control process.
- Re-test affected controls after configuration changes so the evidence in your SPRS-supporting records stays current.
- Ask any provider, including DeployOpen, to confirm how support scope, response expectations and quoted effort are defined in writing.
