Why a self-hosted Cisco Duo alternative for air-gapped networks starts with the boundary
privacyIDEA runs multi-factor authentication entirely on premises, and the blocker in an isolated network is Duo's dependency on outbound access. The Duo Authentication Proxy takes RADIUS and LDAP requests from VPNs, firewalls and admin tools, then calls Duo's cloud on port 443 to complete the second factor. A network that cannot open that path cannot use the proxy as designed, whatever the proxy's local configuration. Before comparing products, document every login path that needs a second factor: VPN concentrators, RADIUS-attached network devices, Windows logon and RDP, SSH into OT jump hosts, and web consoles. Each path decides which integration you need. The choice then depends on the factors and integrations you must support. Confirm which second factors your users actually carry, such as push, FIDO2 security keys, PIV or x509 smartcards, or TOTP and HOTP apps, and whether hardware tokens must be imported from existing seed files. Then confirm the integration points: RADIUS for VPNs and network devices, the PAM module or Windows credential provider for hosts, and the REST API for applications. Ask each vendor or integrator to demonstrate those paths with the outbound connection blocked, because a feature list does not show whether a dependency is hidden.
Treat the air-gap as a supply chain boundary too. Every package, container image and rule set carried across the boundary needs a verification step, and the NERC CIP-013-2 supply chain control is a useful reference for what that process should cover. Plan the upgrade path now: confirm how privacyIDEA releases arrive and how you will stage them into the isolated network, and check whether your key management, token seed custody and backup of the user store can run without any external service. Scope the work as a written, fixed set of paths and tests so the boundary is proven in your own environment rather than assumed.
What an air-gapped MFA service must do
An MFA service on an isolated network has to work with no call to a vendor cloud, accept the protocols that network devices already speak, and bring its software and token seeds across the boundary in a verifiable state. The cards below list the checks that connect those requirements to remote access and supply chain expectations in the NERC CIP standards.
No outbound vendor cloud dependency
The MFA service must complete every challenge inside your network, with no call to a vendor cloud for validation, push delivery or licensing checks. Duo's Authentication Proxy relies on outbound access to Duo's cloud on port 443, which an isolated segment cannot provide. privacyIDEA is licensed under AGPLv3 and is designed to keep user data inside the operator's infrastructure. Confirm with the vendor which features, such as push, need an external service, and test each factor with all egress blocked.
RADIUS and LDAP entry points
Firewalls, VPN concentrators and operating systems typically reach MFA through RADIUS or LDAP, not through a web login. The service must accept those protocols locally, so network devices authenticate against an on-premises server. privacyIDEA integrates with VPNs such as OpenVPN, Fortinet and Palo Alto through RADIUS and reads users from LDAP, including Active Directory. Ask the vendor which RADIUS attributes and challenge modes your devices need, and verify them in a lab before cutover.
Hardware and smartcard factors
Isolated sites often prohibit phones and SMS, so hardware keys and smartcards become the primary second factor. The service should validate FIDO2 and WebAuthn keys, PIV and x509 smartcards, and hardware OTP tokens without any cloud lookup. privacyIDEA supports these factors and imports token seeds in several formats. Confirm which token models your procurement approved and that each enrollment path works without internet access.
Verified software and token seeds
Everything that crosses the isolation boundary, including packages, container images and token seed files, needs an integrity check and a record of its source. NERC CIP-013-2 requires supply chain procurement processes to address verification of software integrity and authenticity for vendor software and patches. Hash and sign each transfer, keep the import records for seed files, and destroy copies once they are loaded. Ask your compliance team which of these records they need for assessment.
Intermediate system and MFA for remote access
NERC CIP-005-7 expects all Interactive Remote Access to high and medium impact BES Cyber Systems to pass through an Intermediate System, use encryption and require multi-factor authentication. It also expects methods to detect and disable active vendor remote access sessions. Design the MFA service as one part of that path, and confirm with your auditor how session termination and logging will be shown. This is a design reference, not a statement of compliance.
Which self-hosted options meet the constraint and where each falls short
privacyIDEA covers the widest range of factors among the options for isolated networks. It describes itself as a self-hosted MFA platform that keeps user data inside the operator's infrastructure, and it is licensed under AGPLv3, so the server runs entirely where you place it. Its factor set matters most for sites that need hardware-backed login, because the same server handles both one-time passwords and certificate-based methods.
- Hardware and passkey factors: FIDO2, WebAuthn passkeys and hardware keys are supported, along with PIV and x509 smartcards.
- One-time passwords: TOTP and HOTP work through the privacyIDEA Authenticator app or standard apps such as Google Authenticator.
- Push needs its own app: push notifications require the privacyIDEA Authenticator app, so plan its distribution to isolated devices as a separate step.
- SMS and email: these channels exist, but they depend on a messaging path that many air-gapped sites do not allow, so confirm the design before relying on them.
- Token import: hardware token seeds in OATH CSV, PSKC and other formats can be imported from existing inventories.
Confirm which factors your policy requires, then test each one on the exact hardware keys, smartcards and client versions in your environment.
The factor list only matters if the server can reach the systems that need it. privacyIDEA integrates with VPNs through RADIUS, with Linux through a PAM module, with Windows logon through a credential provider, and with web applications through its REST API. On the directory side, it reads users from LDAP services, including Active Directory, as well as SQL, SCIM, HTTP and flat file sources, so existing user stores can stay where they are.
- VPN gateways: RADIUS integration is documented for OpenVPN, Fortinet and Palo Alto, which covers the remote access paths that Keycloak does not serve.
- Linux logins: the PAM module applies the second factor to local and SSH logins on hosts that stay inside the isolated network.
- Windows logon: the credential provider is the path for workstation and RDP logons, and the supported Windows versions need checking against your fleet.
- Directory sources: LDAP resolvers read users from an existing directory, so the isolated network does not need a second copy of accounts.
- Keycloak plugin: privacyIDEA can act as an identity provider plugin for Keycloak, which lets one MFA service back both web SSO and network logins.
Confirm each integration against the exact VPN firmware, Windows build and directory schema in use, and document how the RADIUS shared secrets are rotated.
Keycloak is Apache 2.0 licensed and offers built-in OTP and WebAuthn for logins to applications that use OpenID Connect, OAuth 2.0 or SAML 2.0. It can also federate users from existing LDAP and Active Directory servers. For a team whose Duo use is mainly the second factor on web SSO, Keycloak may cover that need without adding a separate service. It does not cover the non-web paths that many isolated networks depend on.
- Web SSO only: Keycloak's MFA applies to logins that pass through its SSO flows, not to every login on the network.
- No RADIUS: VPNs and network devices that authenticate over RADIUS need a separate service, such as privacyIDEA.
- No Windows logon: workstation and RDP logons are outside Keycloak's MFA scope, so they need a credential provider from another product.
- Backup limits: the export and import commands produce realm JSON files, and the documentation warns that this is a limited backup mechanism and that all nodes must be stopped during an export.
- Operational planning: the stop-all-nodes requirement affects maintenance windows in an isolated environment, so plan backups around it.
Confirm which logins your Duo deployment protects today, then map each one to Keycloak or to a RADIUS or PAM service before you decide whether Keycloak alone is enough. The export guidance is at Keycloak: Importing and exporting realms.
authentik's open-source core is MIT licensed, and its free edition supports OIDC, SAML, LDAP, SCIM, RADIUS, Kerberos and proxy authentication. That set makes it a candidate for the RADIUS and LDAP paths that Keycloak does not serve. The free edition comes with community support only, and some features and certifications sit in paid editions, so the edition choice is a design decision for regulated buyers, not a detail to settle later.
- Free edition scope: RADIUS and LDAP are part of the free edition, which is the starting point for a network-facing deployment.
- Community support only: the free edition has no vendor support, so plan internal or contracted operations coverage.
- Enterprise features: the Enterprise edition adds features such as privileged access management and ticket-based support.
- Enterprise Plus: the pricing page lists SLAs, multi-instance support and FIPS compliance in this tier, so check the FIPS requirement against the current documentation.
- Outpost placement: the RADIUS and LDAP outposts need a network path back to the authentik core, so confirm the segmentation rules allow that path before choosing this design.
Confirm the outpost connectivity model, the RADIUS and LDAP feature set in your target version and the support obligations your assessor expects. The current editions are on the authentik pricing page.
Why the Duo Authentication Proxy cannot serve isolated networks
The Duo Authentication Proxy sits between your VPNs, network devices and directories on one side and Duo's cloud on the other. It accepts RADIUS and LDAP authentication requests from those systems, checks the primary password against your directory, then sends the second-factor request to Duo's cloud over outbound HTTPS on port 443. Any network segment that cannot open that outbound path cannot complete a Duo authentication, no matter how well the proxy is built or how many replicas run beside it. For isolated operational technology, defense or lab networks with no route to the internet, that single egress requirement is the whole problem.
The failure mode is quiet and affects operators first. When the proxy cannot reach Duo, second-factor checks time out, so VPN logins, RADIUS-backed device administration and LDAP-bound applications fail or fall back to whatever the device is configured to do. Engineers often discover this during an outage or a maintenance window, not during design. Before you rely on any Duo-based design for an isolated segment, confirm the current egress requirements, supported proxy versions and fallback behavior directly in Cisco's Duo documentation for your release, and test a login from inside the isolated network with the outbound path blocked.
Because the requirement belongs to the product architecture, a firewall exception or a proxy in a DMZ does not fix it without creating a route that the isolated network was designed to lack. That is why sites with strict boundaries, including those bound by NERC CIP-005-7 interactive remote access rules, usually need the second factor evaluated as an on-premises service. privacyIDEA can run inside the boundary and answer RADIUS and LDAP requests locally, so your validation work moves to the factor server, its database and its enrollment process, all of which you control.
How to deploy privacyIDEA inside an air-gapped boundary
This sequence takes privacyIDEA from an offline package set to a working MFA service inside an isolated network, with user resolution, token enrollment, RADIUS and host logon integration verified before any user depends on it.
Build and verify the offline package set
Someone on the connected side, usually the platform team with the security function, assembles every package, dependency and wheel that the chosen install path needs, then records a checksum for each file in a manifest. Confirm the exact package list and install path in the privacyIDEA installation documentation before you download anything, because the supported routes are pip and the Ubuntu and CentOS or RHEL-family guides. Check each artifact against its published checksum or signature where the project provides one, and keep the manifest with the transfer record. The step is done when the manifest is complete and a second person has reproduced the checksums.
Transfer media through the approved process
The package set crosses the boundary on media handled under your own cross-domain or media transfer procedure. Your security team scans the media, re-computes the checksums inside the enclave, and compares them against the manifest. This is the point where your supply chain controls for vendor software integrity apply, including the verification expected under NERC CIP-013-2 where it governs your environment. The step is done when the inside checksums match the manifest and the transfer log is signed off.
Install privacyIDEA on supported systems
The platform engineer installs privacyIDEA from the local package set on a supported Ubuntu or RHEL-family host, following the installation guide for that distribution, and points the installer at the local repository rather than any public mirror. Confirm that the service starts, the web interface loads over the internal certificate, and the database backend is local to the enclave. The step is done when a test administrator can log in and the service logs show no outbound connection attempts.
Connect LDAP or AD as the user ID resolver
An identity administrator adds the existing directory as a user ID resolver so privacyIDEA reads users from LDAP or Active Directory without copying passwords into the MFA store. Use a read-only bind account, and confirm the attribute mapping for the login name and the user identifier with a small test group. The step is done when a test user resolves correctly, authenticates with the directory password, and the resolver is recorded in the configuration.
Import hardware token seeds and enroll tokens
Your token administrator imports existing hardware token seed files through the Token import function, using the SafeNet XML, OATH CSV, Yubikey CSV or PSKC format that matches the vendor export. Where seed files are GPG-encrypted, use the privacyIDEA GPG key handling described in the import documentation. Check a sample of imported tokens by generating a test OTP against the device. The step is done when each imported token validates, and the seed files are removed from the working directory and stored under your key management policy.
Configure RADIUS for VPNs and network devices
A network engineer defines the RADIUS clients for each VPN concentrator and network device, sets the shared secrets through your secrets process, and tests a challenge-response login from a pilot device. Confirm that the device sends the request to the privacyIDEA RADIUS listener on the internal address and never to an external service. The step is done when a pilot user completes a login through the VPN with the second factor and the audit entry appears in privacyIDEA.
Set up Linux PAM and the Windows credential provider
A systems administrator installs the privacyIDEA PAM module on a pilot Linux host and the Windows credential provider on a pilot workstation or server, both pointing at the internal privacyIDEA endpoint. Test a logon on each, then test what happens when the MFA service is unreachable, using the fallback behavior your policy approves. Record the result before any wider rollout. The step is done when pilot logons succeed with the second factor, and the unreachable-service behavior matches the written access decision.
Confirm the install path and offline image handling
Before go-live, the platform team checks whether the chosen deployment is a plain host install or a containerized one. If it is containerized, apply offline image handling to the platform: pull and save images on the connected side, transfer them, and load them into a private registry inside the enclave, following the same pattern as the Kubernetes kubeadm offline guidance or the GitLab offline environment documentation for their own components. Confirm the exact steps with the privacyIDEA documentation for your version. The step is done when no build or runtime step requires internet access and the deployment record names the version and checksum of every component.
Evidence assessors and regulators ask for
An isolated MFA deployment is only as credible as the records that show it stayed isolated, carried only verified software, and made consistent access decisions. The four evidence types below map to the expectations assessors apply to electronic access and supply chain controls. DeployOpen prepares this evidence inside your environment, but independent auditors and regulators decide whether it meets the standard.
Network diagrams showing no egress
Keep current configuration exports and network diagrams that show every path into and out of the privacyIDEA servers, RADIUS listeners and LDAP or SQL resolvers. The goal is to show that no route leads to an external service, including Duo's cloud on port 443. Under NERC CIP-005-7, the electronic security perimeter and Intermediate System design must be documented, so the diagram is the starting point for that evidence. Ask your assessor which diagram version they expect and how often you must re-run the egress tests.
Integrity records for carried packages
Every package, container image, rule set and update that crosses the isolated boundary needs a record of its source, checksum or signature verification, and approval. This is the evidence behind software integrity and authenticity checks for vendor software and patches. Under NERC CIP-013-2, supply chain procurement processes must address these checks, so the transfer log should name who verified each item and when. Confirm with your assessor whether they want hashes stored alongside the transfer ticket.
Enrollment and token inventory records
Maintain a current inventory of every user, device and hardware token enrolled in privacyIDEA, including who issued each token, when it was assigned, and when it was revoked. Imported seed files and smartcard enrollments belong in the same record. NIST SP 800-82 Rev. 3 treats OT security as an access control and asset management problem, so the inventory shows that only known, authorized credentials can reach control networks. Ask the team how lost tokens are reported and whether the revocation timestamps are preserved in logs.
Logs of RADIUS and MFA decisions
Retain logs of every RADIUS and MFA accept, reject and bypass decision, with user, client device, factor type and timestamp. These records support investigations of interactive remote access and show that multi-factor authentication actually ran. CIP-005-7 expects methods that detect and disable active vendor remote access sessions, so the logs should show session starts and terminations. Confirm your retention period with your compliance lead, since the required duration depends on your program and regulator.
Questions buyers ask before moving to privacyIDEA in an air-gapped network
Does privacyIDEA really run with no internet access?
Yes, privacyIDEA is self-hosted software that keeps user data inside the operator's infrastructure, and its design does not depend on a vendor cloud for the second factor. The deployment still has to be planned for the isolated network: the server, its database, the user ID resolver (such as LDAP or Active Directory) and any RADIUS or PAM clients must all sit inside the boundary. Packages, container images and updates must be brought in through a controlled transfer process. Confirm the exact install path, dependency list and update method for your operating system and version in the written scope, because offline installation steps depend on your environment and are not a one-line change. The privacyIDEA project page is the natural starting point for the product's own description.
What does our team need to provide for an air-gapped privacyIDEA rollout?
Your team typically supplies the following: a named owner for the directory and user ID resolvers, access to the systems that hold users and any existing hardware token inventory, the RADIUS or PAM clients that will call the MFA service, and a secure transfer process for software packages across the isolation boundary. Your security team also needs to define how packages are verified before they cross into the network, which relates to supply chain controls such as NERC CIP-013-2 where it applies. Ask the engagement to list each dependency on your side in writing before work starts, so change windows and approvals are not discovered late.
How long does an air-gapped privacyIDEA rollout take?
The duration depends on the number of users, the number of clients being integrated, the hardware token situation, and how many change windows your isolated environment allows. No duration is set by this page, so ask for a timeline as part of the written scope rather than relying on a general estimate. Good questions to put in that scope include which integrations are in the first phase, how enrollment is staged across user groups, and what testing happens in a lab or cyber range before production. Fixed-scope engagements agree deliverables and timelines in writing before work begins.
How does push authentication work when the network is offline?
Push notifications need the privacyIDEA Authenticator app to receive and answer a challenge from the server, and the design of that channel must be confirmed for your network before you commit to it. Push is not the only option: privacyIDEA also supports FIDO2 and WebAuthn hardware keys, PIV and x509 smartcards, and TOTP or HOTP codes that need no push channel at all. Many isolated sites choose OTP, FIDO2 or smartcards for this reason. Ask the implementation team to document, for each factor you plan to offer, whether it works fully inside your boundary and what devices users need.
Will users with Google Authenticator keep working after the switch?
Standard TOTP and HOTP tokens are the compatibility path: users of standard TOTP apps such as Google Authenticator can keep their app, provided the token is registered with privacyIDEA. Users who want push need the privacyIDEA Authenticator app instead. For existing hardware tokens, privacyIDEA can import seed files in SafeNet XML, OATH CSV, Yubikey CSV and PSKC formats, so the seeds do not always need to be re-issued. Confirm with the vendor or your implementation partner which token types you hold, and plan enrollment so no user is locked out during cutover.
What drives the cost of self-hosted privacyIDEA on an isolated network?
Costs fall into a few components. Software licensing is different from the operating cost: privacyIDEA is AGPLv3 licensed, and an optional Enterprise Edition from NetKnights is available as a separate subscription, so ask whether you need it. Recurring costs include the servers, high availability design (typically at least two nodes plus a shared database), patching, backups and staff time. Ongoing help desk work for enrollment and lost token replacement often exceeds the server cost. Hardware tokens, if you buy new ones, are a one-time expense. Ask any quote to break out infrastructure, implementation, token purchases, support and help desk assumptions separately.
Can DeployOpen run an air-gapped privacyIDEA project as a fixed-scope engagement?
Yes, DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside a client's own infrastructure, including isolated networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from the written scope. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications, which independent auditors and certification bodies provide.
How to move from Duo without locking out operators
Export the inventory before anything else changes, because the Duo contract end date sets the deadline for everything after it. Use the Duo Admin API to pull users, phones, hardware tokens and integrations while the subscription is still active, and store the output on the air-gapped side with the same access controls as other identity data. Confirm with Duo which API scopes your plan grants and which authentication logs remain readable after termination, since those records feed your audit evidence. Hardware token seeds are the item most likely to be lost, so confirm early whether your Duo tokens can be exported in a format privacyIDEA imports, such as OATH CSV, PSKC or Yubikey CSV, and plan for re-enrollment of any token that cannot be moved.
Run privacyIDEA alongside Duo on one pilot segment before touching the rest of the estate. Choose a small group of operators on a single VPN concentrator or jump host, point their RADIUS client at privacyIDEA, and keep their existing Duo path available as a fallback until the pilot has produced several weeks of clean logins. Resolve those users from your existing directory through an LDAP user ID resolver so that usernames and group membership do not drift between systems. Record every failed authentication and every help desk ticket during the pilot, because those records tell you which factor enrollment steps and which RADIUS settings need correcting.
Cut over RADIUS clients one network zone at a time, starting with the least critical and ending with the zones that control industrial or defense systems. Move one client, confirm its shared secret, timeouts and second-factor prompts behave as expected, then proceed to the next. Do not disable the Duo Authentication Proxy for a zone until every operator who needs access there has a working factor on privacyIDEA. Enrollment and help desk planning decide whether the cutover holds: schedule enrollment sessions before each cutover, stage spare hardware tokens, define how a locked-out operator is verified and reset, and check the sibling pages in this hub on migrating from Cisco Duo to privacyIDEA and on the Duo cost comparison for the staffing and token assumptions to confirm against your own environment.
How DeployOpen implements privacyIDEA inside isolated networks
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For isolated networks, we scope the work in writing before any installation so the MFA design matches the network boundary, the factors users need and the evidence your assessors will ask for.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We map which logons, VPNs and network devices need a second factor and whether each path reaches RADIUS or LDAP inside the isolated zone.
- We confirm the user store, hardware token inventory and factor mix, including OTP, FIDO2 and smartcard, before design begins.
How we build
- We install privacyIDEA on your own servers and connect it to your existing LDAP or Active Directory user resolvers.
- We configure RADIUS and PAM integrations for the VPNs, network devices and Linux hosts identified in scope, and test each path with the network disconnected from the internet.
- We import hardware token seed files in the formats your inventory requires and document the verification steps for each batch.
How we hand over
- You receive configuration documentation, runbooks for enrollment, lockout recovery and token replacement, and a record of what was tested.
- We document how software packages and container images are checked before they cross the isolated boundary, so your procurement and integrity controls have a written record.
- We train your help desk and administrators on enrollment, revocation and the offline procedures your team will run after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers agreed separately from the initial scope.
- We prepare systems, controls and evidence for compliance assessments, while independent auditors and certification bodies issue any audit reports or certifications.
- We back up configuration and token data, and plan upgrade windows for privacyIDEA releases, which you should confirm against the current release notes in your environment.
