Okta alternative for US government and FedRAMP environments

Okta alternative for US government and FedRAMP environments: when self-hosting is the right answer

Okta for Government High holds FedRAMP High authorization, so an agency or contractor that buys it inherits a large set of controls already assessed at the cloud service level. Running a self-hosted identity provider inside your own authorization boundary is a control-ownership decision, and it does not carry that authorization over to your deployment. FedRAMP's scope covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. A system used only for one agency's own operations on cloud infrastructure, and not offered as a shared service, is out of scope, so your authorizing official decides its acceptance through the agency's own process. Confirm how the FedRAMP scope rules apply to your architecture before you assume either outcome.

The short answer is that Keycloak, authentik and ZITADEL can each run inside the client's boundary, on the client's cloud accounts, data centers or air-gapped networks. Keycloak is Apache 2.0 licensed and supports PostgreSQL 14 to 18 in production, while ZITADEL self-hosts on PostgreSQL 14 or later. The client then owns the controls Okta would otherwise inherit: identity server configuration baselines, access control and audit logging, patching of the identity server and its database, backup and restore, high availability, and the cryptographic modules used for authentication. Under NIST SP 800-53 Rev. 5, each control is assigned to a system owner, a provider or a shared responsibility, and for a self-hosted identity provider most identity controls fall to your side of that line. Check whether the free authentik edition meets your FIPS needs, since the pricing page places FIPS compliance in Enterprise Plus.

Before you choose, run three checks. First, document what identity data the system will hold, because CUI and criminal justice information bring their own handling rules, including the FIPS 140-3 requirement in CJIS Security Policy version 6.1 for CJI outside physically secure locations. Second, map each control Okta would have inherited to a named owner in your control inventory. Third, ask each vendor in writing which cryptographic modules are FIPS 140-3 validated for the exact version you plan to run. Contractors pursuing CMMC Level 2 should ask their assessor whether the identity system sits inside their own assessment scope. DeployOpen can prepare systems, configuration and control evidence for these assessments, but independent assessors and authorizing officials make the authorization decision.

What FedRAMP, NIST SP 800-53 and CMMC require from an identity provider

FedRAMP, NIST SP 800-53, CJIS and CMMC each set requirements on the system and on the organization that owns it, not on a product. An identity provider inherits those requirements once it sits inside an authorization boundary, so the cards below show which obligations an identity service has to meet and who answers for them.

FedRAMP scope under M-24-15

FedRAMP applies to cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. A system used only for one agency's own operations on cloud infrastructure, and not offered as a shared service, falls outside that scope. A self-hosted Keycloak or authentik instance run solely for one agency therefore may not need FedRAMP authorization, while a managed identity service serving several agencies does. Confirm the scope determination with your authorizing official before you choose the architecture.

NIST SP 800-53 baselines and ownership

SP 800-53 Rev. 5 defines low, moderate and high baselines that select 149, 287 and 370 controls and enhancements respectively. For an identity provider, the authorizing agency or contractor owns the controls on the system, including account management, authentication, audit logging and configuration management, and may inherit some from the hosting platform. Map each control to a named owner in your system security plan. Under FISMA, Inspectors General independently assess agency system security and report to OMB, so expect that scrutiny of your identity controls.

CJIS v6.1 cryptography for criminal justice data

CJIS Security Policy version 6.1 took effect on 26 June 2026 and requires FIPS 140-3 certified cryptographic modules, or FIPS 197 AES with at least 256-bit keys, for criminal justice information in transit and at rest outside physically secure locations. Identity traffic that carries CJI, along with stored credentials and session data, has to meet this bar. Ask your vendor or integrator which cryptographic modules and build of Keycloak or authentik are validated, and whether the FIPS mode you need is supported in the version you deploy.

CUI on non-federal systems under 32 CFR 2002.14(h)(2)

When a federal agency sets requirements for controlled unclassified information on non-federal information systems, it must use NIST SP 800-171 unless the CUI category's authority prescribes other safeguards. A contractor that runs its own identity provider to authenticate users of CUI systems will usually be expected to meet those requirements in its own environment. Document which identity components touch CUI, and confirm with the contracting officer which safeguards the contract requires.

CMMC Level 2 cloud rule

Under 32 CFR 170.17(c)(5), a defense contractor pursuing CMMC Level 2 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. This rule applies to the cloud service that holds CUI, so a self-hosted identity provider in your own assessed boundary is assessed within your scope instead. If you use a hosted identity service that touches CUI, confirm its FedRAMP status and baseline before you rely on it.

What FedRAMP covers and excludes for a self-run identity provider

