Open-source alternative to JumpCloud Cloud RADIUS

Open-source alternative to JumpCloud Cloud RADIUS: the short answer

If your Wi-Fi controllers and VPN gateways authenticate against JumpCloud Cloud RADIUS, you need a RADIUS service on your own network that those devices can reach. authentik's RADIUS provider and privacyIDEA's RADIUS support can both fill that role. The deciding question is whether MFA and the user store should live in the same product. If you want one platform for directory, SSO and RADIUS, authentik is the natural candidate. If you already run a directory such as Active Directory or LDAP and want a separate MFA layer in front of RADIUS, privacyIDEA fits that split better.

The free authentik edition includes RADIUS according to the supplied pillar facts, with community support only. privacyIDEA is licensed under AGPLv3 and runs as a separate MFA platform that connects to RADIUS clients and to existing user stores. Confirm the license obligations and support model with each vendor before you commit, particularly if you plan to modify the code or buy a support contract.

The server software is the smaller part of this move. The real work sits in the access points, controllers and VPN appliances: the RADIUS server address and port each device uses, the shared secret configured on both sides, the authentication method each device supports, and the order in which you repoint devices so users are not locked out. Check your vendor documentation for each model before planning the cutover, because RADIUS behavior and MFA prompts differ between products, and no single configuration applies to every Wi-Fi or VPN vendor.

Which open-source option covers each RADIUS capability

This table maps each RADIUS capability in scope to the JumpCloud feature to verify, the authentik and privacyIDEA components that address it, and what you must test before cutover. Read the JumpCloud column as a checklist to confirm against JumpCloud's own RADIUS documentation, since those details are not yet verified here. The main takeaway is that MFA, EAP methods and accounting need hands-on testing with your own controllers and gateways.

Capability	JumpCloud Cloud RADIUS (verify)	authentik and privacyIDEA	What the reader must confirm
Access requests for Wi-Fi and VPN	Confirm which Wi-Fi controllers and VPN gateways JumpCloud documents as supported clients.	authentik's RADIUS provider and privacyIDEA's RADIUS interface both answer access requests from network devices.	Test with your exact controller and gateway models and their RADIUS client versions.
User and group based access	Confirm whether access is granted by user, group or device attribute, and how nested groups are handled.	authentik uses users and groups from its sources. privacyIDEA reads users through LDAP, SQL, SCIM or HTTP resolvers.	Verify group filters and nested group behavior against your directory schema before migrating policies.
MFA on RADIUS logins	Confirm whether MFA applies to RADIUS logins and which factor types it accepts.	privacyIDEA covers FIDO2, push, TOTP, HOTP, SMS and email. Confirm how authentik's RADIUS provider handles MFA challenges.	Check how push and one-time code prompts behave on each Wi-Fi and VPN client you use.
Shared secrets and device configuration	Confirm how shared secrets are created, stored and rotated for each device or client.	Shared secrets are configured per RADIUS client in each product. Confirm the exact setting path in your chosen version.	Plan secret rotation per device and identify any appliance that limits secret length or character set.
Certificate-based Wi-Fi (EAP methods)	Confirm whether JumpCloud issues device certificates and which EAP methods it supports.	privacyIDEA supports x509 and PIV smartcards as tokens. Confirm EAP-TLS, PEAP and other method support in each product.	Test EAP-TLS and PEAP end to end, including certificate authority integration, before cutover.
Accounting and logging	Confirm whether RADIUS accounting records and authentication logs are available, exported and how long they are kept.	Confirm accounting packet support and log export in authentik and privacyIDEA for your version.	Forward logs to your SIEM and verify that a full connect and disconnect session is recorded.
Components and dependencies	Confirm which parts run in JumpCloud's cloud and which, if any, need equipment on your network.	authentik needs its server, worker and PostgreSQL. privacyIDEA runs as a Python application with its own database.	Map the network path from controllers and gateways to the RADIUS host and size the database and hosts.

authentik RADIUS provider or privacyIDEA for RADIUS: when each fits

Replacing JumpCloud Cloud RADIUS means choosing which service answers Wi-Fi and VPN access requests on your network. The three options below separate a directory-led design, an MFA-led design and a split design, so you can match the service to where your users and second factors already live.

authentik RADIUS provider

Choose this when your users already sign in through authentik and you want one product to handle the directory, sign-in and RADIUS. The RADIUS provider is part of the free edition, so the decision rests on running the platform, not on a license fee. It needs a server container with the embedded outpost, a worker container and PostgreSQL, which stores all configuration and data except uploaded files. Check that your Wi-Fi controllers and VPN gateways accept the RADIUS features you rely on, and confirm MFA support for your device types before cutover. The main trade-off is that authentik carries the whole identity stack, so its availability becomes your network access availability.

