Open-source alternative to the Duo Authentication Proxy

Open-source alternative to the Duo Authentication Proxy: the short answer

privacyIDEA's RADIUS integration and authentik's RADIUS and LDAP outposts can keep the second-factor decision inside your network, so a VPN, firewall or network device no longer needs a path to Duo's cloud to complete a login. The Duo Authentication Proxy sits between your network devices and Duo: it receives RADIUS or LDAP authentication requests from VPN concentrators and other devices, checks the primary password against your directory, and then calls Duo's cloud to approve the second factor. That outbound call on port 443 is the core reason many teams replace it. If a site cannot reach Duo's cloud, or policy forbids sending authentication traffic to a third party, the proxy cannot do its job, regardless of how well it is configured.

The replacement changes who runs the second factor. With privacyIDEA, a RADIUS client such as an OpenVPN, Fortinet or Palo Alto gateway sends the request to a privacyIDEA server you host, which validates TOTP, HOTP, push, FIDO2 or other supported tokens against user stores you already maintain, such as LDAP or Active Directory. With authentik, the RADIUS and LDAP outposts run close to the devices and talk to the authentik server you operate, and the server stores its configuration and data in PostgreSQL. The main trade-off is that your team now owns availability, patching, backups, token enrollment and help desk work that Duo previously carried. Before you commit, confirm with the vendor which RADIUS attributes and challenge modes each of your devices requires, and test failover behavior when the MFA service is unreachable.

Start with an inventory of every RADIUS and LDAP client that points at the Duo proxy, including the shared secrets and the user groups each one serves. Then check whether those clients can be reconfigured to a new RADIUS endpoint and whether they support the challenge-response flow your chosen product uses. Decide early which users keep hardware tokens and which move to app-based or passkey factors, because that choice drives both the migration plan and the ongoing support load. Ask any implementation partner for a written scope that names the devices, factors and failure scenarios covered, since that scope, not the software license, determines the effort involved.

Which proxy functions map to open-source options

This table maps each job the Duo Authentication Proxy performs to privacyIDEA's RADIUS integration, authentik's RADIUS and LDAP outposts, or a gap you must close another way. Read each row as a question to test in your own lab, since the answer depends on the device vendor and the factor you use. The main takeaway is that the network path can stay inside your perimeter, but push and device-specific challenge behavior need validation before cutover.

Proxy function	privacyIDEA	authentik outposts
RADIUS server for VPNs and network devices	privacyIDEA accepts RADIUS requests from VPNs such as OpenVPN, Fortinet and Palo Alto, so the RADIUS path stays on your network.	authentik's RADIUS provider serves RADIUS clients through an outpost. Confirm the supported attribute and challenge handling for each VPN model.
LDAP primary authentication	Users resolve from existing LDAP or Active Directory stores through user ID resolvers, and the first factor is checked against that directory.	The LDAP outpost binds to your directory for primary authentication. Confirm bind account permissions and group filtering in your environment.
Push approval	Push needs the privacyIDEA Authenticator app. Standard TOTP and HOTP apps cannot receive push, so users must install the privacyIDEA app to match Duo Mobile behavior.	Push depends on the authentication flow you build and the client app used. Confirm with your device vendor whether its RADIUS challenge supports a push-style prompt.
Passcode factor	TOTP, HOTP and hardware token codes work over RADIUS, and users of standard authenticator apps can keep them.	OTP and WebAuthn are configured through authentik flows. Confirm the passcode prompt format each VPN expects over RADIUS.
Phone call and SMS factors	SMS is supported, but carrier costs and delivery depend on your provider. Phone call verification is not listed in the researched feature set, so confirm it before relying on it.	Phone call verification is not listed in the researched feature set. Confirm SMS options with your flow design and provider before planning.
Failmode behavior	Duo's failmode choice decides whether logins succeed when the MFA service is unreachable. Plan privacyIDEA's own availability and define the same fail-open or fail-closed rule explicitly.	Failmode depends on how you deploy outposts and how the device handles RADIUS timeouts. Test an outage with each device and record the result.
Outbound connectivity to Duo's cloud	Not required. privacyIDEA runs inside your infrastructure, so the proxy no longer needs outbound access on port 443.	Not required. Outposts communicate with the authentik core inside your network, so no call to a vendor cloud is needed.
Device vendor challenge behavior	Confirm each VPN and network device accepts the RADIUS challenge flow used by privacyIDEA in your own lab before production cutover.	Confirm each VPN and network device accepts the RADIUS challenge flow used by authentik in your own lab before production cutover.

