Support Library

Certificate-Based Network Authentication

Certificate-based authentication lets a device prove its identity with a private key and an X.509 certificate signed by a certificate authority you trust. On networks it is usually done with EAP-TLS, where the device and the RADIUS server each check the other's certificate before the device is let in.

Author
CategoryZero Trust & Network Access
Length9 minute read
UpdatedOctober 24, 2026

The short answer

A password is a secret the user knows and can be tricked into typing somewhere else. A certificate is different: the secret is a private key that never leaves the device, and the certificate is a public statement, signed by your certificate authority (CA), that this key belongs to this device or user. To authenticate, the device proves it holds the key by signing part of a TLS handshake. Nothing that crosses the network can be replayed to log in again.

  • For Wi-Fi and wired ports the method is EAP-TLS, run inside 802.1X.
  • For VPN and ZTNA a device certificate is often required alongside the user's sign-in, so a stolen password alone does not get in.
  • For service-to-service traffic the same idea is called mutual TLS (mTLS).
Mutual means both sides check.

The server proves itself to the device as well. That stops a fake access point from impersonating your network, which is the main weakness of password methods whose server check is skipped or misconfigured.

What a certificate says

Network certificates follow the X.509 profile in RFC 5280. The fields that matter for authentication are:

FieldExampleWhy it matters
Subject and Subject Alternative Namelaptop-0423.corp.example.com or a user principal nameThe identity the server maps to an account and policy
IssuerExample Issuing CA 1Which CA signed it; the chain must lead to a root the other side trusts
ValidityNot before / not after datesExpired or not-yet-valid certificates fail, which is why device clocks matter
Extended key usageClient Authentication or Server AuthenticationA device certificate needs Client Authentication; the RADIUS server's needs Server Authentication
Public keyRSA 2048-bit or an ECDSA P-256 keyMatches the private key the holder uses to sign

How EAP-TLS checks both sides

EAP-TLS, defined in RFC 5216 and updated for TLS 1.3 in RFC 9190, runs a normal TLS handshake inside EAP. The only unusual part is that the server always asks for a client certificate.

Mutual certificate authentication with EAP-TLS An enterprise certificate authority issues a device certificate, through MDM, SCEP or EST, and a server certificate for the RADIUS server. A revocation service, a CRL or OCSP responder, is available to the server. In the handshake the server sends its certificate first, then the device sends its certificate and signs the handshake with its private key, which is kept in a TPM and cannot be exported. The device checks that the server's chain leads to the trusted root, that the name matches the expected server and that the certificate is in date. The server checks the device's chain, that the certificate is not revoked, that the device proved it holds the private key, and that the identity maps to an account and policy. If both pass, the server sends Access-Accept. Private CA Enterprise certificate authority Offline root, online issuing CA Revocation status CRL or OCSP responder, published by the CA Issues device certificate via MDM, SCEP or EST Issues server certificate Device CN=laptop-0423 Private key in the TPM, cannot be exported Trusts: Example Root CA RADIUS server CN=radius.example.com Private key stays on the server Trusts: Example Root CA 1 Server certificate 2 Client certificate plus a signature made with the private key The device checks the server Chain leads to the trusted root CA Name matches the configured server name Certificate is within its validity dates No prompt to trust an unknown server The server checks the device Chain leads to the trusted issuing CA Not revoked, by CRL or OCSP Signature proves it holds the private key Identity maps to an account and policy Both pass: Access-Accept Mutual certificate authentication with EAP-TLS An enterprise certificate authority issues certificates to the device and the RADIUS server. The server sends its certificate, then the device sends its certificate and signs with its private key, which stays in the TPM. The device checks the server's chain, name and dates. The server checks the device's chain, revocation status, proof of the private key and account mapping. If both pass, the server sends Access-Accept. Private CA Enterprise CA Issues device and server certificates Device CN=laptop-0423 Key in the TPM, cannot be exported RADIUS server CN=radius… Trusts the same root CA The handshake 1 Server sends its certificate 2 Device sends its certificate and signs with its private key The device checks the server Chain leads to the trusted root CA Name matches the configured server Certificate is within its dates The server checks the device Chain leads to the trusted issuing CA Not revoked, by CRL or OCSP Signature proves it holds the key Identity maps to an account and policy Both pass: Access-Accept
This example uses one private CA. EAP-TLS only requires each side to validate the other’s chain and expected identity under its configured trust policy; the two chains can use different CAs. The device's private key is used to sign, but never leaves the device, so there is nothing on the wire to replay.

If any check fails, the handshake stops and the server sends Access-Reject. Because the server certificate is checked against a CA and name that were configured in advance, a rogue access point cannot simply present its own certificate and wait for the user to click "connect".

Why certificates beat passwords and MAC addresses

PropertyPassword (PEAP)MAC address (MAB)Certificate (EAP-TLS)
Can be phished or typed into a fake networkYes, if the server check is weakNot needed: it is broadcast in every frameNo; the private key is never sent
Can be copied to another deviceYesYes, trivially spoofedNot if the key is in a TPM or secure enclave
Identifies the device, not just the userNoWeaklyWith a machine certificate; a user certificate identifies the user. Hardware binding and device health require additional controls
Can be revoked for one deviceOnly by changing the user's passwordBy removing it from a listYes, through the CA
Works for devices with no user signed inOnly with a machine accountYesYes, with a machine certificate