privacyIDEA for RADIUS

Choose this when second-factor policy is the main requirement and your user store is LDAP, Active Directory, SQL or SCIM. privacyIDEA reads users from those stores through its user ID resolvers and answers VPN gateways such as OpenVPN, Fortinet and Palo Alto through RADIUS, while supporting FIDO2, TOTP, push and other token types. It installs with pip or on Ubuntu and RHEL-family systems, so it fits a Linux team that already runs its own servers. The trade-off is that privacyIDEA does not provide the SSO and application federation that authentik offers, so you may still need a directory and sign-in service next to it. Confirm which token types your users need, since push notifications require the privacyIDEA Authenticator app.

Running both services together

Choose this when you want authentik to hold the directory and sign-in while privacyIDEA verifies second factors for RADIUS clients. Each request passes through two systems, so a user can be authenticated in one and challenged in the other, and the handoff between them must be tested end to end. Test every device class, including Wi-Fi, VPN and any device that cannot show a challenge, and record which component failed when a login is refused. Budget for two services to patch, back up and monitor, and confirm which team owns each one before the cutover. This design is the most flexible but the most work to operate.

Running the RADIUS service next to the rest of JumpCloud

Moving RADIUS does not mean moving the whole directory at once. Each JumpCloud service you keep, and each one you move, creates a dependency that the new RADIUS service must respect. The cards below cover the decisions that connect Wi-Fi and VPN authentication to the LDAP, SSO and device services that stay in place.

Confirm what JumpCloud can export

Before you plan the RADIUS cutover, establish what JumpCloud will give you. Usernames, groups and attributes are usually straightforward to take out, but password hashes and MFA enrollments may not be exportable in a form another system can use. Ask JumpCloud directly what its current export includes, in what format, and whether any credential material is available. Treat the answer as the baseline for the enrollment plan.

Plan separate RADIUS enrollment

If credentials cannot move, users will need to enroll again on the new RADIUS side. Decide early whether that means a password reset, a new MFA token or a supervised enrollment window for each Wi-Fi and VPN group. Illustrative example: a site with a few hundred staff may need a staged schedule so help desk capacity is not exhausted in one day. Confirm the schedule with your own service desk before you announce it.

Keep LDAP clients on JumpCloud for now

LDAP binds from applications, NAS devices and Linux hosts do not have to move with RADIUS. Leaving them pointed at JumpCloud Cloud LDAP keeps those clients working while the RADIUS service is validated. The risk is a split source of truth: a user disabled in one place may still authenticate in the other. Document which directory is authoritative for each service and who changes it.

Decide where SSO and device policy stay

JumpCloud also handles SSO and device management, which RADIUS does not replace. If the new RADIUS service reads users from JumpCloud through LDAP, a user removed from SSO may still connect to Wi-Fi until the LDAP side reflects the change. Map which account state governs network access, and confirm with JumpCloud how device trust and policy signals are exposed to other systems before you rely on them.

Secure RADIUS shared secrets and device configuration

Each access point, firewall or VPN gateway needs the RADIUS server address and a shared secret. Store secrets in your password manager or secrets tool, not in ticket comments, and rotate them when staff leave or devices are replaced. Record which device uses which secret so a rotation does not break authentication for an entire site. Test one device before changing the rest of the fleet.

Sequence the cutover and the rollback

Run the new RADIUS service in parallel with JumpCloud for a defined pilot group, then move devices in batches. Keep the JumpCloud path available until the pilot has authenticated successfully, and write down the steps to point a device back. Ask your vendors and integrators for their own cutover checklist, and confirm the rollback steps against your own network before the first production change.

Migrating RADIUS clients without breaking Wi-Fi and VPN logins

This sequence moves Wi-Fi and VPN authentication from JumpCloud Cloud RADIUS to a RADIUS service on your own network, with each client cut over in a controlled order and a rollback path kept open at every stage.