The first question is whether the identity provider sits inside FedRAMP scope at all. FedRAMP's scope, set by OMB memo M-24-15, covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. Under the same scope statement, a system used only for one agency's own operations on cloud infrastructure, and not offered as a shared service, is out of scope. A Keycloak or authentik deployment that one agency runs in its own cloud account for its own workforce can therefore fall outside FedRAMP, while the same software offered to several agencies or to contractors as a common login service is likely in scope. Read the FedRAMP scope guidance and put the question to your authorizing official in writing, because the answer depends on how the service is shared, not on the software chosen.

Okta for Government High holds FedRAMP High authorization, but that authorization covers Okta's service and its boundary. It does not transfer to your environment. If you choose a self-hosted identity provider, you own the hosting platform, the operating system, the database, backups, network paths, key management, logging and the administrators who can change realms or policies. Those layers still need control evidence mapped to NIST SP 800-53 for your system security plan, whatever the FedRAMP outcome. Confirm which federal or contractor systems will depend on the identity provider for authentication, because a service that is out of FedRAMP scope can still be in scope for your agency's authorization and for contract requirements that name FedRAMP.

Before you commit, document the boundary in a short decision record: who consumes the identity service, whether any other agency or tenant shares it, which cloud account or enclave hosts it, and which parties can administer it. Ask the authorizing official to confirm the outcome and the controls you must evidence. DeployOpen can prepare the architecture, control mapping and evidence for that review, but the scope determination and any authorization decision belong to your authorizing official and the FedRAMP process.

Which open-source identity providers fit a government boundary

Keycloak is the broadest fit for a government boundary because it is licensed under Apache 2.0, supports OpenID Connect, OAuth 2.0 and SAML 2.0, and has built-in user federation with existing LDAP and Active Directory servers. It is a Cloud Native Computing Foundation incubating project, so its governance is open, but the project does not hold a FedRAMP or FIPS validation for the software itself.

Protocols and federation: OIDC, OAuth 2.0, SAML 2.0 and LDAP or Active Directory federation cover most agency and contractor applications without a second product.
Production databases: PostgreSQL 14 to 18 is supported, along with other listed engines. The development file database is not for production.
Operator and upgrades: The Keycloak Operator manages realms and clients as custom resources. The Operator documentation strongly recommends manual approval mode for updates, which fits change control in an authorized boundary.
Gaps to plan for: Realm export and import is documented with limits as a backup method and requires all nodes to be stopped, so backup design needs its own control evidence.
Confirm: Whether your team needs a FIPS 140-3 validated Java runtime and crypto module, and whether your chosen Red Hat build of Keycloak or other distribution carries the validation your CJIS or agency control set requires.

Ask the vendor or distributor in writing for the exact cryptographic module and its validation status before your authorizing official reviews the design.

Who owns each NIST SP 800-53 control when you self-host

This table compares which party carries each NIST SP 800-53 control family when Okta for Government High is used against a self-hosted Keycloak or authentik inside your own authorization boundary. Read each row as a question to put to Okta and to your assessor, since inheritance depends on the signed agreement and must be confirmed in writing. The main takeaway is that self-hosting moves most identity-layer controls, and their evidence, onto your own team.

Control family and ID	Okta for Government High	Self-hosted Keycloak or authentik
AC access control	Provider may inherit platform access controls under its FedRAMP High package; tenant admin roles remain yours	You own realm or tenant roles, admin access, client registration and least-privilege policy
IA identification and authentication	Provider operates the authentication service; you configure MFA and policies within it	You own MFA factors, password policy, federation trust, account lifecycle and re-enrollment
AU audit and accountability	Provider generates platform audit logs; you confirm retention and access to them	You own log generation, forwarding to your SIEM, retention periods and review evidence
SC-13 cryptographic protection	Provider states its cryptographic modules; confirm FIPS 140-3 validation for the exact service used	You select and configure TLS, signing keys and modules; confirm FIPS 140-3 validated modules for CJI use
SC-28 protection of information at rest	Provider encrypts its stored data; confirm the scope of encryption and key management in writing	You own database encryption, key storage, backup encryption and the 256-bit AES requirement for CJI
RA-5 vulnerability scanning	Provider scans its service under its continuous monitoring; you scan your own configuration	You own scanning of the identity servers, database and container images, at least monthly for CJI
CA and SI patching and monitoring	Provider patches the service on its schedule; you track the notices that affect your tenant	You own patching, Keycloak or authentik upgrades, change control and vulnerability tracking
Inheritance and evidence	Obtain the customer responsibility matrix and the inheritance statement from the provider	Assemble your own control implementation statements, configuration baselines and assessor evidence

