JumpCloud vs Keycloak: which to choose

JumpCloud vs Keycloak: when each one fits your estate

JumpCloud fits teams that want one managed service covering the directory, SSO, MFA, LDAP, RADIUS and device management, with the vendor operating the cloud side. Keycloak fits teams whose main need is SSO, federation and MFA for web and SAML applications, and who are prepared to run a separate user store next to it. The choice rarely turns on login features alone. It turns on three questions: how many LDAP clients and RADIUS devices must keep authenticating through the cutover, whether laptop and phone management is in scope, and who will operate the stack after go-live. Keycloak itself is licensed under Apache 2.0 and supports OpenID Connect, OAuth 2.0 and SAML 2.0, with built-in user federation to existing LDAP and Active Directory servers. It does not act as a RADIUS server or a device manager, so those duties need other components or stay where they are.

The split is worth making when the LDAP and RADIUS load is small and well understood. Each Wi-Fi controller, VPN concentrator, NAS or Linux host that binds to a directory is a dependency that must be inventoried, repointed and tested before JumpCloud is switched off. Keycloak can federate users from an existing LDAP or Active Directory source, but a directory still has to serve bind requests. Teams that want to keep that role inside their own infrastructure usually add a lightweight directory such as LLDAP, which Keycloak can use as a source of truth over LDAP, or run FreeIPA where Linux access control is also needed. Confirm each LDAP and RADIUS dependency, its bind account and its group filter in writing before you commit to a design, and check whether JumpCloud's export covers what you need, since passwords and MFA enrollments usually require re-enrollment.

Operating effort is the cost that recurs. Keycloak releases move on a fixed cadence: the project plans four minor releases a year, and the Keycloak Operator documentation strongly recommends manual approval mode for operator updates. Database backups need care too, because the Keycloak realm export is documented with limitations as a backup mechanism and requires all nodes to be stopped while it runs. Ask your integrator or platform team to name who patches, who tests upgrades, who owns the PostgreSQL or other supported database, and who answers when a device fails to authenticate at 2 a.m. If those owners cannot be named, the managed JumpCloud contract may still be the cheaper option once directory, device and support duties are counted together.

Which option fits which scenario

This table maps common buyer situations to the better fit between JumpCloud and a Keycloak-based design. Read each row against your estate: the condition in the middle of the sentence is what decides the choice, and a different condition can flip the answer.

Scenario	Better fit	Why
SaaS SSO only, users already in Active Directory or another LDAP server	Keycloak	Keycloak fits when the user store already exists and the need is web SSO, because it federates that directory and brokers OIDC and SAML logins without holding a second copy of accounts.
Mixed estate with LDAP-bound NAS devices, Linux hosts and Wi-Fi on RADIUS	Keycloak plus a directory and RADIUS component	Keycloak speaks OIDC, OAuth 2.0 and SAML but not LDAP bind or RADIUS for network devices, so these clients need LDAP and RADIUS services alongside it.
Regulated organization wanting identity inside its own data center	Keycloak or authentik, self-hosted	Both run on your own servers, but Keycloak's production setup depends on a supported database and a synchronously replicated design for high availability, so confirm your team can operate that.
Team with no appetite for running a directory	JumpCloud or a managed service	If nobody will own patching, replication, backups and the directory lifecycle, a self-hosted stack adds operating duties that a managed directory removes.
Linux-heavy fleet needing SSH, sudo and host access rules	FreeIPA alongside or instead of Keycloak	Keycloak does not manage Linux host access, sudo rules or Kerberos, so teams with these needs usually add FreeIPA rather than expect Keycloak to cover them.
Greenfield customer-facing app login with no existing directory	Keycloak	Keycloak can hold its own users and provide SSO, MFA and federation, so no separate directory is needed when internal staff logins are not bound to network devices.
Organization planning a Windows-centric directory consolidation	Keycloak with Active Directory kept as the source	Keycloak federates Active Directory without replacing it, so the split is worth it when Active Directory stays the account source and Keycloak adds modern SSO on top.

How SSO, MFA and federation differ between a bundle and a broker

JumpCloud delivers SSO, MFA and directory services from one managed console, so an administrator creates a user once and manages sign-in, device access and second factors in the same place. Keycloak is a different kind of product: it is an identity broker that supports OpenID Connect, OAuth 2.0 and SAML 2.0, offers identity brokering between upstream identity providers and an admin console, but does not hold a user directory of its own by default. That split is the core of the comparison. A bundle is simpler to run because one vendor or one team owns the directory, the federation and the policies. A broker is more flexible when the identity source already exists and must stay where it is.

