Open-source alternative to Entra Conditional Access

Can an open-source alternative replace Entra Conditional Access?

Keycloak conditional authentication flows and privacyIDEA cover the common MFA, role and location-style policies for self-hosted applications, but they do not reproduce Entra's signal-based risk evaluation or device compliance checks. If your renewal or sovereignty review is asking whether Conditional Access can move off Microsoft, the honest answer is that the policies you can move are the ones that depend on who the user is, which group or role they hold, and which step-up method they must use. Microsoft Learn describes Conditional Access as a policy engine that can also weigh application, device and real-time risk signals before it grants access. Those signals are where the gap sits. The licensing question comes first. Conditional Access requires Entra ID P1 licenses, which are also included in Microsoft 365 Business Premium, while risk-based policies on sign-in and user risk require Entra ID Protection, a P2 feature. Before you decide anything, confirm with Microsoft which of these your tenant already includes, because a bundled P1 may change the cost comparison more than any open-source feature does. Also confirm which of your policies depend on device state, since those will not carry over to a self-hosted identity provider without a separate device management source.

Keycloak's conditional flows decide whether a step such as OTP runs, based on conditions such as User Role, User Configured, User Attribute, sub-flow executed and client scope. privacyIDEA adds the second factor methods, including FIDO2 passkeys, push and TOTP, and can be attached to Keycloak as an identity provider plugin. Together they can express policies like "admins must use a hardware key" or "finance group must step up for the ERP application." The sections below map each common policy to its component and name the policies that have no equivalent, so you can test them against your own rule set before committing.

Which Conditional Access policies map to Keycloak and privacyIDEA

This table maps common Entra Conditional Access controls to a Keycloak conditional authentication flow condition, a privacyIDEA policy or a stated gap. Entra evaluates IP location, device state and real-time risk signals, so treat each mapping as a starting point and confirm it against your own sign-in logs and test accounts before you rely on it.

Entra Conditional Access control	Keycloak conditional flow	privacyIDEA or gap
MFA for administrators	User Role condition on an admin role, with an OTP or WebAuthn step set to required in the browser flow	privacyIDEA policy scoped to the admin group through its user ID resolver, enforced by the Keycloak plugin. Confirm the policy applies to every admin path, including the console.
Block sign-in by location	No native IP location condition in the standard conditional flow; use a custom authenticator or a reverse proxy rule	Gap in privacyIDEA for geolocation. Confirm whether your edge proxy or firewall can enforce country or network allow lists.
Step-up MFA for sensitive apps	Client scope condition or sub-flow executed condition that triggers an extra OTP step only for selected clients	privacyIDEA policy per application or per RADIUS, SSH or PAM target. Test that the step-up prompt appears on the sensitive client only.
Require compliant or hybrid joined device	No built-in device compliance check; requires a custom authenticator or a device posture integration	Gap. Device state is not a standard privacyIDEA signal. Ask which posture tool your endpoint team would connect.
Sign-in risk (real-time risk)	No built-in risk engine in Keycloak core; approximate with failed-login thresholds and brute-force detection settings	Gap for risk scoring. privacyIDEA can require a second factor on demand, but it does not score sign-in risk. Confirm the scope with your security team.
User risk	No built-in user risk score; use User Attribute or User Configured conditions to flag accounts for extra steps	Partial. privacyIDEA policies can be applied to flagged users, but the flag must come from your own process or SIEM.
Require password change	Required actions on the user record, triggered by an admin or a custom flow	Not a privacyIDEA function. Confirm the password reset process in your directory source, such as LDAP or Active Directory.
Require approved client app	Client policies restrict which OIDC clients and grant types a login may use	Not a privacyIDEA function. Confirm the client registration list and policies in Keycloak instead.

Keycloak, privacyIDEA or both: which option fits which policy set

Keycloak conditional authentication flows let you decide, per login, whether a step such as OTP runs. The conditions include User Role, User Configured, User Attribute, sub-flow executed and client scope. That covers the common pattern of asking for a second factor only when a user holds an admin role or when the request targets a sensitive client. It keeps the policy close to the application and removes a separate service from the path. The limits are visible when a rule depends on signals outside Keycloak, such as device compliance, network location or real-time risk, because Keycloak does not evaluate those signals natively.

