When Keycloak MFA fits a Duo replacement and when it does not
If your Cisco Duo renewal mainly guards single sign-on logins to web applications, Keycloak's built-in OTP and WebAuthn can take over that role. RADIUS for VPNs and Windows logon sit outside what Keycloak covers, so those flows need a separate answer. The decision starts with an inventory: list every Duo protected application, integration and logon path, then mark which ones authenticate through SAML 2.0 or OpenID Connect and which ones send RADIUS, LDAP bind or Windows and Linux logon requests. Keycloak is licensed under Apache 2.0 and is a Cloud Native Computing Foundation incubating project, which matters if your procurement rules favor permissive licensing and a neutral foundation.
Next, check whether Duo's device trust features are part of the requirement. Keycloak's built-in second factors cover one-time passwords and WebAuthn, but you should confirm with your own security team whether any policy depends on Duo's device health checks, managed device status or risk signals before you commit. Also ask who will run the platform. Keycloak is a server you operate: you will own clustering, the database, upgrades and backups. Its documentation describes a manual realm export and import process with limitations as a backup mechanism, so plan your own backup and restore approach. Confirm the required operating skills and support path before the Duo contract ends.
If the answer to the inventory is mostly web SSO, Keycloak is a reasonable fit and the next step is a pilot with a small group of applications. If VPNs, RDP or workstation logons also depend on Duo, plan to keep a RADIUS-capable MFA service alongside Keycloak, such as privacyIDEA, which integrates with Keycloak as an identity provider plugin and offers RADIUS and Windows logon integration. Treat that pairing as a two-component design with two owners, two upgrade paths and two sets of enrollment records. Record the decision in writing, with the list of flows each component covers, before you start the migration.
Which option fits which scenario
This table maps common Duo use cases to the open-source option that fits each one best. Read the Better fit column first, then the reason, which names only capabilities stated for each product. Keycloak covers most web SSO second-factor needs, while RADIUS, Windows logon and Linux login point to privacyIDEA. Device trust is the row to verify against current Duo and Keycloak documentation before you commit.
| Scenario | Better fit | Reason |
|---|---|---|
| SSO second factor for web apps | Keycloak | Built-in OTP and WebAuthn protect OIDC and SAML logins on the same server that already handles single sign-on. |
| VPN and network device RADIUS | privacyIDEA | Keycloak does not serve RADIUS. privacyIDEA integrates with OpenVPN, Fortinet and Palo Alto through RADIUS. |
| Windows logon and RDP | privacyIDEA | privacyIDEA provides a Windows credential provider. Keycloak does not cover Windows logon, so confirm this before relying on it. |
| Linux SSH and local logons | privacyIDEA | privacyIDEA offers a PAM module for Linux. Keycloak covers web and application logins, not PAM-based sessions. |
| Device trust and conditional access | Confirm first | Not established in this comparison. Check Duo's device trust features and Keycloak's authentication flow options in current documentation. |
| Air-gapped or sovereignty-bound sites | privacyIDEA | Keeps user data inside your own infrastructure, which suits isolated or sovereignty-bound networks. Confirm offline operation in your environment. |
| Mixed estates with SSO, VPN and logon | Both together | Keycloak handles SSO and federates existing AD or LDAP users, while privacyIDEA covers RADIUS and logon flows. |
Where the MFA data and control sit
Duo's second-factor decision is made by Cisco's cloud service. Duo-protected applications and the Duo Authentication Proxy send authentication requests to that service, so the availability and data path of the MFA step depend on a service you do not operate.
- Service location: Duo's decision logic and factor data run in Cisco's environment. Confirm with Cisco which regions, retention periods and data handling terms apply to your contract.
- Outbound paths: Duo-protected services and the proxy need outbound connectivity to Duo's cloud, so firewall reviews must account for those flows.
- Keycloak placement: Keycloak runs where you deploy it, including your cloud account, a data center or an air-gapped segment, and its OTP and WebAuthn checks run inside that boundary.
- Remaining dependencies: Keycloak still depends on its database, its user store and any LDAP or Active Directory federation, so those paths must stay reachable even though the MFA check stays inside your network.
Ask your network team which Duo endpoints your firewalls currently allow, then compare that list with the paths your Keycloak deployment will need.
Keycloak is Apache 2.0 software that you install, operate and patch in the environment you choose. Its supported production databases include PostgreSQL 14 to 18, and its documented high availability designs depend on a synchronously replicated database.
- Supported databases: Keycloak lists MariaDB, Microsoft SQL Server, MySQL, Oracle Database, PostgreSQL, Amazon Aurora PostgreSQL, Azure SQL and EnterpriseDB Advanced. The development file database is for development only.
- High availability: The documented designs are a single cluster, optionally spread across availability zones, and multi-cluster deployments. Both supported designs need a synchronously replicated database, so plan that before you buy hardware.
- Kubernetes: The Keycloak Operator can be installed through Operator Lifecycle Manager or kubectl. The operator documentation strongly recommends manual approval mode for updates.
- Air-gapped operation: Keycloak's authentication flow does not call a vendor service, so it can run on an isolated network. Confirm how container images and updates will reach that network.
Have your platform team map the database, cluster topology and update path on paper before any MFA cutover, because each one determines where credentials and session data live.
The MFA secrets that matter most are TOTP seeds, registered WebAuthn credentials and user passwords. Under Duo, Cisco holds the enrollment and factor records. Under Keycloak, your database holds the OTP credentials and WebAuthn public keys, so custody of that data moves to your side of the boundary.
- Who holds seeds: Under Keycloak, TOTP secrets sit in the database you run. Under Duo, enrollment records sit with Cisco, so the custody question moves to your team.
- WebAuthn keys: Registered passkeys and security keys store a public key on the server and keep the private key on the device. A leaked credential table therefore exposes less than a leaked TOTP seed would.
- Database access: Database administrators, backup operators and monitoring accounts can reach the credential tables. Restrict those roles and confirm with Keycloak's documentation and your database vendor how data is protected at rest.
- Key and secret owners: Record who owns the TLS certificates, database encryption keys and Keycloak admin credentials, and document how each is rotated.
Ask your security team to write down who can read the credential tables today, then compare that list with the access model you will operate in Keycloak.
Keycloak exports and imports realms as JSON files with the kc.sh export and kc.sh import commands. The project documentation warns that this process has limitations as a backup and restore mechanism, and all nodes must be stopped while it runs. A realm export is useful for migration and recovery planning, but production data also needs database-level backups.
- Downtime: Because all nodes must stop during an export, schedule it as a maintenance window and measure how long that window takes in your own environment.
- Limitations: Read the limitations described in the Keycloak import and export guide before relying on a JSON file for restore, and test what it does and does not include.
- Database backups: Use database-native backup and point-in-time recovery for production data, and run restore tests on a set schedule.
- Recovery records: Keep a record of each test restore, including the date, the scope, the person who ran it and the result, so the restore history can be shown during an assessment.
Run a test export and import in a non-production realm, note what is missing from the result, and decide which database backup covers that gap.
A compliance team needs to show how MFA is configured, who can change it and what was logged, using evidence an independent auditor can sample. DeployOpen prepares systems, controls and evidence for assessments. Independent auditors and certification bodies issue any audit report, attestation or certification.
- Configuration baseline: Export the realm configuration and authentication flow settings, store them under change control and keep the version history.
- Access records: Document who administers Keycloak and its database, and how privileged access is granted, reviewed and removed.
- Logs and events: Confirm which login and admin events Keycloak records in your setup, where they are forwarded and how long your retention policy keeps them.
- Duo baseline: Capture Duo's current policies and reports before cutover so the old and new MFA states can be compared. Confirm with Cisco what your contract allows you to export.
Agree the evidence list with your auditor before the migration starts, so each control can be shown in both the old and new environments.
What Keycloak does not cover for Duo users
Keycloak covers web and application SSO, but it does not act as a RADIUS server or a Windows logon provider. Teams that use Duo for VPN sign-in, firewall administration, or network device logins should assume those flows need a separate component. Keycloak speaks OpenID Connect, OAuth 2.0 and SAML 2.0, which are web protocols, so a VPN concentrator or switch that only understands RADIUS cannot use Keycloak OTP or WebAuthn directly. The same applies to Windows logon and RDP, where Duo's credential provider has no Keycloak equivalent. Before you commit to Keycloak, list every Duo integration in your Admin Console and mark each one as web SSO or as RADIUS, LDAP, or Windows, then confirm the gap with your own VPN and endpoint vendors.
privacyIDEA fills these gaps when it is paired with Keycloak. It integrates with Keycloak as an identity provider plugin, so Keycloak still handles the login flow while privacyIDEA handles the second factor. It also exposes a RADIUS integration for VPNs and network devices, a Windows credential provider for logon, and a PAM module for Linux. Under this design, one set of tokens can serve both web and network logins, which avoids enrolling users twice. Note that the Windows and PAM components depend on the operating system versions you run, so confirm support for your exact builds with the privacyIDEA project before you plan the rollout.
The pairing adds a second system to operate. Keycloak and privacyIDEA each need their own servers, patching, backups, monitoring and certificates, and each must be able to reach the same user store. If Keycloak federates users from Active Directory and privacyIDEA resolves them from a different LDAP source, a disabled account or a renamed user can be honored in one place and missed in the other. Decide which directory is the source of truth, document how account changes flow to both systems, and test a disabled-user scenario before cutover. Ask your team who owns the privacyIDEA side of on-call and how a failure in either component affects sign-in.
What drives the cost of running Keycloak MFA
Keycloak itself carries no license fee, so the cost of running it for MFA sits in the components around it: the database, the cluster, the upgrade cycle, enrollment support and any second product needed for VPN or Windows logon. Each card below is a cost line to price separately when you compare against your Cisco Duo renewal.
Keycloak software licensing
Keycloak is licensed under Apache 2.0, so the software itself carries no license fee. Costs come from the people and infrastructure that run it, and from any paid support you choose to buy, such as Red Hat's build of Keycloak. Ask each vendor whether support is per node, per core or per user, and whether it covers the MFA features you use. Confirm the support model before comparing totals with a Duo renewal.
Production database
Keycloak stores realms, users, credentials and OTP and WebAuthn registrations in a database. Supported production options include PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database, Amazon Aurora PostgreSQL and Azure SQL. Your database team may already run one of these, which lowers the added cost, but backup, patching and licensing for commercial engines are recurring items. Ask whether your chosen engine carries a license fee.
High availability design
A highly available Keycloak deployment needs at least two nodes and a database that replicates synchronously, as the supported high availability designs require. Cross-zone placement adds network and database cost. Multi-cluster designs add further infrastructure. Each design choice changes the server count, load balancing and database spend, so ask your architect to price the design you pick, not a generic cluster.
Upgrade and operator effort
Keycloak plans four minor releases a year and a major release every two to three years, so staff time for testing and rollout recurs. The Operator docs recommend manual approval mode for updates to avoid unplanned upgrades. Budget for a staging environment, a test plan for each MFA flow, and a rollback path. Ask any implementation partner to state in writing which releases are covered and how many upgrade cycles the retainer includes.
Enrollment and help desk work
Duo users already have enrolled devices. Moving them to Keycloak OTP, WebAuthn or passkeys means each user enrolls again, and the first weeks generate help desk tickets for lost phones and locked accounts. This is usually the largest one-time cost in the move and recurs with every new hire and device replacement. Ask for a verification procedure and a set of recovery codes or backup factors before you size the help desk.
VPN and Windows integration effort
Keycloak does not serve RADIUS for VPNs or Windows logon. If those flows stay on Duo, you still pay for Duo. If you add privacyIDEA for them, you add a second product to install, patch, back up and test against each VPN and Windows fleet. Ask for the integration scope per device type, the Windows credential provider rollout plan, and the test matrix for each VPN vendor before you accept a quote.
How a move from Duo to Keycloak MFA is structured
The sequence moves second-factor enrollment for web SSO from Duo to Keycloak in stages, so users keep access throughout and RADIUS and Windows flows stay covered until each one is verified. The end state is a Keycloak realm handling SSO MFA, with Duo retired only after a confirmed overlap period.
Inventory users and enrolled factors in Duo
Export the user list, enrolled devices and hardware tokens from Duo, and record which factor each user relies on and which applications each factor protects. Use the Duo export guide for the Admin API steps and plan limits. The step is done when you have a reconciled inventory that separates users who only sign in to web SSO from users who depend on VPN, RADIUS or Windows logon. The security team and the Duo administrator usually own this work, and the output feeds every later step.
Connect Keycloak to LDAP or Active Directory
Configure Keycloak user federation against your existing LDAP or Active Directory server so that accounts, groups and passwords stay in the directory of record instead of being copied into Keycloak. Confirm the bind account, search base and attribute mappings with your directory team, and test with a pilot group. The step is done when a test user authenticates through a Keycloak client with the expected groups and attributes, and the directory remains the source of truth.
Configure OTP and WebAuthn in Keycloak
Enable the built-in OTP and WebAuthn credential types in the realm, set the required-action and conditional authentication flows that decide when a second factor is asked, and decide which factors are offered to which groups. Check the server administration guide for the current options in your release. The step is done when a test account can enroll a TOTP app and a hardware security key, and the browser login prompts for the second factor as the flow specifies.
Plan staged enrollment so no one is locked out
Pilot with a small group, then move remaining groups in waves. Give each user a documented way to enroll the new factor before their Duo factor is disabled, and keep a help desk procedure for recovery codes and identity checks. Define who can reset a factor and how that is logged. The step is done when every wave has a sign-off from its business owner and help desk, and no wave starts before the previous one shows a low rate of enrollment failures.
Keep Duo or privacyIDEA for RADIUS and Windows flows
Keycloak does not serve RADIUS for VPNs or Windows logon, so those flows keep their current second factor during the overlap. Decide whether Duo stays for them or whether privacyIDEA takes them over through its RADIUS and credential provider integrations, and document the owner and the cutover date for each flow. The step is done when every non-SSO flow has a named MFA service and a tested path, with no flow left without a second factor.
Cut over SSO clients to Keycloak
Point each SSO application at the Keycloak realm, one client at a time, starting with applications that have the least dependence on Duo-specific behavior. Verify the redirect URIs, token lifetimes and claims for each client, and keep a rollback path to the previous configuration until the client has run cleanly. The step is done when every SSO application authenticates through Keycloak with its MFA prompt, and the application owners confirm their access.
Verify, then retire Duo
Run both systems in parallel for a verification period that your security team sets based on login volume and audit needs, and review Keycloak authentication logs and help desk tickets for failures. Then disable Duo integrations for SSO, retire the Duo Authentication Proxy only where its flows have moved, and cancel the subscription at contract end. Confirm the Duo contract terms and data retention rules with the vendor before deletion. The step is done when logs show no remaining Duo dependency and the decommissioning record is signed off.
Operating Keycloak in production
The first operating decision is the database and high availability design, because it determines everything else. Keycloak supports PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database, EnterpriseDB Advanced, Amazon Aurora PostgreSQL and Azure SQL for production, and the dev-file database is for development only. Keycloak documents three high availability architectures: a single cluster optionally spread across availability zones, multi-cluster deployments (v2) without external Infinispan, and the deprecated multi-cluster v1. Both supported designs need a synchronously replicated database, so your team should confirm with its DBA that the database platform can meet that requirement before the Keycloak design is fixed. The current release is 26.8.1, published October 13, 2026. Since Keycloak 26.0, the project plans four minor releases a year and a major release every two to three years, with breaking changes in minor releases made opt-in, so budget recurring upgrade testing as a standing task.
Install the Keycloak Operator through Operator Lifecycle Manager, the recommended method, or with kubectl or the experimental Helm chart. The Operator manages Keycloak, KeycloakRealmImport, KeycloakOIDCClient and KeycloakSAMLClient resources, which lets realm configuration live in version control. The Operator documentation strongly recommends manual approval mode for updates, so an upgrade only starts after a reviewer approves it. Keycloak migrates its database schema automatically at startup by default. For large deployments the upgrading guide suggests manual migration instead, where your DBA applies the SQL before the new version starts. Confirm which path your change process allows, and rehearse it against a copy of the production database. Keycloak's realm export with kc.sh export has documented limits as a backup mechanism and requires all nodes to be stopped, so plan database-level backups and tested restores as the primary recovery method.
Enable metrics and health endpoints from the start so that login failures, token errors and database latency are visible before users report them. The observability documentation describes the metrics configuration, and the production configuration guide covers the hardening settings your security team will ask about. For the commercial question, Red Hat build of Keycloak is Red Hat's supported distribution based on the open-source project and replaces Red Hat Single Sign-On. Its product page showed version 26.6 as the latest, so confirm the current supported version and subscription terms with Red Hat if your buyers need vendor support contracts. Otherwise, the operating work above falls to your own platform team or to a DeployOpen retainer, and the written scope should name who owns upgrades, backups and on-call response.
Questions buyers ask before switching from Duo to Keycloak
Can Keycloak replace Duo push notifications?
Not as a built-in feature. Keycloak's built-in OTP and WebAuthn cover web SSO second factors, but Duo push with its mobile app and device trust checks is a Duo-specific capability that Keycloak does not provide out of the box. Teams that rely on push should confirm which login flows use it, then decide whether a different second factor (TOTP, WebAuthn or passkeys) is acceptable for those users. If push is a hard requirement, pairing Keycloak with privacyIDEA, which supports push through its own authenticator app, is the path to check in your own environment before you commit.
How much effort does a Duo to Keycloak migration take?
The effort depends on the number of applications that use Duo through SSO, how users are stored today, and how much enrollment work the rollout needs. Start by inventorying which applications and users depend on Duo, then map each one to a Keycloak client and second factor. Enrollment planning matters most, because users must register new factors before Duo is turned off. No researched figure is available for duration, so ask any implementation partner for a written scope and timeline that lists these items individually.
Can our own team migrate from Duo without outside help?
Yes, many teams do this internally, provided they have people who already run Keycloak or are willing to learn it. The work includes standing up a production-grade deployment on a supported database, configuring realms and clients, and planning enrollment so nobody is locked out. Teams without Keycloak experience often find the high availability design and upgrade process the hardest parts. DeployOpen plans, implements, hardens and documents self-hosted platforms under a fixed-scope written agreement, and ongoing support is available as a retainer, so you can compare doing it internally against a scoped engagement.
What do identity and network staff need to contribute?
Identity staff own the directory, user lifecycle and enrollment communication, while network and security staff own the VPN, firewall and RADIUS decisions. Identity staff should confirm how users are sourced, whether Active Directory or LDAP is in use, and which applications redirect to Duo. Network staff should list every VPN, appliance or Windows logon that calls Duo today, since those flows need a separate plan. Both teams should agree on a rollback path and an owner for help desk escalations before cutover.
What happens to VPN MFA when we move to Keycloak?
Keycloak serves OpenID Connect, OAuth 2.0 and SAML 2.0 flows, so it does not act as a RADIUS server for VPN appliances. VPNs that authenticate over RADIUS need a separate component. privacyIDEA integrates with VPNs such as OpenVPN, Fortinet and Palo Alto through RADIUS, which is why many teams pair the two products. Confirm which VPN and network devices use the Duo Authentication Proxy today, and test each one against the chosen RADIUS integration before removing Duo from those paths.
Does Keycloak support passkeys and hardware keys?
Keycloak supports WebAuthn as a second factor, which covers hardware security keys and platform authenticators that many teams use as passkeys. Confirm the exact passkey behavior, including discoverable credentials and account recovery, against the Keycloak server administration guide for the version you deploy. Plan a recovery method for users who lose their device, since a WebAuthn key registered only once can block a login. Test your chosen authenticators with each application before rollout.
How do backups and realm exports work in Keycloak?
Keycloak exports and imports realms as JSON files using the kc.sh export and kc.sh import commands. The project documents that this process has limitations as a backup and restore mechanism, and all nodes must be stopped while it runs. For production, plan database-level backups alongside realm exports, and schedule a restore test in a non-production environment. Ask any implementation partner to define backup scope, retention and restore procedures in the written scope, and read the Keycloak import and export documentation before deciding on the approach.
Deciding whether pairing is worth the added system
A team whose Duo use is limited to MFA on web single sign-on can often run Keycloak alone. Keycloak's built-in OTP and WebAuthn cover the browser and application logins that pass through its realms, and adding privacyIDEA only makes sense when a flow Keycloak does not serve is still protected by Duo. Duo is a mature, well-supported product with push and device trust features that many organizations value, and a team that gets those features from Duo today should not assume Keycloak will match them. Before deciding anything, list every place Duo is called: SSO applications, VPN gateways and network devices through the Duo Authentication Proxy, Windows logon or RDP, and SSH on Linux servers. Each one is a separate decision.
Four questions settle the decision. First, which flows does Duo actually protect, and does each of them terminate at Keycloak? Any RADIUS, LDAP or Windows logon flow will still need a second system. Second, is device trust a hard requirement? Keycloak's built-in factors do not replace Duo's device health and trusted endpoint checks, so confirm whether a control framework or internal policy requires them, and plan for a different control if it does. Third, what operating capacity does the team have? Running two MFA stacks means two upgrade paths, two sets of backups and two sets of enrollment support, and a small identity team may prefer one system with a known gap over two systems with more coverage. Fourth, does the license fit procurement? privacyIDEA is licensed under AGPLv3, and the privacyIDEA Enterprise Edition is available from NetKnights, so ask legal whether AGPLv3 use inside the organization is acceptable and whether a support subscription is needed.
Write the answers down as a short decision record: the flows in scope, the factors each flow must support, the named owner for each system and the date the Duo contract ends. If only browser-based SSO remains, Keycloak alone is usually the simpler path, and the work moves to planning enrollment so nobody is locked out. If VPN or Windows logon stays on the list, confirm that privacyIDEA covers those flows in your environment before committing, because pairing two systems is only worth it when each one has a clear job.
How DeployOpen helps evaluate and implement the move
DeployOpen is a Chainscore Labs company that plans, implements, hardens and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from Cisco Duo to Keycloak MFA, we start by sorting which Duo use cases Keycloak covers and which need privacyIDEA alongside it.
How we scope
- Inventory which Duo-protected SSO applications, VPNs, RADIUS clients and Windows or Linux logons exist today
- Map each use case to Keycloak OTP, WebAuthn, or a privacyIDEA component, and flag gaps in writing
- Agree a fixed scope, deliverables and timeline in writing before any work starts
How we build
- Deploy Keycloak in your environment with a production database from the supported list and an agreed high availability design
- Configure WebAuthn, OTP enrollment flows and federation to your existing LDAP or Active Directory
- Test enrollment, fallback and lockout recovery paths before any user is moved
How we hand over
- Document realm configuration, authentication flows, backup steps and the upgrade procedure for your team
- Set up a backup and restore runbook, noting that realm export is not a complete backup mechanism
- Provide evidence and control records that your internal or external auditors can review
How we support
- Plan Keycloak minor and major upgrades with a tested rollback path before each change
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Confirm current supported versions and dates with the vendor before scheduling each upgrade
