Why authentik fits a public sector identity build, and where it needs a licensing decision
Agencies and contractors usually need sign-in to stay inside controlled networks, need to show assessors how access is granted and removed, and need to support login methods that federal programs require, such as smart cards and client certificates. authentik can be self-hosted in your own infrastructure, including the Docker Compose and Kubernetes deployment paths its documentation describes, so the identity service, its PostgreSQL database and its logs can stay under your control. Most of the code is published under the MIT license (SPDX: MIT), which is the part a platform team usually evaluates first. The code in the authentik/enterprise/ directory is covered by a separate enterprise license defined in that directory, and that split matters for a public sector build because several of the features it needs sit there.
Before the design is fixed, confirm which of your requirements the open-source edition covers and which need a paid edition. The authentik pricing page places mTLS client certificate authentication, Google Workspace and Microsoft Entra ID integrations, enhanced audit logging and password history in Enterprise, and lists FIPS compliance for FedRAMP requirements as an Enterprise Plus item alongside dedicated support with SLAs and multi-instance deployment support. If your agency needs client certificate or PIV-style login, FIPS-validated cryptography or an audit trail that assessors will accept, treat the edition as a scoping decision made early, with the subscription cost written into the quote. Ask the vendor to confirm in writing which capabilities apply to your deployment model, and ask DeployOpen to map each control requirement to a named feature in the written scope before any build begins.
Which public sector requirements shape the authentik build
This table maps each public sector requirement in scope to its source and to what it means for the authentik identity layer. Read each row as a question to settle before the build starts: which system holds the data, which identity controls the requirement touches, and what evidence an assessor will ask for. The main takeaway is that most of these requirements apply to the whole system around authentik, so the identity design has to be agreed with the compliance owner early.
| Requirement | What it asks for | What it means for the authentik build |
|---|---|---|
| NIST SP 800-53 Rev. 5 baselines | Low, moderate and high baselines under SP 800-53B select 149, 287 and 370 controls and enhancements respectively, in Release 5.2.0 (27 August 2025). | Confirm the baseline with the authorizing official first. Map access control, identification and authentication, and audit controls to specific authentik settings, flows and log exports. |
| FISMA and OMB Circular A-130 | Agencies protect federal information systems under FISMA, and Inspectors General independently assess agency system security and report to OMB. | Expect assessors to test the identity layer directly. Keep configuration exports, change records and access review results ready for an independent review. |
| CJIS Security Policy v6.1 encryption and scanning | Version 6.1 (effective 26 June 2026) requires FIPS 140-3 validated modules or AES with 256-bit keys for CJI in transit and at rest outside physically secure locations, and vulnerability scanning at least monthly. | Confirm which authentik edition and build provides FIPS-validated cryptography for TLS and stored secrets. Include the authentik server, worker, PostgreSQL and reverse proxy in monthly scanning scope. |
| 32 CFR 2002.14(h)(2) for CUI on non-federal systems | Federal agencies set requirements using NIST SP 800-171 for CUI on non-federal systems, unless the CUI category prescribes other safeguards. | If authentik will sign users into systems holding CUI and run outside agency networks, the agency will likely require NIST SP 800-171 controls for the identity provider as well. |
| CMMC Level 2 cloud rule under 32 CFR 170.17(c)(5) | A contractor may store or process CUI in a cloud service only if it is FedRAMP Authorized at Moderate or higher, or meets equivalent requirements. | Self-hosting authentik inside the contractor's own scope is generally assessed within that scope. Confirm with the assessor whether any hosted component, such as a managed database or backup service, falls under the cloud rule. |
| CMMC Level 2 assessment objectives | Level 2 is assessed against NIST SP 800-171A objectives, and a requirement is met only with evidence in final form. | Authentik configuration, role assignments and MFA enforcement need final, dated evidence. Draft runbooks and unsigned access reviews will not count toward a MET result. |
| NIS2 public administration scope | NIS2 covers central government entities regardless of size and lists public administration as a high-criticality sector. Member States may extend it to local administration, and it excludes national security, defense and law enforcement. | Confirm with the national authority whether the agency is in scope. Where it is, the identity provider falls under risk management and incident reporting duties, so logging and recovery procedures for authentik should be defined. |
| ADA Title II WCAG 2.1 AA for sign-in pages | State and local government web content and mobile apps, including contracted content, must meet WCAG 2.1 Level A and AA from 26 April 2027 for entities serving 50,000 or more people, and from 26 April 2028 for smaller entities and special districts. | Login, enrollment, recovery and consent pages built with authentik flows and branding are public web content. Test them against WCAG 2.1 AA, including custom styling and any MFA prompts. |
Which authentik modules and settings matter for government users
Agency employees usually authenticate against a directory they already own, so the main decisions are which source authentik reads from and which providers sit in front of agency applications. Directory-backed staff accounts keep joiner, mover and leaver actions in one authoritative place, and the provider choice determines how each application signs users in.
- Source of truth: Decide whether authentik reads from an LDAP directory or an upstream identity provider, and document which system owns account creation and deactivation.
- Protocol providers: Use OAuth2/OIDC or SAML providers for modern web applications, LDAP for applications that bind to a directory, and RADIUS where network equipment requires it.
- Proxy provider: Place legacy internal applications behind the proxy provider so they receive authentication without application changes.
- Enterprise-only identity connectors: The Google Workspace and Microsoft Entra ID integrations are listed as Enterprise features on the authentik pricing page, so confirm whether the agency's tenant requires them.
- Password history and audit logging: Password history and enhanced audit logging are Enterprise-only features on the pricing page, and both should be confirmed against the agency's retention and reuse rules.
Confirm each setting against the agency's written access standard before configuration begins, and keep a record of which system is authoritative for each staff attribute.
Contractors often hold accounts in their own company directories and need access to a narrower set of agency applications for a fixed period. The settings that matter here focus on federation boundaries, account expiry and which applications a contractor can reach, since the agency rarely controls the contractor's source directory.
- Federation boundary: Use SAML or OIDC federation with the contractor's identity provider where it exists, so the agency does not create duplicate credentials.
- Scoped groups and policies: Limit contractor access with groups and policies tied to specific applications, and review them on the agency's schedule.
- Account expiry: Set expiry dates on accounts that are created directly in authentik for contractors without a federated source.
- Separate sources per contract: Keep contractor sources separate from employee sources so offboarding one contract does not touch staff accounts.
- Enterprise-only features: Confirm whether the Enterprise edition or the Enterprise Plus tier is needed for the controls the agency expects, using the pricing page as the starting point.
Ask the contracting officer and the agency security office which contractor populations are in scope before you design the source layout.
Members of the public or external partners who use agency services raise different questions. The main concerns are accessibility of sign-in pages, self-registration rules and what data authentik stores about them, since these users are not in an agency directory.
- Self-registration and recovery: Decide whether external users can enroll themselves or must be invited, and define recovery steps that the agency can defend.
- Accessibility of flows: Sign-in and recovery pages used by state and local entities may fall under the ADA Title II web accessibility rule, so test the flows against WCAG 2.1 Level AA.
- External user licensing: The pricing page lists a per-external-user charge in addition to the per-user rate, so count external users in the quote request.
- Data minimization: Limit the attributes collected at enrollment to what the service needs.
- Tenant boundaries: Keep external users separate from workforce groups so that policies for one population do not apply to the other.
Confirm the external user count, the applicable accessibility deadline for the agency's size, and the enrollment model with the program owner before design.
PIV or CAC login depends on client certificate authentication, and the authentik feature that handles mutual TLS is Enterprise-only according to the pricing page. Certificate trust chains, revocation checking and the mapping from certificate attributes to user accounts are environment-specific and must be validated in the agency's own network before anyone relies on them.
- Enterprise requirement: Mutual TLS client certificate authentication is listed as an Enterprise feature, so budget for that edition if PIV or CAC login is required.
- Trust chain and revocation: Confirm which certificate authorities the agency accepts and how revoked credentials are detected in the deployment.
- Certificate-to-account mapping: Define which certificate field identifies the user and how it maps to an authentik account.
- Reverse proxy and TLS termination: Check where client certificates are terminated, because the proxy in front of authentik must pass the certificate data correctly.
- Validation in your environment: Test with agency-issued cards and the agency's certificate authorities, since public documentation cannot confirm how a given PIV or CAC configuration behaves on the agency's network.
Ask the agency's PKI team for the certificate policy and a test card set before scoping the work.
How a government authentik rollout moves from design to evidence
This sequence turns a public sector authentik plan into a deployed, tested and documented identity service that the agency or contractor can operate and show to assessors. Each phase produces an artifact that the next one depends on.
Confirm the system boundary and data categories
The agency or contractor security lead, with DeployOpen, lists every application that will sign in through authentik, the data each one handles, and whether any of it is controlled unclassified information, criminal justice information or another regulated category. The output is a boundary diagram and a data inventory that name which systems fall inside the assessed scope. Confirm early whether any identity component would be a cloud service, because that changes which FedRAMP or equivalent authorization questions apply.
Choose the edition against FIPS and mTLS needs
Map each requirement to an edition before any build work starts. The authentik pricing page lists client certificate authentication over mTLS, privileged access management, enhanced audit logging and FIPS compliance for FedRAMP requirements as Enterprise-tier features, with FIPS listed under Enterprise Plus. Ask the vendor to confirm in writing which FIPS validation status applies to the exact release you will run. The output is a signed edition decision that cites each requirement it satisfies.
Build the air-gapped image and registry supply chain
DeployOpen builds an offline transfer path: container images, Helm charts or Compose files, PostgreSQL packages and their dependencies are pulled on a connected staging host, scanned, checksummed and moved across the boundary through the approved media process. Verify each artifact against the vendor's published checksums and record the software bill of materials. Confirm the release channel: supported versions and security fix timing are published in the authentik security policy, so the chosen version must sit on that list. The output is an internal registry and a signed transfer record.
Deploy with a separately managed PostgreSQL
The team deploys the server and worker containers inside the client network and connects them to a PostgreSQL service the client already runs or operates under its own controls. The authentik architecture stores configuration and data in PostgreSQL, and the Kubernetes guide recommends a separately managed database for production rather than the bundled test database. Confirm the connection count sizing after upgrades, since the 2025.10 release notes warn of higher PostgreSQL connection use. The output is a running deployment with backups confirmed and a restore test recorded.
Configure certificate login and MFA
DeployOpen configures the authentication flows, client certificate validation against the agency certificate authority, revocation checking, and the second factors the policy requires. Test PIV or CAC style smart card login with the certificate chain your PKI actually issues, and document which fallback methods exist and who can use them. Enable enhanced audit logging so that sign-in, policy and administrative events reach your log platform. The output is a configuration baseline in version control with a test matrix of login outcomes.
Run assessment-ready testing
The team tests access control, authentication strength, session handling, logging and recovery against the control requirements in the boundary. Tests cover negative cases such as revoked certificates, disabled accounts and blocked MFA attempts, and each result is linked to the control identifier it supports. Run vulnerability scanning on the deployed images and hosts at the frequency your assessment baseline requires. The output is a test report where each control shows its evidence, its tester and any open findings.
Hand over evidence and runbooks
DeployOpen delivers the architecture and data flow documents, configuration baseline, transfer and checksum records, test results, the vulnerability and patching process, and operational runbooks for upgrades, backup restores, certificate rotation and incident response. The client's assessors use this package to check controls, and DeployOpen does not issue audit reports or certifications. The client team confirms it can run the upgrade path and restore procedure without the partner present. The output is an accepted handover package and a named internal owner for each runbook.
How to deploy authentik in an air-gapped network
The hard part of an air-gapped authentik install is not the software itself but getting every artifact across the boundary intact. Container images for the server and worker, the Helm chart or Compose files, and any sidecar images must be pulled on a connected system, copied into a controlled internal registry, and checked before they are transferred. Record the digest of every image and file, verify those digests on the isolated side, and keep the transfer log with the change record. This is the same kind of evidence NERC CIP-013-2 expects for verifying the integrity and authenticity of vendor software before it enters a protected environment, and it is the discipline other offline-capable platforms describe in their own air-gapped guidance. Confirm with your security team which verification method they accept, such as signature checks or hash manifests, before the first transfer.
Sizing decisions come early. The Docker Compose guide calls for at least 2 CPU cores and 2 GB of RAM and positions Compose for test setups and small-scale production, so treat that as a floor for a pilot rather than a production target for a public-sector user base. The Kubernetes guide installs with Helm and states that the PostgreSQL bundled with the chart is meant for demonstration and testing, with a separately managed PostgreSQL recommended for production. In an isolated network, that means your PostgreSQL service, its backups and its patch process must also be mirrored and approved, so plan it as a dependency of the authentik deployment rather than an afterthought. Ask your platform team to confirm the sizing with the current release notes before procurement.
The component list is shorter than many teams expect. Since the 2025.10 release, authentik no longer uses Redis, moving caching, tasks, sessions and WebSocket functions to PostgreSQL. That removes one image family, one set of credentials and one backup target from the offline bundle, but it also means PostgreSQL connection capacity becomes a planning item, because the release notes warn of roughly 50% more connections after upgrading. Choose the authentik version you will mirror against the security policy's list of supported releases, and make sure the same version is mirrored for every upgrade step you expect to take, since later upgrades must be applied in sequence from a bundle you have also verified.
How authentik supports CMMC, NIST SP 800-53 and CJIS evidence
Public sector frameworks ask for the same identity facts in different words: who has access, how they proved who they are, and what was logged. The cards below separate what authentik configures and records from what an assessor must decide, so your evidence file reflects both.
Access control and audit logging
Access control evidence comes from who was granted which application, group and role, and from the events authentik records when those grants are used or changed. Enhanced audit logging is an Enterprise feature on the pricing page, so confirm it is included in the edition you plan to run before you design the evidence trail. Check that logs leave the cluster through a forwarding path you control, because an assessor will ask for records that outlive the instance.
MFA and client certificate authentication
Smart card and PIV login depends on client certificate authentication, which the pricing page lists as mTLS client certificate authentication under Enterprise. Confirm with the vendor that your certificate chain, revocation checking and PIV mapping work for your credential type in a test environment before you commit to a design. Record which factors each application requires, because access control assessments examine the policy as configured, not the policy intended.
FIPS 140-3 modules for CJI
CJIS Security Policy v6.1 requires FIPS 140-3 certified modules or FIPS 197 AES with at least 256-bit keys for criminal justice information in transit and at rest outside physically secure locations. FIPS compliance for FedRAMP requirements is listed as an Enterprise Plus extra, so ask in writing whether it covers the cryptographic modules your deployment actually uses, including the database and TLS termination in front of authentik.
CMMC Level 2 mapped to NIST SP 800-171 Rev. 2
Level 2 requirements are identical to NIST SP 800-171 Rev. 2, counted as 110 requirements, and assessed against the objectives in SP 800-171A. The Department of War suspended Phase II on 13 July 2026, so certification is not currently required, but Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. Confirm the current status with your contracting officer before you plan.
Who assesses and what DeployOpen provides
Level 2 certification assessments are performed by C3PAOs authorized or accredited by The Cyber AB, and Level 3 assessments are performed by DCMA DIBCAC. DeployOpen prepares configurations, control mappings and evidence packages for those assessments, but it does not issue audit reports, attestations or certifications. Ask your assessor which evidence formats and sampling approach they expect before the package is built.
What agencies and contractors ask before hiring a partner for authentik
What drives the cost of an authentik deployment for a public sector body?
The main drivers are the edition you need, the FIPS scope, the number of separate environments or enclaves, the certificate-based login integration, and the volume of evidence your assessor expects. Open-source authentik is free to download under the MIT license for most of the code, but the enterprise directory carries its own license. The pricing page lists Enterprise at $5 per user per month billed annually plus $0.02 per external user per month, and Enterprise Plus starting at $20k annually. Features such as mTLS client certificate authentication, enhanced audit logging and FIPS compliance for FedRAMP requirements sit in the paid tiers, so confirm the exact edition against each requirement before you scope the work. Ask any partner to price each environment and each evidence deliverable separately.
Can our in-house team run authentik for a government system without a partner?
Yes, many teams run it, but the question is whether they have the capacity for the work that is specific to government. Day-to-day operation covers upgrades within supported versions, PostgreSQL care, backups, monitoring and user lifecycle, and each of these needs a named owner. Authentik's security policy lists 2026.5.x and 2026.8.x as the supported versions receiving security fixes, so your team must track releases and apply security updates on a schedule. Assessment preparation adds control mapping, configuration records and evidence collection. Assess your team against those tasks honestly, and use a partner for the pieces you cannot staff, such as the initial hardening or the first evidence package.
What should a quote for an authentik public sector project include?
A quote should follow from written scope, and it should name each item you will receive. Ask for the list of environments, including connected, segmented and air-gapped networks, and the deployment method for each. List the identity sources to connect, such as directories, smart card certificate authorities and any upstream providers. Specify the applications to integrate, the number of users and external users, and the edition each feature requires. Include the evidence deliverables, the acceptance criteria and who signs them off. Finally, confirm which items are one-time work and which are recurring, so the budget reflects both.
Which parts of an authentik public sector deployment are recurring costs?
Recurring costs usually include the enterprise subscription if you use paid features, support or retainer work, and the ongoing effort of upgrades and patching. Subscription pricing on the authentik pricing page is annual for Enterprise, so budget for renewal each year. Patching within supported versions also recurs, because security releases are announced at least 24 hours in advance and must be applied promptly. Upgrades between versions require planning, since each release can carry breaking changes. Recurring evidence work, such as access reviews and log retention checks, also needs an owner. Ask a partner which of these are included in a retainer and which are billed separately.
Does DeployOpen issue FedRAMP, CMMC or NIST certifications for authentik?
No. DeployOpen plans, implements, hardens and documents systems, and prepares controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. For CMMC Level 2 certification, for example, assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB. For FedRAMP, authorization comes through the program's own process. Ask any partner to show how their evidence maps to the assessor's needs, and confirm the assessor's requirements before you start.
How do we confirm whether FIPS and FedRAMP apply to our authentik deployment?
Start with the contract and the system boundary, not the software. FedRAMP's scope covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency, so a system used only for one agency's operations on cloud infrastructure, not offered as a shared service, may fall outside it. For CMMC, a contractor storing CUI in a cloud service generally needs FedRAMP Authorized at the Moderate baseline or equivalent. Confirm with your contracting officer, your assessor and your own compliance lead which requirement applies to each component. Then ask the vendor which FIPS-related features are available in your edition, and verify them in a test environment before relying on them.
Does an air-gapped authentik deployment need a different approach from a connected one?
Yes. An air-gapped deployment needs every container image, package and dependency brought across the boundary and verified before use. Plan an offline transfer process with a documented review of each artifact, including its integrity and authenticity, since NERC CIP-013-2 addresses software verification in a similar way. Plan for updates as well, because each security release must be transferred, tested and applied on the isolated network. Authentik's Docker Compose guide positions that method for test setups and small-scale production, and its Kubernetes guide recommends a separately managed PostgreSQL for production. Confirm your offline image process and your PostgreSQL hosting with the team that will operate it.
Which identity sources and certificate integrations should we confirm before the project starts?
Confirm every source of identity and every credential type before scoping. List the directories that hold accounts, the provider types you need from authentik's documented set, such as OAuth2/OIDC, SAML, LDAP, proxy and RADIUS, and the smart card or PIV certificate authorities that must work for login. Ask whether client certificate authentication needs the mTLS feature in your edition, and whether revocation checks are required by your policy. Document the attributes each application expects, because mismatched claims are a common cause of failed access. Test each path in a staging environment that mirrors production, and record the results as evidence.
What a DeployOpen engagement needs from your team
The fastest way to scope an authentik deployment for a government agency or contractor is to hand over a system boundary document before the first workshop. It should name every authentik component in scope (the server and worker containers, the PostgreSQL database, any outposts and the reverse proxy in front of them), the networks they sit on, and the enclaves or accreditation boundaries they must stay inside. Alongside it, provide an application inventory listing each system that will sign users in through authentik, the protocol it uses (OIDC, SAML, LDAP, proxy or RADIUS), and the user populations behind it, such as employees, contractors, administrators and any external partners. Those user groups determine which smart card, client certificate and MFA paths we design, so ask your team to confirm them early rather than after build.
For smart card and PIV login with client certificates, we need the details of your certificate authority: the root and intermediate chains, certificate revocation or OCSP endpoints, the certificate policies you accept, and who owns issuance. Also provide your existing system security plan, control narratives or assessment documentation for the systems in scope, since authentik configuration has to be mapped to the controls your assessor will read. Name one approver for change control with authority to accept configuration changes, access model decisions and evidence packages. Every fixed-scope engagement is agreed in writing before work starts, with deliverables and acceptance criteria listed, and ongoing support, upgrades and continuous testing are available as a retainer once the system is in production.
How DeployOpen scopes and delivers authentik for public sector clients
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For authentik in the public sector, the work starts with a written scope that fixes the edition, the protocols, the evidence set and the deployment boundary before any build begins.
How we scope
- Confirm the edition needed for each feature, such as mTLS client certificates, FIPS compliance or dedicated support, against the authentik pricing page before scope is written.
- Map each application to a provider type (OAuth2/OIDC, SAML, LDAP, proxy or RADIUS) and record which apps need smart card or PIV login.
- Define the deployment boundary, including air-gapped networks, data centers and the hosting of PostgreSQL, and agree who owns each component.
How we build
- Install authentik with Docker Compose or Helm in the client's environment, using a separately managed PostgreSQL for production rather than the bundled test database.
- Configure flows, policies, groups and certificate-based authentication, then test each login path with users holding the actual credentials they will use.
- Stage every package and container image carried across the isolated boundary, and record the integrity checks performed on each one.
How we hand over
- Deliver the configuration, runbooks, backup and restore procedures and an upgrade plan that follows authentik's sequential upgrade rule.
- Provide control mapping and evidence records for the scoped NIST SP 800-53 or CMMC requirements, written for the client's assessor to review.
- Walk the client's operations team through monitoring, log forwarding, lockout recovery and the procedure for applying security releases.
How we support
- Support after handover is available as a retainer covering upgrades, security release review and troubleshooting on the agreed scope.
- Ongoing work is priced from the written scope, so changes to editions, applications or boundaries are agreed in writing before they start.
- DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports, attestations or certifications, which independent assessors provide.