How to deploy Keycloak inside the boundary under FedRAMP and CJIS constraints

This sequence takes a Keycloak deployment from scoping and control inheritance to a monitored, patched, and backed-up identity service that sits inside the agency or contractor authorization boundary.

Confirm scope and control inheritance
Before any build work, the system owner meets the authorizing official and the compliance lead to record which systems the identity provider serves, which data classes it touches (including any criminal justice information or controlled unclassified information), and which NIST SP 800-53 controls the organization will own, inherit from the hosting provider, or share. Ask the cloud or data center provider for its authorization package and control responsibility matrix. The step is done when a signed control ownership worksheet and a boundary diagram show every Keycloak component, database, log store and admin path inside the authorized scope. Confirm with the authorizing official whether FedRAMP applies to the hosting service, since FedRAMP scope turns on whether a cloud service is offered to agencies as a shared service.
Select the build and cryptographic modules
The platform team chooses the Keycloak release, the container or operator image, and the cryptographic modules that the boundary requires. CJIS Security Policy version 6.1 requires FIPS 140-3 certified modules or AES with at least 256-bit keys for criminal justice information in transit and at rest outside physically secure locations. Confirm with the assessor which FIPS 140-3 validated module the JVM, TLS stack and operating system use, and whether the Keycloak build enables FIPS mode for your environment. Record the chosen version and the approach for patching it. The step is done when the cryptographic inventory names each module, its validation status as published by NIST, and the key lengths used for TLS, database connections and token signing.
Deploy on a supported database with high availability
The team provisions a production database from Keycloak's supported list, with PostgreSQL 14 to 18 as the most common choice in the documentation, and never the development file database. Keycloak documents three high availability designs, and both supported designs require a synchronously replicated database, so the storage team must confirm synchronous replication across zones before go-live. Configure TLS between Keycloak nodes, the database and the load balancer, and test a node failure in the target environment. The step is done when a failover test in a staging copy of the boundary keeps logins working and the failover record is attached to the control evidence.
Run the Operator in manual approval mode
If the deployment runs on Kubernetes, the platform team installs the Keycloak Operator through Operator Lifecycle Manager, which the project recommends, and manages the Keycloak, KeycloakRealmImport, KeycloakOIDCClient and KeycloakSAMLClient resources as code. The Operator documentation strongly recommends manual approval mode for operator updates, so set the subscription so no upgrade installs without a reviewed change ticket. Store all custom resources in version control and require review before they are applied. The step is done when a test upgrade runs through the approval path and the change record shows who approved it and what release notes were reviewed.
Plan manual schema migration for large deployments
Keycloak migrates its database schema automatically at startup by default. For large deployments, the upgrading guide suggests that administrators apply the SQL themselves. The database team generates the migration SQL for the target version, reviews it, applies it during a change window, and then starts the Keycloak nodes on the new release. Keep the previous schema and a verified database backup available for rollback. The step is done when a rehearsal in staging shows the generated SQL, the apply time, and the post-upgrade login tests, and the production runbook names the person who approves each statement.
Back up the realm and database separately
Keycloak's realm export and import commands (kc.sh export and kc.sh import) are useful for configuration review and for moving realms, but the documentation warns that they have limitations as a backup and restore mechanism and that all nodes must be stopped while they run. Export is therefore not a backup plan. The operations team sets up scheduled, encrypted database backups with tested point-in-time recovery, and keeps a separate, versioned copy of realm configuration in source control. Confirm the backup retention and recovery objectives with the business owner and the assessor. The step is done when a documented restore into an isolated environment has been completed and the restored instance authenticates a test user.
Enable metrics, logging and monthly vulnerability scanning
The security team turns on Keycloak's metrics endpoint so that health, login and error counters feed the boundary monitoring stack, and it sends administrative and authentication events to the central log store that the assessor has approved. Configure the production options as described in the production configuration guide, including restricted hostnames and TLS. Schedule vulnerability scanning of the Keycloak image, the operating system, the JVM and the database at least monthly, which matches the minimum cadence in CJIS Security Policy version 6.1. The step is done when a sample scan report, an alert for a failed login spike and a log entry for an admin change are all visible in the evidence repository.
Assemble control evidence for the assessor
The compliance lead collects the artifacts that the assessor will ask for: the boundary diagram, the control ownership worksheet, the cryptographic module inventory, the Operator approval records, migration rehearsal notes, backup and restore test results, configuration baselines and scan reports. Map each artifact to the NIST SP 800-53 control it supports, and mark the controls inherited from the hosting provider with the provider's evidence reference. DeployOpen prepares these systems, controls and evidence, but independent assessors and the authorizing official decide whether the deployment meets the requirements. The step is done when the evidence index is complete and the assessor has confirmed the list of items in writing.