privacyIDEA or authentik outposts for RADIUS and LDAP

Duo's proxy is the piece that handles VPN and network device logins, so the replacement has to answer RADIUS and LDAP requests on your own network. privacyIDEA and authentik both do this, but they reach that goal from different starting points. The cards below cover what each platform brings, where each fits, and what to confirm before you commit.

privacyIDEA as a dedicated MFA service

privacyIDEA is licensed under AGPLv3 and is built as an MFA platform first. It answers RADIUS requests from OpenVPN, Fortinet and Palo Alto, and it reads users from LDAP and Active Directory through its user ID resolvers. Its strongest case is a separate MFA service that handles several factor types, including hardware tokens and smartcards, behind the network devices. Confirm which RADIUS attributes your VPN and firewall vendors need, since each one expects its own configuration.

Hardware tokens and smartcards in privacyIDEA

If your estate relies on hardware OTP tokens, PIV or x509 smartcards, the factor coverage is the main reason to choose privacyIDEA. It can import token seed files in SafeNet XML, OATH CSV, Yubikey CSV and PSKC formats, which removes a manual re-enrollment step for existing hardware. Plan who holds the seed files and how the import is audited, because seed files are sensitive material. Ask your token vendor which formats they export.

authentik outposts for RADIUS and LDAP

authentik runs RADIUS and LDAP providers through outposts, so the same platform that handles SSO can also answer network device requests. The core is MIT licensed, and since release 2025.10 authentik stores its data in PostgreSQL without Redis. Be aware that outposts must reach the authentik server, so confirm the network path from each VPN or firewall segment before you place the outpost.

One platform for SSO and network MFA

When the same team must run SSO for applications and RADIUS for VPNs, authentik lets you manage both from one admin console and one PostgreSQL database. That reduces the number of systems to back up and patch. The trade-off is that a single platform becomes a shared dependency, so a sizing or upgrade issue affects both web and network logins. Test failover of the outpost before you retire Duo.

Enterprise-only features and support limits

The free authentik edition supports RADIUS, LDAP and proxy authentication, but its support is limited to the community Discord. Features such as mTLS client certificate authentication, password history, enhanced audit logging and ticket-based support sit in the paid Enterprise edition. If your audit or change control needs contractual support, price the Enterprise tier before the design is final. Confirm current feature availability on the pricing page.

Choosing between the two

Choose privacyIDEA when the MFA service itself is the priority, especially with hardware tokens, smartcards or a dedicated MFA tier separate from identity. Choose authentik when SSO, RADIUS and LDAP should share one platform and one administrative team. Either way, confirm which RADIUS clients you must support, which factors each user group needs, and how the service behaves when it is unreachable, because that behavior decides whether VPN logins fail closed.

Running the new RADIUS service beside the rest of Duo

This path fits organizations that keep Duo for cloud applications and web single sign-on while moving only the RADIUS and LDAP traffic from VPNs and network devices to on-premises infrastructure. The on-premises service handles the second factor for those network flows, and Duo continues to serve its existing integrations. Both systems then hold enrollment data, so the scope of each must be written down before cutover.

Assign each integration to one system: Map every VPN, firewall and network device to either the new RADIUS service or Duo, so no integration points at both.
Plan the user directory split: Confirm which directory is the source of truth for usernames, because both systems will authenticate the same people.
Keep the LDAP bind account separate: Use a dedicated, read-only bind account for the new service rather than reusing the account that Duo's proxy uses.
Document the shared secret per client: Each RADIUS client needs its own shared secret, stored in your secrets manager and rotated on a set schedule.
Plan for dual enrollment: Users who already enrolled a phone in Duo may need a separate factor for the on-premises service, so communicate that early.

Before cutover, confirm with the vendor and your own testing that the new service accepts the RADIUS attributes your VPN appliances send and that failover behavior matches your policy.

Moving VPN and network device authentication off the Duo proxy