Keycloak's built-in user federation connects to existing LDAP and Active Directory servers, so the user store can remain in place while Keycloak handles the SSO layer for web and API applications. Before you commit, map your current JumpCloud flows to what Keycloak needs: which applications use SAML or OIDC, whether the source directory is Active Directory, OpenLDAP or another LDAP service, and who will maintain the federation mappings and attribute rules. Ask for a written list of the SSO connections you rely on today and test each one against a Keycloak realm in a non-production environment.

MFA is a capability to confirm for each option and environment, not a given. Check the second-factor methods you need (for example, authenticator app codes, hardware security keys, push or SMS) against the current Keycloak documentation and the version you plan to run, and check how those methods apply to Linux logins, VPN or Wi-Fi authentication, which JumpCloud may handle differently. Keycloak alone does not cover RADIUS or LDAP bind clients, so those flows need a separate decision. Verify the second-factor set and enrollment workflow with a pilot group before deciding.

Capabilities of JumpCloud and Keycloak side by side

This table places JumpCloud's cloud directory services beside Keycloak, an open-source SSO and identity broker that you run yourself. Read the Keycloak column with the companion rows in mind, since Keycloak needs a user store and separate components for LDAP clients, RADIUS devices and device management. Confirm JumpCloud's current feature list with JumpCloud and check Keycloak 26.8.1 behavior in the Keycloak documentation before you decide.

Capability	JumpCloud	Keycloak 26.8.1
SSO protocols	Single sign-on to supported applications, confirm which of OIDC, OAuth 2.0 and SAML 2.0 your apps need	Supports OpenID Connect, OAuth 2.0 and SAML 2.0 natively
User directory and federation	Cloud directory holds users and groups; confirm sync options for existing directories	Needs a user store; built-in user federation with existing LDAP and Active Directory servers
LDAP service for clients	Provides LDAP for apps, NAS devices and Linux hosts that bind over LDAP	Needs companion: Keycloak does not act as an LDAP server, so add a directory such as LLDAP, FreeIPA or OpenLDAP
RADIUS service for Wi-Fi and VPN	Provides RADIUS for Wi-Fi and VPN authentication from the cloud	Needs companion: a separate RADIUS service, such as the one in authentik or privacyIDEA, is required
MFA	Included MFA; confirm supported factor types and where enforcement applies	Built-in one-time password support; confirm factor types and WebAuthn options for your version
Device management (Windows, macOS, Linux)	Device management for Windows, macOS and Linux endpoints	Needs companion: Keycloak does not manage devices, so pair it with an MDM or configuration tool
Admin console	Web Admin Portal for users, groups, apps and devices	Web admin console for realms, clients, users and authorization services
Licensing	Commercial service, billed under the subscription terms in your order form	Apache License 2.0, with no license fee for the open-source project
Hosting model	Vendor-hosted cloud service; data location depends on the region and contract you hold	Self-hosted in your own cloud accounts, data centers or air-gapped networks, operated by your team or a partner

Where the data lives and who controls the identity plane

JumpCloud runs its directory and SSO in a vendor-operated cloud, while Keycloak runs wherever you deploy it. The four cards below cover where identity data sits, how the hosting model shifts control, who can administer the platform, and what evidence an assessor will ask for.

Data location and residency

With JumpCloud, user records, authentication logs and directory data sit in the vendor's cloud, so residency depends on the regions and contract terms the vendor offers you. With Keycloak, the realm data lives in the database you attach, typically PostgreSQL, in a location you choose. Ask JumpCloud in writing where each data type is stored and processed, including backups and support access. Then map that against any residency rule that applies to your users.

Hosting models and operating boundary

JumpCloud is a vendor-run service, so availability, patching and infrastructure sit outside your team. Keycloak runs in your own cloud account, data center or air-gapped network, and your team or a partner operates the cluster, database and upgrades. This matters most when regulated data, a data residency rule or an air-gapped requirement prevents identity traffic from leaving your boundary. Confirm which operating model your risk owner has accepted before you size the project.

Admin plane access and separation

Whoever administers the identity platform can change any user, group, client or login policy, so the admin plane is often the most sensitive part of the design. In a self-hosted Keycloak deployment, you decide how administrator accounts are federated, how privileged roles are split, and where the admin console is reachable from. Review how JumpCloud staff access customer tenants and what logging you receive for those actions. Document who holds the keys to the database and the realm exports as well.

Compliance evidence and assessor roles

