VPN MFA with authentik RADIUS: PAP and OTP setup

VPN login with MFA through authentik RADIUS for RADIUS-only devices

Some VPN concentrators and firewalls only accept RADIUS for user authentication, and replacing the device is rarely a practical option when the goal is simply to add a second factor. The authentik RADIUS provider uses PAP for password authentication, and the user enters a one-time code by appending it to the password after a semicolon. authentik validates that suffix against Duo, TOTP or static authenticators, so the device sends one password field and authentik checks both factors in a single request. This page's RADIUS path covers that flow only. It does not cover SAML sign-in to the VPN, which uses a browser redirect and a different trust model. Before committing to this design, confirm three things with the device vendor and in your own lab. First, check that the VPN or firewall can send PAP and that its RADIUS client does not force CHAP or MS-CHAPv2, because the provider's documented password method is PAP. Second, confirm the password length limit and whether the device strips or rejects semicolons, since the separator is part of the credential format. Third, decide which authenticator types your users will hold. Duo, TOTP and static codes are the supported options over RADIUS, so an SMS code cannot be used here: authentik cannot send a code during the bind. Users who depend on SMS will need a different factor before this design works for them. The operational cost sits in the user experience and the helpdesk. Every login becomes a password followed by a code, which some users will mistype, and TOTP drift or lost enrollment will show up as lockouts. Plan enrollment, a recovery path and a documented way to issue static codes for emergencies before rollout. A useful test is a pilot group that logs in through the real device from outside your network, not only from the admin console.

What the team needs before configuring RADIUS MFA

RADIUS MFA through authentik depends on a running authentik stack, a supported version line, a network path the VPN can reach, and users who have already enrolled a factor. Each card below is a prerequisite to confirm before you touch the VPN configuration, because a gap in any one of them shows up as a login failure that looks like a password problem.

Server, worker and PostgreSQL

An authentik deployment has a server container, which runs core and an embedded outpost, a worker container for background tasks, and PostgreSQL, which holds all configuration and data except uploaded files. Confirm that both containers are running and that the RADIUS provider is served by the embedded outpost, since a stopped worker or unreachable database will break authentication in ways that are hard to trace from the VPN side.

Supported version line

Run a version line that still receives security fixes. The security policy lists 2026.5.x and 2026.8.x as supported, and the project announces security releases at least 24 hours in advance. Plan the upgrade path before go-live so the VPN team is not forced into an emergency change when a fix ships.

Hosting choice for the deployment

The Docker Compose guide targets test setups and small-scale production on a host with at least 2 CPU cores and 2 GB of RAM. For a production VPN dependency, confirm capacity, high availability and backup needs with your platform team. The Kubernetes guide uses a Helm chart whose bundled PostgreSQL is for demonstration and testing, so plan a separately managed PostgreSQL for production.

Reachable RADIUS listener path

The VPN appliance or network device must reach the authentik RADIUS listener over UDP on the address and port you configure. Check firewall rules between the VPN gateway and the authentik host, confirm which interface the outpost binds to, and test from the device's network segment rather than from your workstation, since a path that works from the admin network may still be blocked for the VPN.

Shared secret handling

The RADIUS client and the authentik provider must use the same shared secret. Generate a long random value, store it in your secrets manager, and restrict who can read the VPN configuration that holds it. Plan a rotation procedure that updates both sides in one window, because a mismatch typically looks like a rejected login with no clear message on the user's screen.

Enrolled factors and vendor confirmation

Each user needs an enrolled factor that RADIUS can validate, such as TOTP, Duo or a static code, before the VPN is switched over. Confirm with the VPN vendor that its RADIUS client supports PAP and that PAP is the password method it sends, because the provider accepts PAP only. Test one enrolled account end to end before you enable the policy for everyone.

How to configure the authentik RADIUS provider and MFA

This sequence takes a VPN that only speaks RADIUS from password-only sign-in to password plus a second factor checked by authentik. The result is a tested RADIUS provider, a bound authentication flow with TOTP or Duo validation, and a VPN that sends the password and code together in one PAP request.