Inventory every RADIUS client
List every access point, wireless controller, firewall, VPN concentrator and other device that sends RADIUS requests today, including the IP address, the SSID or tunnel group it serves, the authentication method it uses and the JumpCloud RADIUS settings it points to. Ask the network team to confirm whether any device uses accounting or CoA messages, since these need the same planning. The step is done when the list covers every device your change window must touch and the owner of each device has signed off on it.
Deploy the RADIUS service in a test network
Build the self-hosted RADIUS service in an isolated test network, either authentik's RADIUS provider with its outpost or privacyIDEA with its RADIUS integration, connected to the same user store the pilot will use. Confirm the platform versions you intend to run against the vendor's current security guidance before installing. The step is done when a test client can complete an authentication against the service and the logs show the request, the user and the result.
Create a dedicated shared secret per client
Generate a unique shared secret for each RADIUS client rather than reusing one value across the fleet, record each secret in your password manager or secrets store, and enter it on both the client and the new server. Limit who can read the secrets and plan how they will be rotated later. The step is done when every client has its own secret, the secrets are stored outside personal notes, and a test request from each client is accepted by the new server.
Configure a pilot SSID or VPN group
Choose one low-risk SSID or VPN tunnel group, ideally one used by IT staff, and point only that group at the new RADIUS service while the existing JumpCloud configuration stays in place for everyone else. Confirm that user lookups, group membership and any VLAN or policy attributes returned by the new server match what the JumpCloud setup delivered. The step is done when pilot users can join the network and receive the same network access as before.
Run parallel authentication
Keep the JumpCloud RADIUS path and the new path active side by side for a set of pilot users, so each user's logins can be compared across both systems. Review failed authentications, timeouts and attribute differences in the logs of both services, and fix any mismatch before widening the pilot. The step is done when a full set of normal login patterns, including reconnects, password changes and roaming between access points, succeeds on the new service without manual intervention.
Enroll MFA for pilot users
If the RADIUS service enforces a second factor, enroll pilot users in MFA on the self-hosted platform, using the methods your policy allows, and record which users completed enrollment. Note that users who enrolled with the JumpCloud factor will need to enroll again, and that standard TOTP apps and push notifications may need different enrollment steps. The step is done when each pilot user has a working second factor and help desk staff can walk through the reset process.
Cut over group by group with rollback
Move the remaining SSIDs and VPN groups to the new service in small batches, one group per change window, keeping the JumpCloud configuration documented and ready to restore on each device. After every batch, check authentication success rates and help desk tickets before starting the next group. The schedule depends on your device count and approved change windows, so confirm both with the network and security teams before setting dates. The step is done when every client authenticates against the new service and the rollback settings for each group have been tested and recorded.

What changes when the endpoint is no longer in JumpCloud's cloud

Once the RADIUS server runs on your network, your team owns its uptime, its TLS and certificate lifecycle, and its patching. JumpCloud operated the cloud RADIUS endpoint for you. With authentik's RADIUS provider, the outpost and the core run in your environment, so a certificate expiry, a stalled container or a missed upgrade becomes your incident. Plan the patch cadence around the authentik security policy, which lists 2026.5.x and 2026.8.x as the branches receiving security fixes, and confirm with the project which branch your deployment should track before you schedule upgrades. Also confirm the advance notice the project gives for security releases, so your change window can absorb them. Back up PostgreSQL on a schedule that you test by restoring, because it holds all authentik configuration and data except uploaded files, including the RADIUS provider settings and the users that sign in over Wi-Fi and VPN.

Network path and logging change as much as the software does. Access points, VPN concentrators and firewalls now have to reach your RADIUS listener on the authentication and accounting ports you configure, and the return path must be open too. Map every source, including guest and management networks, before cutover. Accounting and authentication logs no longer sit in JumpCloud's console. Decide where they go, how long they are kept, and who can read them, and forward them to your SIEM or log store before you decommission the old setup. Confirm with your access point and VPN vendors which accounting attributes they send, since that determines what your logs can answer during an investigation.

A failed RADIUS server can block every Wi-Fi and VPN sign-in at once, so redundancy and monitoring are part of the design. Run at least two RADIUS endpoints, list both on every access point and VPN gateway in the correct failover order, and test what a client does when the primary stops answering, because timeout values differ by vendor. Monitor the listener, the database connection and certificate expiry, and alert on failed authentication spikes as well as on outages. Rehearse a fallback path, such as a documented break-glass local account on the gateway, and keep it current. Ask your hardware vendors to confirm their failover and timeout behavior in writing before you rely on it.

Wi-Fi, VPN and wired 802.1X: what to check for each

Wi-Fi access points and controllers usually send RADIUS requests for WPA2 or WPA3 Enterprise clients, and many also send accounting records. Before you point them at a self-hosted server, confirm with the controller vendor which EAP methods the controller passes through to RADIUS, whether it supports RADIUS over TLS or only plain UDP, and which attributes it expects in the Access-Accept. Most Wi-Fi flows do not prompt for an MFA code at the network layer, so MFA usually has to be handled by the EAP method or by a separate captive or portal step.

EAP methods: Ask the vendor which EAP types the controller forwards to RADIUS. Do not assume a method works until the vendor documentation or a test confirms it.
Shared secret: Confirm the maximum and minimum secret length the controller accepts and whether it allows special characters.
Accounting: Check whether accounting is sent to the same server, which port it uses and whether interim updates are configurable.
MFA path: Decide whether MFA runs inside the EAP exchange, through a captive portal, or not at all for Wi-Fi, and document that choice per SSID.
Failure modes: Watch for timeouts when the RADIUS server is slow to answer, and for mismatched secrets that show up as silent rejects.