The trade-off is operational: certificates need a CA, a way to enroll every device, renewal before expiry and a working revocation service. That is why MAC Authentication Bypass is still used for devices that cannot hold a certificate.

Building the PKI

Network authentication certificates should come from a private CA that you control, not a public web CA. Public CAs are moving their TLS hierarchies to server authentication only under browser root program rules, and most vendor notices now give 2027 as the date by which new public TLS certificates stop carrying the Client Authentication usage. A private CA also lets you choose the names, lifetimes and policies that suit your devices.

  • Two tiers at least. Keep the root CA offline and use it only to sign one or more issuing CAs, which sign device, user and server certificates. If an issuing CA is compromised, you revoke it without replacing the root on every device.
  • Separate templates. Use distinct certificate profiles for machines, users and RADIUS servers, each with only the key usages it needs.
  • Distribute trust deliberately. Push the root certificate, and the expected RADIUS server name, to every device in its network profile.

Getting certificates onto devices

Issuing certificates by hand does not scale. These protocols automate it:

ProtocolDefined inCommon use
SCEPRFC 8894The most widely supported by MDM platforms for phones, tablets and laptops; authenticates enrollment with a shared challenge
ESTRFC 7030A newer HTTPS-based alternative with better authentication of the enrolling device
ACMERFC 8555Built for public web certificates; extensions for device attestation are being developed for private use
Directory auto-enrollmentVendor-specificDomain-joined Windows machines and users requesting certificates from Active Directory Certificate Services

In practice most organizations let their device management platform do the work: it creates the key on the device, requests the certificate over SCEP or a vendor connector, installs the Wi-Fi or VPN profile that uses it, and renews it before it expires.

Protecting the private key

A certificate is only as strong as the protection on its private key. If the key is stored as an exportable file, malware or an administrator can copy it to another machine, and the network will accept that machine as the original.

  • Use hardware-backed keys. A TPM 2.0 on Windows and Linux PCs, or the Secure Enclave on Apple devices, can generate the key and sign with it without ever exposing it.
  • Mark keys non-exportable in the certificate profile.
  • Prefer attestation where available. Some platforms can prove to the CA that the key was created in hardware on a specific device before a certificate is issued.

Machine and user certificates

A machine certificate belongs to the device. It lets the device join the network before anyone signs in, which is needed for device management, software updates and the sign-in itself. A user certificate belongs to the person and moves with their account. Many networks use machine authentication at the login screen and user authentication afterwards, or use TEAP, defined in RFC 9930, to chain both into one session so policy can require a managed device and an authorized user at the same time.

On the server side, the certificate has to be mapped to an account. On Windows networks that use Microsoft's Network Policy Server, domain controllers now enforce strong certificate mapping, described in Microsoft KB5014754: certificates must carry the account's security identifier or be explicitly mapped, or authentication is denied.

Revocation and renewal

When a laptop is lost or an employee leaves, revoke the certificate. The RADIUS server then has to find out, either by downloading the CA's certificate revocation list (CRL, RFC 5280) or by asking an OCSP responder (RFC 6960). Two practical points follow:

  • Keep revocation reachable. If the RADIUS server cannot fetch a fresh CRL, it may reject every device or, if set to fail open, accept revoked ones. Monitor CRL expiry like any other critical service.
  • Automate renewal. An expired certificate looks exactly like an attack from the network's point of view. Renew well before expiry, and alert on certificates that are close to it.

Common failures

SymptomLikely cause
Device rejects the serverThe root CA is missing from the device, the server name does not match the profile, or the server sends no intermediate certificate
Server rejects the device as "unknown CA"The issuing CA is not in the server's trusted list, or the device chose the wrong certificate
Fails only on new or rebuilt devicesEnrollment has not finished, or the device clock is wrong so the certificate is not yet valid
Every device fails at onceThe CRL expired or cannot be downloaded, or the RADIUS server's own certificate expired
Works before sign-in, fails afterThe machine certificate is valid but the user certificate is missing, or the profile switches to user authentication

FAQ

What is the difference between EAP-TLS and PEAP?

EAP-TLS authenticates the server and a client identity with certificates, without a password. PEAP protects an inner EAP method with a server-authenticated TLS tunnel. Common PEAP-MS-CHAPv2 exchanges a username and password-derived challenge-response material, not the literal password. A rogue server can capture and attack that material if clients do not strictly validate its certificate and expected name.

Can I use certificates from a public CA for Wi-Fi authentication?

It is not recommended. Public TLS certificates are being restricted to server authentication, you cannot control what a public CA issues for your names, and devices would trust any certificate from that public CA. A private CA for client certificates and a dedicated server certificate for RADIUS is the usual design.

Can a device certificate be stolen?

If the private key is stored in a file and marked exportable, yes, and the thief can authenticate as that device. Keys generated inside a TPM or Secure Enclave and marked non-exportable cannot be copied, which is why hardware-backed keys are recommended.

What happens when a certificate expires?

Authentication fails exactly as it would for an unknown device. Device management platforms renew certificates automatically before they expire, and monitoring for certificates close to expiry, including the RADIUS server certificate, prevents surprise outages.

Sources and further reading

Related support articles

802.1X ExplainedRADIUS ExplainedZero Trust Networking ExplainedMAC Authentication Bypass (MAB)Certificate Transparency for DNS DiscoveryDANE for HTTPS