Assessments need evidence that identity controls operate, such as access reviews, admin change logs and MFA enforcement records. DeployOpen prepares systems, controls and evidence for these assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make that decision. Ask JumpCloud which reports and attestations it provides for its service, and confirm with your auditor which evidence they will accept from a self-hosted Keycloak environment.

Why LDAP clients and RADIUS devices need a component next to Keycloak

Keycloak is an SSO and identity broker, not a directory that LDAP clients can bind to directly. It handles OpenID Connect, OAuth 2.0 and SAML 2.0 logins for web and API applications, and it can federate users from an existing LDAP or Active Directory server. An application, NAS device or Linux host that expects to bind over LDAP, or a Wi-Fi controller or VPN gateway that sends RADIUS requests, needs a separate service that speaks those protocols. Before you replace JumpCloud's Cloud LDAP or Cloud RADIUS, list every device and application that performs an LDAP bind or RADIUS request today, because each one determines which component you must add next to Keycloak.

For LDAP, you have four practical options. If you already run Active Directory or another LDAP server, keep it as the source of truth and point Keycloak at it through user federation. LLDAP provides a lightweight LDAP front end with a web UI for users and groups, but its README says it is not a full LDAP server and suggests pairing it with Keycloak or Authelia for OAuth and reverse proxy features. Its FAQ also states it has no commercial support, is maintained by volunteers, and is not recommended for the infrastructure of a large organization unless your team can audit and maintain the code. FreeIPA is the stronger choice for Linux-heavy estates because it bundles an LDAP directory with Kerberos and host access controls. authentik can serve LDAP and RADIUS from its own outposts, which keeps SSO and the directory in one product.

The split is worth it when SSO is the main need and a directory already exists, because Keycloak then adds federation, MFA and standards-based logins without forcing a directory rebuild. It is not worth it when the same team must also serve LDAP and RADIUS from one identity source, since you would then operate Keycloak, a directory and a RADIUS service with separate backups, upgrades and user lifecycle steps. In that case, compare FreeIPA or authentik as a single product, and confirm with each vendor which RADIUS and LDAP features your devices require.

What a split stack costs compared with a bundled service

A bundled service sends one invoice, while a Keycloak-based stack spreads cost across software, infrastructure, a user directory, availability design and operations. The cards below separate the recurring and one-time parts so you can ask each vendor and consultant for the right line items.

JumpCloud subscription

Recurring. This is the fee you pay JumpCloud for the packages or individual products you license, such as directory, LDAP, RADIUS, SSO, MFA and device management. Cost moves with the number of users or devices in scope, the products you select and the billing term. Ask JumpCloud for a written quote that lists each product you would keep, how suspended users are billed and what happens to pricing at renewal.

Keycloak software license

One-time to adopt, no license fee. Keycloak is licensed under Apache License 2.0, so the software itself carries no license charge. Your costs shift to the people who install, configure and test it, and to any commercial support contract you choose, such as the Red Hat build of Keycloak. Ask any support provider to state in writing whether support covers the Keycloak Operator, the database and the directory integration.

Servers and production database

Recurring. Keycloak needs compute, storage and a supported production database. The supported list includes PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database and others, and the development file database is not for production. Cost drivers are the database edition or managed service you pick, backup storage and the number of nodes. Ask for the database version and licensing terms in your quote.

Directory and RADIUS components

Recurring plus one-time migration. Keycloak does not replace LDAP clients or RADIUS devices, so you need a user store next to it. Keycloak can federate an existing LDAP or Active Directory server, but a separate component is still needed for LDAP binds and RADIUS, such as FreeIPA, OpenLDAP, LLDAP or an authentik outpost. Each choice adds servers, licensing or support and migration work. Ask each vendor which protocols its product serves natively.

High availability design

One-time design, recurring infrastructure. Keycloak documents single-cluster and multi-cluster architectures, and both supported designs need a synchronously replicated database. That means extra nodes, a second site if you need one, and database replication that you must size and monitor. The multi-cluster v1 design is deprecated. Ask your consultant to document the chosen topology, failover tests and the recovery time you can commit to.

Upgrades, backups and operator

Recurring operations effort. Keycloak ships four minor releases a year under the project plan, and the Operator documentation recommends manual approval mode for updates. Export and import of realms is documented with limitations and requires all nodes to be stopped, so backups need a planned method. Staff time, test environments and on-call coverage are the main drivers. Ask for a written runbook, an upgrade cadence and the backup approach before you sign.

What a move from JumpCloud to Keycloak involves

The sequence maps every JumpCloud dependency first, then builds the replacement user store and protocol components before any device or app is repointed. Each phase ends with a check that proves the next one can start safely.

