Why MFA for air-gapped networks needs a different design
In an air-gapped enclave, the usual second factors stop working. Push notifications need a vendor cloud, SMS needs a carrier network, and cloud-based validation has nowhere to call. Every login has to be verified by a server inside the boundary, using credentials that were loaded onto the network before anyone used them. That changes the design from the first decision: the token types you can accept, how seeds reach the server, and how the validating service stays up without a path to the outside world. Treat the MFA server as a core dependency of the enclave, not an add-on, because a failed validator locks out every user at once.
Three design areas drive most of the work. First, token types: hardware OTP tokens and FIDO2 keys are the realistic options, and each needs a documented enrollment path that does not depend on the internet. Second, seed handling: if vendor seed files arrive as SafeNet XML, OATH CSV, Yubikey CSV or PSKC, confirm which format your token batch uses, who holds the decryption material, and how the import is logged and verified against the token serials. Third, high availability inside the enclave: plan replicas, backups and a recovery path for the validator, since an offline system cannot fetch a fix on demand. Software and packages entering the boundary also need an integrity check, which the NERC CIP-013-2 supply chain requirement makes explicit for operators of bulk electric system assets.
For the short answer, privacyIDEA fits most token-heavy enclaves, because it imports seed files, validates hardware OTP and FIDO2 keys, and offers a REST API and RADIUS and PAM integrations that cover VPNs and servers. FreeIPA fits Linux and Kerberos-centric estates, where HOTP and TOTP tokens and central SSH and sudo policies are already part of the directory. Confirm the choice against your user stores, required integrations and token inventory before you commit, and ask a partner to run an import and failover test in a non-production enclave first.
Which requirements shape an air-gapped MFA build
This table maps three regulatory requirements to concrete consequences for an air-gapped MFA build, such as on-premises verification, token seed handling and audit logs. It describes what each requirement means for the design, not legal advice, and the main takeaway is that the regulator's view of the enclave boundary must be confirmed before the architecture is fixed.
| Requirement | What it asks for | What it means for the build |
|---|---|---|
| HIPAA 45 CFR 164.312 (person or entity authentication) | Covered entities and business associates must verify that a person or entity seeking access to ePHI is who they claim to be. | Verification must run inside the enclave, so the MFA server cannot depend on a cloud check. Keep records of which factor was accepted and when. |
| HIPAA 45 CFR 164.312 (unique user identification) | Each user must be identifiable by a unique identifier, so shared logins cannot be used to access ePHI. | Enroll each person's hardware token or key against their own directory identity, and retire tokens from departed staff in the same workflow. |
| HIPAA 45 CFR 164.312 (audit controls) | Systems holding ePHI must record and allow examination of activity. | Forward MFA success, failure and enrollment events to an on-premises log store inside the enclave and set a retention period your compliance lead approves. |
| FTC 16 CFR 314.4(c) (MFA for any individual) | Covered financial institutions must use MFA for any individual accessing any information system, with no exceptions for internal users. | Plan token coverage for admins, vendors and service-facing staff in the enclave, and document any accounts that cannot use an interactive factor. |
| NERC CIP-005-7 (interactive remote access) | Interactive remote access to high and medium impact BES Cyber Systems passes through an intermediate system with encryption and MFA, with methods to detect and disable active vendor sessions. | Place the MFA check at the intermediate system on premises, and keep session-kill procedures that work when the enclave has no external connectivity. |
| Token seed handling (NERC CIP-013-2 and general practice) | Vendor software and supply chain components must be verified for integrity and authenticity before they enter the environment. | Seed files for OATH tokens are sensitive. Import them through a controlled process, encrypt them at rest, and confirm with your assessor how seed custody is evidenced. |
| Enclave boundary interpretation | Each regulator defines what counts as in scope, and the boundary of an isolated network is not always the same across frameworks. | Confirm with your regulator, assessor or counsel where the enclave boundary sits and whether the MFA server, its replicas and its logs fall inside it. |
Which open-source platforms fit an offline enclave
An air-gapped MFA design depends on a server that validates second factors without calling a cloud service. The platforms below cover that core, the directory and certificate services it relies on, and the web SSO layer that sits in front of applications. Each card names what to confirm in your enclave before you commit.
privacyIDEA as the MFA core
privacyIDEA validates OTP and FIDO2 factors on your own servers and is licensed under AGPLv3. Hardware OTP seeds can be imported from SafeNet XML, OATH CSV, Yubikey CSV and PSKC files, and GPG-encrypted seed files are supported. Integrations cover the Linux PAM module, the Windows credential provider and RADIUS for VPNs. Confirm that your token vendor's seed export format is on this list, and that the enclave accepts the FIDO2 attestation model you plan to use.
FreeIPA for directory and OTP
FreeIPA combines 389 Directory Server, MIT Kerberos, the Dogtag certificate authority and SSSD clients in one GPL-3.0-or-later package. It supports HOTP and TOTP tokens, including YubiKeys, and can proxy OTP checks to an existing RADIUS server. Plan for at least two to three replicas per datacenter, and confirm that the enclave can hold its own internal CA and DNS. Keep the first server's certificate renewal and CRL duties in mind when you design backups.
Keycloak as the web SSO layer
Keycloak provides OpenID Connect and SAML 2.0 single sign-on for internal web applications and can federate to LDAP and Active Directory user stores on premises. It is Apache-2.0 licensed and includes WebAuthn support for hardware keys. Push notifications and SMS are not usable here, because they need an external service. Confirm which second factor types Keycloak will enforce for each application, and test the login path with the enclave's own user directory.
Hardware key and attestation policy
FIDO2 security keys work offline because the browser or client verifies the key directly, but the server still has to decide which keys it trusts. Ask the enclave owner which key models and manufacturers are approved, and whether attestation statements must be checked against a local trust list. Record the approved list as configuration evidence. Vendor certificate roots may need to be copied into the enclave by the same transfer process used for software packages.
Seed file transfer and key custody
OTP seeds are secrets, so the process for moving them into the enclave matters as much as the import format. Decide who exports seeds from the vendor system, how the files are protected in transit, and whether they are GPG-encrypted before import. Confirm that the import workflow records each token serial and the operator who loaded it. The seeds should exist only in the enclave once the import is complete.
Offline validation and failover
A validation server in an isolated network has no external fallback, so the design has to keep login working when one node fails. Run at least two MFA nodes behind the same user store and test the failure path before go-live. Confirm that clock drift is controlled, because TOTP and HOTP checks depend on synchronized time. Document how an administrator recovers a locked-out user without a cloud channel.
How hardware token seed files get into an isolated MFA server
Hardware OTP tokens ship with a *seed file*, the secret that lets the MFA server compute the same codes as the token. In an isolated enclave, that file has to cross the air gap before anyone can enroll a token, so the import workflow is part of the security design. privacyIDEA can load seed files in SafeNet XML, OATH CSV, Yubikey CSV and PSKC formats through Token, Import, and it can also import seed files that have been GPG-encrypted with its own GPG key. Before ordering, confirm with each token vendor which export format it produces, whether it encrypts the file, and whether it will deliver the file separately from the tokens. The OATH CSV format covers HOTP, TOTP, OCRA and TAN tokens, so a mixed batch may need more than one import pass or a format check per line.
The reader must define the handling controls before the first file arrives. Specify the transfer medium approved to carry seed files across the boundary, who may hold them at each step, and where they are stored between delivery and import. Keep the person who receives the token shipment separate from the person who imports the seeds, so no single operator can both hold a token and its secret. Set a rule that each seed file is deleted from the import workstation and transfer media once the import is confirmed, and record that deletion. Treat the GPG private key used for encrypted imports as a secret in its own right, with custody and rotation owned by a named role rather than the MFA administrator alone.
Test the workflow with a non-production batch before live tokens are imported. Confirm that each token serial appears in privacyIDEA after import, that a code generated by the physical token authenticates, and that the import event is written to the audit log. Record which person performed each step, the file hashes at each transfer and the deletion confirmation, since these become evidence for access control reviews. Keep the seed file workflow documented alongside the enrollment procedure so that a replacement token batch can follow the same controls.
How an air-gapped MFA rollout runs in phases
The sequence moves from a defined enclave boundary to verified offline media, hardened MFA servers, enrolled tokens and tested high availability, so admin and VPN logins are cut over only after each phase produces its evidence.
Confirm the enclave boundary and requirement scope
The team agrees which networks sit inside the enclave, which systems need a second factor first (admin consoles, VPN concentrators, Windows and Linux logon, SSH) and which regulations or frameworks set the evidence bar. The engagement lead and the client's security owner sign off on a written scope before any package is built. The output is a signed scope statement with a system inventory, the authentication targets and the list of data flows that cross the boundary. Ask the implementation partner to show how they record the boundary so later changes can be traced.
Build the offline package set and verified media process
Packages, container images, operating system media and rule sets are collected on a connected staging system, then checked for integrity and authenticity before they are carried into the enclave. Every item is listed in a manifest with hashes and a record of who approved it, which supports the software verification expectations in NERC CIP-013-2 where those apply. The output is a signed package manifest and a media transfer log. Confirm with the partner which signing keys they use and how the transfer media is sanitized and tracked.
Install and harden the MFA servers
The privacyIDEA or FreeIPA servers are installed from the verified set on dedicated hosts, with the operating system baseline, TLS certificates from the enclave's own certificate authority, administrative access restricted and audit logging sent to the enclave log store. Installation uses only local repositories, with no outbound calls to public services. The output is a hardening checklist with each item marked as tested, and a configuration backup taken after the baseline is in place.
Import seeds and enroll hardware keys
Hardware OTP seed files are imported through the token import function, using the file format the token vendor supplied, and the import is run in a test instance first. Seed files are handled under the client's key custody rules, and GPG-encrypted files are decrypted only with the designated key. FIDO2 keys are enrolled by the users or help desk under a supervised procedure with identity checks. The output is a tested import log that reconciles counts of imported, rejected and duplicate tokens, and an enrollment record for each user.
Add HA replicas and test failover
Replica servers are added in line with the directory and replication guidance for the chosen platform, and the team confirms that token state and policies replicate. Failover is tested by stopping the primary, authenticating through each integrated system, and restoring service, with the results captured against the expected behavior. The output is a failover test record listing each target system, the observed result and any defects fixed before cutover. Ask the partner how they handle replication conflicts and what backup restore test they run.
Cut over admin and VPN logins first
Administrative accounts and VPN or remote access logins are switched to require the second factor first, since these carry the highest exposure and are the most visible in audits. Break-glass accounts and service accounts are documented and handled separately, and a rollback path is kept ready until the cutover is accepted. The output is a cutover sign-off signed by the system owner and the security lead, with the first audit log entries for each cut-over system attached. Remaining logons follow in a later wave once that evidence is reviewed.
Keeping the MFA server highly available inside the enclave
FreeIPA combines 389 Directory Server, MIT Kerberos, the Dogtag certificate system and SSSD on clients, and its OTP support can run on that same identity layer. Availability comes from replicas. The FreeIPA deployment recommendations advise at least two to three replicas in each datacenter, so that losing one server does not remove authentication for the site. The directory is multi-master, which means each replica accepts changes, so the topology itself needs care.
- Replica count: Plan two to three replicas per datacenter and keep dedicated servers that run no other applications.
- Replication agreements: Keep no more than four replication agreements per replica to avoid a dense mesh that is hard to troubleshoot.
- PKI and DNS placement: If you use the integrated certificate authority or DNS, run at least one replica per datacenter with those roles.
- Client DNS: Configure at least two DNS servers in each client's resolv.conf so clients can find an IdM server when one is down.
- OTP coverage: Confirm which OTP paths a client can complete while the local replica is isolated from the others.
Confirm with your own test lab how your chosen token types behave when a replica or the first server is offline.
privacyIDEA is a separate application that stores users in an existing resolver, such as LDAP, and keeps token and policy state in its own database. High availability is usually built by running more than one privacyIDEA node behind a load balancer, with the database replicated so that any node can validate a token. The design must make sure that a token counter or a used OTP value is not accepted twice on two different nodes, so verify how your database and replication setup handle that state.
- Node pool: Run at least two privacyIDEA nodes behind a load balancer inside the enclave, and test failover by stopping one node during an enrollment and a login.
- Database replica: Use a database replica with a documented promotion procedure, and rehearse it before go-live.
- Health checks: Configure the load balancer to remove a node that fails its health check, and log those removals for audit.
- Integration endpoints: Point RADIUS clients, the PAM module and the Windows credential provider at the virtual address, not at a single node.
- Time synchronization: Keep all nodes on enclave NTP sources, because TOTP validation depends on accurate clocks.
Confirm with your vendor or partner how each token type behaves during a node or database failover before you commit to a design.
Redundancy protects against a failed server, but not against corrupted data or an operator mistake, so backups remain necessary even in a replicated design. FreeIPA provides ipa-backup and ipa-restore, which can take full backups or online data-only backups. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so restores must follow a documented procedure that deals with the rest of the topology.
- Backup scope: Use ipa-backup for full and data-only backups, and store copies on enclave media that you control.
- Restore discipline: Do not restore an outdated backup into an active replica topology. Rebuild or reinitialize affected replicas according to the FreeIPA procedure instead.
- Certificate authority data: Back up the certificate system data together with the directory, since the Dogtag CA holds issued certificates and revocation state.
- Restore rehearsals: Test restores in an isolated lab built from the same versions, then record the time and steps taken.
- privacyIDEA data: Back up the database and the configuration that holds token and resolver settings, and test that a restored node can validate an existing token.
Ask your implementation partner for the written restore runbook and confirm who is authorized to start a restore inside the enclave.
In FreeIPA, the first server installed in a topology has a special role. By default it handles certificate renewal and certificate revocation list (CRL) publication. Clients and services depend on current certificates and a published CRL, so losing or misconfiguring that server can affect certificate-based logins and smartcard or certificate checks long before user passwords or OTP fail. Treat this role as a dependency to plan for, not as a background detail.
- Role inventory: Record which server holds certificate renewal and CRL publication, and document how to move those roles to another replica.
- Renewal monitoring: Alert on upcoming certificate expiry for system and service certificates, not only for user credentials.
- CRL distribution: Confirm how clients and relying services in the enclave fetch the CRL and what they do when it is stale.
- Change control: Treat decommissioning of the first server as a planned change with a documented handover.
- Evidence: Keep logs of renewals and CRL publications as part of your access control evidence.
Confirm with your environment which certificate-dependent logins you rely on, and how each one behaves when a renewal or CRL update fails.
Evidence auditors ask for and which component produces it
This table maps the evidence an assessor typically asks for in an air-gapped MFA deployment to the requirement it supports and the component that produces it. Use it to decide which logs, records and tests to design in from day one, since evidence that is not captured during enrollment or transfer cannot be reconstructed later. Confirm the exact evidence set with your assessor before build.
| Evidence | Requirement it supports | Component that produces it |
|---|---|---|
| Enrollment record per hardware token (serial, owner, issue date, assignment) | Unique user identification and authenticator control under the HIPAA Security Rule access control standard, and the Safeguards Rule MFA requirement | privacyIDEA token inventory, or FreeIPA OTP token records, exported on a schedule |
| Seed import log for each token batch (file name, format, import time, operator, count of tokens loaded) | Chain of custody for authenticator secrets moved into an isolated enclave; supply chain integrity expectations in NERC CIP-013-2 | privacyIDEA Token Import audit entries, plus the signed hash of the seed file kept in the transfer record |
| Authentication logs for successful and failed second-factor checks | Audit controls that record and examine activity in systems containing ePHI (45 CFR 164.312) and activity logging for authorized users (16 CFR 314.4) | privacyIDEA audit log, or FreeIPA and SSSD logs forwarded to an on-premises SIEM such as Wazuh |
| Interactive remote access session records through the intermediate system | Encrypted access and multi-factor authentication for remote access to in-scope systems under NERC CIP-005-7 | Intermediate system logs combined with privacyIDEA authentication events for the same session |
| Configuration baseline for the MFA server, replicas and integrations | Documented security configuration and change control for authentication systems, supporting access control and person authentication reviews | Version-controlled configuration exports and OS hardening records maintained by the operator, with release versions recorded |
| Backup and restore test results for token database and directory data | Contingency planning and reliable recovery of authentication data without losing enrolled tokens | FreeIPA ipa-backup and ipa-restore job output, and dated restore test reports from a non-production enclave |
| Media transfer records for every package, rule set and token file carried across the boundary | Verification of software integrity and authenticity for vendor software and patches before it is installed inside the enclave | Transfer manifest and checksum log kept by the operator, produced outside the MFA component |
| Token lifecycle events (lost, replaced, revoked, disabled) | Timely removal of access for departing users and reissued authenticators | privacyIDEA token events and help desk tickets linked by token serial |
What do buyers ask before building air-gapped MFA?
What drives the cost of air-gapped MFA?
The main cost drivers are hardware keys, highly available servers inside the enclave, enrollment and help desk effort, integration work for each system, and offline package maintenance. Self-hosted privacyIDEA and FreeIPA are open source, so license fees are usually not the largest line item, but the software is not the whole cost. Hardware OTP tokens and FIDO2 keys are bought per user and replaced over time, which makes them a recurring cost. Each VPN, Linux fleet, Windows domain and web app needs its own configuration and testing. Ask any partner for a quote that separates one-time work (design, integration, seed import, hardening) from recurring work (token replacement, patch intake, support and staff time), and that states which items are priced per system, per user or per site.
How long does an air-gapped MFA rollout take?
The timeline depends on scope: how many systems must use MFA, whether the enclave needs its own high availability pair or cluster, how many token types are in use, and how many users must be enrolled and supported during cutover. Seed file imports, enrollment waves and integration tests usually take longer than the software installation itself. No duration is given here because timelines are set in the written scope for each engagement. Ask for a phased plan that lists which systems move first, the test and rollback steps for each phase, and the dependencies on enclave access, hardware delivery and change approval.
What must our team provide for an air-gapped MFA project?
Your team usually provides network and enclave access details, the list of systems to protect, the user directory or directories to connect, and a named owner for each integration. You also need to supply the change approval path, the hardware token inventory or procurement plan, and the people who will run enrollment and the help desk. For seed imports, your team must control how token files are received, stored and destroyed. Your security team should confirm the required authentication policy for each system before work begins, because the written scope depends on those decisions.
Can our internal team build air-gapped MFA without a partner?
Yes, an internal team can build it if it has experience with the target platform, Linux administration, directory services, RADIUS or PAM integration, and offline software management. The skills most often missing are high availability design, secure seed handling and repeatable offline update procedures. Confirm that your team can maintain the platform after launch, including patch intake, backup and restore testing, and incident response for the MFA server. A partner can take on any of these pieces under a fixed-scope agreement, and the division of work should be written down before the project starts.
How do offline updates stay verifiable inside an isolated network?
Each package carried across the boundary should be checked for integrity and authenticity before installation, and the check should be recorded. NERC CIP-013-2 asks utilities to address verification of software integrity and authenticity of vendor software and patches in their supply chain processes, and that expectation is a useful model for other regulated sectors. In practice, verify published checksums and signatures against the vendor's release records, keep a manifest of every artifact transferred, and test updates in a staging enclave before production. The Security Onion airgap process, which updates from newer ISO media, shows how an offline update path can be structured. Ask your partner to document the transfer, verification and rollback steps for each package type.
How do hardware token seed files get imported into privacyIDEA safely?
privacyIDEA imports hardware token seed files in SafeNet XML, OATH CSV, Yubikey CSV and PSKC formats through Token, Import, and it can import GPG-encrypted seed files with its own GPG key. The OATH CSV format covers HOTP, TOTP, OCRA and TAN tokens. Keep seed files encrypted in transit and at rest, limit who can read them, and delete the source files after a verified import. Record which file, format and operator performed each import so that token assignments can be audited. Confirm the exact import steps for your version in the privacyIDEA documentation before planning the work.
Why are push notifications and SMS not used in an air-gapped network?
Push notifications and SMS depend on external services or carrier networks that an isolated enclave cannot reach. Push also depends on an app that connects to a notification service, which is outside the enclave. Air-gapped designs therefore rely on hardware OTP tokens, FIDO2 security keys, smartcards and locally verified TOTP or HOTP where the policy allows. privacyIDEA supports these token types, and users of standard TOTP and HOTP can keep apps such as Google Authenticator, while push notifications need the privacyIDEA Authenticator app. Confirm that every token type in your design works without outbound connections before procurement.
What happens to logins if the MFA server fails inside the enclave?
Without a highly available design, an MFA outage can lock out administrators and remote staff at the same time. Plan at least two servers in each site, with replication for the user and token data, and test failover before go-live. FreeIPA's deployment recommendations advise at least two to three replicas in each datacenter, and its backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Define an emergency access procedure for break-glass accounts, and confirm how each integrated system behaves when the MFA service is unreachable.
Questions to ask an implementation partner for an isolated enclave
Start with seed handling, because it decides whether the enclave can enroll hardware tokens at all. Ask who imports the seed files, in which format (SafeNet XML, OATH CSV, Yubikey CSV or PSKC, per the privacyIDEA import documentation), and where the files sit between the vendor and the import step. Ask who holds the GPG key used for encrypted seed files, how it is generated, where the private key is stored, and who can revoke it. Ask for the written procedure that deletes plaintext seed files after import and for the log that proves it ran. A partner that cannot name the key custodian before work starts is not ready for a classified or regulated enclave.
Next, test how the partner verifies what crosses the air gap. Ask how each package, container image, rule set and privacyIDEA or FreeIPA update is checked for origin and integrity before it enters the enclave, and whether those checks are recorded in a manifest that your team can re-verify. NERC CIP-013-2 is written for the electric sector, but its supply chain expectation for verifying software integrity and authenticity of vendor software and patches is a useful yardstick for any isolated boundary. Ask what the partner will not do: they should not sign off on your vendor's security posture or issue an audit report. Ask who owns the evidence afterward.
On the MFA design itself, ask how FIDO2 attestation is enforced: which authenticator models are allowed, whether attestation statements are validated or only logged, and who maintains the allowed list. Ask for a high-availability design for the replica topology with the number of replicas, the replication agreements and the failover test plan, including what happens to logins during a site or replica loss. Ask how backups of the replica set are taken and restored, and how the partner avoids restoring an outdated backup into an active topology, which the FreeIPA backup documentation warns can break replication. For lost hardware keys, ask for the recovery path, the identity proofing step, and whether a second enrolled key or a supervised re-enrollment is required.