Create the RADIUS provider with PAP
Open the authentik admin interface and create a RADIUS provider. Select PAP as the password authentication method, since authentik's RADIUS provider supports PAP for password authentication. Generate and record the shared secret, because the VPN must be configured with the same value. Check the provider list to confirm the provider saved, then keep the page open so you can attach it to an application in the next step. Confirm the exact field names against the RADIUS provider documentation for your authentik version.
Create the application and bind the flow
Create an application in authentik and attach the RADIUS provider to it. Bind the authentication flow that your VPN users will sign in through. Confirm that the password stage runs before the authenticator validation stage, because the RADIUS client sends the password and code in one field and authentik splits them at the semicolon. Your check is that the application appears in the application list with the provider attached, and that a test sign-in through the flow reaches the password prompt.
Add a TOTP or Duo validation stage
Add authenticator validation to the flow and decide which supported method you will accept, either TOTP or Duo. These are the second factors authentik supports over RADIUS, so do not plan on SMS codes for this client. Static codes are also supported, but treat them as a recovery method and confirm with your team how they are issued and rotated. Make sure the stage applies to the group your VPN users belong to. Check that the stage appears in the flow's stage order and that the flow saves without errors.
Enroll a test user's authenticator
Create a test account and enroll a TOTP device or a Duo device for it using the enrollment path authentik provides for the chosen method. For TOTP, register the device in an authenticator app and keep a current code available. Use a test account only, and confirm the enrollment steps against the authentik documentation for your version before you enroll real users. Check that the test user's account now shows an enrolled authenticator of the expected type.
Point the VPN at the RADIUS outpost
Enter the RADIUS outpost address, port and shared secret in the VPN's RADIUS settings, and select PAP if the VPN offers a choice. Confirm the outpost is running and healthy in authentik first. The VPN appliance must reach the outpost over the network, so verify routing and firewall rules before testing. Check that the VPN reports the RADIUS server as configured and that its test authentication returns a response. A wrong shared secret often looks like a password failure, so check it first if the test fails.
Test a successful login with password and code
Sign in to the VPN as the test user and enter the password, a semicolon, and the current one-time code in the password field. The format looks like this (illustrative): the password, then ;, then six digits from the app. Check that the VPN session establishes and that authentik logs a successful authentication for the test user. Use a code from the current time window, since TOTP codes expire, and record the result before moving on.
Test a failed login with a wrong code
Repeat the sign-in with the correct password followed by a semicolon and an incorrect code. Check that the VPN refuses the session and that authentik records a failed authentication for the test user. A refusal confirms the second factor is enforced. If the wrong code is accepted, stop and review the flow's stage order and the validation stage binding before onboarding any users.

How the password and code format works over PAP

The client sends the password and the one-time code as a single string, with the code appended to the password after a semicolon. The VPN or network device does not send a second prompt. It submits one PAP request, and authentik splits the string at the semicolon, validates the password against the bind, then validates the code against the user's enrolled authenticator. This is why the scheme works only with PAP: PAP sends the password in a form authentik can read and split on the server side. Other RADIUS methods that run a challenge exchange do not give authentik a clean place to receive a second value in the same request, so the format depends on the client using PAP for password authentication.

Static codes and Duo pushes behave differently. A static authenticator's value is appended the same way as a TOTP code, so users combine a password and a fixed value in one string. A Duo authenticator is also validated from the appended value, which means a push approval is not triggered by the bind the way a push is in a web sign-in. Confirm with the Duo side and your authentik version how the appended value is expected to be formed for each factor before you publish instructions to users, because the behavior depends on the authenticator configuration. Plan for the password itself to contain no semicolon, or confirm how your client handles a password that does.

Users must learn the format, and the VPN login screen was not designed for it. Most clients label the password field once and do not explain the appended code, so users will type only the password, or the code without the separator, and sign-in will fail. Prepare a short user guide with the exact string layout and test it with a real account before rollout. Ask the VPN or device vendor whether the login prompt labels can be changed, whether a custom banner or help text is possible, and whether the client trims or escapes semicolons, and confirm these answers in writing before relying on custom wording.

Why SMS codes cannot work over RADIUS

RADIUS authentication is a single request and response, so the second factor has to be ready before the VPN or device sends the bind. The cards below cover why SMS drops out, the three factors authentik accepts on this path, and what each one costs you in recovery and helpdesk work.

SMS cannot be sent during the bind

authentik cannot send a text message while the RADIUS bind is in progress, so SMS authenticators are not supported on this path. The VPN or firewall sends one request with the password and any code, and authentik has no channel to prompt the user and wait. If your current VPN relies on an SMS prompt, plan a different factor before you cut over, and do not assume a web portal flow will carry over to RADIUS clients.

TOTP in the password field

A TOTP code is appended to the password after a semicolon, so the user types something like their password, a semicolon, then the six-digit code from an authenticator app. Recovery is largely self-service when users keep backup codes, but a lost phone without backups means an administrator must re-enroll the device. Confirm how your VPN client handles a long password field and whether it masks or truncates input.

Duo push or code

The Duo authenticator is also supported on the RADIUS path and works with the same semicolon pattern. Users can approve a push on a phone, which reduces typing errors, but it depends on an external Duo service and a Duo account that your organization must license and manage. Confirm your Duo edition and whether your security team accepts that dependency before choosing it for administrator access.