This sequence moves RADIUS and LDAP second-factor checks from Duo's cloud to a self-hosted server inside your network, one device group at a time. Each step ends with a check so the proxy is only retired after every VPN and network device answers from your own infrastructure.

Inventory every proxy-dependent device
The network team lists each VPN concentrator, firewall, and network device that sends RADIUS or LDAP requests to the Duo Authentication Proxy. For each one, record the RADIUS client settings: shared secret, listening ports, NAS identifier, the authentication method it requests, and the user search base if it uses LDAP. Also note which Duo integration key and application each device uses. The inventory is complete when every device that touches the proxy host has a row, and each row shows which Duo integration it depends on.
Stand up the self-hosted MFA server
The platform team deploys privacyIDEA or authentik in a test network that mirrors production routing, without any path to Duo's cloud. For privacyIDEA, the installation documentation covers pip and Ubuntu or CentOS and RHEL-family systems. For authentik, the Docker Compose guide suggests at least 2 CPU cores and 2 GB of RAM for small test setups, and its architecture uses a server container, a worker container, and PostgreSQL. The step is done when the MFA server answers a test RADIUS request from a lab client and logs the result.
Connect LDAP or Active Directory as the user source
The directory team configures the MFA server to read users from the existing Active Directory or LDAP service, using a read-only bind account. In privacyIDEA this is a user ID resolver; in authentik it is an LDAP source. Confirm the search base, the username attribute your VPNs send, and group filtering so that only the intended population can authenticate. The step is complete when a test user resolves correctly and a wrong password is rejected by the directory, not by the MFA server.
Pilot one device group
Choose a low-risk group, such as a single VPN concentrator used by a small admin team, and point it at the new RADIUS endpoint in a maintenance window agreed with the owners. Keep the Duo proxy running and its configuration unchanged so you can revert quickly. Test the full login path, including the second factor, failure cases, lockout behavior, and session timeouts. The pilot is accepted when the group logs in with the new factor and the authentication logs on the MFA server record each attempt.
Export users and hardware tokens from Duo
The identity team pulls the user list, enrolled devices, and hardware token assignments from Duo's Admin API, which requires an Admin API application with the appropriate permissions. Build a single inventory that maps each username to its enrolled factors and token serials. Confirm with Duo's documentation which fields your plan exposes and what the API rate limits are before running the export. The step is done when the inventory reconciles against the AD user count and every hardware token has a serial and an assigned user.
Re-enroll factors and import tokens
Hardware tokens are imported into the MFA server using the formats it supports, such as OATH CSV or PSKC, after confirming seeds and serials match the inventory. Users who relied on Duo Mobile push must enroll the privacyIDEA Authenticator app or a standard TOTP app, and the help desk should schedule enrollment sessions with identity verification. Enrollment is the step most often underestimated: plan for users who change phones, lose tokens, or have no working device during the cutover. Plan your help desk capacity and a fallback process for each group. The step is complete when every pilot and cutover user has an active factor and a tested recovery method.
Cut over device by device
Repoint each VPN and network device in the inventory to the self-hosted RADIUS endpoint, one group at a time, with the rollback configuration ready. After each change, the network team checks a successful login, a failed second factor, and a logged event on the MFA server. Keep the Duo proxy reachable until the last device in the inventory is confirmed, so no device loses access in a gap. The cutover is complete when the authentication logs show zero requests going to the proxy for a full business cycle agreed in advance.
Decommission the proxy host
Once every device has moved, the team revokes the Duo integration keys and the Admin API application that the proxy used, then stops the proxy service. Remove the proxy host from the network and firewall rules, delete its stored credentials and configuration, and update the asset and architecture records. Confirm with Duo's billing or account team how the subscription changes before cancelling, since your contract terms govern that. The step is done when the proxy host is gone, its keys are revoked, and the change record is signed off by the owners.

What the cost of self-hosting RADIUS MFA is made of

