Okta alternative for air-gapped networks: what an isolated network needs from identity
On an isolated network, the realistic answer is a self-hosted identity provider running inside the enclave, and Keycloak is the most direct choice for most teams. It speaks OpenID Connect, OAuth 2.0 and SAML 2.0, federates with existing LDAP or Active Directory servers, and has no runtime dependency on a vendor cloud. authentik and FreeIPA are useful complements: authentik adds LDAP, RADIUS and proxy authentication for legacy apps, while FreeIPA brings Kerberos, an internal certificate authority and its own directory for Linux-heavy estates. Okta cannot fill this role. Its Workforce Identity suite is delivered as a cloud service, and even Access Gateway depends on Okta's cloud, so no part of that stack can be kept inside a network that has no route to the internet.
The first decision is where identities live. If Active Directory or FreeIPA already holds the user base, Keycloak should federate to it rather than copy it, so passwords and group membership stay under the existing directory owner. Confirm with your directory team which attributes Keycloak needs and whether service accounts can bind over LDAPS. Next, plan MFA that does not call out to a cloud. Keycloak's built-in one-time password and WebAuthn factors work offline, and hardware keys avoid any dependency on a phone network. Confirm which factors your policy requires and how recovery is handled when a token is lost.
Plan patching before go-live, because an isolated system cannot fetch updates on its own. Keycloak publishes four minor releases a year, and its Operator documentation strongly recommends manual approval mode for updates, so each release should be imported as a reviewed artifact with its checksums verified. Database schema changes also need a plan: Keycloak migrates automatically at startup by default, while large deployments often apply the SQL manually. Keycloak's own export and import tooling is not a complete backup mechanism, so schedule database backups inside the enclave and test restores. Ask your implementation partner to show the offline update path in writing before the design is approved.
What an air-gapped identity deployment must meet
An identity provider on an isolated network has to log users in, check MFA and resolve directory lookups without calling any outside service. The four requirements below cover the login path, the directory source, workstation and internal app authentication, and how software crosses the boundary, and each one is a decision your team must document before go-live.
No runtime dependency on SaaS
Every step of login, MFA verification and directory lookup must resolve inside your network. Okta is a cloud service, so its tenant cannot be reached from an isolated segment at all, and even hybrid components such as Access Gateway depend on it. Keycloak runs in your own cluster with its own database, so the check is simple: block all egress from the identity tier and confirm that a full login, MFA prompt and token refresh still succeed. Also confirm that email, SMS and push MFA channels either run on-premises or are removed from the design.
Federation with on-premises directories
Users usually already exist in an LDAP directory or Active Directory inside the boundary, so the identity provider should read from that source instead of holding a second copy in the cloud. Keycloak supports user federation with LDAP and Active Directory, and FreeIPA can serve as the directory where no Active Directory exists. Ask which attributes are read-only, how group membership maps to roles, and how disabled accounts are handled. Test password validation against the directory, since it determines whether users can change passwords from inside the boundary.
Kerberos and local MFA
Workstations and internal web apps often need single sign-on without a browser redirect to a login page. Kerberos through an Active Directory or FreeIPA realm provides that for domain-joined machines, and the identity provider can add local second factors such as one-time passwords or WebAuthn hardware keys. Confirm which applications need Kerberos, which need OIDC or SAML, and where the MFA enrollment and recovery process runs. Recovery must not depend on a phone network or an external SMS gateway.
Verified patch and image pipeline
Patches, container images and packages must be built or mirrored outside the boundary, scanned, signed or checksummed, and then carried in on approved media. Kubernetes offers a documented way to pre-pull control plane images and point installs at a private registry, and the Keycloak Operator can run from a mirrored catalog. For NERC CIP-013-2 covered entities, the procurement process must address verification of software integrity and authenticity for vendor software and patches. Outside that sector, use the same checks as internal policy. Keep manual approval for operator upgrades and test each Keycloak release against a copy of production before it crosses the boundary.
Which self-hosted identity options work offline
This table compares Keycloak, authentik, ZITADEL, FreeIPA and WSO2 Identity Server on the requirements that matter in an isolated network: offline installation, directory federation, Kerberos, protocols, licensing and support. Use it to shortlist candidates, then confirm offline installation support for each product in your own environment before committing.
| Requirement | Keycloak | authentik |
|---|---|---|
| Licensing | Apache 2.0, with no paid tier needed to run the core server | MIT core, with the directory integrations and FIPS compliance under the separate authentik EE License |
| Protocols | OpenID Connect, OAuth 2.0 and SAML 2.0 | OIDC, SAML, LDAP, SCIM, RADIUS, Kerberos and proxy authentication in the free edition |
| LDAP and Active Directory | Built-in user federation with existing LDAP and Active Directory servers | LDAP support in the free edition; Google Workspace and Microsoft Entra ID integrations are Enterprise features |
| Kerberos | Confirm Kerberos and SPNEGO support for your version and realm setup in your own test environment | Kerberos in the free edition, community support only |
| Offline installation | Confirm offline image, package and operator delivery for your chosen install method | Confirm offline container image and PostgreSQL delivery in your own environment |
| Support model | Community support in the open-source project; a commercial distribution is available from Red Hat | Community support in the free edition; ticket-based support and SLAs require Enterprise or Enterprise Plus |
How Keycloak runs offline with LDAP, Active Directory and Kerberos
Keycloak keeps identities inside the isolated network when you point its user federation at an existing LDAP or Active Directory server on that network. Keycloak reads users and groups from the directory and authenticates them against it, so the directory stays the system of record and no user store has to leave the enclave. Confirm with your directory team which attributes Keycloak maps, whether password validation happens by bind against the directory, and whether group membership is imported or read live, because those choices decide what happens when the directory is unreachable. Kerberos fits in front of that federation: a client holding a valid Kerberos ticket can sign in to Keycloak without typing a password, and Keycloak can fall back to the directory password where Kerberos is not available. Local MFA, such as Keycloak's built-in OTP and WebAuthn factors, is enforced by Keycloak itself after the primary factor, so it works without any external service.
Choose the database before you go offline, because Keycloak's supported production databases are MariaDB, Microsoft SQL Server, MySQL, Oracle Database, PostgreSQL (14 to 18), EnterpriseDB Advanced, Amazon Aurora PostgreSQL and Azure SQL. Your organization probably already runs and patches one of these internally, which keeps the database inside the same operational and backup process. The default dev-file database is for development only and should never hold production identities. Plan the database and any container or operator images in the same offline transfer as the server itself, since nothing can be pulled at install time.
Keycloak migrates its database schema automatically at startup by default. In a connected lab that is convenient, but on an isolated network it means a server upgrade can change the schema the moment a new node starts. For large deployments the upgrading guide suggests manual migration, where your database administrators apply the SQL themselves after review and under change control. Treat the schema change as a planned step in each upgrade window, with a tested database backup taken first, and check the upgrading guide for each release you move to. Keycloak's own export and import commands are not a substitute for that backup, as its documentation warns.
How to deploy Keycloak in an isolated network
This sequence takes Keycloak from an architecture decision to a running, federated, MFA-enabled identity service inside a network with no internet access, with a tested backup routine that does not depend on the realm export alone.
Confirm architecture, database and high availability design
The security architect and the platform team agree on the deployment model (a single server, a clustered deployment, or a Kubernetes deployment with the Keycloak Operator), the production database, and the availability target. Keycloak supports several production databases, including PostgreSQL 14 to 18, and the high availability designs both need a synchronously replicated database, so confirm that your isolated environment can host one. Record the Keycloak version you will install. The current release is 26.8.1, and the team should confirm it is the version it will certify internally before any package crosses the boundary. The step is done when a signed-off architecture note lists the components, the database engine and its replication model, and the owner of each one.
Build the offline package and image set in staging
In a staging zone that has controlled connectivity, the team assembles everything the isolated network will need: the Keycloak server distribution or container image, the database and operating system packages, JDBC drivers, the Keycloak Operator bundle if you use Kubernetes, and any theme or provider JARs. For Kubernetes, run kubeadm config images list to enumerate the control plane images, then kubeadm config images pull to fetch them, and push them to a private registry that the isolated cluster can reach. Pass that registry to kubeadm init with the --image-repository flag. Keep a manifest that lists every artifact with its version and checksum. The step is done when the manifest matches the staging contents and the private registry lists every required image.
Verify integrity before transfer
Before media or a data diode carries anything across the boundary, the security team checks each artifact against the checksums and signatures published by its source, and records who approved the transfer. This is the control that NERC CIP-013-2 describes for verifying software integrity and authenticity of vendor software and patches, and most isolated-network programs apply the same check to every package. Scan the container images and packages with the tools your program has approved, and keep the scan output with the manifest. Note that a clean scan on the staging side does not prove the artifact is safe once it is loaded offline, so the isolated side should re-verify hashes on arrival. The step is done when every artifact on the transfer media has a matching checksum in the approved manifest and a recorded approval.
Install Keycloak and its database inside the isolated network
The platform team installs the database first, then Keycloak. For a Kubernetes deployment, install the Keycloak Operator through Operator Lifecycle Manager, or with kubectl, from the offline bundle, and set the operator update approval mode to manual, which the Keycloak Operator documentation strongly recommends to avoid unintended upgrades. Create the Keycloak custom resource pointing at the internal database and the private image. Keycloak migrates its database schema automatically at startup by default. For larger deployments, the upgrading guide suggests applying the schema SQL manually, and you should decide that before the first start. Create the initial administrator through a controlled process and disable any default or development settings. The step is done when Keycloak starts, the admin console loads on the internal hostname, and the database shows the expected schema version.
Federate the internal directory and configure Kerberos
Connect Keycloak to the existing LDAP or Active Directory server with Keycloak's user federation, using a read-only bind account with the least directory rights that still allow authentication and group lookup. Map the attributes that applications need, such as username, email and group membership. If you use Kerberos for desktop single sign-on, configure the Kerberos realm, service principal and keytab that the directory team issues, and test ticket acceptance from a domain-joined client. If the identity source is FreeIPA, which combines 389 Directory Server, MIT Kerberos and SSSD, confirm the Kerberos and certificate settings with the directory team before you configure Keycloak. The step is done when a test user from the directory signs in through Keycloak with a password, and a test Kerberos login succeeds without a password prompt.
Configure local MFA and register client applications
Enable the one-time password and WebAuthn factors that Keycloak provides, and set the required actions for enrollment. Because the network cannot reach external SMS or push services, plan for authenticator apps, hardware security keys and any local RADIUS or token system you already run. Register each application as an OIDC client or SAML client, and test the login, logout and token lifetime settings against a staging copy of the application before cutover. Confirm that every application that must enforce MFA receives the expected authentication context. The step is done when a test user enrolls a second factor, signs in to each pilot application with that factor, and the audit log records the events.
Test failover and restore from a backup
Run a planned node or database failover in the test environment and confirm that sessions, clients and federation continue to work as the architecture note describes. Then restore a backup into a separate environment and verify that users, clients and realm settings are present. Keycloak's realm export with kc.sh export is useful for configuration, but the Keycloak documentation warns that it has limitations as a backup and restore mechanism and that all nodes must stop while it runs. Therefore, design the backup as a separate workstream that covers the database engine's own backup and point-in-time recovery, the configuration as code, and any secrets and certificates the server needs. The step is done when a documented restore completes in the test environment and the team has measured the outage the procedure causes.
Set up export, backup and patch routines
Document the recurring tasks: scheduled database backups, periodic configuration exports during planned maintenance windows when all nodes can be stopped, monitoring through Keycloak's metrics, and a patching process that brings each approved release into the staging zone, verifies it, and carries it across the boundary. Keycloak's project plans four minor releases a year and says breaking changes in minor releases will be opt-in, which helps the team plan its change windows. Assign an owner to each routine and store the runbooks inside the isolated network. The step is done when the runbooks are approved, the first scheduled backup has completed, and the first patch cycle has been rehearsed end to end.
Keeping Keycloak patched without internet access
Keycloak now ships four minor releases a year, and the project says breaking changes in a minor release are opt-in, which makes patching a routine operational task rather than a yearly project. The current release in the supplied facts is 26.8.1, published October 13, 2026. Your air-gapped process should assume a steady stream of minor updates, each of which must be imported, tested and approved before it reaches the production enclave. Build a test enclave that mirrors production in Keycloak version, database engine, realm configuration and LDAP or Active Directory federation. Run each upgrade there first, verify logins with each MFA method and each federated application, and only then carry the approved image and artifacts across the boundary. Read the Keycloak upgrading guide for every release you skip, since opt-in changes still need to be reviewed.
If you run the Keycloak Operator, keep manual approval mode enabled for operator updates, as the Operator documentation strongly recommends. Automatic upgrades cannot be reviewed on a network that cannot reach the upstream registry or check what changed, so an approval step is the control that keeps each upgrade a deliberate, documented event. Pin Keycloak and operator container images by digest rather than by tag, record the digests in your change record, and verify them against the artifacts you scanned before transfer. The same discipline applies to the database. Keycloak supports several engines, including PostgreSQL 14 to 18, and the database vendor's own patch path, offline installers and support matrix govern how you update it. Confirm with each vendor which offline update methods they provide, and confirm that the Keycloak version you plan to run is supported on the exact database build you hold. Schema changes also run automatically at startup by default, so consider the manual migration path the upgrading guide describes, which lets your DBAs review the SQL before it is applied to production.
Confirm with Red Hat or your Keycloak distributor how offline errata and updates are delivered if you use Red Hat build of Keycloak or another supported distribution, because the upstream project release does not replace a vendor's update channel. Plan backups before each change, noting that the export and import commands have documented limits as a backup mechanism and require all nodes to be stopped while they run. Keep a rollback path, document who approves each upgrade, and align the process with the change control your regulator or assessor expects, such as the supply chain integrity expectations in NERC CIP-013-2 where that standard applies.
Evidence assessors ask for from an offline identity system
An offline identity provider is only as credible as the records behind it. The cards below list the artifacts that show what the system trusts, how users log in, how updates entered the network and whether recovery works. DeployOpen prepares this evidence, but auditors and certification bodies issue any assessment outcome.
Architecture and trust boundary diagrams
Assessors start with a diagram that shows where the Keycloak nodes, database, directory servers and MFA components sit, and where the boundary to the rest of the network lies. Mark every path that crosses it, including the file transfer point used for updates. Check that the diagram matches the running configuration, not the design from the start of the project. Record the date and the owner who approved each version.
Federated directories and login paths
List every LDAP or Active Directory source Keycloak federates with, the attributes it reads, and every application login route, including Kerberos and local accounts. Local accounts that bypass the directory are the first thing an assessor will ask about, so document why each one exists and who holds it. Confirm the list against the realm configuration with a dated export.
MFA configuration records
Keep the exported authentication flow settings, the enabled factors such as OTP and WebAuthn, the enrollment method for each user group and the rules for fallback or recovery codes. Record who may reset a factor and how that action is logged. An assessor will compare these records with the policy the organization states, so any gap between the two should be fixed or explained in writing.
Verified software bill and transfer logs
Each offline update should come with an inventory of the packages and container images it carries, the checksums or signatures checked before import, and a log of who moved the media across the boundary and when. This is the evidence behind the supply chain control in NERC CIP-013-2, which asks for verification of software integrity and authenticity for vendor software and patches. Store the logs outside the system they describe.
Backup and restore test records
A backup is evidence only after a restore has been tested. Keep the database backup schedule, the location and encryption of copies, and dated restore test results that show the realm, client and user data came back intact. Note that the realm export and import commands have documented limits as a backup method and that all nodes must be stopped during that process, so the test should cover the database backup path as well.
Administrator access review records
List every account with administrative rights in Keycloak, the directory and the underlying operating system, and record the review date, the reviewer and the decision for each one. Include service accounts used by federation and the break-glass account kept for emergencies, with its storage and use logged. Reviews should repeat on a schedule the organization sets, and the results should be retained with the other records.
Questions buyers ask before an air-gapped identity project
Can Keycloak run with no internet access at all?
Yes, Keycloak can run on an isolated network once its container images, operating system packages and dependencies are copied across the boundary, because it does not need a cloud service to authenticate users. It supports OpenID Connect, OAuth 2.0 and SAML 2.0, and it can federate users from existing LDAP and Active Directory servers that sit on the same network. Confirm three things in your own environment: that every image and package is mirrored into an internal registry or repository, that your database (Keycloak supports PostgreSQL 14 to 18 among others) is internal, and that your SMTP, DNS and time sources resolve locally. Check the signatures and checksums of each artifact you carry across, which is the same discipline NERC CIP-013-2 asks utilities to apply to vendor software and patches.
How much of the air-gapped identity work can our own team do?
Most organizations with a platform or directory team can run day-to-day operations in-house, and the split depends on skills you already have. Your team typically owns user lifecycle in the directory, application registration, backups and the patch workflow, while the planning, integration and hardening work is where outside help usually adds value. Ask whether your staff have run Keycloak clusters, configured LDAP federation and handled certificate management on closed networks. Engagements from DeployOpen are fixed-scope, with scope and deliverables agreed in writing before work starts, and ongoing support, upgrades and testing are available as retainers, so you can take over some tasks and keep others under contract.
What drives the effort in an air-gapped Keycloak project?
Effort rises with the number of things that have to be wired together and how often they change. The main drivers are:
- Directory count and structure: one Active Directory forest, several LDAP trees, or a directory that must be shrunk or replaced first.
- Application count and protocol mix: each OIDC, SAML or header-based application needs its own client configuration and testing.
- High availability design: Keycloak documents a single cluster across availability zones, a multi-cluster design, and a deprecated multi-cluster design, and both supported designs need a synchronously replicated database.
- MFA scope: OTP, WebAuthn, RADIUS for VPN or Windows logon, and hardware tokens each add enrollment and recovery work.
- Patch process: how packages and images are transferred, verified and staged on an isolated network.
What should a quote for an air-gapped identity project include?
A useful quote lists the scope, deliverables, assumptions and the parts that are one-time versus recurring. Ask for these items in writing:
- Architecture scope: directories, applications, high availability design, database and backup targets.
- Air-gap specifics: the artifact transfer process, the internal registry or repository, and how signatures and checksums are verified.
- Integration and migration work: LDAP or Active Directory federation, application re-federation, and password and MFA re-enrollment planning.
- Hardening, documentation and evidence: the configuration baseline and the records that support a compliance assessment. DeployOpen prepares these artifacts, but independent auditors issue any audit report.
- Recurring items: support, upgrades, testing and any Keycloak subscription you choose to add.
Assumptions matter as much as line items, so ask the provider to state what it expects from your team and infrastructure.
How long does an air-gapped identity migration usually take?
No fixed duration applies to every air-gapped migration, and the research behind this page does not give a timeline you can plan against. The schedule depends on the directory count, the application inventory, whether passwords and MFA must be re-enrolled, and how quickly accredited transfers and change approvals happen on your side. Ask any provider for a phased plan with milestones, and ask which phases depend on your staff, your change board or your transfer process. Keycloak's own guidance matters here as well: it recommends manual approval mode for operator updates, which means each upgrade is a scheduled event that your team has to approve.
Does an air-gapped network need a substitute for Okta Access Gateway?
Access Gateway depends on Okta's cloud, so it cannot serve an isolated network, and you need an offline substitute for header, Kerberos or URL-based legacy applications. authentik's free edition includes proxy authentication, and Pomerium is another option that sits in front of applications, but neither should be assumed to fit your setup until it is tested. Confirm in your environment whether each legacy application can be fronted by a proxy, how Kerberos ticket handling works with your directory, and where session and header trust are enforced. Keep the Kerberos and proxy evaluation on the same test plan as your SSO applications.
How do we keep Keycloak patched without internet access?
Patching on an isolated network is a transfer and verification process, not a download. Keycloak ships four minor releases a year under its current plan and publishes breaking changes in minor releases as opt-in, which helps you stage upgrades. The latest release at the time of writing is 26.8.1, published October 13, 2026, according to the Keycloak website. Set up a repeatable workflow: pull the release artifacts on a connected staging network, verify their integrity, move them through your approved transfer path, test them in a non-production realm, and then schedule the change. Schema migration runs automatically at startup by default, but larger deployments can apply SQL manually, so decide which method fits your change control before the first upgrade.
How DeployOpen deploys identity inside isolated networks
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source identity platforms inside your own infrastructure, including networks with no internet access. Each engagement starts with a written scope that sets out how Keycloak, your directory, MFA and the offline patch process will work together.
How we scope
- Inventory which applications need OIDC, SAML or Kerberos sign-on and which legacy apps need LDAP binds.
- Confirm the directory source, whether Active Directory, FreeIPA or a Keycloak-held user store, and where identities live.
- Agree in writing how local MFA, enrollment and account recovery will work without any cloud dependency.
How we build
- Deploy Keycloak with a supported production database, configured for your isolated network and high availability needs.
- Federate users with LDAP or Active Directory and test Kerberos sign-on from domain-joined workstations.
- Stage every container image, package and patch on approved media and verify integrity before it crosses the boundary.
How we hand over
- Document realm configuration, client registrations, federation mappings and the export and backup procedure.
- Provide an offline upgrade runbook covering database migration, testing order and rollback steps for each release.
- Deliver evidence of configured controls so your internal team and independent auditors can assess the platform.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing upgrades, backups and continuous testing are available as a retainer after handover.
- Ask any provider to confirm which tasks are performed on site, which need approved media, and who holds the admin credentials.