What assessors and contracting officers will ask to see

Assessors and authorizing officials judge a self-hosted identity provider by the records it produces, not by its feature list. The cards below cover the artifacts that tie Keycloak, the operating team and the hosting environment to specific controls. DeployOpen prepares systems, controls and evidence for these assessments, but independent assessors and authorizing officials issue the audit results and authorization decisions.

System security plan and boundary diagram

The system security plan states what the identity service is, which components sit inside the authorization boundary, and which external services it depends on, such as the LDAP or Active Directory source, the database, the MFA provider and the log pipeline. The boundary diagram must show every path that carries credentials, tokens and user attributes. Check that the plan names who administers the realm, the admin console and the database, because those roles define the access boundary.

Control inheritance matrix

The matrix shows which NIST SP 800-53 controls the cloud provider or hosting environment inherits, which the agency or contractor implements, and which are shared. A self-hosted Keycloak deployment inside your own boundary makes most identification and authentication controls your responsibility, not a provider's. Ask your assessor which baseline applies, and confirm each control row names an owner and a test method.

Cryptographic module validation records

Assessors will ask which cryptographic modules protect data in transit and at rest, and whether those modules carry FIPS 140-3 validation certificates. For CJI, the CJIS Security Policy requires FIPS 140-3 certified modules or FIPS 197 AES with at least 256-bit keys outside physically secure locations. Keep the certificate numbers for the TLS stack, the database encryption and the JVM or runtime the Keycloak server uses, and confirm FIPS mode is configured in the deployment rather than assumed.

Vulnerability scan results

Scan records show the scope, tool, date and findings for the Keycloak container images, the operating system, the database and the Operator. The CJIS Security Policy calls for vulnerability scanning at least monthly, and a FedRAMP-aligned program will expect the same discipline. Keep the remediation tickets alongside the scans, including accepted risks with a named approver and an expiry date.

Change and upgrade records

Keep a record of every change, including the Keycloak release in use. Version 26.8.1 was released on October 13, 2026, and the record should state the exact version, the release notes reviewed and the test evidence for each upgrade. Keycloak Operator documentation strongly recommends manual approval mode for operator updates, so the approval record for each change is part of the evidence. Ask how schema migrations were applied: automatically at startup or manually as SQL.

Backup and restore test records

Assessors look for proof that identity data can be recovered, not only that backups run. Keycloak realm export and import is documented with limitations as a backup mechanism and requires all nodes to be stopped while it runs, so the backup design usually depends on database-level backups. Keep dated restore test results that show a realm, its clients and its user federation settings came back intact, along with who ran the test and how long recovery took.

User lifecycle and access review logs

These logs show who was joined, moved and removed, which administrative actions were taken, and which accounts and privileged roles were reviewed on a schedule. Confirm that realm admin events and authentication events are retained and forwarded to the agency log system, and that the review records name the reviewer and the decision. Your assessor will sample joiner and leaver cases against directory records, so the source of truth for each account should be documented.

Common questions about replacing Okta for Government High

Does self-hosting Keycloak remove the need for FedRAMP?

No. Self-hosting changes who owns each control, but it does not remove the obligation. FedRAMP's scope covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. A self-hosted identity provider run only for one agency's own operations on cloud infrastructure, and not offered as a shared service, falls outside that scope. That exclusion does not automatically cover a contractor, a shared platform or a system that holds CUI or other controlled data. Your agency or assessor decides the authorization boundary. Under NIST SP 800-53, the agency still owns the controls for identity, authentication, audit logging and configuration, and must document how the self-hosted service meets them. Okta for Government High already carries a FedRAMP High authorization, so the trade is between inherited controls and controls you implement and evidence yourself.

What drives the cost and effort of a FedRAMP or NIST assessment?

The largest drivers are the size of the authorization boundary, the number of applications and user populations that depend on the identity provider, and how much control evidence already exists. Costs fall into one-time items (architecture and boundary design, control mapping to the chosen baseline, hardening, integration of each application, migration of users and policies, and the independent assessment) and recurring items (patching, monitoring, vulnerability scanning, log review, backups tested on a schedule, and continuous monitoring evidence). Independent auditors and certification bodies, not DeployOpen, issue any authorization or attestation. When requesting a quote, ask for the control baseline in scope, the list of applications and directories, the evidence each control needs, who performs each task, and which assessment costs sit outside the implementation scope.

What does the work need from our security and identity teams?