Static codes for break-glass access

Static authenticators hold fixed codes that are appended to the password in the same way. They suit a small, tightly controlled set of emergency accounts, such as a break-glass administrator when the phone-based factors are unavailable. Because a static code never changes, store it in a sealed, audited location, rotate it after each use, and keep it out of routine user enrollment. Heavy reliance on static codes raises helpdesk and audit work quickly.

Helpdesk load by factor

Each factor shifts a different kind of support work onto your team. TOTP generates re-enrollment tickets after a device change, Duo generates account and device reconfiguration requests, and static codes generate rotation and custody questions. Ask your partner or internal team to map expected ticket types for each factor to your user count and to agree on the recovery process before rollout. Factor choice for the wider estate is covered on the authentik MFA and passwordless page.

Which attributes and groups map to VPN access

This table compares the authentik objects that decide VPN access over RADIUS, such as group membership, user status and the authenticator bound to each account. Read it as a checklist to confirm in your own provider and VPN settings before you rely on it for access control.

Control point	What it decides	What to confirm
Permitted VPN group	Which authentik group may complete a VPN login, typically enforced by the provider or application binding	The group name and whether the RADIUS provider or the VPN's own user list performs the final check
Excluded users	Accounts that must never reach the VPN, such as leavers, contractors past their end date or service accounts	That deactivated users fail the bind and that exclusion does not depend on the VPN keeping a separate local list
Authenticator enrollment	Which TOTP, Duo or static authenticator the user has, and therefore which code must follow the password	That the user has exactly one usable authenticator for this flow and that the VPN sends the code after the password
Password-only fallback	Whether an account without an authenticator can log in with a password alone	Whether the flow rejects such accounts or allows them, since that choice decides whether MFA is enforced for everyone
VPN role or access policy	The VPN user role, address pool or policy assigned after a successful RADIUS response	The attribute name returned in the Access-Accept response, which depends on the RADIUS provider and VPN configuration
Admin versus user roles	Whether administrators reach the firewall management interface through a separate group and policy	That administrator accounts are not granted VPN user access by default and that the VPN separates these roles
Attribute names	The RADIUS attribute or vendor-specific value that carries group or role data to the VPN	Exact attribute names in the RADIUS provider settings and in the VPN's documentation, since these vary by product and version

When SAML on the VPN is the better choice

RADIUS MFA is the right path when the device or VPN can only send a username and password over RADIUS, and no SAML or OIDC option exists in its management interface. In this model, authentik receives the PAP request, checks the password, and then validates an appended factor such as a TOTP code, a Duo push, or a static code. Nothing else changes for the user beyond typing the code after the password.

Legacy appliances: Older firmware or niche network gear often exposes only RADIUS for remote access.
Simple user flow: The user enters one combined string at the VPN prompt, with no browser redirect.
Controlled factor set: Only Duo, TOTP and static authenticators apply, so SMS is not an option.
Narrow policy scope: MFA is enforced at the RADIUS provider, not across every application.
Confirm first: Check the exact RADIUS and PAP behavior of your device with its vendor before committing.

Before you rely on this path, confirm that your VPN offers no SAML option in the installed firmware version.

Securing the RADIUS path against password and code exposure

RADIUS carries the password and the appended MFA code from the VPN to authentik in one exchange, so the channel itself is part of the authentication design. The cards below cover the shared secret, network restrictions, transport protection, lockout behavior and logging, which together determine how much a captured or guessed credential is worth.

Shared secret strength and rotation

The RADIUS shared secret between each VPN gateway and the authentik outpost is what protects the packet integrity of the exchange. Use a long, random value generated for each client rather than a shared word reused across devices. Plan a rotation procedure that updates the outpost client entry and the device at the same change window, and confirm with the VPN vendor how the secret is stored on the device and whether it is visible in its configuration export.

Restricting clients by source IP

Configure the authentik RADIUS client entries so that only the known VPN gateways and network devices can reach the RADIUS port. Any other host that can send a request is a candidate for password guessing or replay attempts. Verify the source address the outpost sees, since NAT, load balancers and Kubernetes service addresses can change what the outpost observes and cause legitimate requests to be dropped.

Isolating the RADIUS network path

Place the outpost and the VPN gateways on a dedicated segment or VLAN where the device allows it, so RADIUS traffic does not cross user networks. Ask the VPN vendor whether its RADIUS client supports TLS-protected transport, such as RadSec, and whether it is available in your version. Where it is not, the isolated segment is the main control for the traffic between the gateway and the identity provider.