Inventory every JumpCloud dependency
Your team lists each SSO application, LDAP bind account, RADIUS device, SSH or sudo host and MFA enrollment that relies on JumpCloud, with the protocol, owner and fallback for each. The inventory is complete when every item has a named owner and a target component, and nothing is left to be discovered during cutover.
Choose and stand up the user store
Decide where users and groups will live, using Keycloak's built-in store or an existing LDAP or Active Directory server that Keycloak federates with, and confirm that the database is one of the production databases Keycloak supports. Your platform team deploys Keycloak in a test environment with a supported database and treats the setup as done when a test login succeeds through the chosen store.
Add LDAP and RADIUS components beside Keycloak
Because Keycloak speaks OpenID Connect, OAuth 2.0 and SAML 2.0 rather than LDAP bind or RADIUS, LDAP clients and RADIUS devices need a separate directory service or authentication component that reads from the same source of truth. Confirm which component serves each protocol and test a bind and a RADIUS authentication from a representative device before moving production traffic.
Configure realms, clients and federation
Your identity engineers create realms, OIDC and SAML clients for each SSO application, group-to-role mappings, and MFA policies in Keycloak, and connect any existing LDAP or Active Directory source through user federation. The step closes when each application signs in against a test realm and the claims or attributes it expects are present.
Export users and plan re-enrollment
Export user records and group memberships from JumpCloud, then record what the export does not carry, such as passwords and MFA enrollments, so that users can re-enroll before the old service is switched off. Keycloak's realm export and import are described in its documentation as having limitations as a backup mechanism, and all nodes must be stopped while that process runs, so plan imports in a maintenance window rather than treating them as routine backups. The check is a reconciled user count and a written re-enrollment list per group.
Repoint devices and applications in batches
Move LDAP clients, RADIUS devices and SSO applications in small groups, starting with low-risk systems, and record which endpoint now authenticates against which component. Each batch is complete when its users can sign in, MFA works after re-enrollment, and the help desk has the updated runbook.
Run the cutover window with rollback
Schedule a cutover window in which the last remaining dependencies move, with JumpCloud kept available until every inventoried item is verified. Your team defines the rollback trigger and the steps to point each device back before the window opens, and the cutover closes only when the inventory shows every item authenticating against the new components.

When a split stack is worth the extra component

When every application speaks OpenID Connect or SAML, Keycloak can serve as the single broker for SSO, MFA and federation, and no second component is needed. JumpCloud's SSO role maps onto Keycloak's realms, clients and identity brokering, and Keycloak's own user store can hold the accounts. The split adds nothing here because there are no LDAP binds or RADIUS clients to serve.

One service to run: Users, SSO, MFA and federation sit in one deployment, so the operating surface is one service plus its database.
Protocol fit: OpenID Connect, OAuth 2.0 and SAML 2.0 cover most SaaS applications, but check each vendor's SSO requirements one by one.
Recurring work: Upgrades, database backups and a high availability design still need staff time. The Keycloak upgrading guide sets out the upgrade path.
Device management gap: JumpCloud's device management has no direct equivalent in Keycloak, so decide separately how laptops and phones are managed.

Confirm that no application, printer, NAS, Wi-Fi controller or VPN in your inventory needs LDAP or RADIUS before you treat this as a single-component design.

Questions buyers ask before switching from JumpCloud to Keycloak

Can Keycloak replace JumpCloud entirely?

Not on its own. Keycloak covers the SSO side well: it supports OpenID Connect, OAuth 2.0 and SAML 2.0, provides identity brokering and has built-in user federation with existing LDAP and Active Directory servers. It does not include a user directory of its own that LDAP clients, RADIUS devices and Linux hosts can bind to, so you need a user store behind it and, for some device types, another component. Map each JumpCloud function you use (SSO, MFA, LDAP, RADIUS, device management) to a named component before you plan the cutover, and confirm the device management gap with your team.

What does a migration need from our team?

The work splits into four inventories: applications using SSO, LDAP bind accounts and group filters, RADIUS-connected Wi-Fi and VPN devices, and enrolled MFA methods. Each one needs an owner on your side who can change the application or device configuration and test it. Keycloak migrates its own database schema at startup by default, so the database administrator should agree on whether schema changes run automatically or manually before production. Expect your identity and network teams to be involved for the cutover window, because the directory and the SSO clients change together.

How long does a JumpCloud to Keycloak migration take?

