Key Points
- Certificate-based RADIUS authentication (via EAP-TLS) eliminates password theft but still relies on a certificate that was valid at the time of issuance — not necessarily at the time of connection.
- Real-time identity lookup queries the identity provider during every authentication event to confirm user status, group membership, and device compliance.
- Combining both layers — certificate validation plus live IdP check — closes the gap that static certificates and password-based RADIUS each leave open.
Most organizations deploying 802.1X authentication know the goal: replace passwords with certificates, use EAP-TLS, and stop worrying about credential theft. That part of the story is well understood. What gets less attention is what happens after the certificate is issued.
A certificate proves that a device was trusted at the time of enrollment. It does not prove that the user is still active in Okta, that the device is still managed in Intune, or that the employee still works at the company. That gap between issuance and authentication is where the real risk lives.
This post walks through how RADIUS authentication works in a certificate-based model, where the trust gaps appear, and how real-time identity lookup addresses them.
What Is RADIUS Authentication?
RADIUS (Remote Authentication Dial-In User Service) is an authentication, authorization, and accounting (AAA) protocol that governs network access. Originally defined by the Internet Engineering Task Force (IETF) in RFC 2865 in the early 2000s (with roots in 1990s dial-up networking), RADIUS has evolved into the standard protocol for controlling who gets onto enterprise Wi-Fi, VPN, and wired networks.
When a device connects to a network protected by 802.1X, the access point or switch forwards the authentication request to a RADIUS server. The RADIUS server validates the device’s credentials — a password or a digital certificate — against an identity source and returns an access decision. It also handles authorization (what the device can access) and accounting (logging the connection event).
RADIUS communicates over UDP ports 1812 (authentication) and 1813 (accounting), with legacy deployments sometimes using ports 1645 and 1646. The protocol uses four core packet types:
- Access-Request: Sent by the network device to the RADIUS server with the user’s credentials
- Access-Accept: The RADIUS server approves the connection
- Access-Reject: The RADIUS server denies the connection
- Access-Challenge: The RADIUS server requests additional information (used during EAP exchanges)
How RADIUS Authentication Works with Certificates
Traditional RADIUS authentication uses passwords. A user connects to the network, the access point forwards their credentials to a RADIUS server, and the server checks those credentials against a directory. This is the PEAP-MSCHAPv2 model that most IT teams know, and it carries all the risks of any password-based system: phishing, credential stuffing, over-the-air interception.
EAP-TLS authentication replaces the password exchange with a certificate handshake. The client presents a digital certificate, the RADIUS server validates it against a trusted certificate authority, and if the certificate is valid and not revoked, the server allows the connection. No password crosses the wire.
The EAP-TLS flow looks like this:
- Client associates with the network: The device connects to an SSID or wired port configured for 802.1X.
- RADIUS challenge: The access point forwards the authentication request to the RADIUS server.
- Certificate exchange: The client and server exchange certificates to establish mutual trust.
- Certificate validation: The RADIUS server verifies the client certificate against the issuing CA, checks expiration, and reviews the certificate revocation list (CRL).
- Access granted: If the certificate passes all checks, the RADIUS server returns an Access-Accept to the access point.
This flow eliminates the password entirely, but the trust decision is still based on information that was baked into the certificate when it was issued.
EAP Methods Comparison for RADIUS Authentication
The EAP method determines the security profile of your RADIUS authentication deployment. Here is how the common options stack up:
| EAP Method | Authentication Factor | Credential Risk | Cloud IdP Compatible |
| EAP-TLS | X.509 certificate | None — private key never transmitted | Yes |
| PEAP-MSCHAPv2 | Username/password (hashed) | Hash vulnerable to offline cracking | Limited — requires NTLM support |
| EAP-TTLS/PAP | Username/password (plaintext in tunnel) | Depends on tunnel integrity | Yes — works with cloud IdPs |
| EAP-FAST | Password or certificate | Moderate — PAC provisioning adds risk | Vendor-specific |
EAP-TLS is the only method that removes credentials from the authentication flow entirely. For organizations that have already moved identity to the cloud (Okta, Entra ID, Google Workspace), EAP-TLS also avoids the protocol incompatibilities that make PEAP-MSCHAPv2 difficult with cloud identity providers.
The Problem with Static Certificate Trust
When a certificate is issued, it encodes a snapshot of the user’s identity: their name, email, device identifier, and organizational unit. That snapshot might be accurate for months. Or it might become stale within hours.
Consider these scenarios:
- Employee termination: A user is disabled in Okta on Friday. Their certificate does not expire until next quarter. Without a revocation event, the certificate is still technically valid.
- Device falls out of compliance: A laptop that was compliant when the certificate was enrolled has not checked in with Intune in 30 days. The certificate says nothing about current device posture.
- Role change: A user moves from Engineering to Marketing. Their certificate still carries the Engineering OU attribute, and the RADIUS server may still assign them to the Engineering VLAN.
- Compromised device: An endpoint security tool flags a device as compromised in CrowdStrike. The certificate on that device is unaffected.
Certificate revocation lists (CRLs) and the Online Certificate Status Protocol (OCSP) were designed to handle some of these cases. In practice, CRL propagation can lag by hours, and many environments do not check OCSP on every authentication. That creates a window where a revoked or outdated certificate can still grant access.
What Real-Time Identity Lookup Adds
Real-time identity lookup is a second verification layer that runs during every RADIUS authentication, after the certificate is validated. Instead of stopping at “is the certificate valid,” the RADIUS server takes an additional step: it queries the identity provider to check the current status of the user or device associated with that certificate.
Here is how the expanded flow works with JoinNow Cloud RADIUS:
- Certificate validation (via EAP-TLS): Cloud RADIUS verifies the client certificate the same way any RADIUS server would — CA trust chain, expiration, revocation status.
- Identity extraction: Cloud RADIUS reads identity attributes from the certificate (e.g., user principal name, device ID, email).
- Live directory query: Using those attributes, Cloud RADIUS queries the identity provider — Okta, Entra ID, Google Workspace, or another supported IdP — to confirm the user’s current status.
- Policy evaluation: Cloud RADIUS checks group membership, account status (active, suspended, deprovisioned), and device compliance signals from Intune, Jamf, or other MDM platforms.
- Access decision: The final accept/reject decision factors in both the certificate validity and the live directory response.
This is what makes the model different from standard EAP-TLS. The certificate gets the device in the door. The identity lookup confirms whether it should still be there.
Why This Matters for Okta Environments
Organizations running Okta as their primary IdP often discover a gap when they move to certificate-based 802.1X. Okta handles user lifecycle management, group membership, and application access policies. But the RADIUS server handling Wi-Fi and VPN authentication might not be connected to Okta at all.
This disconnect means that disabling a user in Okta does not automatically revoke their network access. IT has to separately revoke the certificate, update the CRL, and wait for propagation. In many organizations, that process is manual and delayed.
Cloud RADIUS eliminates this gap by querying Okta directly during authentication. When a user is deactivated in Okta, the next time their device attempts to authenticate, Cloud RADIUS sees the status change and denies access. It does not need a separate revocation workflow.
The same applies to device management. If an organization uses Jamf, Intune, Google, Kandji, or another MDM alongside Okta, Cloud RADIUS can check device compliance status in addition to user identity. A device that has been unenrolled from MDM or flagged as noncompliant gets denied at the network edge, even if its certificate is technically still valid.
Cloud RADIUS vs. On-Premises RADIUS for Identity Lookup
On-prem RADIUS servers like Microsoft NPS were not designed for cloud identity providers. Connecting NPS to Okta requires LDAP proxying, custom plugins, or third-party middleware. Most organizations that attempt this end up with a fragile integration that breaks during IdP updates and does not support real-time attribute checks.
| Capability | On-Prem NPS | Cloud RADIUS |
| Native Okta integration | No (requires LDAP proxy or middleware) | Yes (direct API integration) |
| Real-time identity lookup | No | Yes, on every authentication |
| Device compliance check (MDM) | No | Yes (Intune, Jamf, Google, Kandji) |
| Uptime SLA | Self-managed, varies | Up to 99.999% managed availability |
| Certificate lifecycle management | Separate PKI required | Integrated with Dynamic PKI |
| Infrastructure required | Physical or virtual server, AD dependency | None – fully cloud-hosted |
For organizations that have already moved their identity stack to the cloud, keeping the RADIUS server on-prem creates a gap in the authentication chain that cloud-native alternatives close.
How Cloud RADIUS Identity Lookup Works in Practice
A typical deployment follows this pattern:
- Certificate enrollment: Managed devices receive certificates automatically through Intune, Jamf, or another MDM using SecureW2 enrollment gateways. BYOD users self-enroll through JoinNow MultiOS, which walks them through certificate installation via a branded portal tied to the organization’s Okta SSO.
- Network configuration: Access points are configured for 802.1X with EAP-TLS and pointed at Cloud RADIUS. There are no on-prem servers to deploy.
- Authentication flow: When a device connects, Cloud RADIUS validates the certificate, extracts the user identity, queries Okta for current status and group membership, optionally checks the MDM for device compliance, and returns the access decision to the AP — including VLAN assignment if applicable.
- Lifecycle enforcement: When a user is deprovisioned in Okta, their next authentication attempt is denied with no need for manual certificate revocation. When a device falls out of MDM compliance, access is restricted automatically.
The entire chain, from certificate issuance to real-time access decisions, runs without on-prem infrastructure. And because Cloud RADIUS is a fully managed service with 99.999% availability, the authentication layer itself is not a single point of failure.
Move to Real-Time Identity-Based RADIUS Authentication
Password-based RADIUS authentication is a known liability. But certificate-based RADIUS without identity lookup is only half the fix. The certificate proves device identity at issuance. The identity lookup proves user and device status at connection time. Both layers working together is what continuous trust looks like at the network edge.
JoinNow Cloud RADIUS integrates with Okta, Entra ID, Google Workspace, and other IdPs to perform real-time identity validation on every authentication. Paired with JoinNow Dynamic PKI for automated certificate lifecycle management, it replaces the patchwork of on-prem servers, LDAP proxies, and manual revocation workflows. For more on the Okta-specific setup, see the RADIUS authentication with Okta guide.
Schedule a demo to see how Cloud RADIUS with real-time identity lookup works with your Okta environment.
