Can an open-source stack replace Okta Adaptive MFA for our workforce?
Keycloak's built-in OTP and WebAuthn factors, paired with privacyIDEA for everything that does not go through a browser, cover most workforce factor types and login paths, but the risk-based signals that Okta Adaptive MFA evaluates must be rebuilt by your team or accepted as gaps. Start by checking which Okta suite and add-ons you hold. Okta's pricing page lists Adaptive MFA as an add-on to the Starter suite and included in Core Essentials and higher suites, so a renewal or add-on price change affects you differently depending on whether MFA is bundled or bought separately. That answer determines how much of the feature set you are actually replacing.
Split the design into two roles. Keycloak acts as the web SSO and MFA broker: it authenticates users to OIDC and SAML applications, enforces required authentication flows and step-up rules that you configure, and issues tokens to relying parties. privacyIDEA acts as the MFA platform for everything Keycloak does not front: RADIUS for VPNs and network devices, the PAM module for Linux logon and SSH, the Windows logon credential provider, and hardware tokens such as OATH, YubiKey and PIV smartcards. Confirm each of these integrations against your own applications and operating systems before you commit, since coverage differs by client type and version. The decision to act on is which Adaptive MFA behaviors you truly depend on. Device trust, IP reputation, impossible travel and per-app policy tuning are signals Okta evaluates from its own telemetry, and an open-source stack will not reproduce them out of the box. List the policies you use today, map each to a Keycloak authentication condition, a privacyIDEA policy or a compensating control, and record any gap as an accepted risk with an owner.
Which Okta MFA capabilities map to which open-source option
This table maps the Okta MFA and Adaptive MFA capabilities a renewal review usually checks to Keycloak, privacyIDEA or a gap, with a coverage note for each. Read the coverage column as native, integration or confirm in your environment, because a supported factor does not mean the same risk logic exists. The main takeaway is that factor coverage is broad, while risk-based sign-on decisions need to be designed and tested as a separate workstream.
| Okta capability | Open-source option | Coverage notes |
|---|---|---|
| Push notifications | privacyIDEA | Integration: requires the privacyIDEA Authenticator app. Standard TOTP apps cannot receive push. |
| WebAuthn and FIDO2 security keys | Keycloak and privacyIDEA | Native in Keycloak for WebAuthn. privacyIDEA also supports FIDO2 and passkeys and hardware keys. Confirm the authenticator models you need. |
| TOTP authenticator apps | Keycloak OTP and privacyIDEA | Native in both. Users of standard TOTP can keep apps such as Google Authenticator. |
| SMS and email one-time codes | privacyIDEA | Native in privacyIDEA. Keycloak SMS or email codes need a custom authenticator or extension, so confirm the approach first. |
| Hardware token seed import | privacyIDEA | Native. Imports SafeNet XML, OATH CSV, Yubikey CSV and PSKC seed files. Confirm vendor formats for your token inventory. |
| Smartcards (PIV and x509) | privacyIDEA | Native per the README. Confirm card middleware on client devices. |
| Windows and Linux logon MFA | privacyIDEA | Integration: Windows credential provider and Linux PAM module. Test each OS build during pilot. |
| VPN and RADIUS MFA | privacyIDEA | Integration through RADIUS for VPNs such as OpenVPN, Fortinet and Palo Alto. Confirm the exact appliance firmware. |
| Enrollment policies and self-service enrollment | Keycloak required actions and privacyIDEA policies | Integration: configure per realm or per policy. Confirm how enrollment is gated and how re-enrollment is handled. |
| Adaptive sign-on based on network zones, device context and risk scores | No direct equivalent | Gap: must be designed with conditional logic, custom authenticators or an external risk engine. Confirm feasibility before committing. |
| MFA reporting and audit trails | Keycloak events and privacyIDEA logs | Integration: forward to your SIEM. Confirm retention and fields against your audit requirements. |
Keycloak alone, privacyIDEA alone, or both together
Keycloak's built-in OTP and WebAuthn cover web single sign-on, while privacyIDEA extends MFA to RADIUS, PAM, Windows logon and hardware tokens. The right option depends on which protocols and login paths your users actually touch, and whether you can run a second service.
Keycloak OTP and WebAuthn only
Keycloak's built-in OTP and WebAuthn factors cover browser-based single sign-on for applications that use OpenID Connect or SAML 2.0. This fits an estate where most access goes through web apps and there is no VPN, Windows desktop logon or SSH path that needs a second factor. Check that every app authenticates through Keycloak, because a legacy app that bypasses it will not get MFA. Also confirm which factor types your users need, such as passkeys or hardware keys, before you commit to this design.
privacyIDEA behind Keycloak
Keycloak can delegate authentication to privacyIDEA as an identity provider plugin, so one MFA server handles push, TOTP, HOTP, FIDO2, PIV and SMS for the realm. This is useful when you also need RADIUS, PAM or Windows logon to share the same enrollments. The trade-off is operating two services, with separate upgrades, databases and monitoring. Push notifications require the privacyIDEA Authenticator app, while standard TOTP and HOTP work with apps such as Google Authenticator.
privacyIDEA for RADIUS, PAM and Windows
Without Keycloak, privacyIDEA can protect VPN concentrators through RADIUS, Linux logins through its PAM module, and Windows logon through a credential provider. This suits teams whose main gap is network and workstation access rather than web SSO. Check the specific VPN and operating system versions against the privacyIDEA documentation before you plan rollout. Note that privacyIDEA is licensed under AGPLv3, so review how modifications and hosted use fit your legal obligations, and that the privacyIDEA Enterprise Edition is available from NetKnights if you need commercial support.
Hardware token-led design for high-assurance users
For administrators and privileged users, a design built around FIDO2 keys and PIV smartcards with privacyIDEA can reduce reliance on phone-based factors. Hardware tokens also need a lifecycle: issuance, replacement after loss, and revocation. privacyIDEA can import seed files from SafeNet XML, OATH CSV, Yubikey CSV and PSKC formats, which helps when you inherit existing tokens. Ask the vendor and your auditors which assurance level your use case needs before buying hardware, since the choice of token drives the cost more than the server does.
Enrollment and recovery at scale
Whichever design you pick, enrollment is where MFA rollouts stall. Plan how users register factors, how help desk staff verify identity before resetting a factor, and how you handle users who change phones. Map your existing user store to privacyIDEA through its LDAP, SQL or SCIM resolvers so identities are not duplicated. Test the registration flow with a pilot group before you set a deadline for all staff.
Which Adaptive MFA risk signals open source does not replicate
Okta Adaptive MFA decides whether to challenge a user based on signals that a vendor collects and maintains across a large customer base. The commercial engine typically weighs threat intelligence feeds about malicious IP addresses and anonymizers, behavioral history such as usual sign-in times and typical locations, device trust derived from a managed endpoint fleet, and risk models that the vendor retrains as attack patterns change. The research supplied for this page does not show that privacyIDEA or Keycloak offers equivalents for these signals. Keycloak's conditional authentication and privacyIDEA's policies can act on the attributes you give them, such as network range, group membership, client, or time, but they do not ship a vendor-fed threat or behavior model. Treat any claim of parity as unverified until you test it.
Start by exporting the policy and sign-on rules from your Okta tenant and listing every condition that changes the outcome of an MFA prompt, including device, risk level, zone, and network. Map each condition to a signal you can produce yourself. Some will have a direct equivalent in your identity provider, such as a network zone defined by IP range. Others, such as a vendor-scored risk level, will have none. For each unmatched condition, decide among three options: accept a rule-based replacement built from Keycloak conditional authentication and privacyIDEA policies, add an external risk engine that feeds scores into the flow, or accept a gap for specific applications and require a fixed MFA step for them. The third option is often the simplest for high-value systems, and it should be a documented decision with the application owner.
Running open-source MFA beside the rest of an Okta suite
This split leaves Okta as the identity provider for applications and moves only the second factor. privacyIDEA can act as a RADIUS server, a PAM or Windows logon factor, or an identity provider plugin for systems that already sit behind Okta, so the application integrations and sign-on policies in Okta stay as they are. Okta's factor enrollments do not transfer to privacyIDEA, so users register new tokens there. Adaptive MFA signals such as device, network and location context are Okta policy features and must be rebuilt as privacyIDEA policies or accepted as lost.
- Application integrations: Okta keeps the SAML and OIDC app assignments. Apps that need a second factor from privacyIDEA must be reached through a separate path, such as RADIUS or a web-tier integration, which you need to design and test per app.
- Factor enrollments: Okta push, Okta Verify and WebAuthn enrollments remain in Okta and are not exported to privacyIDEA. Plan a re-enrollment campaign for each user who moves to the new factor.
- Adaptive policies: Okta risk rules tied to device trust or network zones do not carry over. Document each rule and decide whether privacyIDEA policies or Okta itself will enforce it.
- Login reporting: Okta System Log events keep recording sign-ins, while privacyIDEA logs second-factor decisions on its own server. Forward both to your SIEM so one investigation sees the full sequence.
- Dual running: Keep Okta's factor policies in place until privacyIDEA enrollment is complete for the pilot group.
Confirm which Okta edition and add-ons you hold, because Adaptive MFA is an add-on to the Starter suite and included in Core Essentials and higher suites, and check which factors your policies currently require.
In this split, Keycloak becomes the OpenID Connect and SAML broker for applications while Okta keeps the directory, lifecycle and provisioning role. Keycloak can federate users from LDAP or Active Directory and can delegate authentication to an external factor, so privacyIDEA can handle the second step as a Keycloak identity provider plugin. Okta's Adaptive MFA logic still lives in Okta, so you must decide whether the Keycloak login path or the Okta policy is the authoritative control for each application.
- Application integrations: Each app is re-pointed from Okta to Keycloak clients. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, so most app protocols can be preserved, but redirect URIs and signing certificates change per app.
- Factor enrollments: Okta-held factors cannot be used by Keycloak. Users enroll OTP, WebAuthn or privacyIDEA tokens in the new flow, and you need to confirm how Okta lifecycle events will trigger enrollment reset when accounts move.
- External second factor: Keycloak calls privacyIDEA for the second step, so the browser flow must be configured to run that step after the password. Test the fallback when privacyIDEA is unreachable.
- Login reporting: Keycloak events and Okta System Log entries now describe different parts of the same login. Correlate them by user and session identifiers in your SIEM.
- Directory sync: Keep Okta as the source of truth for joiners and leavers, and verify that disabled Okta accounts are also blocked in Keycloak and privacyIDEA.
Confirm whether your Okta contract covers the directory and lifecycle features you intend to keep, and confirm which Keycloak release and database your team will operate.
A full replacement removes Okta from sign-on, MFA, directory and lifecycle at once. Keycloak handles protocols and user federation, privacyIDEA handles second factors and hardware token enrollment, and your team owns every login path afterward. Because Okta's factor enrollments and policies are not portable to privacyIDEA, the migration is mainly a re-enrollment and rebuild project, not a data copy. Okta's export options cover user lists and some configuration, but they do not produce a working MFA state for the new system.
- Application integrations: Every Okta app is rebuilt as a Keycloak client or privacyIDEA-protected resource, with cutover planned per application group.
- Factor enrollments: All users re-enroll. Hardware tokens may be imported into privacyIDEA from supported seed file formats, but only where you hold the seed files and the vendor allows it.
- Adaptive policies: Each Okta risk rule is listed, mapped to a Keycloak or privacyIDEA control, or formally accepted as removed, which matters for audit evidence.
- Login reporting: Okta System Log history stops being the live record. Export or archive what your retention rules require before the subscription ends, and route Keycloak and privacyIDEA logs to your SIEM from day one.
- Access during cutover: Keep a break-glass path and a rollback window for each application group until enrollment and login metrics are stable.
Confirm your Okta edition and add-ons, your exit date and the data you must retain, and whether your auditors need the Adaptive MFA decisions documented.
How to move MFA users, tokens and enrollments off Okta
This sequence separates what can be carried over from Okta, what must be re-enrolled, and how identities and hardware tokens reach privacyIDEA without leaving the organization's control. It ends with a pilot group validated before any cutover.
Inventory Okta factors, policies and enrollments
The identity team lists which factors each user holds, which policies decide when Okta challenges them, and which applications depend on those policies. Okta documents exports of active users through the Password Health report CSV in the Admin Console, the community Rockstar extension, or the List Users API with a filter, so use one of these as the user baseline. Confirm with Okta which factor and policy data your tenant can export, because enrollment records are not the same as user lists. The step is done when every factor type and every policy rule has a named owner and a decision to migrate, re-enroll or retire.
Decide which factors migrate and which re-enroll
Okta does not export reusable secrets for software factors such as push and most authenticator app enrollments, so those users must enroll again in privacyIDEA. Hardware tokens are the exception when the organization holds the original seed files from the vendor and can import them. The security lead should record the decision per factor type and per user group, including how users prove identity during re-enrollment. The output is a signed-off enrollment matrix that the help desk can follow.
Connect user identities through privacyIDEA resolvers
The directory team configures privacyIDEA user ID resolvers against the LDAP or Active Directory server that holds the authoritative identities, rather than loading users by hand. privacyIDEA supports LDAP resolvers for any LDAP service, including Active Directory, as well as SQL, SCIM and HTTP resolvers. Test that the expected accounts resolve, that the attributes used for token assignment are present, and that disabled accounts are excluded. Done when a sample of users resolves with the correct attributes in the privacyIDEA user view.
Import hardware token seed files securely
Import the seed files for hardware tokens that the organization has legal and contractual right to use, using the supported formats: SafeNet XML, OATH CSV, Yubikey CSV or PSKC. Seed material is equivalent to a credential, so the import should run from a restricted workstation under the organization's key management controls. Where the vendor supplies GPG-encrypted seed files, import them with privacyIDEA's GPG key and keep the private key in the custody process the organization already uses. Done when each imported token shows the correct serial, type and assigned user, and the source files are removed or stored as the policy requires.
Configure policies that mirror Okta behavior
Map each Okta policy that chose a factor for an application, network zone or user group to a privacyIDEA policy, and to the Keycloak authentication flow or RADIUS, PAM or credential provider that calls it. Okta's risk-based signals, such as device context or location, are not replicated by privacyIDEA in the same way, so each one needs a documented replacement or an accepted gap. Ask the vendor to confirm the exact policy conditions available in the version you deploy. Done when a policy matrix shows every Okta rule, its replacement and the owner who accepted any gap.
Run a pilot group before cutover
Select a pilot group that covers each factor type, each application path and at least one VPN or Windows logon path. Pilot users enroll in privacyIDEA, authenticate through every flow, and report failures to the help desk, which logs them against the enrollment matrix. The pilot should also test lockout and recovery procedures, such as lost hardware tokens and replaced phones. Done when the pilot has passed every flow and the recovery runbook has been exercised by the help desk.
Cut over and retire Okta factors
Switch the production applications and access paths to privacyIDEA in controlled batches, starting with the groups proven in the pilot. Keep Okta factor enrollments available as a fallback until the batch has run cleanly, then disable them. Record which enrollments were migrated, which were re-enrolled and which tokens were retired, so the audit trail can show the change. Done when no production path depends on Okta for MFA and the enrollment records match the matrix.
Enrolling thousands of users without help desk overload
Enrolling thousands of users is mainly a sequencing problem. Move people in staged waves by department or risk tier, starting with a pilot group that represents the mix of devices, locations and roles in your workforce. Use the pilot to measure help desk volume per wave: count enrollment tickets, lost-device reports, and password or token resets, and tie each spike to a specific step in the enrollment flow. Those numbers will tell you whether the next wave should widen, pause or receive extra guidance. Confirm with your own service desk which tickets they expect to handle and which they want routed to self-service before the first wave starts.
Self-service is where most of the volume reduction comes from. In privacyIDEA, users can register their own tokens through the self-service portal when the policy allows it, and the enrollment policies decide which token types a user may register and whether a second factor is required to add one. Keycloak handles its built-in OTP and WebAuthn credentials through the account console, where users set up their own authenticators. For fallback, privacyIDEA supports registration codes, which an administrator or help desk agent generates for a single enrollment, and security questionnaires, which can replace a code when the user cannot receive one. Confirm which identity verification steps your policy requires before a registration code or questionnaire is issued, because that decision determines how much help desk time each fallback consumes.
Hardware keys and lost devices need their own process. Decide who distributes FIDO2 keys or hardware tokens, how they are shipped and tracked, and how importing seed files for hardware tokens is controlled, since privacyIDEA can import seeds in several formats and that import should be restricted to named administrators. For lost devices, plan a revocation step that disables the lost token immediately and a re-enrollment path that goes through the same identity checks as first enrollment. Ask your auditors and security team to confirm the evidence they need for token issuance and revocation, and make sure the help desk runbook records it.
What buyers ask about replacing Okta MFA
What does it cost to replace Okta MFA with open source?
The software licenses are often the smallest line. privacyIDEA and Keycloak are open source, so the recurring costs are the database, high availability infrastructure, hosting, a support subscription if you want one, and staff time for operations. privacyIDEA is AGPLv3 licensed, and NetKnights offers a privacyIDEA Enterprise Edition, which is a license line to price if you choose it. Okta's pricing page lists Adaptive MFA as an add-on to the Starter suite and included in Core Essentials and higher, so compare against the suite you actually pay for. Ask any quote to itemize each component, its one-time and recurring share, and the assumptions behind staff hours.
What drives the cost of an MFA migration up or down?
The main drivers are the number of users and devices to enroll, the number of applications and VPNs that need a new second factor, how many hardware tokens must be imported, and how many directories or resolvers must be connected. Requirements for high availability, multiple sites and a supported database also add cost. Hardware token import is simpler when seed files are in a supported format such as OATH CSV, Yubikey CSV or SafeNet XML, and harder when they are not. Ask the vendor or partner to list each integration (PAM, Windows credential provider, RADIUS, Keycloak, REST API) and price them separately.
Can our own team replace Okta MFA without a partner?
Yes, many teams can, provided they have engineers comfortable with Linux, databases, identity protocols and directory services. privacyIDEA documents installation with pip and on Ubuntu and CentOS or RHEL-family systems, and Keycloak documents production configuration and its Operator. The harder parts are rarely the install itself: they are the risk policies you must rebuild, enrollment communications, helpdesk procedures for lost devices, and testing every RADIUS, PAM and Windows logon path. If you lack that capacity or need evidence for an assessment, a fixed-scope engagement with DeployOpen can plan, implement and document the work in your own infrastructure, with scope and deliverables agreed in writing first.
How long does an Okta MFA replacement take?
The timeline depends on the number of integrations, the state of your directory, and how many users must re-enroll. No duration is set by a supplied source, so treat any figure you hear as an estimate to verify. The work depends on standing up the platform, connecting user stores such as LDAP or Active Directory, configuring each factor and integration, running a pilot group, and staged enrollment. Ask for a timeline with phases and named dependencies, such as directory access approval, change windows and a test environment that mirrors production.
What do we need from our team before the work starts?
Plan for four inputs: read access to your directories (LDAP or Active Directory service accounts with scoped rights), an export of your current MFA enrollment and policy configuration, a test environment that resembles production, and named owners for helpdesk, security policy and each application. For the Okta side, Okta documents three ways to export a list of active users: the Password Health report CSV, the community Rockstar extension, and the List Users API with a filter. Confirm with your Okta administrator that your role allows these exports, because policy and factor configuration usually must be rebuilt by hand.
Do Keycloak upgrades need planning if we run it for MFA?
Yes. Since Keycloak 26.0 the project plans four minor releases a year and a major release every two to three years, and says breaking changes in minor releases will be opt-in. The current release is 26.8.1, published October 13, 2026. Keycloak migrates its database schema automatically at startup by default, but the upgrading guide suggests manual migration for large deployments. The Operator documentation strongly recommends manual approval mode for updates. Build a test upgrade path, and remember that realm export and import have documented limits as a backup method, so use database backups.
What do the risk-based signals missing from open source mean for us?
Okta Adaptive MFA evaluates contextual signals and adjusts challenges, and privacyIDEA and Keycloak do not replicate that behavior out of the box in the way the commercial product does. Before migrating, list the policies you rely on, such as location, device trust or impossible-travel rules, and decide which ones to rebuild with conditional logic, which to accept as lost, and which to handle elsewhere. Confirm what each open-source option supports with the vendor before you commit, because capability statements change between releases.
How DeployOpen scopes and delivers an MFA replacement
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source identity platforms inside your own infrastructure. For an Okta Adaptive MFA replacement, we start from the factors and login paths your users and systems actually depend on, then build Keycloak and privacyIDEA around them with a written scope agreed before work begins.
How we scope
- Inventory every application, RADIUS client, Windows logon and VPN that currently sends Okta MFA prompts.
- Map each login path to a factor option such as WebAuthn, TOTP, push or hardware tokens, and record any risk-based rule that will not carry over.
- Agree the scope, deliverables and timeline in writing before work starts, since most engagements are fixed-scope.
How we build
- Deploy Keycloak and privacyIDEA in your environment, connected to your existing LDAP or Active Directory user store.
- Configure privacyIDEA resolvers, policies and integrations for Linux PAM, Windows credential provider, RADIUS and web applications.
- Test enrollment, step-up behavior and fallback paths, and import any hardware token seed files under controlled handling.
How we hand over
- Document factor policies, enrollment steps, helpdesk procedures and the compensating controls for risk signals you no longer get.
- Provide runbooks for token lifecycle, backup and restore of the database, and Keycloak upgrade planning.
- Walk your operations and helpdesk teams through the platform and leave evidence that supports your compliance assessment.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Security testing of the MFA flows and integrations can be scoped separately from the platform build.
- Your independent auditor or certification body makes the compliance determination, and we prepare the controls and evidence they review.
