How do you migrate Cisco Duo web SSO MFA to Keycloak without locking users out?
If Duo mainly guards web SSO logins, the move is mostly enrollment and integration work, not a data copy. Keycloak covers the web second factor through its built-in OTP and WebAuthn support, and passkeys can follow where your Keycloak version and browser support allow it. RADIUS for VPNs and Windows logon usually stays on privacyIDEA, so plan for two systems rather than one. Your first decision is which applications and realms move, and which Duo-protected flows must keep a second factor elsewhere before the Duo contract ends.
The work usually sits with your internal identity team, with an implementation partner doing the Keycloak configuration, the browser and application testing and the cutover runbook. Keycloak's authentication flows, required actions and per-client settings need to be set up and tested for each application, and the team should confirm which Duo factors (push, phone, hardware token) map to which Keycloak option before any user is switched. The effort is driven by the number of applications, the factor mix and how many users must re-enroll. Ask any partner for a fixed scope covering these items.
The main risk is lockout. Keep Duo active in parallel for a defined window, enable Keycloak OTP or WebAuthn for a pilot group, and require that each user enroll a second method, such as a backup code or a second passkey, before Duo is removed for them. Confirm with your help desk how identity is verified for re-enrollment, since that step is where social engineering usually succeeds. Use the export and import documentation in the Keycloak server guide to rehearse realm changes in a non-production environment, and remember that exports are not a complete backup, and that all nodes must be stopped while an export runs.
Which Duo capabilities map cleanly to Keycloak, which need rework, and which are gaps
This table maps the Duo capabilities that a web SSO deployment usually relies on against Keycloak's built-in OTP, WebAuthn and passkey support, identity brokering and privacyIDEA. Read each row by its label: clean means Keycloak covers the use case with configuration, rework means it is possible but changes enrollment or application behavior, and gap means Keycloak does not serve it as documented and a second component is needed. The main takeaway is that web SSO second factors move cleanly, while RADIUS and Windows logon flows need privacyIDEA.
| Duo capability | Keycloak or privacyIDEA equivalent | Migration label |
|---|---|---|
| Second factor on SAML 2.0 and OIDC SSO logins | Keycloak supports OpenID Connect and SAML 2.0 applications, so browser logins can require an OTP or WebAuthn step in the authentication flow | Clean |
| TOTP codes in an authenticator app | Keycloak OTP enrollment works with standard authenticator apps, but users must re-enroll because Duo secrets cannot be carried over | Needs rework |
| WebAuthn and passkey logins | Keycloak supports WebAuthn security keys and passkeys as second factors, so confirm passkey policy and browser support for each application | Clean |
| Duo Push approval and Duo Mobile | Keycloak does not provide Duo-style push approval as documented; confirm this with the Keycloak release you plan to run or plan a privacyIDEA push component | Gap |
| Device trust and health checks | Keycloak's built-in flows do not document Duo-style device trust or endpoint posture checks; plan an equivalent through conditional policies or another control | Gap |
| Identity brokering from existing IdPs | Keycloak identity brokering and user federation with LDAP and Active Directory replace the directory links Duo used for user lookup, after a directory mapping review | Needs rework |
| RADIUS for VPNs and network devices | Keycloak does not serve RADIUS as documented; route these flows to privacyIDEA's RADIUS integration on the same users | Gap |
| Windows logon and RDP second factor | Keycloak does not provide a Windows credential provider; privacyIDEA covers this with its Windows integration | Gap |
What data and integrations move, and which exports exist
Moving from Duo to Keycloak MFA is less a data copy than a set of separate moves: the user inventory, the directory that holds identities, the realm configuration, and the enrolled factors. Each one has a different export path and a different limit, so plan them as distinct workstreams.
User and device inventory from Duo
Start with a list of every Duo user, their group memberships, enrolled devices and the applications each one reaches. Duo's Admin API can provide much of this, but which endpoints you can call depends on your Duo plan and API credentials, so confirm access with Cisco before the contract ends. Use the inventory to decide who moves in the first wave and which applications need a Keycloak client before they can switch.
Identity source through user federation
Keycloak does not need Duo users copied into its database when identities already live in Active Directory or LDAP. Configure Keycloak's user federation so logins check the existing directory, and keep password management where it is today. Confirm which attributes Keycloak must map, such as username, email and group membership, before you test with a pilot group.
Realm export and import with kc.sh
Keycloak exports and imports realms as JSON using kc.sh export and kc.sh import. Use the export to capture realm settings, clients, roles and the import of a test realm in a staging environment. The documentation warns that this is limited as a backup and restore method and that all nodes must be stopped during the run, so plan a maintenance window and keep a separate database backup for recovery.
Rebuilding application client registrations
Each application that trusts Duo through SAML or OIDC needs a matching client in Keycloak with the same redirect URIs, signing certificates and attribute mappings. Keycloak's Operator can manage KeycloakOIDCClient and KeycloakSAMLClient resources if you want client definitions under version control. Test each client against a staging copy of the application before changing the production sign-on path.
Factor enrollments must be re-enrolled
Duo factor enrollments do not transfer as secrets, so Keycloak cannot take over a user's Duo Mobile push or device registration. Each user must enroll a new Keycloak OTP app, WebAuthn key or passkey. Schedule enrollment in waves, keep the Duo method active until each user has a working Keycloak factor, and make sure the help desk has a documented identity verification step for recovery.
Keycloak realm export limitations
A realm JSON export describes configuration but is not a full backup of user credentials, sessions or event data stored in the database. Treat the export as documentation of configuration and keep database-level backups for recovery. Ask your DBA to confirm the backup method for your chosen database, and test a restore in a non-production environment before cutover.
What happens in each migration phase, and what each phase produces
The sequence moves Duo's second factor for web SSO to Keycloak in stages, so each application changes only after its users have enrolled and its login path is tested. Each phase ends with a written artifact that the next phase depends on.
Inventory users, applications and factors
Your team exports the user list, enrolled devices, hardware tokens and the applications protected by Duo, using the Duo Admin API or the admin console where your plan allows it. The output is an inventory that maps each application to its Duo integration, the factors each user holds, and whether a login path uses RADIUS or LDAP rather than a SAML or OIDC connection. The step is done when every Duo integration is assigned to Keycloak, to privacyIDEA, or to a decision to retire it.
Build the pilot realm and enrollment flow
Your identity team creates a pilot realm or group in Keycloak, configures OTP and WebAuthn as required or optional authentication steps, and connects the directory through user federation with your LDAP or Active Directory server. A small group of volunteers enrolls authenticator apps and passkeys while the team checks how recovery and re-enrollment behave. The output is a pilot sign-off record that lists the tested factors, the enrollment steps users follow, and the help desk procedure for a lost device.
Plan enrollment so no user is locked out
Before any application changes, your team sets a date window in which users enroll their Keycloak factor while Duo still works, and confirms that each user has at least one working method on both systems. Hardware tokens and users who will not move to passkeys need a documented path, such as a backup code or a verified help desk identity check. The output is an enrollment tracker with per-user status and a rollback statement that says how a user returns to Duo if enrollment fails.
Run Duo and Keycloak in parallel
Duo continues to protect the existing applications while one or two low-risk applications are switched to Keycloak as the identity provider and its second factor. Your team watches login success rates, support tickets and Keycloak event logs during this period and records every issue with its cause. The output is a parallel run log that shows which applications work on Keycloak, which need configuration fixes, and which must stay on Duo for now.
Cut over applications in stages
Each remaining application moves to Keycloak in its own change window, following a written runbook that lists the client configuration, the redirect URIs, the login test cases and the fallback step. Your team switches one application at a time, confirms the test cases pass, and only then moves to the next application. The output is a cutover runbook per application and a signed change record that confirms each application no longer sends second-factor prompts through Duo.
Confirm RADIUS and VPN flows on privacyIDEA
Keycloak does not serve RADIUS, so VPN concentrators, network devices and any Windows or Linux logon that relied on the Duo Authentication Proxy must be tested against privacyIDEA before Duo is removed. Your team checks each RADIUS client, the factors it accepts and its behavior when the MFA service is unreachable. The output is a flow test report that lists each RADIUS and logon path, its privacyIDEA configuration and its result.
Decommission Duo and archive records
After the inventory, pilot, parallel run, cutover and RADIUS tests are complete, your team disables the Duo integrations, revokes the Admin API credentials and removes the Duo Authentication Proxy from service. Exported user and authentication logs are archived under your retention policy before the Duo tenant is closed. The output is a decommission record that lists each integration disabled, each credential revoked and where the archived logs are stored, so auditors and your compliance team can trace the change.
What drives migration cost and duration, and how to keep each down
This table lists the inputs that shape a Duo to Keycloak MFA migration, the one-time and recurring costs each one affects, and the levers that keep them down. Use it to scope the work in writing before asking for a quote, because most of the effort comes from counts you can pull from your own Duo and directory environment.
| Cost driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Number of applications on Duo | Each SSO client needs its Keycloak client, MFA flow and test pass, so the count sets build and testing effort. | Group apps by login pattern, start with the few that cover most users, and retire unused integrations before migration. |
| Number of users and hardware tokens | Users need enrollment and help desk contact, and hardware tokens need inventory and re-issue or re-registration. | Export user and token inventory from the Duo Admin API early, and decide which tokens move as WebAuthn keys and which are replaced. |
| Enrollment model (self-service or assisted) | Self-service enrollment shifts work to users but needs clear guidance, while assisted enrollment adds help desk hours during the cutover window. | Enable self-service enrollment with a grace period, publish step-by-step guides, and stage cutover by department. |
| RADIUS and Windows logon flows | Keycloak does not serve RADIUS or Windows logon, so each such flow needs a separate privacyIDEA component and its own test plan. | Count these flows before design, keep them on privacyIDEA only where required, and confirm integration support for each VPN or device model. |
| Keycloak database and high availability design | The supported production databases and the HA designs both need a synchronously replicated database, which adds infrastructure and licensing decisions. | Pick a supported database you already operate, and size HA only for the availability your MFA service must meet. |
| Internal testing capacity | Test accounts, staging environments and a test group of users determine how long validation takes before production cutover. | Reserve named testers, build a staging realm that mirrors production, and confirm testing scope in the written statement of work. |
| One-time build, migration and testing | Realm design, client configuration, data mapping, pilot runs and cutover support are paid once, usually as fixed-scope project work. | Agree deliverables and acceptance criteria in writing so the scope does not expand during the project. |
| Recurring Keycloak operations and upgrades | Keycloak ships four minor releases a year, and each upgrade needs testing, while the Operator docs recommend manual approval for updates. | Plan a recurring upgrade window, use manual approval mode, and ask whether a support retainer covers upgrades and testing. |
| Recurring support and staff time | Your team or a retained partner carries monitoring, backups, incident response and help desk volume after go-live. | Ask for runbooks and documentation as deliverables, and confirm which support tasks are in a retainer and which are billed separately. |
What usually goes wrong and how to prevent it
Most failed Duo-to-Keycloak moves fail on enrollment, cutover timing or operations rather than on the software itself. The cards below cover the failure points we see most often in planning, and the check to run before each one turns into an outage or a support queue.
Enrollment gaps lock users out
Users who have not registered a Keycloak OTP or WebAuthn credential before Duo is switched off cannot complete a web SSO login. Build an enrollment report that lists every user with at least one usable second factor, and set the cutover date only after the remaining group is small enough to handle with supervised enrollment. Confirm that enrollment is possible from the user's own session, not only through an administrator.
No second factor after Duo is off
Turning off Duo before the replacement is proven leaves users with a password-only login, which many policies treat as a failed control. Keep the Duo tenant read-only and reachable for a fallback period, and agree in writing who can approve a temporary exception. Test a login for each user group, including contractors and service accounts that were exempt from Duo, before the switch.
Keycloak upgrades that change behavior
Keycloak plans four minor releases a year and says breaking changes in a minor release will be opt-in, but authentication flows, default settings and deprecated features can still shift between versions. Pin the version used in production, run your authentication flows and client logins in a staging realm on the next release, and read the upgrade notes for each release before adopting it.
Realm export mistaken for a backup
The kc.sh export command writes realm JSON, but the Keycloak documentation warns that this has limitations as a backup and restore mechanism. Users' credentials and some runtime state may not be restored the way you expect. Use database-level backups as the restore path, and test a restore into a separate environment before you rely on it for the migration.
Export window stops every node
The export process requires all Keycloak nodes to be stopped while it runs, so a cluster serving logins will have an outage if export is planned casually. Schedule the export in a maintenance window that users have been told about, and rehearse the stop, export and restart sequence in staging so the time it takes is measured rather than guessed.
Operator upgrades apply unplanned
The Keycloak Operator documentation strongly recommends manual approval mode for operator updates, because automatic approval can upgrade Keycloak without a change review. Set the approval mode explicitly in the cluster, record which version each environment runs, and route operator upgrades through the same change process as application releases.
VPN users without RADIUS coverage
Keycloak does not serve RADIUS, so VPN concentrators and network devices that send second-factor requests over RADIUS will fail once Duo's proxy is removed. Inventory every VPN, Wi-Fi and network device that uses Duo, then decide which of them move to privacyIDEA's RADIUS integration before the cutover. Confirm each device's RADIUS and MFA settings in a test login.
How the migration changes by starting point
When Duo mainly sits in front of web SSO and the user base already lives in Active Directory, the identity data is the easy part. Keycloak can read users and groups from AD through its built-in user federation, so the migration centers on the authentication flows rather than on copying accounts. Most of the work is deciding which users keep their Duo factor on the new side and which move to OTP, WebAuthn or passkeys.
- Federation first: Connect the AD user federation provider in a test realm and confirm that group membership maps to the roles your applications expect before touching any factor.
- Browser flows: Rebuild the Duo prompt as a Keycloak browser flow with conditional OTP or WebAuthn steps, and test each application's login path separately.
- Factor mix: Decide which users move to passkeys, which keep TOTP apps and which need a hardware key, then enroll pilot groups before the general rollout.
- Directory writes: Confirm whether Keycloak is allowed to store factor data in its own database, since the AD schema usually stays read-only for this purpose.
- Fallback path: Keep the Duo application live until every SSO app has passed a login test on Keycloak.
Ask your identity team to confirm which AD attributes carry the group and department data your apps depend on before scheduling the cutover.
Organizations that issued many hardware tokens through Duo need a plan for the tokens themselves, not only for the users. Keycloak supports WebAuthn security keys and passkeys, but it is a different credential model from Duo's hardware OATH tokens, so existing tokens cannot simply be carried over. The migration therefore splits into tokens that can be re-registered as WebAuthn keys and tokens that must stay on an OATH-compatible path until their holders are replaced.
- Token inventory: Export the hardware token list from Duo and sort tokens by type, owner and whether the user still logs in through SSO.
- Key replacement: Plan WebAuthn enrollment for users who can register a security key or passkey, with a supervised session for each.
- OATH tokens: Where hardware OATH tokens must continue to work, confirm whether they can be supported in Keycloak OTP or whether privacyIDEA should handle that group, and state the decision in writing.
- Lost token handling: Define how the help desk revokes and replaces a token before the change window.
- Stock and logistics: Ask the vendor or your procurement team which key models you must buy and how long delivery takes.
Confirm with your security team how many tokens will need a replacement path, since that number drives the help desk load more than the server work.
When Duo protects VPN concentrators, network devices or Windows and RDP logons, Keycloak does not cover those flows by itself. These logins use RADIUS, LDAP or local credential providers rather than browser redirects, so the scope of the migration becomes two parallel tracks. Keycloak handles the web SSO factors, and privacyIDEA takes over the RADIUS and Windows integrations that Keycloak does not serve.
- Flow inventory: List every Duo integration by type, including the Duo Authentication Proxy, Windows logon and any Unix or SSH agents, before deciding which track each one follows.
- RADIUS track: Replace the Duo proxy path with a privacyIDEA RADIUS setup for VPNs and network devices, and test one device at a time.
- Windows track: Plan the credential provider rollout separately, including offline logon behavior and the Windows Server version support status you must confirm.
- Shared users: Keep a single source of user identity for both tracks so a user does not hold two unrelated enrollments.
- Change control: Schedule network device changes separately from web app changes so a failed VPN change does not block SSO.
Confirm the list of non-web Duo integrations with your network and endpoint teams before agreeing on a single cutover date.
When Keycloak will run on Kubernetes, the Keycloak Operator becomes the main way to define the realm, clients and the server itself. The migration then includes deployment design: the database must be one of the supported production databases, the high availability architecture must be chosen up front, and realm configuration should live in version-controlled resources. The Duo cutover is the same, but the change control around it is more formal.
- Operator setup: Install the Operator through Operator Lifecycle Manager, the recommended method, and define Keycloak and KeycloakRealmImport resources in Git.
- Update control: Set operator updates to manual approval, as the Operator documentation strongly recommends, so upgrades never happen during a login cutover.
- Database and HA: Choose a supported production database and confirm that the replication design meets the synchronous requirement for the chosen HA architecture.
- Schema changes: Decide between automatic schema migration at startup and manual SQL application for the production database.
- Rollback: Keep the Duo integration intact until the Kubernetes deployment has passed the same login tests as a standalone server.
Confirm with your platform team which Keycloak version and database versions your cluster supports before writing the deployment plan.
What buyers and engineers ask before moving off Duo for web SSO
What drives the cost of moving Duo web SSO MFA to Keycloak?
Cost depends mostly on how many applications, directories and user groups sit behind Duo, and on how much of the work your own staff can absorb. The software itself is Apache 2.0 licensed, so there is no license fee for Keycloak. The recurring costs are the servers or Kubernetes capacity, the database, backups, upgrades and the help desk time spent on enrollment. The one-time costs are design, application re-integration, testing and cutover. Ask any vendor for a quote that splits these components, shows who is paid for each, and states what recurs each year.
How long does a Keycloak MFA migration from Duo take?
The duration depends on your Duo inventory more than on Keycloak itself. Teams need to know how many applications use Duo through SAML or OIDC, how many users have push, phone or hardware token enrollments, and which groups need a different second factor. An inventory built from Duo's Admin API and your directory makes the schedule predictable. Keycloak's release cadence is four minor releases a year, so plan an upgrade window into the project. Ask for a timeline that is tied to the written scope, with milestones for pilot, enrollment waves and Duo shutdown.
What must our team provide before a migration engagement starts?
Plan to supply application owners who can confirm redirect URIs, claims and session behavior for each SSO app, plus directory access. Keycloak can federate existing LDAP and Active Directory servers, so you need a service account with read access and a clear view of which attributes identify users. You also need a set of test users spanning each group, device type and factor, and a change window with help desk staff available during cutover. Name these owners in the statement of work so they are not discovered mid-project.
Can our own team run the Duo to Keycloak migration in-house?
Yes, many teams can do it in-house if they already run Keycloak or have engineers comfortable with OIDC, SAML and directory integration. The work that usually needs experience is high availability design, which requires a synchronously replicated database for supported designs, backup and restore planning, and the handling of schema migrations during upgrades. Consider whether your team can keep the platform patched after the project ends. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your environment, under a written fixed scope, so you can choose to hand over the whole project, part of it, or only a review.
Do passkeys replace Duo push notifications in Keycloak?
Passkeys and WebAuthn can replace push for most web SSO logins, but they are not a one-to-one swap. Keycloak supports WebAuthn-based second factors and OTP, so users who relied on push need enrollment of a passkey, security key or authenticator app before Duo is switched off. Some users will not have a suitable device, and some workflows still expect push. Confirm with your application owners which logins require a phishing-resistant factor, and plan a fallback for users without passkey-capable devices.
Do we still need privacyIDEA if we move web SSO to Keycloak?
You need privacyIDEA only if some flows fall outside Keycloak's scope. Keycloak handles web SSO through OpenID Connect, OAuth 2.0 and SAML 2.0, but it does not act as a RADIUS server for VPN concentrators or serve Windows logon and SSH second factors. privacyIDEA covers RADIUS for VPNs, PAM for Linux, Windows credential provider logon and REST API use, and it has a Keycloak identity provider plugin. Inventory every Duo integration first, including the Duo Authentication Proxy, and decide which of them stay on privacyIDEA before you retire Duo.
How do we ask for a fixed-scope quote for this migration?
Send a written request that lists your Duo integrations, the number of applications, directory sources, user counts by factor type, and any air-gapped or compliance constraints. Ask the provider to state deliverables, assumptions, client responsibilities, test and cutover steps, documentation, post-migration support and the exclusions. DeployOpen works from a written scope agreed before work starts and does not publish a price list, so a quote follows from that scope. Ask whether ongoing support and upgrades are offered as a separate retainer, and whether the quote covers the Duo export and enrollment waves.
How DeployOpen scopes, runs and supports the Keycloak MFA migration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted Keycloak inside your own infrastructure, including the enrollment plan that keeps users out of lockouts. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory which applications use Duo for web SSO and which flows, such as VPN or RADIUS, stay with privacyIDEA
- Agree the factor mapping for OTP, WebAuthn and passkeys in a written scope before work starts
- Define the enrollment waves, fallback methods and help desk procedure that prevent lockouts
How we build
- Deploy Keycloak in your environment on a supported database, with the high availability design you select
- Connect Keycloak to your existing LDAP or Active Directory sources through user federation
- Configure clients, authentication flows and MFA policies, then test each application login end to end
How we hand over
- Document realm configuration, client definitions, enrollment steps and rollback procedures for your team
- Deliver a tested backup and restore runbook, since realm export and import have documented limits
- Provide operator upgrade guidance, including manual approval of updates and schema migration plans
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Review Keycloak release notes with your team before each planned minor or major upgrade
- Confirm with your auditors which control evidence from the migration your assessment expects