Self-hosting RADIUS MFA moves cost from a per-user Duo subscription into components you buy and staff yourself. The software license is often the smallest line. The larger lines are the servers that run privacyIDEA or authentik, the high availability design around them, the database behind them, and the people who enroll users and answer help desk calls. privacyIDEA is licensed under AGPLv3, so the core platform carries no license fee, but an optional privacyIDEA Enterprise Edition is available from NetKnights and carries a subscription you should price separately. For authentik, the free edition has no license fee and community support only, while Enterprise is published at $5 per user per month billed annually plus $0.02 per external user per month, and Enterprise Plus starts at $20k annually (authentik pricing page). Those figures apply only if you choose that tier, and they will not cover your servers or staff.

Plan for the RADIUS path to stay up even when one node fails, because a VPN or network device that cannot reach its second factor locks out remote staff. That means at least two MFA nodes, a shared database with its own backup and failover, and a load balancer or RADIUS failover configuration on the Duo Authentication Proxy's replacement side. Each node, the database and the monitoring stack are recurring infrastructure costs, and they grow with user count, login volume and the number of RADIUS clients. Adding SMS or email one-time codes adds per-message charges from your carrier or email provider, which recur monthly and rise with login volume. Hardware tokens such as FIDO2 keys or OATH tokens are one-time purchases per user, with replacement costs for lost or damaged devices.

Ask any integrator or vendor for a written quote that separates one-time work from recurring charges. Request the hours or fixed fee for installation, RADIUS client configuration, directory integration, and cutover, along with the per-year cost of the Enterprise subscription if you need one. For internal staff time, estimate enrollment and help desk hours from your own pilot group, because no supplied figure gives a reliable number. Confirm with the vendor which features your RADIUS flows need, since some enterprise features such as mTLS or ticket-based support are tier-specific. The cost falls when you reuse existing directories, automate enrollment and keep the number of supported factors small. It rises with every extra factor, region, RADIUS client and support tier you add.

Questions buyers ask before replacing the Duo Authentication Proxy

How much effort does replacing the Duo Authentication Proxy take?

Effort depends mainly on how many RADIUS and LDAP clients sit behind the proxy, how many users and hardware tokens must move, and how many factors (push, OTP, FIDO2, smartcards) you need to keep. The proxy itself is a small component, so most of the work is in the MFA service, the user source and the enrollment plan. Each VPN, firewall or network device that points at the proxy needs a new RADIUS target and shared secret, and each one should be tested separately. Ask any implementation partner for a written scope that lists each client, each factor and each user population before agreeing on a timeline.

Can our own team replace the Duo Authentication Proxy without outside help?

A team with experience in Linux, RADIUS and directory services can usually do it internally, provided it has time to test each network device and plan enrollment. privacyIDEA installs with pip or on Ubuntu and RHEL-family systems, and authentik offers Docker Compose for small setups and Kubernetes for larger ones. The harder parts are usually the RADIUS policy design, the user resolver to Active Directory or LDAP, and the help desk process for enrollment. Outside help is most useful for a fixed-scope review of the design, a pilot on one VPN, and documentation the operations team can maintain afterward.

How long does a pilot for a RADIUS MFA replacement run?

The pilot length is not something to plan from a generic figure, because it depends on your environment, the number of clients and how many users you involve. Pick one non-critical VPN or network device, run it against the new service with a small group of users, and record every login result, including failures. Confirm the duration with the chosen vendor and with your own change board before the pilot starts. A written scope from DeployOpen will state the pilot's deliverables and timeline before any work begins.

What does the replacement need from our network and identity teams?

The network team must confirm which RADIUS and LDAP clients use the proxy, open the required ports between those clients and the new MFA service, and keep traffic inside the network. The identity team must confirm the user source, usually Active Directory or LDAP, the attributes used for matching, and which groups need MFA. Both teams should agree on a rollback path for each device. Because the new service stays on your own servers, there is no outbound dependency on Duo's cloud, which removes one firewall rule that the proxy required.

Do RADIUS clients need reconfiguration after the change?

Yes, in most cases. Each RADIUS client currently points at the Duo Authentication Proxy, so its server address, shared secret and authentication method usually need updating to the new service. Some devices also cache settings or require a restart, and some expect specific attribute handling for push or challenge responses. Inventory every client first, test a change on one device, and keep the old proxy running until the last device has been verified. Confirm with the device vendor how it handles a RADIUS challenge before you change its configuration.

What happens if the MFA service goes down during a login?