Understanding PAP exposure

PAP sends the password in a form that depends on the transport in use, so the protection a reader gets depends on the path the packet takes. Over an unprotected network segment, the password and appended code can be recovered by anyone who observes the traffic. Confirm with the VPN vendor exactly how the password is encoded on the wire and whether the VPN tunnel itself, the RADIUS transport or a separate network control protects it.

Lockout and failure policies

Decide how many failed attempts a user can make before the account or the MFA step is locked, and how long the lock lasts. Because the password and code arrive together, a failed attempt may reveal which part was wrong. Test the policy with a deliberately wrong code and a deliberately wrong password, and confirm that the lockout behavior on the VPN side does not conflict with the one configured in authentik.

Logging failed attempts

Forward authentik events for failed RADIUS logins and the VPN gateway's own authentication logs to your central log platform. Correlate them by username, source address and time so that a password spray across many accounts is visible as one pattern. Confirm which fields authentik records for RADIUS rejections and whether source addresses are kept, since that determines what your security team can investigate later.

Common RADIUS MFA failures and their causes

This table lists the failures teams most often hit when adding MFA to RADIUS logins through authentik, with the likely cause and the fix for each. Read it by matching the symptom you see on the VPN or device to a row, then checking the cause in your authentik provider and client settings. Most failures trace back to the client's authentication method, the code format, or the user's group membership rather than to authentik itself.

Symptom	Likely cause	Fix
Correct password rejected	Client sends CHAP or MS-CHAP instead of PAP, so authentik cannot validate the password as expected	Set the client's RADIUS authentication method to PAP and confirm the authentik RADIUS provider is configured for PAP
Login fails when a code is entered	Code appended without the semicolon separator, or appended in the wrong position after the password	Enter the password, then a semicolon, then the code, with no spaces; check the format against the RADIUS provider documentation
Login fails only for some users	Code uses a method authentik cannot validate over RADIUS, such as SMS	Enroll the user in TOTP, Duo or a static authenticator; SMS cannot be used over RADIUS because no code can be sent during the bind
TOTP code always rejected	Clock drift between the authentik server and the user's authenticator app	Synchronize server time with NTP and ask the user to confirm the authenticator app uses automatic time
Password accepted but VPN access denied	User lacks the group that the RADIUS provider or the firewall policy uses to grant VPN access	Add the user to the authorized group in authentik and confirm the group matches the access rule on the device
Intermittent failures after upgrade	Changed connection behavior or reduced headroom on PostgreSQL after upgrading past 2025.10, which moved caching and sessions off Redis	Review PostgreSQL connection limits and pooling before and after each upgrade, and test RADIUS logins after the change
Static code works, TOTP does not	Static authenticator enrolled but the user is trying a time-based code, or the wrong device profile is selected	Confirm which authenticator the user is enrolled with and use only that method's code in the password field

Questions teams ask before adding RADIUS MFA

How much does it cost to add MFA to a VPN through authentik RADIUS?

The cost is mostly internal staff time and VPN vendor support time, plus the authentik edition you choose. The authentik pricing page lists an Open Source edition at no license fee, an Enterprise edition at $5 per user per month billed annually plus $0.02 per external user per month, and Enterprise Plus starting at $20k annually. RADIUS password authentication and the Duo, TOTP and static authenticator options are part of the RADIUS provider, so confirm with your edition which features you need. Ask for a written scope quote that separates one-time build work from recurring support and upgrade work.

How long does a RADIUS MFA project take?

Duration depends on the number of VPN gateways, the number of user groups, the factor mix you choose and how much change control your organization requires. No single duration applies to every environment, so ask for a timeline in the written scope rather than relying on a general figure. The work usually splits into a test deployment, one pilot gateway, a helpdesk process for enrollment and lost devices, and a staged rollout. Your VPN vendor's change window often sets the pace more than the authentik configuration does.

Can our own team set up authentik RADIUS for the VPN?

Yes, a team with experience running authentik, the VPN appliance and a PostgreSQL-backed deployment can do this in-house. The main skills are the RADIUS provider configuration, the authenticator validation settings, the VPN's RADIUS client settings and a test plan that covers failover. Teams without recent VPN or RADIUS experience often find the gateway-side configuration and the rollout plan take the most time. DeployOpen plans, implements and documents this work in your infrastructure when you prefer a partner, under a written scope.

What do we need to provide before starting the work?

You need to provide access to the authentik instance and the VPN gateways, a list of user groups and their VPN access, the factor you plan to use for each group, and a named contact who approves changes on the VPN side. You also need a decision on how users enroll TOTP or Duo, how lost devices are handled and who staffs the helpdesk. Confirm the VPN vendor's RADIUS and password-length rules before the engagement starts, because they affect how codes are appended to passwords.

