Why air-gapped SSO changes the identity build
For an isolated enclave where sign-in must work with no outbound internet and no cloud identity provider, Keycloak or FreeIPA are the realistic core. The choice turns on two things: whether you need Kerberos single sign-on for Windows and Linux clients, which points toward FreeIPA, and how much directory, certificate and DNS footprint you are willing to operate, which points toward Keycloak federating an existing LDAP or Active Directory source. Both run entirely inside the enclave, but neither comes with a vendor cloud fallback, so every dependency must be present on your side before cutover.
The build differs from a connected deployment in four ways. First, certificates must come from a local certificate authority, such as the Dogtag CA that FreeIPA integrates, or from a private PKI you run, so there is no public trust chain to lean on. Second, multi-factor authentication must work offline: FreeIPA supports HOTP and TOTP tokens, including hardware tokens, and Keycloak needs its own enrolled factors, and you should confirm which token types your staff will use and how lost tokens are re-enrolled without a network. Third, the identity stack is patched by media, so every update must be verified and carried across the boundary in a controlled way. Fourth, there is no SaaS identity provider to fail over to, which makes backup, replica placement and break-glass accounts the design's main risk controls.
Regulations do not change the technology, but they change the evidence you must produce. The HIPAA Security Rule at 45 CFR 164.312 and the FTC Safeguards Rule at 16 CFR 314.4 are examples of the access control, authentication, audit logging and MFA expectations that apply to any isolated system holding regulated data. Before design freezes, ask your compliance lead which of these apply, which configuration exports and logs an assessor will request, and where those records will be stored inside the enclave.
Which requirements shape an air-gapped identity design
This table maps each regulatory requirement that touches workforce login on an isolated network to what it means for the identity build. Read each row as a question to answer in design: which evidence an assessor will ask for, and which component has to produce it without a connection to a cloud service.
| Requirement | What it asks for | What it means for the build |
|---|---|---|
| HIPAA 45 CFR 164.312 access control and unique user identification | Each user in a system with ePHI has a unique identifier, and access is granted to that identity | Disable shared or generic accounts in the directory. Keep the unique user ID consistent across the local Kerberos realm, LDAP directory and every application. |
| HIPAA 164.312 person or entity authentication and audit controls | Verify that a person or entity is who they claim to be, and record and examine activity in systems with ePHI | Authentication events from the identity provider and directory must be written to local logs and forwarded to a SIEM inside the enclave. Test that events are retained and reviewable offline. |
| FTC Safeguards Rule 16 CFR 314.4(c) MFA | Multi-factor authentication for any individual accessing any information system | Plan offline second factors such as TOTP or HOTP tokens, including hardware tokens, and a recovery process that does not depend on an internet-hosted service. |
| FTC Safeguards Rule 16 CFR 314.4(c) activity logging | Monitor and log the activity of authorized users | Set up local audit log forwarding and retention so that administrator and user sign-ins are traceable after a network outage or during an offline review. |
| NERC CIP-005-7 remote access (where OT is involved) | Interactive Remote Access to high and medium impact BES Cyber Systems passes through an Intermediate System with encryption and multi-factor authentication, with methods to detect and disable active vendor sessions | Place the identity provider and MFA path so vendor logins route through the Intermediate System. Confirm with the applicable regulator and your compliance lead how the requirement applies to your asset classification. |
| NERC CIP-013-2 software integrity (every package carried across the boundary) | Supply chain procurement processes address verification of software integrity and authenticity of vendor software and patches | Verify checksums and signatures on every identity package, container image, rule set and certificate bundle before it crosses into the isolated network. Record each transfer and its verification result. |
| Vendor and offline media handling | Controls on what enters the network and how the chain of custody is recorded | Use a documented media transfer procedure with hash verification, a named approver and a log. The same procedure applies to identity patches and directory updates. |
Which open-source identity platforms fit an isolated network
On an isolated network, the identity provider is also the source of truth for login, so the choice depends on which protocols your applications need, whether Kerberos is required, and who will patch and operate the stack. The cards below cover the main candidates and the checks to run before committing to one.
Keycloak for web and federated login
Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, and can federate users from LDAP and Active Directory, which covers most web applications on an isolated network. It is licensed under Apache-2.0 and supports PostgreSQL 14 to 18 as a production database. For high availability, the documented designs require a synchronously replicated database, so plan that replication inside the enclave. Confirm offline installation steps, including image and extension handling, with the project before design.
FreeIPA for Kerberos and internal PKI
FreeIPA combines 389 Directory Server, MIT Kerberos, a Dogtag certificate authority and SSSD clients in one integrated package, which suits Linux and UNIX estates that need Kerberos single sign-on without a cloud dependency. It issues certificates locally and supports HOTP and TOTP tokens, including hardware keys such as YubiKeys. It is licensed under GPL-3.0-or-later with no paid edition. Its deployment guidance calls for multiple replicas per datacenter and careful backup handling, so confirm the staffing to run it.
authentik for web SSO with a lighter footprint
authentik is licensed under MIT, except the authentik/enterprise directory, which has its own enterprise license, so confirm which directories your deployment uses. It is a good fit for teams that want a web-focused identity provider with a management interface for OIDC and SAML applications. Before selecting it for an isolated network, confirm whether its container images and dependencies can be mirrored and updated by media, and how it handles passkeys without internet access.
ZITADEL for passkeys and multi-tenant access
ZITADEL is licensed under AGPL-3.0 and its documentation lists SSO, MFA, passkeys through FIDO2 and WebAuthn, OpenID Connect certification, SAML 2.0, SCIM and multi-tenancy. Those features suit organizations that want phishing-resistant login across several business units inside one enclave. AGPL-3.0 carries network-use obligations for modified versions, which legal teams should review. Confirm that passkey registration and verification work without any external service, and that the release process supports offline patching.
Ory Kratos and Hydra as components
Ory Kratos handles identity and user management, while Ory Hydra provides an OAuth 2.0 and OpenID Connect server, both under Apache-2.0. They suit teams with developers who will build their own login screens and token flows in the enclave, but they do not provide an admin console or a complete SAML and Kerberos story out of the box. Expect more integration work than a single product, and confirm that each component can be built and updated from mirrored sources.
How to patch the identity stack by media
Patching an air-gapped identity stack is a controlled import, not a download. Build and verify every package on the connected side first: container images, RPMs or DEB packages, Keycloak distribution archives and operator bundles. Record a checksum and a detached signature for each artifact in a manifest that travels with the media, and confirm the signatures against the vendor's published keys before anything crosses the boundary. The NERC CIP-013-2 supply chain requirement, which asks for verification of software integrity and authenticity of vendor software and patches, is the standard to map this step to if you operate in that sector. Transfer by approved media only, log the chain of custody, and re-verify the checksums on the isolated side before installation.
Validate in a staging enclave that mirrors production before any identity server changes. Keycloak's upgrading guide suggests manual database schema migration for large deployments, instead of the automatic migration at startup, so plan for applying the SQL yourself and keeping the migration script in the change record. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades, which matters when the cluster cannot reach a registry to recover from a bad upgrade. Since Keycloak 26.0, the project plans four minor releases a year and says breaking changes in a minor release will be opt-in, so read each release note and decide which new defaults you will accept before the import, not after.
Roll through FreeIPA replicas one at a time, and never restore an outdated backup into a live topology. FreeIPA's deployment recommendations advise at least two to three replicas in each datacenter, and the first server handles certificate renewal and CRL publication by default, so confirm which server holds those roles before you begin and keep a verified ipa-backup taken after each stage. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Patch cadence is not optional: FreeIPA 4.13.4, dated July 9, 2026, fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials. A media process that takes months to cross the boundary leaves that exposure open, so set a patch window you can meet and confirm the release notes for every import.
How the rollout moves from design to a tested enclave
The sequence turns an isolated network with no cloud identity provider into a tested identity service with its own certificate authority, offline MFA, documented recovery paths and a handover package the client's own staff can run. Each phase closes with a named output that the next phase depends on.
Inventory directories and scope the applications
DeployOpen works with the client's identity, security and application owners to list every directory, user population, host and application that must authenticate inside the enclave, and to record which ones speak SAML, OpenID Connect, LDAP or Kerberos and which cannot do single sign-on at all. Systems that need standing service accounts or offline access are flagged here. The output is a signed scope document with an application inventory and a directory map. The phase is complete when the client's owners have approved both in writing.
Design the identity and CA hierarchy
The design fixes the Kerberos realm name, the DNS zones and their resolution path inside the enclave, and the certificate authority hierarchy, including which root stays offline and which issuing authority serves the directory and applications. It also records replica placement, backup targets and which component owns certificate renewal and revocation publication. The output is an architecture record and a PKI and DNS plan that the client's security team reviews. Ask the implementation partner to show how a fresh client resolves the identity service with no internet route.
Build the enclave from prepared offline media
Container images, operating system packages, identity platform builds and rule sets are gathered on a connected staging system, checked for integrity and authenticity against the publisher's signatures, and carried across the boundary on approved media. DeployOpen installs from a private registry or package mirror inside the enclave and records a hash manifest for every item transferred. The output is a bill of materials for the enclave, a transfer log signed by the client's custodian, and a build that installs with no outbound connections. The same procedure is reused for every later update.
Enroll MFA tokens and document recovery
Staff are enrolled in the chosen one-time password or hardware token scheme in controlled batches, with identity verified against the client's onboarding records before any token is issued. The recovery procedure covers lost tokens, token resynchronization, emergency access for privileged accounts and the approval steps required before a reset. Enrollment and recovery are tested with a sample of users and with the break-glass account. The output is an enrollment register, a recovery runbook approved by the client, and test records showing that each recovery path works without outside help.
Test application integration end to end
Each application in the scope document is connected to the identity service over its agreed protocol, then tested for login, logout, session expiry, group-based authorization, certificate-based login where used, and the behavior when the identity service is unreachable. Test cases are written from the scope document so the client can confirm coverage. Defects are logged, fixed and retested under change control. The output is an integration test report that maps each application to its passed cases and to any accepted exceptions signed by the business owner.
Prove failover and backup restore
The team stops one replica, confirms that authentication continues through the remaining replicas, and restores a backup into a separate test topology to confirm that the directory, certificates and revocation data come back consistently. Restoring an outdated backup into a live replica topology can break replication, so the test checks restore order and replica state explicitly. The output is a failover and restore report with timings observed in the test environment, the restore steps as they were actually run, and a list of gaps with owners.
Hand over runbooks and the evidence pack
DeployOpen walks the client's operations staff through the runbooks for patching by media, backup, certificate renewal, token recovery and incident response, and observes them performing at least one of each. The evidence pack gathers configuration exports, access control and authentication settings, test records, change logs and the transfer manifests, indexed to the client's control framework. DeployOpen prepares this evidence but does not issue any audit opinion. The phase closes when the client signs the handover acceptance and names the staff who will own each runbook.
Evidence assessors ask for from an isolated identity system
This table maps each piece of evidence an assessor typically asks for to the component that produces it on an isolated network. Read it as a checklist of what to export, retain and test, with the owner of each record. DeployOpen prepares this evidence, while auditors and certification bodies draw the conclusions.
| Evidence | Produced by | What the assessor checks | Where it usually fails |
|---|---|---|---|
| Unique user identifiers and directory exports | FreeIPA (389 Directory Server) or Keycloak user store | Each person has one account, no shared logins, and the export matches the HR source of record | Shared service accounts or local Keycloak users created outside the approved process |
| MFA enrollment and token inventory | FreeIPA OTP tokens (HOTP and TOTP) or Keycloak required actions | Every in-scope user has an enrolled factor, and each hardware or software token is traceable to an owner | Tokens issued by hand with no inventory, or lost hardware tokens still active |
| Keycloak admin event and login event logs | Keycloak event and admin event logging, forwarded to Wazuh or Security Onion on the internal network | Administrative changes and failed or successful logins are recorded, retained and reviewed | Logs kept only on the identity node, or no review record showing anyone read them |
| FreeIPA audit and access logs | FreeIPA server logs and directory access logs, forwarded to an internal monitoring stack | Privileged changes to users, groups, sudo and certificate policy are attributable to a named administrator | Log forwarding was never tested after a restart or media update |
| Backup and restore test records | ipa-backup and ipa-restore runs, plus Keycloak database backups | Backups exist, are encrypted, and a restore was tested into a separate environment with the result recorded | Backups taken but never restored, or restores that broke replication when an outdated backup was applied |
| Certificate authority and key records | FreeIPA Dogtag CA or a local certificate authority, with issuance and revocation logs | Certificate issuance is limited to approved roles, and revocation and CRL publication are documented | The first server holding CA and CRL duties was not identified, or CA backups were not tested |
| Package verification records for media transfers | Hash and signature checks recorded at the isolated boundary before each import | Each package carried across the boundary has a recorded checksum or signature check tied to an approved change | Media imported on a single person's word, with no hash list or chain of custody |
| Patch and change records for the identity stack | Change tickets, offline update logs and version records for Keycloak and FreeIPA | Each update is traceable to a vendor release, tested in staging, and approved before production use | Releases such as FreeIPA 4.13.4 applied without a recorded decision on the fixed CVEs |
How much work and what it costs to run SSO on an air-gapped network
What drives the cost of running SSO on an air-gapped network?
The main cost drivers are directory size, the mix of applications, the token types you need, the high availability design and the media process for moving updates across the boundary. Directory size and replica count set how much infrastructure and database capacity you carry. Applications that need Kerberos or LDAP bind are usually more work than applications that accept SAML or OIDC, because each one needs its own configuration, testing and sometimes a service account. Hardware tokens, software tokens and any RADIUS proxy add enrollment and support work. A two-site design with replicated databases costs more to build and test than a single cluster. Ask any quote to break these components out separately so you can see which decisions move the price.
Can an internal team run air-gapped SSO without outside help?
A capable internal team can run it, but the work depends on skills that many organizations hold in separate groups. Operating FreeIPA or Keycloak on isolated Linux servers requires solid Linux administration, certificate authority design and renewal, DNS and time synchronization, and database operations. Kerberos adds clock, keytab and ticket troubleshooting that generalist administrators rarely practice. Keycloak upgrades, backups and replication also need a tested runbook. Before deciding, check whether at least two people can cover the stack during an incident and whether they have time to perform media-based patching on a fixed schedule.
What does the client need to provide before an air-gapped SSO project starts?
Before work starts, the client usually needs to settle four inputs. First, a network access plan that shows which hosts can reach which, how media enters and leaves the enclave, and who approves each transfer. Second, decisions on the certificate authority hierarchy, including whether the root stays offline, how intermediates are issued, and which lifetimes apply. Third, a list of applications with their protocols and owners, since each owner must confirm redirect URIs, attribute needs and test windows. Fourth, a named contact for MFA enrollment and help desk procedures. Missing any of these usually moves work into a later phase, so ask the partner to list them in the written scope.
How long does an air-gapped SSO rollout take?
The duration depends on scope, meaning how many applications, sites and directories are involved, how much CA design is needed and how many approvals the media process requires. No fixed timeline applies across these variables, so the schedule should come from the written plan that DeployOpen agrees with you before work begins. Ask for milestones tied to specific deliverables, such as a tested offline build, a completed cutover for each application group and a documented media patch cycle. Be cautious about any timeline that does not list its assumptions about access approvals and application owner availability.
Do air-gapped SSO platforms require paid editions?
The open-source core of Keycloak, FreeIPA and other identity platforms carries no paid edition requirement for offline use under its license, but licensing terms are not the only question. Keycloak is Apache 2.0 licensed and FreeIPA is GPL-3.0-or-later, and FreeIPA has no paid edition of its own. Red Hat build of Keycloak is a supported distribution with its own subscription terms. In other products, air-gapped deployment is often a paid feature. For example, Mattermost lists it in Enterprise Advanced, and Metabase offers it only on its Enterprise plan. Confirm each platform's terms for any add-on, supported distribution or offline update channel you plan to use.
How do you upgrade and patch SSO without internet access?
Upgrades on an isolated network move by media, and the process should be written down before the first release. Build the new images or packages on a staging network, scan them, record checksums, and carry them across through an approved transfer path. Keycloak documents manual database migration for large deployments, and the Keycloak Operator documentation strongly recommends manual approval mode for updates, which fits a media process well. FreeIPA warns that restoring an outdated backup into an active replica topology can break replication, so take backups before each change and test restores in a lab. Verify each package for software integrity and authenticity, which NERC CIP-013-2 addresses for supply chain procurement. Confirm the vendor's offline update path for your exact product version.
What should an air-gapped SSO quote include?
A useful quote lists each component and who pays for it. Ask for separate lines for discovery and design, the CA hierarchy, directory and identity build, application integration by protocol, MFA token enrollment, the media patch process, backup and restore testing, handover documentation and training. Mark which items are one-time and which recur, such as patch cycles, support retainers and token replacement. Ask what is excluded, such as hardware, licenses for supported distributions and application-side changes. DeployOpen does not publish a price list, so the quote follows from the written scope.
What to ask an implementation partner before you commit
Start with the transfer path, because it is where an isolated identity stack is most often compromised. Ask how every package, container image, Keycloak or FreeIPA update and rule set is verified before it crosses the boundary, and who checks the signatures against the publisher's keys. Ask for the transfer record: a signed manifest listing each artifact, its hash, the media it traveled on, the approver and the date. A partner who cannot show that record for the last media update has not yet solved the problem. Also ask how they handle the Security Onion and Wazuh offline update paths if those tools sit beside the identity stack, since each has its own airgap procedure.
Next, ask how the local certificate authority is built and kept alive. Request the hierarchy in writing: an offline root, an issuing intermediate that FreeIPA's Dogtag or another local CA runs, which server holds the first CA role (the FreeIPA deployment guidance says the first server handles certificate renewal and CRL publication by default), and how CRLs reach clients that cannot reach the internet. Ask for the rotation plan for each tier, including how a root or intermediate key would be replaced without breaking Kerberos or TLS trust on every offline machine. For Kerberos, ask how offline Linux and Windows clients receive the krb5 configuration, keytabs and the DNS and time settings they depend on, and whether DNS and NTP are served inside the enclave, since Kerberos fails when clocks drift.
Then ask about recovery, since offline MFA is only as strong as its fallback. Ask how a lost hardware or software OTP token is revoked, who authorizes the re-enrollment, and how the identity of the requester is confirmed without a phone call to an external provider. Ask how they test restores with ipa-restore: whether they rehearse restoring a backup into a live replica topology in a lab first, and how they confirm that replication still converges afterward. Finally, ask who holds the break-glass credentials, how they are split (for example, sealed envelopes or split knowledge across two officers), where they are stored, and how each use is logged and reviewed. Request the evidence pack in advance: the file formats, the configuration exports, backup and restore test records, transfer manifests and access logs, and the retention period the partner recommends.
How DeployOpen scopes and supports air-gapped identity
The sequence below takes an isolated identity deployment from a written scope to a hardened, tested and documented service that your team can run and upgrade by media. Each step ends with an artifact your security and compliance owners can review.
Agree the written scope and deliverables
Before any work starts, DeployOpen and your team agree in writing which identity functions are in scope, which applications and directories must authenticate, which enclave hosts the platform, and which deliverables you will receive. Most engagements are fixed-scope, so the scope document defines what the quote covers and what is excluded. Your team should confirm the source directories (FreeIPA, Active Directory or another LDAP server), the protocols each application needs, and the MFA token types you plan to issue. The step is complete when both parties have signed off on the scope, the deliverables list and the acceptance criteria for each deliverable.
Confirm the isolated architecture and trust model
DeployOpen reviews the enclave design with your architects: where Keycloak or FreeIPA runs, how Kerberos realms, DNS and time sources are set up without internet access, how the local certificate authority is rooted, and where replicas sit. The review also covers high availability, which Keycloak documents as requiring a synchronously replicated database, and FreeIPA's deployment recommendations on replica count and dedicated servers. Your team should confirm which supported database and operating system versions your enclave can accept. The output is an architecture decision record that names each component, its owner and its failure behavior.
Build and install the platform inside the enclave
DeployOpen installs the identity stack into your own infrastructure, whether that is a data center, a classified or regulated enclave, or an isolated cloud account. Installation uses artifacts staged from approved media, with packages, container images and certificates verified before they cross the boundary. Realm or domain configuration, client registrations, user federation, OTP enrollment and backup jobs are set up as code where the platform supports it, so the configuration can be reviewed and reproduced. The step closes when the identity provider authenticates a test user against each in-scope application and the build record lists every artifact and its checksum.
Harden and security test the identity stack
DeployOpen applies hardening to the operating system, databases, certificate authority, admin consoles and replication links, then runs security testing against the identity services and the applications that depend on them. Testing covers authentication flows, token handling, admin access, LDAP and Kerberos exposure, and the controls that stop unauthenticated access to credentials. Findings are logged, rated and tracked to closure with your team. The step is complete when retesting confirms the agreed fixes and the test report, with open items accepted in writing, is delivered to your security owner.
Prepare the compliance evidence set
DeployOpen prepares the configuration exports, access control settings, MFA policy records, audit log configuration and backup and restore records that your internal or external assessors may ask for. Mapping these artifacts to your chosen control framework is part of the scope, but DeployOpen does not issue audit reports, attestations or certifications; independent auditors and certification bodies make those determinations. Your compliance lead should confirm which framework requirements apply to your organization before the evidence set is designed. The step closes when the evidence index is delivered and your compliance owner confirms that each artifact is in the agreed format.
Hand over runbooks and train operators
DeployOpen documents the operating procedures your team needs for enclave life: user lifecycle, OTP token issuance and replacement, certificate renewal and revocation, backup and restore, and the procedure for patching the identity stack by media. Training covers the admin consoles, the replication and high availability checks, and the restore steps. Operators run at least one restore or failover exercise under supervision. The step is complete when your operators have executed the runbooks and the documentation set is accepted in writing.
Run patch and upgrade cycles by media
Ongoing work covers the upgrade path for the identity stack, including the release cadence the Keycloak project publishes, verification of each package carried across the boundary, and test runs in a non-production copy before production changes. FreeIPA and Keycloak release notes and security fixes are reviewed for impact on your configuration. Under a retainer, DeployOpen prepares media, updates the runbooks and supports rollback decisions. Your team should confirm the retainer scope, response expectations and the approval process for each change. The output is a change record for every upgrade, showing the artifact checksums, test results and the approver.