Best fit: web and OIDC or SAML applications that already sign in through Keycloak and need step-up by role, attribute or client.
Strength: one product to configure, version and back up, with the flow logic stored in the realm.
Gap: no built-in device compliance or risk scoring comparable to Entra ID Protection.
Gap: non-web consumers such as VPNs and SSH hosts do not go through these flows.
Operations: flow changes are realm configuration, so test them in a non-production realm before promoting them.

Before you commit, list each Conditional Access rule and confirm whether its inputs exist as Keycloak conditions or as user attributes you can populate.

How Keycloak conditional flows decide when OTP runs

Keycloak does not have a single Conditional Access policy engine. Instead, a browser authentication flow can contain conditional authentication steps that run only when their conditions match. Each condition, such as User Role, User Configured, User Attribute, sub-flow executed or client scope, decides whether a step like OTP runs for a given login. The design work is in deciding which conditions and which step order produce the result you want, and it sits with your administrators, not with a product default.

A common pattern is to build a conditional sub-flow for a group of admin roles, for example an illustrative role named realm-admin-ops, and place an OTP step inside it with a condition that matches that role. A second sub-flow can cover a sensitive client scope, such as an illustrative scope named payments-write, so that the OTP step runs only when the login requests that scope. Keep the condition logic readable: fewer nested sub-flows are easier to audit than many overlapping ones, and each one should have a name that states its purpose.

Treat the flow design as the core of the migration, and test it per client. Each application's client scopes, redirect behavior and login paths can trigger the flow differently, so run test accounts with and without each role through every client, confirm that the OTP prompt appears only where intended, and record the results. Check the Keycloak Server Administration Guide for the exact condition options in the release you run, because the set of conditions and their behavior should be confirmed in your own environment before you rely on them.

What has no direct equivalent to Entra risk and device controls

Conditional Access on Entra ID draws on signals that Microsoft collects inside its own cloud: risk detections, device health and tenant-wide telemetry. A self-hosted Keycloak or privacyIDEA design can match the policy logic you write, but each of these signals has to be sourced, built or accepted as a gap before you retire the Entra policies they feed.

Sign-in and user risk scoring

Entra ID Protection, a P2 feature, scores sign-ins and accounts for risk using Microsoft's threat data and then drives policies that step up or block access. Keycloak conditional flows can branch on roles, attributes and client scope, but they do not score risk on their own. You must build a risk signal from your own logs, buy it from a separate detection product, or accept step-up rules based on static conditions. Ask the vendor which risk detections, if any, are included in the edition you run.

Device compliance and hybrid join

Entra policies can require a compliant or hybrid joined device, which depends on device state reported by Intune or Entra device registration. Keycloak has no built-in device registration or compliance feed, so a device check has to come from an MDM or endpoint tool that you integrate yourself, or from a posture check in a zero trust gateway. Confirm how your device management platform passes a compliance result into the login flow before you promise parity to users.

Microsoft telemetry and real-time signals

Entra draws on Microsoft's global sign-in telemetry to flag attacks across many tenants, and that data does not travel with a self-hosted deployment. Your own deployment only sees the logins it handles, so anomaly detection depends on your log volume and on rules you write. Plan for a SIEM or log pipeline that receives Keycloak events and decide whether that coverage is acceptable for your threat model.

Number matching in push approvals

Microsoft Authenticator number matching makes the user type a number shown on the sign-in screen, which blocks many push fatigue attacks. privacyIDEA offers push through its own authenticator app, and the README describes that app and standard TOTP apps, but the number-matching behavior is not something to assume. Test the push flow with your users, confirm whether the privacyIDEA Authenticator app shows the challenge in the way you need, and document the result for your MFA policy.

Named locations and country rules

