MFA for LDAP and RADIUS clients in authentik: what it does and when you need it
authentik can enforce a second factor for LDAP and RADIUS clients by appending one-time codes or authenticator responses to the password. This matters for legacy applications, network gear and VPNs that bind over LDAP or RADIUS and have no way to show a web MFA prompt. The user types a single password field, and the code travels with it. If your estate contains clients like these, a web-only MFA rollout leaves them as the weakest entry point to your directory, so the question is which of them need the second factor and which factor each one can carry.
The LDAP provider runs binds through an authentik flow, so the same stages and policies that govern web logins also apply to LDAP binds. That means a single set of rules for lockouts, device restrictions and conditional access rather than a separate policy for directory traffic. For RADIUS, the provider's authenticator validation supports Duo, TOTP and static authenticators. The user enters the password, then a semicolon, then the code, for example password;123456 (illustrative). SMS authenticators are not supported on this path, so any device or network client that depends on SMS delivery needs a different plan. Before you commit, confirm each client's password field length limit and whether it strips or rejects the semicolon character, because a client that cannot send the separator cannot use this method.
Decide per client before you enable anything. Identify which applications and devices can accept a combined password and code, which ones need Duo push because they cannot take typed codes, and which should stay on a directory-only bind until they are replaced. Ask each vendor whether their LDAP or RADIUS client supports a code appended to the password and whether it caches credentials, since caching can quietly bypass a prompt you expected to see. Plan a test bind for each client against a non-production authentik instance, and verify that a failed code is rejected and logged before you apply the policy to production users.
Which second factor fits LDAP and RADIUS clients
This table compares the second factors authentik can apply to LDAP and RADIUS binds, with the user experience and recovery path for each. Read the confirmation column first, because whether a factor works depends on whether your client can send a password followed by a code or push request in one credential string. The main takeaway is that RADIUS does not support SMS, and that every option needs a planned fallback before rollout.
| Option | User experience | Recovery | Confirm in your client |
|---|---|---|---|
| Duo push | User approves a push on a registered device after entering the password | Handled through Duo enrollment and device management, so a lost phone needs Duo-side reset | Whether the client can trigger a push from a single credential string |
| Duo passcode | User appends a Duo passcode to the password in the bind or login field | Same Duo enrollment path as push, plus any passcodes the user already holds | Maximum password length, since the appended code counts toward it |
| TOTP | User appends the six-digit app code to the password, separated by a semicolon on RADIUS | Re-enroll a new authenticator app through the enrollment flow, ideally with a fallback in place | Support for the separator format and whether the code can be entered without a prompt |
| Static tokens | User appends a pre-issued code from a list to the password | Serves as the fallback itself, so storage, issuance and reissue procedures need an owner | Whether the client accepts repeated typing of the same secret format for each login |
| SMS codes | Not supported for RADIUS, so the option is unavailable on those clients | Not applicable for RADIUS, and LDAP use needs separate confirmation against the current documentation | Confirm SMS support for LDAP flows before planning around it |
| Email codes | Not covered in the supplied RADIUS documentation, so use is unconfirmed | Depends on mailbox access and the email factor's recovery settings | Confirm RADIUS and LDAP support with authentik before committing to this method |
| Hardware keys (WebAuthn) | Generally needs a browser interaction, which most bind-based clients do not provide | Would need a separate fallback because keys cannot be used in a plain bind | Confirm with the client vendor whether any bind-based client can use a security key |
Setting up MFA on an authentik LDAP or RADIUS provider
This sequence turns a plain password bind into a password-plus-code check that runs through an authentik flow, so LDAP and RADIUS clients enforce the same policies as web logins. Each step ends with a check that tells you whether the next step can start.
Confirm the authenticator devices for each user
Decide which authenticator types the LDAP or RADIUS clients will accept, then confirm that test users have enrolled devices of those types. For RADIUS, the supported types are Duo, TOTP and static authenticators, and SMS is not supported, so SMS should not be part of the design. Create a test TOTP device for a pilot user in the authentik admin interface and confirm it appears under that user's devices. Done means the pilot user has at least one working device of an accepted type.
Create the authenticator validation stage
Create an authenticator validation stage in the admin interface and select only the device classes your clients support. Set the not-configured action so that users without an enrolled device are handled as your policy requires, and review the stage settings before attaching it to any flow. Done means the stage saves with the intended device classes, and a test validation against the pilot user's TOTP device returns success with a valid code.
Build a dedicated bind flow with password then validation
Create a flow for LDAP and RADIUS authentication, separate from the web login flow, so changes to browser logins do not change bind behavior. Add an identification stage, a password stage, and then the authenticator validation stage, in that order, and bind the flow's policies to the clients that use it. Done means the flow shows the three stages in the intended order and a preview run asks for the password and then the code.
Bind the flow to the LDAP or RADIUS provider
Open the LDAP or RADIUS provider and set its authentication flow to the dedicated flow. For LDAP, also confirm the bind flow setting, since the provider documentation states that binds run through a flow and the same policies as web logins then apply. For RADIUS, confirm how the client sends the code: after the password, separated by a semicolon. Done means the provider saves with the new flow, and the outpost has picked up the change.
Test a bind with a valid code
From a test client on the network path your applications use, bind as the pilot user with the password followed by a current TOTP code, in the format your RADIUS or LDAP client expects. Confirm the bind succeeds and that the user can read only the attributes the client is meant to read. Done means the bind succeeds with a current code and the user's session or access matches what you designed.
Test rejection of a wrong code
Repeat the bind with the correct password and an incorrect code, then with the correct password and no code. Both attempts should fail, and the client should show a clear rejection rather than a fallback to password-only access. Also confirm that a correct code with a wrong password fails. Done means every incorrect combination is rejected and none of them grants access.
Review logs and test each client
Check the authentik event log for the successful and failed attempts you just made, and confirm each entry records the flow, the user, and the outcome. Then repeat the valid and invalid tests in every client application that will use the provider, since client behavior around prompts and code formats varies. Confirm failed attempts appear in the log before you move users onto the flow. Done means every client has passed both tests and the log shows the expected entries for each.
Client patterns: separating appliances, VPNs and applications
RADIUS clients send the username and password in a single access request, and authentik expects any second factor to follow the password in that same field. The RADIUS provider supports Duo, TOTP and static authenticators, and SMS authenticators are unsupported, so plan around those three types only. Build a dedicated flow for each appliance group so that changes to a VPN policy do not alter browser logins.
- Flow design: Create a RADIUS provider bound to a flow that includes an authenticator validation stage, then attach it to the outpost the appliance can reach.
- Code format: Users type the password, a semicolon, then the code, for example
password;123456(illustrative). Confirm that the appliance does not strip or escape the semicolon. - Authenticator choice: TOTP and static codes are typed by the user. Confirm with the Duo documentation which Duo method works for your appliance before promising push prompts.
- Shared secret and reachability: Verify that the shared secret, port and source addresses on the appliance match the provider settings before any user tests.
- Failure behavior: Check how the appliance reports a wrong code, an expired code and a timed-out Duo request, because some devices show these as the same generic failure.
Before rollout, pilot one account per appliance and test a correct code, a wrong code and a replayed code, then confirm the appliance's own lockout settings.
The LDAP provider supports code-based MFA and binds through a flow, so the same stages and policies that apply to web logins also apply to LDAP binds. Applications that show only one password field often need the code typed into that field after the password. The exact separator and acceptance rules depend on the client, so the test with the client version you run is the only reliable check. Review the LDAP provider documentation before designing the bind flow.
- Stage order: Place identification, password and authenticator validation in a bind flow, and confirm the order against the provider documentation.
- Code format: Confirm the separator the client expects and test it with a live code, since some applications trim or reject long input.
- Policy reuse: Group, GeoIP and reputation policies on the bind flow will affect LDAP users as they affect web users, so review them before enabling.
- Service accounts: Accounts that the application uses to search the directory need a separate flow or an explicit exemption, or every search will fail the second factor.
- Connection pools: Applications that keep pooled connections may reuse a bind, so confirm how often they authenticate and whether that triggers throttling.
Test a bind with a valid code, a bind with no code and a bind with a reused code, and watch the logs for repeated binds from the application.
Some LDAP clients accept only a username and password and cannot send a live code at all, so the second factor cannot be typed during the bind. For these clients, the design choice is between keeping them outside the MFA-protected path, moving them to a narrower service path or confirming a method the client can actually use. Do not assume a client supports a method until a test bind proves it. Record each decision with the risk owner so that exceptions stay visible.
- Inventory: List every LDAP client and record whether it can send a password plus code, only a stored bind password or something else.
- Service paths: Give non-interactive binds their own provider and a narrower scope, so that user-facing MFA rules stay clear and easy to audit.
- Static codes: Static authenticator codes can serve clients that cannot send a live code, but a shared static code weakens the factor, so limit their use to defined cases and confirm the policy with the risk owner.
- Push and out-of-band prompts: Confirm with the client vendor and the authentik documentation whether any push or out-of-band prompt is available for LDAP binds.
- Exception records: Keep a dated list of excluded users and clients, with a named owner for each exception.
Before announcing a rollout date, run a real bind from each client and confirm both the success path and the failure path.
Security risks of code-based MFA on legacy bind protocols
LDAP and RADIUS clients send credentials in a single bind or access request, so the password and the one-time code travel together and the client often controls retries. The risks below connect at that point: each one changes how much protection the second factor actually adds, and each has a control you can set and verify in authentik.
Guessing attacks on appended codes
With LDAP or RADIUS, the user's password and code arrive as one string, so an attacker can try many password and code combinations from a single client. Code-based factors have a short lifetime and a small value space, which makes throttling and lockout settings the main defense. Check how many failed attempts each authenticator tolerates, whether failures count per user or per source address, and whether the bind flow applies reputation policies before the code is checked.
Static token reuse
Static authenticators hold fixed codes, so a copied code works until someone removes or replaces it. Treat them as recovery material rather than daily second factors for legacy clients. Confirm who can issue static tokens, where they are stored, how they are shown to users once, and how quickly an administrator can revoke a set after a suspected leak.
Service accounts that skip MFA
Bind accounts used by applications to read directories often cannot answer a code prompt, so teams exempt them from MFA policy. Those accounts then become a password-only path to the same directory data. Inventory every bind identity, restrict it to read scopes and source networks, and keep it out of the user-facing flow that carries the second factor.
Cleartext or weak LDAP and RADIUS transport
A bind over plain LDAP or a RADIUS request without a protected tunnel exposes the password and code to anyone on the path. Confirm that the client, the outpost and the network segment all use encrypted transport, and that certificate validation is enforced on the client side rather than skipped for convenience. Test the path with a packet capture in a lab before users depend on it.
Shared secret management for RADIUS
RADIUS clients authenticate to the server with a shared secret, and that secret protects the authentication exchange between each NAS device and the server. Secrets copied into many devices, rarely rotated, or stored in configuration files with broad read access weaken every factor behind them. Record which devices hold each secret, set a rotation procedure, and confirm the secret is unique per client.
Failed bind alerting
A spike of failed binds or code rejections is often the first visible sign of guessing, a misconfigured client or a locked-out user. Without alerts on failed authentication events, these patterns stay in logs nobody reads. Decide which events to forward, which thresholds page someone, and who responds, and test the alert with a deliberately failed bind from a non-production client.
Questions buyers ask about MFA for LDAP and RADIUS in authentik
Does SMS work as a second factor over RADIUS in authentik?
No. According to the authentik RADIUS provider documentation, the authenticator validation for RADIUS supports Duo, TOTP and static authenticators, and SMS authenticators are not supported. If your users depend on SMS codes today, plan for a different second factor on RADIUS clients, such as TOTP, Duo or static codes, and confirm the current list in the authentik RADIUS provider documentation before you commit to a design. Email codes and SMS codes are also worth checking against the RADIUS flow in your own test environment, since the supported list is the vendor's statement and your client may add its own constraints.
What does the client team need to provide for an LDAP or RADIUS MFA rollout?
The client team usually provides the list of applications that bind over LDAP or RADIUS, the network paths from those clients to the authentik server, a test account set, and an owner who can change each client's bind or authentication settings. Each application also needs a decision about how users type their credentials, because code-based MFA is appended to the password in many RADIUS clients, which changes the login experience. Ask the implementation partner to list these inputs in the written scope, and confirm with each application vendor whether its LDAP or RADIUS client accepts the separator format authentik expects.
How long does a pilot take, and what makes it longer?
The duration depends mainly on how many client applications are in scope, how many of them use RADIUS versus LDAP, and whether each one can be tested with a real user flow. A single LDAP application with one bind flow is much simpler than several RADIUS clients that each handle the appended code differently. Other drivers include the number of second factors being offered, whether Duo credentials and user imports are needed, and how quickly your security team approves the bind flow design. This page does not supply a fixed duration, so ask for a timeline in the written scope that lists each application and the test cases it must pass.
Can our in-house team set up MFA for LDAP and RADIUS clients without a partner?
Yes, if your team has experience with authentik flows and policies, the LDAP and RADIUS providers and your client applications' authentication behavior. The work is less about the authentik settings than about testing each client, because the same policies apply to LDAP binds as to web logins, but every RADIUS client may format the password and code differently. Teams without a test lab, a plan for rollback and someone who can read authentik logs during failed binds often find that the first pilot takes longer than expected. A partner can take the testing and documentation load, while your team keeps ownership of the final configuration.
Does the open-source edition of authentik include MFA for LDAP and RADIUS?
The authentik pricing page lists an Open Source edition at no cost with community Discord support, and it lists enterprise-only features such as Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history, enhanced audit logging and ticket-based support. MFA for LDAP and RADIUS is not on that enterprise-only list, but the supplied facts do not confirm which features each edition includes in detail. Check the current authentik pricing page and the license terms in the repository against your exact requirements before you assume a feature is available in the open-source edition.
What cost components should a quote for this work cover?
A quote usually splits into planning and design, configuration of the authentik flows and providers, testing against each LDAP or RADIUS client, documentation and handover, and any work on third-party services such as Duo accounts or an SMS gateway. Some costs are one-time, such as the pilot and the initial configuration, while others recur, such as updates, monitoring and support for new applications. Authentik hosting costs also belong in the comparison, since the Docker Compose guide calls for at least 2 CPU cores and 2 GB of RAM for small-scale production, and Kubernetes deployments need a separately managed PostgreSQL for production. Ask for each cost line to name its owner, and for any third-party license to be shown separately.
Which bind flow design choices affect security the most?
The most important choice is whether the LDAP provider's bind goes through a flow that includes the authenticator validation stage, because authentik applies the same policies to LDAP binds as to web logins. Other choices include which second factors each client can accept, how remembered-device or validation thresholds apply to non-interactive binds, and how failed attempts are throttled and logged. Make these decisions with your security team before testing, and record them in the written scope so auditors can trace each rule to a decision.
How DeployOpen scopes an LDAP and RADIUS MFA rollout
Scope starts with an inventory of every client that binds over LDAP or RADIUS, because the second factor that works for one client may not work for another. For each application, record the protocol, the bind method, whether the client can send a code after the password, whether it caches sessions, and which users and groups authenticate through it. The inventory determines the design: RADIUS clients can take Duo, TOTP and static authenticators with the code appended after the password and separated by a semicolon, but SMS is not supported on RADIUS, so any client that depends on SMS needs a decision before work starts. Confirm each client's behavior with its vendor or your own test environment rather than assuming it.
The second part of scope is the flow design and the test plan. The authentik LDAP provider runs code-based MFA through a flow, so the same policies that govern web logins can apply to directory binds, and the RADIUS provider uses its own authenticator validation settings. DeployOpen scopes the flow configuration for each protocol, the test cases for each client (successful bind, wrong code, missing code, lockout behavior, service accounts that must not prompt for a second factor) and the change windows needed to test without disrupting production users. Ask for a named owner on the client side who can confirm results for each application.
The written deliverable is agreed before work starts. Clients typically provide access to their authentik and client test environments, test accounts with known enrollment state, the list of stakeholders who approve cutover, and change windows for each application. DeployOpen delivers the flow and provider configuration, test evidence for each client and protocol, and a runbook covering enrollment, lockout recovery and rollback. Ask any partner for the exact list of deliverables, the acceptance criteria and what happens if a client cannot support the chosen method, since that outcome changes both scope and schedule.
How DeployOpen works on this
DeployOpen scopes, builds and hands over second factors for LDAP and RADIUS clients in authentik as written, fixed-scope work inside your own infrastructure. We map each legacy client to the bind or RADIUS flow it can actually use, then test the code-after-password behavior before anything reaches production users.
How we scope
- Inventory every LDAP and RADIUS client, its bind method, and whether it accepts a password followed by a code
- Confirm which authenticators apply per client, such as Duo, TOTP or static codes, and record SMS as out of scope for RADIUS
- Agree the flow design, policies and user populations in a written scope before any build starts
- Name the owners to confirm vendor behavior for each client, since client-side support varies
How we build
- Design separate LDAP and RADIUS bind flows so the same policies as web logins apply to legacy clients
- Configure the RADIUS provider's semicolon-separated password and code format and test it with each client
- Set throttling and failure handling for code-based attempts on every legacy path before go-live
- Run test accounts through success, wrong-code, lockout and missing-enrollment cases in a non-production instance
How we hand over
- Deliver flow, stage and policy configuration documentation with a per-client MFA behavior record
- Provide a runbook for enrolling users, resetting authenticators and diagnosing failed legacy binds
- Walk your operations team through the test results and the known limits of each client
- Record which items you must confirm with each client vendor and who owns each confirmation
How we support
- Support is available as a retainer for version upgrades, client changes and new LDAP or RADIUS applications
- Re-test affected legacy clients after each authentik upgrade, since bind and RADIUS behavior can change between releases
- Review failed-login alerts and lockout patterns with your team during the retainer period
- Ask for a written quote that lists scope, deliverables, testing and any retainer terms before work begins