What makes the effort go up or down?

Effort rises with the number of devices and gateways that need RADIUS, with the number of factors you support, and with the number of user groups that need different rules. A helpdesk process that is not defined in advance adds rework after rollout. Effort falls when the VPN supports a single authentication profile, when you use one factor type, and when the user population is small and centrally managed. Ask the provider to list each gateway, each factor and each group in the quote so the estimate can be checked against your environment.

Does the cost of VPN vendor support change the plan?

Yes, the VPN vendor's support terms can add cost and change the sequence of work. Some vendors require a support case to change RADIUS settings, validate a new authentication profile or open a ticket for a gateway upgrade. Check your support contract before the project, and ask whether any vendor-side changes need a planned window. Include vendor time as a separate line in the quote so it is not hidden inside internal estimates.

Should we use SAML on the VPN instead of RADIUS MFA?

Choose SAML when the VPN supports it and your users benefit from the browser-based sign-in flow that SAML provides. RADIUS MFA is useful when the VPN or network device only speaks RADIUS and you cannot replace it. Your choice affects the cost, the rollout and the support load, so compare both paths against your gateways before you commit. A written scope should state which path you chose and why, so the reasoning is available for audit reviews.

What recurring work follows the initial rollout?

Recurring work includes authentik version upgrades, VPN firmware updates, factor changes, user onboarding and offboarding, and periodic review of the helpdesk process. authentik publishes a security policy listing the supported versions and announces security releases in advance, so plan a window for them. Ask for a support retainer or a documented run book in the quote so upgrade and maintenance work is priced separately from the initial build.

How the scope of a RADIUS MFA project is set

The scope of a RADIUS MFA project is fixed by inventorying every device that will send RADIUS requests to authentik, then confirming for each one whether it can send PAP and whether it can carry a password field that accepts a code appended after a semicolon. This inventory is the first deliverable. It lists each VPN concentrator, firewall, mesh or Wi-Fi controller, its firmware version, the RADIUS attributes it expects back, its failover behavior, and the user groups that will authenticate through it. Devices that only offer CHAP or MS-CHAPv2, or that require SMS codes, are separated out at this stage because authentik's RADIUS provider supports PAP for password authentication and only Duo, TOTP and static authenticators, so those devices need a different design before any build work starts.

Vendor confirmation comes next. Client support for PAP and for the semicolon code format varies by product and by firmware release, and documentation does not always match behavior. DeployOpen asks the client to obtain written answers from each vendor, or runs a lab test on a matching device, and records the result against the inventory row. Where a vendor cannot confirm the behavior, the device moves to a documented exception list, with the owner, the compensating control and the date the exception is reviewed. The client should also confirm which MFA method each user population will use, since TOTP, Duo and static codes each carry different enrollment and recovery work.

Test cases and rollback are agreed in writing before work starts. The test list covers a successful login with and without a code, a wrong code, an expired or reused code, a locked account, a user with no enrolled factor, and failover to a second RADIUS server. The rollback plan states how the device returns to its previous authentication source, who makes that call, and how long a fallback account stays available. Scope is then signed off as a written document listing the devices in scope, the test cases, the rollback steps and the items excluded, so changes after sign-off go through a change request rather than being absorbed silently into the work.

How DeployOpen delivers RADIUS MFA for authentik

DeployOpen plans and builds the authentik RADIUS setup for your VPN and network devices inside your own infrastructure, including how each device sends passwords and second-factor codes. The written scope fixes which devices, factors and users are covered before any build starts.

How we scope

Inventory every VPN gateway and network device that will authenticate over RADIUS, with its firmware and PAP support confirmed.
Decide which second factor each population uses: TOTP, Duo or static codes, and document why SMS is excluded.
Record the decision on SAML instead of RADIUS for each device that supports it, so the choice is explicit.

How we build

Configure the authentik RADIUS provider, its outpost and the users, groups and authenticators the scope requires.
Test password-plus-code logins with a semicolon separator from each device model, including lockout and failure behavior.
Verify that the RADIUS path reaches the outpost over the network segments you control, with firewall rules documented.

How we hand over

Deliver written configuration records, device setup steps and the test results for each device and factor combination.
Document the operational runbook for enrolling users, resetting authenticators and rotating the RADIUS shared secret.
Walk your network and identity teams through the setup and record who owns each part after handover.

How we support

Fixed-scope engagements have agreed deliverables and timelines, set in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer for changes after handover.
Plan authentik version upgrades and re-test RADIUS logins after each upgrade, against your agreed scope.