Entra named locations are managed in the admin center and can be reused across Conditional Access policies with IP ranges and countries. A Keycloak flow can read the client address through a condition or a custom authenticator, but maintaining country lists and trusted networks becomes your job. Decide who owns the IP and geolocation data, how it is updated, and how a trusted office network is defined when staff work remotely.

Migrating Conditional Access rules without locking out admins

This sequence moves Entra Conditional Access policies into Keycloak flows and privacyIDEA policies one group at a time, so every rule is inventoried, tested in parallel and piloted before users are cut over. It ends with a documented configuration record and a break-glass path that keeps administrators able to sign in during the change.

Inventory every Entra Conditional Access policy
Export or list each Conditional Access policy in the Entra admin center and record its state, the users and groups it targets, the applications it covers, its exclusions, and the controls it applies, such as MFA, compliant device, approved app or password change. Include report-only policies, because they show intended behavior that has never been enforced. The sequence is done when every policy has a row in a shared inventory that an administrator has reviewed, and the exclusion groups are listed by name.
Map each policy to a Keycloak or privacyIDEA control
For each inventory row, decide whether the condition can be expressed in a Keycloak conditional authentication flow, using conditions such as User Role, User Configured, User Attribute, sub-flow executed or client scope, and whether the factor can be enforced by a privacyIDEA policy. Mark rules with no equivalent as stated gaps, such as signals from Entra ID Protection or device compliance, and assign each gap a documented owner and a compensating control or an accepted risk. The step is complete when every policy maps to a flow, a privacyIDEA policy or a recorded gap.
Build flows in a non-production realm
Create a separate test realm on a non-production Keycloak instance, with the same client definitions, user federation settings and privacyIDEA integration as production. Build the conditional authentication flows there, bind them to test clients, and confirm that the step-up steps run only when the condition matches. Confirm the Keycloak version and database in use against the production database guide before building, so the test environment behaves the same way. The step is complete when each mapped rule has a test case that passes or fails as the Entra policy would.
Run parallel logins for test users
Enroll a small set of test accounts that cover each policy's target group, including at least one administrator and one user outside the expected network location, then sign in to the same applications through Entra and through Keycloak. Compare which prompts appear, which factors are accepted and where access is denied, and log the differences. Treat any mismatch as a defect to fix or a gap to record. The step is complete when the comparison log shows no unexplained difference for mapped policies.
Export the realm as JSON for configuration records
Stop all Keycloak nodes, run the kc.sh export command for the configured realm, and store the resulting JSON in version control with restricted access, since it can contain client secrets and sensitive configuration. Keep in mind that the Keycloak documentation warns that export and import have limitations as a backup and restore mechanism, so it complements, and does not replace, a database backup. The step is complete when the export file is stored, its checksum is recorded, and nodes are restarted and healthy.
Pilot with a small production group
Move a limited group, such as an IT team that understands the change, onto the Keycloak flows for a defined set of applications while Entra policies remain in place for everyone else. Collect sign-in failures, help desk tickets and any unexpected step-up prompts, and fix flow conditions before widening the group. Confirm that the privacyIDEA enrollment and token recovery steps work for pilot users. The step is complete when the pilot group has signed in across the mapped applications without an open blocking issue.
Cut over with a break-glass admin path
Before disabling the Entra policies for the wider population, create and test at least two break-glass administrator accounts in Keycloak that use a phishing-resistant factor, store their recovery material offline under dual control, and document how they are used and audited. Keep the Entra break-glass accounts in place until Keycloak administration has been verified from a separate network path. Then switch the remaining applications and retire the Entra policies in stages. The step is complete when administrators have confirmed they can reach the Keycloak admin console through the break-glass route and every mapped application is live.

Running Keycloak alongside Entra ID for Microsoft 365

In most organizations, Microsoft 365 sign-in and its Conditional Access policies stay on Entra ID, so a self-hosted Keycloak deployment would protect only the applications you connect to it. Keycloak does not take over the Microsoft 365 tenant, and Conditional Access evaluating Exchange Online, Teams or SharePoint sign-ins will still run in Entra. Before you map any policy to Keycloak, confirm with your Microsoft account team and your own tenant administrators exactly which applications authenticate against Entra and which would move, since many organizations have Microsoft 365 apps and Azure resources that depend on the tenant's sign-in path.