Confirm each SSID separately, because one controller often serves several profiles with different methods.

Cost, effort and what the work needs from your team

What does replacing JumpCloud Cloud RADIUS actually cost?

The cost comes from several components: software licensing, servers, PostgreSQL, staff time, migration and ongoing operations. The software can be free. The authentik free edition is MIT licensed for the core and includes RADIUS, but it comes with community support only, as stated on the authentik pricing page. If you need vendor support, the authentik Enterprise edition is listed there at $5 per user per month billed annually plus $0.02 per external user per month. Servers and PostgreSQL recur every month, while the migration work is largely one-time. Ask any quote to separate these lines so you can compare them with your current JumpCloud invoice.

What makes the effort grow for a RADIUS replacement?

Effort rises with the number of access points, switches and VPN concentrators that send RADIUS requests, because each one needs a shared secret, a client entry and a test. EAP methods and certificates add work, since certificate issuance, trust chains and client device configuration all have to match. The MFA method mix also matters: standard TOTP and HOTP are simpler to roll out than push notifications or hardware keys. Devices that cannot be reconfigured, and endpoints that were enrolled through JumpCloud's device management, need a separate plan. Inventory these before estimating anything.

Can our internal team run this migration without outside help?

A team with working knowledge of RADIUS, your Wi-Fi controller and VPN platform, and the directory behind them can usually run a pilot alone. The harder parts are certificate design, cutover sequencing so users keep connecting, and testing failover of the RADIUS service. Teams that rarely touch these systems often find the time for testing and documentation is the constraint, not the software. Check whether your staff have done a live cutover on the network hardware involved, and whether someone will own the service after go-live.

What does a fixed-scope engagement with DeployOpen cover?

Most DeployOpen engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work starts. For a RADIUS project, the written scope typically lists the access points and VPN devices in scope, the authentication methods, the RADIUS deployment, the MFA configuration, device configuration guidance, testing and handover documentation. Work that falls outside the agreed scope, such as redesigning the network, is handled as a separate item. Ongoing support, upgrades and continuous testing are available as retainers.

What should we ask for in a written quote for this work?

Ask for an itemized scope tied to your device inventory, with each access point and VPN platform named. Request the deliverables in writing, including configuration documentation, a tested failover plan and a cutover runbook. Confirm which MFA methods are covered, who provides certificates, and what happens if a device model needs a different configuration. Ask what is one-time and what is recurring, including any retainer for upgrades and support. Also confirm what you will need to provide, such as network access, change windows and named contacts on your team.

Which RADIUS and MFA factors change our risk profile after the move?

Once RADIUS runs on your own network, your team owns the shared secrets, the service certificates and the logs that show who authenticated. Shared secrets should be unique per device, stored securely and rotated under a documented process. Failover must be tested, because a RADIUS outage can lock out Wi-Fi and VPN users at once. Confirm with the vendor or project which audit logs are produced and where they are sent. Ask your security team to review the design before go-live.

How do compliance assessments treat a self-hosted RADIUS service?

DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. For a self-hosted RADIUS service, the evidence usually includes access control designs, configuration records, MFA enrollment procedures and change logs. Ask your assessor which controls they expect to see evidence for before the work begins, so the evidence is collected during the project.

How DeployOpen scopes and delivers a RADIUS replacement

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a JumpCloud Cloud RADIUS replacement, the work starts with a written scope covering your Wi-Fi and VPN devices, MFA requirements and the network segments where the RADIUS service will run.

How we scope

Inventory every Wi-Fi controller, VPN gateway and switch that authenticates through JumpCloud Cloud RADIUS today.
Agree in writing which RADIUS provider, such as authentik or privacyIDEA, fits your user store and MFA requirements.
Record the shared secrets, certificates, network placement and logging the written scope will cover before work starts.

How we build

Deploy the RADIUS service in your own cloud account, data center or air-gapped network, with its database kept there too.
Configure client definitions, shared secrets and MFA policies, then test each device type against a staging user group.
Run security testing on the RADIUS endpoints and document the findings and fixes in the agreed deliverables.

How we hand over

Provide configuration records, runbooks and the device configuration templates your network team needs.
Walk your administrators through cutover sequencing so that devices keep authenticating during the switch from JumpCloud.
Deliver backup and restore procedures and the evidence set your compliance assessors will ask for, without issuing any audit opinion.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover RADIUS service upgrades, secret rotation and periodic re-testing of authentication paths.
Confirm support terms, response expectations and upgrade cadence in the written scope before you sign.

Open-source alternative to JumpCloud Cloud RADIUS