The answer depends on the failmode configured on each client. Some devices fail closed and deny access when the RADIUS server does not answer, while others fail open and allow access, which weakens the second factor. Duo's proxy has its own failmode settings, so review what each device does today before you cut over. For a self-hosted design, run at least two instances behind a load balancer or a clustered database, decide per device whether access should fail closed, and define a break-glass account with a documented, audited procedure. Confirm the exact failmode options with the device vendor and with the MFA product's documentation.

Can the new service produce audit evidence for compliance readiness?

Both privacyIDEA and authentik record authentication events, and you can forward those logs to your own SIEM for retention. Compliance readiness means defining which events you keep, who reviews them, how long they are retained, and how configuration changes are approved and logged. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. An independent auditor or certification body makes that determination. Ask the vendor to show exactly which log fields are exported, and confirm retention and integrity controls in your own environment.

Official project and vendor sources to read next

Start with the privacyIDEA README and its installation documentation, because together they set out what the server does for RADIUS and how it installs on your platform. The README states the project is licensed under AGPLv3 and lists RADIUS integration for VPNs such as OpenVPN, Fortinet and Palo Alto. The installation guide covers pip and Ubuntu and CentOS or RHEL-family systems, so check which path matches your operating system before you plan the build. Then review the privacyIDEA GitHub releases page, which shows v3.14 published on October 7, 2026, after v3.13.4 on September 17, 2026. Confirm the RADIUS client, shared secret and user resolver settings in the exact release you plan to deploy, and record the version you tested.

For authentik, the provider documentation is the starting point. The providers page lists RADIUS and LDAP among its provider types, and the architecture page describes the server container with its embedded outpost, the worker container and PostgreSQL. Outposts are the components that receive RADIUS and LDAP traffic inside your network, so confirm where an outpost must sit relative to your VPN concentrators and directory servers, and whether the Docker Compose or Kubernetes install guide fits that layout. Check the authentik security policy for supported versions, which currently list 2026.5.x and 2026.8.x. The releases page shows 2026.8.4 published on October 14, 2026 as the latest release, so pick a supported line before you build.

Read Duo's own Authentication Proxy documentation alongside both projects, because the proxy's configuration defines what your VPNs and network devices currently expect: the RADIUS and LDAP sections, the integration keys and the failmode behavior. No Duo documentation link was supplied for this page, so locate it through your Duo administrator account or the Duo documentation site. Keep a copy of the current proxy configuration file before any change, since it records the exact settings you must map to the new service. Then confirm with each device vendor how it handles RADIUS timeouts, secondary servers and retries, and run test logins against a lab copy of the new service before you change production.

How DeployOpen scopes and delivers a proxy replacement

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the RADIUS and LDAP second-factor path stays on your network. For a Duo Authentication Proxy replacement, we start from the written inventory of VPN, network device and directory clients, then deliver against that scope.

How we scope

We inventory every VPN, network device and LDAP client that currently sends RADIUS or LDAP requests through the Duo proxy.
We confirm which directory supplies users and whether privacyIDEA or authentik outposts will sit beside it.
We agree the written scope, deliverables and timelines with you before any work begins, since most engagements are fixed-scope.
We confirm with each device vendor that its RADIUS settings support the chosen second-factor flow.

How we build

We deploy the RADIUS or LDAP components inside your cloud accounts, data centers or air-gapped network.
We configure shared secrets, failover behavior and directory connections, then harden the hosts and services.
We test each VPN and device login path, including what happens when the MFA service is unreachable.
We integrate the second factor with your existing enrollment and help desk processes.

How we hand over

We document architecture, configuration, network rules and the test results for each login path.
We prepare runbooks for enrollment, token issuance, secret rotation and proxy node recovery.
We set up backup procedures for the platform database and configuration, with restore steps your team can follow.
We walk your administrators through operation and confirm they can run the environment independently.

How we support

Ongoing support, upgrades and continuous testing are available as a DeployOpen retainer.
Upgrades are planned against the vendor release notes and tested in a staging copy before production.
Security testing of the deployed RADIUS and LDAP paths can be scheduled as part of the retainer scope.
Compliance readiness material covers the controls and evidence you will need, while independent auditors issue any assessment.

Open-source alternative to the Duo Authentication Proxy