The main operational risk is policy divergence across two systems. A rule such as "admins need MFA" can be enforced in Entra for Microsoft 365 and in Keycloak conditional authentication flows for internal apps, but the two rules will not automatically share thresholds, exception groups or session lifetimes. Write a single policy register that lists each rule, the system that enforces it, the group it applies to and the owner who approves changes. Review that register whenever either side changes, and record which controls are enforced by Entra and which by Keycloak so that auditors and incident responders can trace a sign-in decision to one place.

The MFA methods offered to users need the same care. If a person registers a phone-based method in Entra and a different factor in privacyIDEA, support staff will field duplicate enrollment requests and users may find themselves with no working method after a device change. Decide which methods are permitted for each user population, confirm which ones your Entra licensing already covers, and check that recovery paths are documented on both sides. The decision to run two systems should follow from the licenses you still hold: if your Microsoft 365 plan already includes the Entra features you rely on, retaining them for Microsoft 365 sign-in costs little extra, and the Keycloak work should focus on the applications that genuinely need a self-hosted control point.

Questions buyers ask before replacing Conditional Access

What does replacing Conditional Access with open source cost, and what drives it up?

The cost is mostly people and time, plus the servers and database that run Keycloak and privacyIDEA. Keycloak and privacyIDEA are free under Apache 2.0 and AGPLv3, so no licence fee replaces the Entra ID P1 or P2 line item. The main cost drivers are the number of applications that move, how many Conditional Access rules must be rebuilt as Keycloak conditional authentication flows, how much high availability the design needs, and how much testing and documentation your auditors expect. Recurring costs include infrastructure, patching, upgrades and any support retainer. Ask any provider for a written quote that separates one-time implementation from recurring operations, and ask which policies are excluded from scope.

Can our internal team run Keycloak and privacyIDEA policies without outside help?

A team can do it if it already has skills in Keycloak authentication flows, LDAP or Active Directory federation, and MFA enrollment and recovery. Conditional authentication flows use conditions such as user role, user attribute and client scope to decide when a step like OTP runs, so someone must translate each Entra rule into a flow and test it. Enrollment flows for passkeys, push and hardware tokens also need careful design, because help desk procedures change. A useful test is whether two people on the team can explain how a sign-in from an unusual location is handled, and can reproduce that behavior in a test realm. If not, a fixed-scope engagement with written deliverables can fill the gap for the first rollout.

How long does a Conditional Access migration take?

The duration depends on scope, and no reliable figure applies before the scope is known. The schedule is driven by how many policies exist, how many applications rely on them, whether users must re-enroll MFA methods, and how many environments (test, staging, production) you need. Ask for a written plan that lists phases, dependencies, a parallel run period and the acceptance tests for each policy. Be cautious with any timeline given before someone has reviewed your policy export and application list.

Which Entra ID P1 and P2 licenses still apply after we move policies?

Entra ID licensing continues for anything still hosted in Entra, which often includes Microsoft 365 sign-in and Microsoft's own apps. Conditional Access needs Entra ID P1, and risk-based policies based on sign-in and user risk need Entra ID Protection, a P2 feature, according to Microsoft Learn. Moving application SSO to Keycloak does not automatically remove those licenses, because Microsoft 365 sign-in may depend on Entra ID. Confirm with your Microsoft account team and licensing advisor which users and apps still depend on Entra, and whether a Microsoft 365 Business Premium plan already includes the P1 features you use.

Do Keycloak upgrades need a support plan?

Yes, plan for upgrades from the start, because Keycloak releases frequently. The current release is 26.8.1, published October 13, 2026, according to the Keycloak website. Since Keycloak 26.0 the project plans four minor releases a year, and it says breaking changes in a minor release are opt-in. If you run the Keycloak Operator, its documentation strongly recommends manual approval mode for operator updates, so upgrades do not happen unintentionally. Keycloak also runs schema migrations at startup by default, and the upgrading guide suggests manual migration for large deployments. Ask whether the work includes a staging upgrade test, a rollback plan and a retainer for ongoing patches.