Expect the identity team to own the directory design, federation of existing sources, application client configuration, and the policy decisions for MFA, session lifetimes and account lifecycle. The security team owns control interpretation, logging requirements, vulnerability management, incident response procedures and the evidence package. Both teams need named approvers for the authorization boundary, change control for operator and Keycloak upgrades, and access to the production and staging environments. Early in the project, agree who signs off on each control statement, since a self-hosted service puts those statements in your hands rather than in a vendor's package.

How long does a migration from Okta to a self-hosted provider take?

No duration can be stated here without a written scope. The timeline depends on the number of applications, whether SAML and OIDC integrations need re-federation, how many legacy or header-based apps sit behind a proxy, the state of your directory, the number of control statements to document, and how many approvals the authorization boundary needs. Assessment timing is set by the assessor and the authorizing official, not by the implementation. Ask for a phased plan with milestones, dependencies and the approvals each phase needs, and confirm it against your agency's or contractor's own authorization calendar.

Can a defense contractor store CUI in a self-hosted identity provider under CMMC?

It depends on where and how the system runs. Under the CMMC program rule in 32 CFR Part 170, a contractor seeking Level 2 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. A self-hosted Keycloak or authentik instance running on infrastructure you control is not a cloud service provider in that sense, so it is assessed within your own scope. Identity data that carries CUI still falls under the NIST SP 800-171 requirements your contract cites. Confirm with your C3PAO and contracting officer how the system boundary is drawn, and whether the hosting provider you choose is itself FedRAMP Authorized.

Can our own team run a self-hosted identity provider without outside help?

Some teams can, especially those with strong Kubernetes or Linux operations, experience with OIDC and SAML, and a documented change process. Keycloak is Apache 2.0 licensed and publishes production guidance, a high availability design that requires a synchronously replicated database, an Operator for Kubernetes, and metrics. The harder parts are the assessment evidence, the hardening baseline, the tested backup and restore procedure, and keeping pace with releases. Keycloak's own documentation notes that its realm export and import has limitations as a backup mechanism and requires all nodes to be stopped during the process, so backup design needs real engineering. Identify which of these tasks your staff can own before deciding whether to bring in an implementation partner.

How do we export users and configuration from Okta?

Okta supports three documented routes for a list of active users: the Password Health report CSV in the Admin Console, the community Rockstar browser extension, or the List Users API with a filter. The API route is the most repeatable for a migration because it can be scripted and rerun. The export gives you user profile data, but it does not carry configuration. Application integrations, sign-on policies, group rules, authenticator enrollments and MFA settings must be recreated by hand in the new provider. Passwords cannot be exported from Okta in usable form, so plan for password reset or re-enrollment, and confirm the approach with your security team and the authorizing official before cutover.

Does moving off Okta for Government High affect our existing FedRAMP inheritance?

Yes, and the change should be documented before any cutover. Okta for Government High carries a FedRAMP High authorization, so controls for the service may be inherited from it today. Once you replace it, those controls become yours to implement, evidence and maintain, and your system security plan must reflect that change. Ask your authorizing official whether the change requires a significant change request under your agency's or contractor's process, and whether any Okta-dependent features, such as the Access Gateway or lifecycle connectors, need a substitute before you retire them.

How DeployOpen deploys identity inside a government boundary

DeployOpen plans and implements self-hosted identity platforms inside the client's own infrastructure, including air-gapped networks. For a US government or contractor environment, the work starts with agreeing which controls and evidence the client's authorization boundary needs, then building and documenting the identity service to match, with the assessment itself left to the client's assessors.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope lists which identity services, directories and applications sit inside the authorization boundary.
We map each relevant NIST SP 800-53 control to the party that owns it, whether the agency, the contractor or the platform.

How we build

We deploy Keycloak or another chosen platform in your cloud account, data center or isolated network, with the database and high availability design agreed up front.
We integrate LDAP or Active Directory federation, SAML and OIDC applications, and MFA methods the scope names.
We run security testing against the identity service and document the findings and fixes in the same engagement record.

How we hand over

You receive configuration documentation, control evidence mapped to the agreed control list, and runbooks for backup, restore and upgrades.
Backup and restore procedures are tested and documented, including the limits of realm export and import noted in the Keycloak documentation.
Staff are trained on administration, and patch and upgrade steps are written for your change control process.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the initial engagement.
We help prepare systems, controls and evidence for your assessment, but we do not issue audit reports, attestations or certifications.
Ask in writing which FedRAMP authorization status, if any, applies to the hosting environment and confirm it with your sponsoring agency or assessor.

Okta alternative for US government and FedRAMP environments