No duration can be stated from the supplied facts, and the answer depends on the number of applications, devices and user records and on how many LDAP and RADIUS clients still bind to JumpCloud. Duration is driven mainly by the count of SSO clients that need reconfiguration, the number of devices that must re-enroll MFA, and how many test cycles your change process requires. Ask any vendor or consultant for a sequenced plan that shows which applications move in each wave and what the rollback step is for each one. A written scope should state the timeline before work starts.

Can we do the Keycloak migration ourselves?

Many teams with an experienced identity administrator and a test environment can run the SSO part internally, especially for a small number of web applications. The effort rises with LDAP and RADIUS dependencies, high availability requirements and the need for documented controls for an assessment. Keycloak's own operator documentation strongly recommends manual approval mode for operator updates, which signals that upgrades need a planned process, not ad hoc changes. If you choose external help, DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms in your own infrastructure under a written, fixed scope.

Does Keycloak cover LDAP and RADIUS clients?

Keycloak does not act as a general-purpose LDAP directory or RADIUS server for your network devices. It can federate with existing LDAP and Active Directory servers, which lets it authenticate users from a directory you already run, but LDAP-only clients such as NAS devices and Linux hosts need an LDAP endpoint, and RADIUS devices need a RADIUS service. Those are separate components you must select and operate, such as FreeIPA for Linux-centric directories or LLDAP for a lightweight LDAP front end. Confirm each client's protocol requirement and the supported bind method before selecting a design.

What does running Keycloak cost compared with JumpCloud?

Keycloak is licensed under the Apache License 2.0, so the software itself has no license fee. The recurring cost is the infrastructure you run it on, a supported database, the user store, backups, monitoring and the staff time to operate upgrades. Those costs are one-time for the build and recurring for operations, and they rise with high availability requirements and the number of environments. JumpCloud charges by subscription, so compare its per-user price and billing terms with your own server, database and staff costs in a written model. Ask a vendor for a quote that separates labor, infrastructure and any support subscription.

How do we keep MFA working during the cutover?

Plan MFA as its own migration track, because JumpCloud enrollments are not generally carried over to another system and must be re-established. Keycloak supports multi-factor authentication, and the approach is to define the required second factors, run new enrollments for pilot groups, and keep the old path available until every user has enrolled. Keep a documented fallback for users who lose their device, and make sure the RADIUS or VPN path has its own MFA plan. Confirm with your vendor how enrollments are exported or re-created before the contract ends.

Does Keycloak need a database, and which ones are supported?

Yes. Keycloak needs an external database for production, and the development file database is for testing only. Its supported production databases include MariaDB, Microsoft SQL Server, MySQL, Oracle Database, PostgreSQL 14 to 18, EnterpriseDB Advanced, Amazon Aurora PostgreSQL and Azure SQL. Your choice should follow your existing database operations skills and licensing, and high availability designs need a synchronously replicated database. Keycloak's export and import of realms is documented as having limitations as a backup method, so plan backups at the database level and test restores before cutover.

How DeployOpen helps you evaluate, implement and migrate

DeployOpen plans, implements, integrates and supports self-hosted open-source platforms inside your own infrastructure, including the Keycloak and user store split described on this page. We start from a written scope that sets out which applications, LDAP clients and RADIUS devices are in play before any work begins.

How we scope

We inventory which apps use SSO, which clients bind over LDAP and which devices authenticate over RADIUS.
The written scope names the user store, the Keycloak realms, the MFA method and each federated application.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.
We confirm with you which JumpCloud features are in use, since MFA enrollments and device policies need separate planning.

How we build

We deploy Keycloak in your cloud account, data center or air-gapped network, using a supported production database.
We configure user federation to your existing LDAP or Active Directory source, or to a separate user store where needed.
We set up SSO clients for each application and document the protocol (OpenID Connect, OAuth 2.0 or SAML 2.0) used.
We test MFA enrollment, login flows and any LDAP or RADIUS dependencies in a staging environment before cutover.

How we hand over

You receive configuration documentation, realm and client inventories, and runbooks for day-to-day administration.
We document backup and restore procedures, including the limits of realm export and import for disaster recovery.
We walk your administrators through the admin console, user onboarding and offboarding steps and access reviews.
Compliance evidence is prepared for your assessors, though audit reports and certifications come from independent auditors.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
We plan Keycloak upgrades against the release cadence, and we keep operator updates under manual approval where the Operator is used.
Security testing of the Keycloak deployment and connected applications can be scoped alongside the platform work.
Retainer scope, response expectations and upgrade windows are written down so your team knows what to expect.

JumpCloud vs Keycloak