Does privacyIDEA cover the same sign-in methods our users have today?

privacyIDEA covers many common methods, but you must check your own list against its feature set. It supports FIDO2 and WebAuthn passkeys and hardware keys, PIV and x509 smartcards, push, TOTP and HOTP, TiQR, SMS, email, SSH keys and registration codes. Standard TOTP and HOTP users can keep apps such as Google Authenticator, while push needs the privacyIDEA Authenticator app. Confirm the methods your Conditional Access policies currently accept, such as Microsoft Authenticator number matching or Windows Hello for Business, and test how each one enrolls in privacyIDEA before you retire it in Entra.

Which Conditional Access features have no direct open-source equivalent?

Several Conditional Access features need work or have no one-to-one match. Device compliance and hybrid join checks depend on Intune or device management data, which Keycloak does not supply on its own. Real-time risk scoring from Entra ID Protection has no built-in equivalent, so you must decide whether to rely on step-up rules or a separate risk engine. Keycloak's conditions cover roles, attributes, client scope and sub-flows, but not every signal Entra uses. Document each Entra policy as one of three outcomes: replicated, partly replicated with a compensating control, or retained in Entra. Ask a provider to produce this mapping before scoping the work.

What drives the cost of self-hosting Conditional Access controls

Self-hosting Conditional Access controls replaces a per-license cloud feature with components you pay for and run yourself. Most of the cost sits in the flow design, the production database and the people who enroll users and answer help desk calls, so those are the items to price first in any quote.

Software licensing

Keycloak is licensed under Apache 2.0 and privacyIDEA under AGPLv3, so neither carries a per-user license fee. The cost question is whether you need support. NetKnights offers the privacyIDEA Enterprise Edition, and Red Hat offers a supported build of Keycloak. Ask any vendor for the support terms, the licensed scope and whether AGPLv3 obligations apply to your modifications. This is a recurring cost only if you buy support.

Infrastructure and high availability

Plan for hosts, a supported production database and a high availability design. Keycloak supports PostgreSQL 14 to 18 and several other databases, and both supported HA designs need a synchronously replicated database. Clustering, load balancing and backups are largely one-time design work, then recurring compute and database operations. Ask for the database sizing, the node count and the backup and restore test plan in the quote.

Flow design and testing

Each Entra Conditional Access policy must be rebuilt as a Keycloak conditional authentication flow or a privacyIDEA policy, then tested against real user groups, locations and apps. This is one-time effort, but it recurs whenever a policy changes. Ask the implementer to map every existing policy to a flow, list which rules have no equivalent, and state how they will test failure paths such as lockout, token reuse and fallback enrollment.

User enrollment and help desk load

Moving MFA and step-up means every user registers new factors, and the first weeks generate tickets about lost devices and blocked logins. Push notifications need the privacyIDEA Authenticator app, while standard TOTP and HOTP can use apps users already have. This cost is mostly one-time for enrollment and recurring for support. Ask who staffs the help desk, how device loss is verified and how recovery codes or hardware token issuance are handled.

Ongoing upgrades and patching

Keycloak plans four minor releases a year, and privacyIDEA publishes frequent releases such as v3.14. Each upgrade needs test runs of your flows, a schema migration plan and a window for maintenance. The Keycloak Operator documentation recommends manual approval mode for operator updates. This is recurring effort. Ask the implementer for an upgrade procedure, a retainer scope if they will carry it, and the staging environment you will need.

What to confirm before you commit

Start by confirming your current Entra entitlements, because the policies you are replacing depend on them. Conditional Access needs Entra ID P1, which is also included in Microsoft 365 Business Premium, while sign-in risk and user risk policies need Entra ID Protection, a P2 feature. Pull the license assignments for every admin and user group in your tenant and list which Conditional Access policies are actually enabled. Then sort the policies into two piles: static rules such as MFA for administrators, location blocks and step-up for sensitive apps, which map to Keycloak conditional authentication flows and privacyIDEA policies, and risk-based rules, which have no direct equivalent in the open-source stack and need a separate decision. Confirm the current license terms with Microsoft, since packaging changes over time.

