How authentik RADIUS and EAP-TLS authenticate Wi-Fi and wired clients
Network teams that need 802.1X for Wi-Fi or switch ports often want authentik to be the identity source behind the RADIUS server. authentik's RADIUS provider supports EAP-TLS, an Enterprise feature added in the 2025.10 release. The provider runs an authentication flow that begins with a Mutual TLS stage, and the server certificate that the client sees is selected on the provider itself. This makes EAP-TLS a certificate-based method: the supplicant on the device presents a client certificate, and authentik checks it during the flow rather than verifying a typed password. The practical difference matters for rollout. PEAP-style flows carry a username and password inside a TLS tunnel, so the directory password is what the device sends and what users must type or save. EAP-TLS removes that password from the network path and replaces it with a client certificate that each device holds. Your team therefore has to decide who issues those certificates, how they reach managed laptops, phones and any unmanaged devices, and how revocation will work when someone leaves or a device is lost. This page covers the authentik side of that design: the RADIUS provider and its outpost, the EAP-TLS flow with its Mutual TLS stage, the server certificate, and the choice of a private certificate authority instead of a public one. The RADIUS provider documentation warns against using a globally known CA for EAP-TLS and recommends private PKI certificates that the end devices trust. Confirm your Enterprise license scope with authentik before you plan around it, and check the RADIUS provider documentation for the current configuration fields.
What you need before enabling EAP-TLS on authentik
EAP-TLS on authentik depends on four things lining up: the right edition and version, a host that can carry the identity stack, a private certificate authority that your devices trust, and access points or switches that speak RADIUS. Confirm each item before you build the authentication flow, because a gap in any one of them tends to surface only when the first laptop fails to connect.
Enterprise edition and version
EAP-TLS on the RADIUS provider is an Enterprise feature, added in 2025.10, so the Open Source edition will not cover this use case. Check the pricing page against your user count and whether you will have external users, since Enterprise is priced per user with a separate charge for external users. Pick a version from the supported list in the security policy, such as the 2026.5.x or 2026.8.x lines, and plan upgrades within it. Confirm the exact current price with authentik before you budget.
Host sizing for the identity stack
A Docker Compose test or small production setup needs at least the minimum host resources listed in the installation guide, but RADIUS authentication adds load on every Wi-Fi reconnect across the estate. Plan for the server and worker containers and a separately managed PostgreSQL for production, since the Helm chart's bundled database is intended for demonstration and test use. Size against your peak reconnect rate, not your average session count.
Private certificate authority
The RADIUS provider documentation warns against using a globally known certificate authority for EAP-TLS and recommends a private PKI whose root certificate is installed on managed devices. Decide who operates the CA, where the signing key is stored, how client certificates are issued and revoked, and how the server certificate will be renewed before expiry. Without a root the devices trust, clients will reject the RADIUS server during the TLS handshake.
RADIUS-capable network equipment
Confirm that every access point controller or wired switch can act as a RADIUS client using 802.1X, and that it supports EAP-TLS rather than only PEAP or EAP-TTLS. Record the model and firmware of each device, since EAP method support varies by vendor and release. Add the authentik RADIUS endpoint and shared secret to each device, and test with one site before a wider rollout.
Device certificate delivery
Each client needs its own certificate issued by your private CA, along with the root and any intermediate certificates. Decide how this reaches laptops, phones and wired endpoints: through your mobile device management platform, a directory-integrated enrollment process, or a manual step for a pilot group. Plan for replacement when devices are reimaged, replaced or lost, and for revoking certificates when staff leave.
Pilot scope and rollback plan
Choose a small pilot group and a single access point or switch segment to test the mutual TLS stage flow, the server certificate selection and the group mapping before any broad change. Keep the existing Wi-Fi authentication method available until the pilot is stable, and write down how you will revert if clients fail. Record which owner signs off on each step, since a misconfigured certificate chain can lock out many users at once.
Why a private CA is required for EAP-TLS
The authentik RADIUS provider documentation warns against using a globally known certificate authority for EAP-TLS and recommends private PKI certificates that the end device trusts. The reason is practical: in EAP-TLS the client presents a certificate to the network, and any public CA can issue a certificate for a name it does not control or for a device it has never seen. If a public CA were trusted for 802.1X, a certificate from almost any issuer could be presented as a valid client identity. An internal CA limits trust to certificates your organization issued under its own enrollment rules, which is why the CA must be private and the devices must be configured to trust only that CA.
Running an internal CA changes who carries the operational load. Your security or PKI team typically owns the root key, the issuing CAs, the certificate templates, the enrollment method and the decision about how long client certificates live. Those choices are recurring work, not a one-time setup, and they should be designed before the RADIUS outpost is configured. Ask who signs issuing CA certificates, where the root key is stored, whether it is kept offline, and who approves changes to certificate templates. Confirm whether your existing internal PKI can issue client certificates with the extensions your devices need, or whether a new hierarchy is required.
Revocation and compromise deserve explicit decisions. A stolen laptop or a departed employee's device keeps a valid certificate until it is revoked or expires, so you need a revocation method that the RADIUS side can check in your deployment, and short certificate lifetimes reduce the window in which that matters. If the issuing CA is compromised, every client certificate it signed must be treated as untrusted, and devices will need a new trust anchor and new certificates. Check the current revocation options in the authentik RADIUS provider documentation and confirm the CA design, validity periods and compromise response with your security team before rollout.
Configuring the RADIUS provider and EAP-TLS flow in order
This sequence takes you from a running authentik RADIUS outpost to a working EAP-TLS login for 802.1X clients, with a private CA and a check at each step so you know the chain works before devices are touched.
Confirm the RADIUS outpost and Enterprise licensing
Confirm that your authentik deployment runs a version that supports EAP-TLS on the RADIUS provider, which the release notes list as an Enterprise feature added in 2025.10, and that a RADIUS outpost is deployed and shows as connected in the Admin interface. Check the outpost status page before continuing. The step is done when the outpost reports a healthy connection to the authentik server and your license covers Enterprise features. Ask your DeployOpen contact or authentik sales to confirm licensing for your user count before you rely on this design.
Create the mutual TLS stage and authentication flow
Create a Mutual TLS stage in the Admin interface and build an authentication flow whose first stage is that Mutual TLS stage, followed by the stages your policy requires. Bind the flow to the RADIUS provider as its authentication flow. Verify the flow in the flow inspector or with a test login, and confirm the stage order is correct. The step is done when the flow saves cleanly and appears as the authentication flow on the provider, even before any certificates are loaded.
Import the private CA and server certificate
Import your private CA certificate into authentik as a certificate key pair, and import the RADIUS server certificate issued by that CA with its private key. Use a private PKI that your devices already trust, not a globally known public CA, as the RADIUS provider documentation advises. Confirm the certificate chain is complete, the server certificate names match what clients will validate, and the expiry dates are recorded. The step is done when both certificates appear in the certificate list with the expected subject and issuer.
Select the server certificate on the RADIUS provider
Open the RADIUS provider, set its authorization and authentication flows as configured earlier, and select the imported server certificate in the EAP-TLS settings. Save the provider and confirm that the provider shows the certificate as active. This is the point where the outpost presents the server certificate during the TLS handshake. The step is done when the saved provider displays the selected certificate and the outpost picks up the configuration without errors in its logs.
Bind the provider to the application
Create or open the application that represents your Wi-Fi or wired network and attach the RADIUS provider to it. Set the policy bindings so only the intended users or groups are allowed through. Confirm the binding by checking the application's provider field and the policy test tool for a sample user. The step is done when the application lists the RADIUS provider and the policy test returns the expected allow or deny result for a test account.
Configure the access point or switch as a RADIUS client
On each access point controller or switch, register the authentik RADIUS outpost as an authentication server, using the shared secret and the outpost address and ports that authentik shows for the provider. Enable 802.1X authentication on the target SSID or port and set the EAP method to TLS. Confirm the device can reach the outpost on the RADIUS ports from its management and client network. The step is done when the device reports the authentication server as reachable in its own status page.
Verify the EAP handshake with a test client
Connect a test device that already trusts your private CA and holds a client certificate issued by that CA. Attempt an 802.1X connection and watch the outpost logs and the authentik event log for the Mutual TLS stage completing and an access accept. If the handshake fails, check the certificate chain, the client certificate's validity, and the shared secret before retrying. The step is done when the test device connects, the logs show a successful EAP-TLS exchange for that user, and a denied account fails as expected.
Record the configuration and confirm the upgrade path
Document the flow name, stage order, certificate identifiers, provider settings, outpost version and the access point or switch configuration, so the setup can be rebuilt and audited. Check the authentik release and upgrade notes for the outpost and provider before any version change, and plan a test client verification after each upgrade. The step is done when the configuration record is stored with your change records and a post-upgrade test is written down as a required check.
Certificate fields and identity attributes mapped to network access
This table compares each identity element in an EAP-TLS 802.1X flow, from the client certificate fields that identify the user to the CA chain and group attributes that decide network placement. Read each row as a check to run before pilot: the certificate must name the account authentik will match, the chain must be trusted by devices, and group-based attributes must be confirmed against the RADIUS provider documentation for your authentik version.
| Element | What it controls | Decision or check | Where it usually fails |
|---|---|---|---|
| Certificate subject or SAN | Which field carries the identity the flow uses to match an authentik user | Pick one field, such as a UPN-style SAN or a common name, and confirm the exact matching behavior in the RADIUS provider documentation for your version | Certificates issued with a field the flow does not read, so every login is rejected as an unknown user |
| User account in authentik | The directory object whose status, groups and attributes apply to the session | Confirm the certificate identifier matches the username or attribute exactly, including case and domain suffix | Renamed or duplicated accounts after a directory sync leave certificates pointing at a stale identity |
| Issuing CA chain | Which issuers the RADIUS server accepts when validating the client certificate | Use a private PKI root and intermediates that devices already trust, and confirm the chain is complete on the authentik side | Missing intermediates or an expired intermediate cause intermittent failures that look like random client errors |
| Server certificate on the provider | What the supplicant validates when it connects to the RADIUS endpoint | Issue from the same private PKI, with a name the devices are configured to check | Clients configured for the wrong server name, or a public CA certificate that devices cannot pin consistently |
| authentik group membership | The basis for choosing a VLAN or access attribute for the session | Map each network segment to one group and confirm the attribute form the RADIUS provider returns for your version | Users in several groups receive conflicting attributes, and the switch or controller applies the wrong VLAN |
| VLAN or access attribute on the network device | The segment, role or ACL the switch or Wi-Fi controller enforces after authentication | Agree the attribute values with the network team and test each one with a sample user before rollout | Attribute names or values that differ between the RADIUS reply and the device configuration |
| Certificate lifetime and renewal | How long a device keeps working access after a user leaves or changes role | Decide revocation and renewal rules with the PKI owner, and confirm what the RADIUS flow checks at each login | Certificates remain valid after offboarding because revocation is not checked by the deployed flow |
Getting client certificates and CA trust onto devices
Every laptop, phone and wired client that authenticates with EAP-TLS needs two things before the first connection: the private CA certificate, so the device trusts the RADIUS server, and a unique client certificate issued from that CA, so the RADIUS server trusts the device. Neither is handled by authentik. The practical question is which channel delivers them. Confirm which MDM platform, directory tooling and certificate enrollment method your estate already runs, because the choice determines how much of the rollout you can automate. Managed Apple and Windows fleets usually take certificates through a configuration profile or Group Policy-driven auto-enrollment from the internal CA, while unmanaged or BYOD devices often need a self-service enrollment step. Ask any partner to map each device class to one delivery path before scoping the work.
Certificate lifetime and renewal need the same attention as the initial rollout. Set the validity period of client certificates in your private PKI policy, then confirm that renewal happens automatically before expiry on each device class. A certificate that expires silently will lock users out of Wi-Fi and wired access at the same moment, and the failure often looks like a network fault rather than an authentication fault. Plan a renewal window and test it on a pilot group. Also confirm how the CA certificate itself will be replaced, since every device must trust the new issuer before the old one is retired.
Revocation and rollback are where fleet rollouts most often go wrong. When a device is lost or an employee leaves, you need a path to revoke that device's certificate and confirm that the RADIUS server rejects it, which depends on whether your PKI publishes a revocation list or an OCSP responder that the server can reach. If a certificate profile is wrong and pushed to the whole fleet, rollback means removing the profile, reissuing certificates and reconfiguring trust on affected devices, which can take days on a large estate. Ask for a documented rollback procedure, a staged deployment plan that starts with a small ring of devices, and a list of which steps the MDM or directory team must perform themselves.
Hardening the RADIUS path and the private CA
EAP-TLS ties network access to the private certificate authority and the RADIUS path that carries authentication decisions. The cards below cover what to protect on the CA side, how the RADIUS client and flow are secured, and how to keep the platform patched while you run it.
Protect the CA private key
The CA private key decides which devices the network trusts. Keep it offline or in a hardware-backed store, and issue device and server certificates from a subordinate CA where possible. Ask your team who can sign client certificates, how issuance is logged, and how a compromised key would be revoked and replaced across every access point and switch.
Use per-client RADIUS secrets
Each access point, switch or controller that sends RADIUS requests needs its own strong shared secret. Generate long random values, store them in your secrets manager, and rotate them on a schedule. Shared secrets reused across sites let one compromised device impersonate every client that trusts the same secret.
Restrict flow and provider changes
Whoever can edit the RADIUS provider, the EAP-TLS flow or the Mutual TLS stage can change who gets network access. Limit those permissions to a small admin group, require change review for certificate and flow edits, and check the audit trail after each change. Confirm that your admin roles separate network configuration from user management.
Encrypt the path to the outpost
Traffic between your access points, the RADIUS outpost and the authentik server crosses your network, so protect it. Confirm how the outpost connects to the core service, keep it on a segment that only network infrastructure can reach, and check which RADIUS transport your switches and controllers support before relying on it.
Turn on enhanced audit logging
Enhanced audit logging is listed as an Enterprise feature, and EAP-TLS already requires Enterprise. Enable it, forward the events to your log platform, and test that authentication failures and configuration changes are recorded with enough detail to investigate a rejected device or a changed flow.
Stay on a supported version
Only the release lines named in the security policy receive security fixes, and security releases are announced at least 24 hours in advance. Subscribe to the release feed, schedule a test upgrade on a staging instance, and include outpost versions in each upgrade plan so the RADIUS path stays patched.
Why EAP-TLS handshakes fail and how to fix them
This table lists the failures that most often stop an EAP-TLS handshake in authentik's RADIUS outpost, with the cause and fix for each. Work down the rows in order when a client cannot connect, since the server certificate, trust chain and flow design are checked before the device and switch settings. Most failures trace back to the provider configuration or the device trust store rather than to the network.
| Failure | Cause | Fix |
|---|---|---|
| Wrong server certificate | The RADIUS provider has a certificate selected that is not the one the devices expect, or it was replaced without updating the provider. | Select the intended server certificate on the RADIUS provider, then confirm the certificate subject matches the name clients validate. |
| Device does not trust the CA | The private CA certificate is missing from the client's trust store, or the profile points at a public CA instead. | Push the private CA certificate to devices through MDM or group policy and set the profile to validate the server certificate against it. |
| Public CA used for EAP-TLS | The server certificate or trust anchor comes from a globally known CA, which authentik's documentation advises against for this use. | Issue the RADIUS server certificate and client certificates from a private PKI that only your organization's devices trust. |
| Expired or revoked client certificate | The device certificate has passed its validity period, or it was revoked while the device still holds it. | Check the certificate validity dates and revocation status, then reissue and redeploy the certificate. Confirm the revocation process removes network access for lost devices. |
| Flow does not start with Mutual TLS stage | The authentication flow bound to the RADIUS provider lacks a Mutual TLS stage first, so the client certificate is never requested. | Build or correct the flow so the Mutual TLS stage runs before any other stage, then bind it to the provider. |
| RADIUS shared secret mismatch | The secret on the authentik provider differs from the secret configured on the access point or switch, so requests are rejected. | Set the same shared secret on both sides, re-enter it rather than copying from notes, and check the switch or controller logs for rejected requests. |
| Client or switch not set for EAP-TLS | The supplicant uses PEAP or another method, or the switch port is not configured for 802.1X with the RADIUS server address and port. | Set the device profile to EAP-TLS, point the switch or controller at the authentik outpost, and test one port or SSID before wider rollout. |
Questions buyers ask about authentik EAP-TLS
Does EAP-TLS with authentik require the Enterprise edition?
Yes. The authentik pricing page lists EAP-TLS support on the RADIUS provider as an Enterprise feature, and the feature was added in the 2025.10 release. The Open Source edition is free but does not include it, so a Wi-Fi or wired 802.1X design that uses certificate-based client authentication needs an Enterprise subscription. Check the current edition table on the authentik pricing page before you fix the budget, because editions and per-user terms can change. Your licensing cost is separate from any implementation fee, and the implementation fee follows from the written scope.
Can we use a public certificate authority for EAP-TLS?
Plan for a private certificate authority. The authentik RADIUS provider documentation warns against using a globally known CA for EAP-TLS and recommends private PKI certificates that the end devices trust. The reason is practical: a publicly trusted CA can issue certificates to anyone, so a device certificate chain that a public CA can satisfy is a weak basis for access control. Confirm with your security team which internal CA will issue client certificates, how its root is distributed to devices, and who can revoke a lost device's certificate.
What drives the effort of an EAP-TLS rollout?
Four factors shape most of the effort:
- Maturity of your existing PKI: whether you already run an internal CA with templates, revocation and an enrollment process, or whether one must be built.
- Device count and types: laptops, phones, printers and shared devices each need a different enrollment path.
- Network footprint: the number of access points, switches and controllers that must be configured to point at the RADIUS service.
- MDM: whether devices can receive certificates and trust anchors automatically, or whether users must install them by hand.
Each factor changes the test matrix and the rollout plan, so the scope should list them explicitly.
How long does an EAP-TLS implementation take?
The duration depends on the written scope, and no fixed figure applies to every organization. A scope that covers one SSID with a mature internal CA and managed laptops takes far less time than one that adds a new CA, several device platforms, and wired switching. Ask for a timeline tied to named deliverables: the RADIUS and flow configuration, the CA and certificate templates, a pilot group, and the staged rollout. Ask the partner to state which assumptions the timeline depends on, such as access to your network team and change windows.
What do we need to provide before the engagement starts?
Prepare access and decisions before work begins. Typical inputs include:
- A working authentik deployment on infrastructure you control, with an Enterprise subscription if EAP-TLS is in scope.
- Details of your wireless controller and switches, including vendor, model and firmware, and their RADIUS configuration options.
- Your PKI documentation, or a decision on a new private CA, along with the policy for certificate lifetime and revocation.
- A device inventory and MDM access if you plan automated certificate delivery.
- A named owner for the network team, the identity team and the pilot group, plus change windows for access point and switch changes.
The written scope should record these inputs and who supplies each one.
Can our internal team implement EAP-TLS without a partner?
Yes, if the team has the skills and time. The work spans identity configuration in authentik, a private PKI, network device RADIUS settings, device enrollment and testing, so the skills are split across several groups. A team that already runs an internal CA and manages devices through MDM has a shorter path. A team without that experience should weigh the cost of learning on a production network against a fixed-scope engagement. DeployOpen plans, implements, documents and supports this work inside your infrastructure, and the choice depends on your internal capacity.
What breaks most often when certificates roll out to devices?
Most failures come from trust and timing rather than the RADIUS flow itself. Common problems include a missing trust anchor on some devices, certificates issued without the client authentication usage, expired or unrevoked certificates, and clients that do not present the expected identity. Test each device platform against the pilot group before the rollout, and confirm how revocation reaches the RADIUS path. Keep a documented fallback for users who lose access during the change, and check the authentik release notes before each upgrade, since the RADIUS provider behavior can change between versions.
Does EAP-TLS support multi-factor authentication?
EAP-TLS authenticates the device with a certificate, so the second factor is the possession of a private key on a managed device rather than a one-time code typed by a user. Whether any additional checks apply depends on the flow design and the protocol, which you should confirm against the authentik RADIUS provider documentation before you promise a control to an auditor. Your compliance mapping should describe exactly which checks run during authentication, so reviewers understand what the design proves.
How DeployOpen scopes an authentik 802.1X engagement
Scope, deliverables and timelines for a DeployOpen engagement are agreed in writing before work starts, so the boundary between your team and ours is fixed on paper before any certificate is issued. For an authentik 802.1X engagement, the written scope normally names the components in play: the RADIUS outpost and its deployment target, the authentication flow that begins with a Mutual TLS stage, the server certificate selected on the RADIUS provider, the private PKI integration, the switch or wireless controller RADIUS configuration, a device rollout method for client certificates, and a test plan covering both wired and wireless clients. Each of these should appear as a named deliverable with an acceptance check, such as a successful EAP-TLS session from a test device on each access point model or switch port profile in use.
What stays with your organization is usually the parts that depend on your own authority and infrastructure: the private CA's root and issuing keys, the policy for who may hold a certificate and for how long, the network hardware and its management access, and the directory groups that authentik maps to VLANs or network roles. Ask for a written list of these client-side responsibilities in the scope, with an owner named for each. Confirm the authentik edition you need before scoping, because the RADIUS provider's EAP-TLS support is listed as an Enterprise feature, and the pricing page is the place to check current terms with the vendor.
DeployOpen prepares systems, configuration, test records and evidence that your organization can hand to an assessor for compliance purposes, such as access control and authentication evidence for network access. DeployOpen does not issue audit reports, attestations or certifications; independent auditors and certification bodies perform those assessments. Ask the scope to state which evidence artifacts will be delivered, in what format, and who is responsible for presenting them to the assessor.
How DeployOpen works on this
DeployOpen plans, implements, documents and supports self-hosted authentik inside your own infrastructure, including the RADIUS outpost, private PKI and EAP-TLS flow for Wi-Fi and wired 802.1X clients. Engagements start with a written scope so that edition requirements, certificate ownership and device rollout are agreed before any configuration begins.
How we scope
- Confirm the authentik edition needed, since EAP-TLS on the RADIUS provider is an Enterprise feature.
- Map which access points, switches, controllers and client platforms will authenticate over 802.1X.
- Agree in writing who owns the private CA, its key storage and the device certificate lifecycle.
How we build
- Deploy the authentik server, worker and PostgreSQL components in your environment, with the RADIUS outpost placed where your network devices can reach it.
- Build the EAP-TLS authentication flow with a Mutual TLS stage and select the server certificate issued by your private PKI.
- Test with pilot devices across each client platform before any group is moved to certificate-based access.
How we hand over
- Deliver configuration records, the flow and provider settings, and the certificate issuance and revocation procedure.
- Document the device certificate rollout method for each platform, with steps your help desk can repeat.
- Walk your network and identity teams through verification results, known limits and the upgrade path for authentik.
How we support
- Support is available as a retainer for monitoring, certificate renewals, authentik upgrades and access point changes.
- Plan authentik version upgrades around the supported release lines named in the security policy, with notice of security releases.
- Review RADIUS logs and authentication failures with your team when a rollout or a certificate change causes connection problems.