Next, decide which applications truly need risk-based decisions and whether device compliance is a hard requirement. Keycloak conditional flows can react to roles, user attributes, client scopes and prior sub-flows, but they do not read a device compliance state from Intune or a risk score from a threat feed unless you build that signal yourself. For each application, ask whether a missing device check would let a managed-only resource open from an unmanaged laptop, and whether your auditors or contracts treat that as a control gap. Document the answer per application, because it decides whether you need a device-posture source at all and whether you accept a weaker control for some apps. Finally, inventory the MFA methods your users hold today and confirm the production database. Count which users rely on Microsoft Authenticator push, FIDO2 keys, passkeys, TOTP or SMS, and check that privacyIDEA supports each one you plan to keep, since push requires the privacyIDEA Authenticator app. On the database side, choose from Keycloak's supported production list, which includes PostgreSQL 14 to 18, and avoid the development file database. Confirm feature parity against the current Microsoft Conditional Access documentation and the Keycloak and privacyIDEA documentation before you commit, because both products change between releases.

How DeployOpen scopes and delivers a Conditional Access replacement

A Conditional Access replacement is a set of decisions about who may sign in, from where, on which device and with which factor, and each one must be tested before users depend on it. The cards below follow the order of a typical engagement, from a written scope through policy mapping, implementation, testing, evidence and ongoing support. Each stage ends with a decision the client signs off.

Fixed scope agreed in writing

Most engagements start with a written scope that lists the applications in scope, the policies to be replaced, the identity sources and the deliverables. The scope also states what stays on Entra ID, such as Microsoft 365 sign-in, so nobody assumes a feature moves when it does not. Ask for the scope to name each Conditional Access policy by its current name and state whether it is being replaced, merged or retired. Pricing follows from this document, so an unclear scope produces an unclear quote.

Policy mapping workshops

Workshops take each Entra Conditional Access policy and record its conditions (users and groups, location, device state, application and risk), its grant or block control and its exceptions. Each row is then matched to a Keycloak conditional authentication flow or a privacyIDEA policy, or marked as having no equivalent. The output is a mapping sheet that security and application owners review line by line before any build starts. Ask who signs off on gaps, because the gaps are where residual risk sits.

Keycloak and privacyIDEA implementation

Implementation covers the Keycloak realm design, the conditional authentication flows, the privacyIDEA deployment and its user resolvers, and the enrollment path for each factor type. It also sets the database, the high availability design and the way Keycloak updates are applied, so that a policy change does not depend on a single administrator's memory. Confirm in writing which identity sources are connected, which token types are migrated and which users must re-enroll.

Hardening and security testing

Before go-live, the authentication paths are tested as an attacker would test them: step-up bypasses, flows that skip MFA on legacy protocols, token reuse, account recovery abuse and misconfigured client scopes. Testing covers the Keycloak server, the privacyIDEA API and the applications behind them. Ask for the test cases, the retest scope and how findings are recorded, and confirm whether testing includes the AI or agent components that some applications now use.

Compliance readiness evidence

For regulated organizations, the change needs evidence: a record of each policy, its owner, its test results and its approval. DeployOpen prepares the systems, controls and evidence that an assessor will ask for, including configuration exports and change logs. It does not issue audit reports, attestations or certifications, so the client should agree in advance with its independent auditor which artifacts that auditor expects. Map the evidence to the control framework the organization already reports against.

Retainers for upgrades and support

After go-live, Keycloak and privacyIDEA need regular upgrades, policy reviews and test runs. Retainers cover these as ongoing support and continuous testing, and they set the response expectations in writing. Ask how upgrades are staged in a non-production realm, who approves them and how a rollback is handled, since a Keycloak minor release can change behavior and the operator should be set to manual approval for updates.

Open-source alternative to Microsoft Entra Conditional Access