What Is Device Identity? Certificates, PKI and 802.1X

Most security teams have strong user identity controls. Multi-factor authentication, single sign-on and identity providers (IdPs) are standard. But device identity gets far less attention than it should. A device connecting to your network is not the same as the user sitting in front of it. A laptop with valid employee credentials can be stolen or compromised. Device identity answers a different question than user identity: not “who is this person?” but “is this machine authorized to be here?”

What Is Device Identity?

Device identity is a cryptographically verifiable representation of a specific machine. It allows a network, application or service to confirm that a connection is coming from a known, trusted device, not just a trusted user on an unknown machine. Every endpoint, server, mobile device and Internet of Things (IoT) sensor on a corporate network can have a device identity. In practice, many organizations manage user identity carefully and manage device identity poorly, relying on MAC addresses or endpoint agents rather than cryptographic proof. Device identity is distinct from device management. A mobile device management (MDM) system like Microsoft Intune or Jamf manages configuration, including software policies, OS updates, and compliance posture. It tells you what a device is doing. Device identity tells you what a device is. Specifically, whether it holds a credential that only the legitimate device should possess. An MDM can inform device identity by pushing certificates during enrollment, but device management and identity verification are different functions.

The most reliable form of device identity is a credential that is:

• Unique to the device: No two machines share the same credential.
• Cryptographically verifiable: The verifying party can confirm authenticity without a central broker.
• Bound to the device: It’s not exportable to another machine and ideally backed by hardware.
• Revocable: When a device is decommissioned or compromised, access can be cut immediately.

X.509 digital certificates satisfy all four properties when issued and managed correctly. That’s why certificate-based device authentication is the standard approach in enterprise environments that take device identity seriously.

Device Identity vs. User Identity: Two Different Trust Decisions

User identity and device identity serve different purposes, but they are equally important to network security and management. Here’s how they differ:

User identity validates the person making the authentication request. Credentials such as a username and password, an MFA token or a hardware security key prove that a specific person is attempting to access a resource. Identity providers like Entra ID, Okta and Google Workspace manage user identity at scale.

Device identity validates the machine making the connection. A device certificate, a TPM-attested key or a hardware identifier proves that a specific machine is attempting to connect, independent of who is using it at that moment.

Why Both Matter

A device with valid user credentials is not automatically trustworthy. A corporate laptop taken home by a former employee, a personal device with saved credentials or a machine compromised by malware can all carry a valid user identity while failing device-level trust checks. User identity secures who gets in. Device identity secures whatmachines get in. A network access policy that checks one or the other will have gaps. Most breaches that rely on credential theft succeed because the target environment enforces user identity but not device identity. A phished password gets an attacker past user authentication. A certificate bound to a specific enrolled device stops the same attacker at the network connection.

How Device Identity Is Established: Four Methods Compared

Not all device identities are equally strong. There’s a significant gap between knowing the device’s MAC address and holding a certificate that only the device’s Trusted Platform Module (TPM) can sign for. Understanding that gap is important when selecting device identity practices.

MAC Address Identification

A MAC address is a unique hardware identifier assigned to a network interface. MAC address authentication (known as MAB, or MAC Authentication Bypass) is a common fallback in 802.1X deployments. The network infrastructure checks whether the connecting device’s MAC address is on an approved list. MAC-based identity has two hard limits. First, MAC addresses can be spoofed in seconds on any operating system. An attacker who observes network traffic can clone a known MAC address and pass authentication. Second, an MAC address is not cryptographically bound to any device state or ownership — it carries no proof that the device is managed, compliant or even the device it claims to be. MAB is appropriate as a fallback for printers, IP phones and IoT devices that don’t support 802.1X. It is not an adequate substitute for certificate-based device authentication on endpoints.

Agent-Based Device Identity

Some endpoint security and MDM platforms establish a form of device identity through agents running on the endpoint. The agent reports device attributes (compliance state, OS version, certificates installed) to a policy engine that decides whether to grant access. Agent-based approaches depend on the agent being present and intact. Agents can be uninstalled, disabled or bypassed. They also typically enforce access at the application layer, not at the network connection itself. A device that fails an agent-based posture check may still connect to the network and attempt lateral movement. Agent-based checks are a useful supplement to certificate-based authentication, not a replacement.

TPM Attestation

A Trusted Platform Module (TPM) is a hardware chip present in most modern enterprise laptops and servers. It stores cryptographic keys in hardware, making them non-exportable. The keys cannot be read off the chip and copied to another device. In a TPM-backed device identity model, a cryptographic key is generated inside the TPM and attested by the TPM chip’s endorsement key. The resulting credential doesn’t just prove that the correct certificate exists, but that the certificate’s private key is physically bound to that specific piece of hardware. TPM attestation is a strong form of device identity because it is, by design, hardware-locked. The operational complexity of TPM attestation is higher. It requires attestation infrastructure, integration with the issuing CA and client support that varies across platforms and OS versions. For organizations that need the strongest possible binding, TPM-backed certificates are the right answer.

X.509 Certificate-Based Identity

An X.509 certificate issued by a trusted Certificate Authority (CA) to a specific device is the most broadly deployed form of device identity. The certificate contains a unique identifier for the device, is signed by the CA and the corresponding private key is stored in the device’s certificate store (or the TPM, for hardware-bound issuance). When the device connects to a network that uses 802.1X authentication with EAP-TLS, it presents the certificate to the RADIUS server. The RADIUS server then validates the certificate against the CA’s trust chain, checks the certificate’s revocation status and applies the access policy. No password is involved in this process, and no user action is required. Certificate-based device identity is cryptographically verifiable, scalable and directly enforceable at the network layer via RADIUS. It’s the standard approach for enterprise Wi-Fi, VPN and wired network authentication in environments that take passwordless access seriously.

X.509 certificates provide the best combination of cryptographic verifiability, network enforcement, scalability and BYOD support. TPM binding adds hardware-level assurance for managed endpoints where operational complexity is acceptable. See the table below for a comparison of device identity methods.

How Certificate-Based Device Identity Works

Certificate-based device identity relies on a public key infrastructure (PKI) to issue, distribute, and validate device credentials. For background on how certificate-based authentication works at the protocol level, we’ll go through the core mechanics in the device context. The process works as follows:

1. CA establishes trust: An enterprise certificate authority issues certificates under a trusted root. The root CA’s certificate is distributed to all infrastructure that will validate device certificates — primarily RADIUS servers.
2. Device enrollment: The device receives a certificate, either through an MDM enrollment profile (Intune, Jamf, Kandji, Google Workspace) using SCEP or ACME protocols or through a self-service enrollment flow for BYOD devices. The private key is generated on the device and never leaves it.
3. Certificate stored: The certificate and private key are stored in the device’s system certificate store (Windows Certificate Store, macOS Keychain or Android/iOS credential storage). On managed devices with TPM, the private key can be generated inside the TPM for hardware binding.
4. Connection attempt: When the device connects to a Wi-Fi network, VPN or wired port configured for 802.1X, the supplicant (built into the OS) initiates an EAP-TLS authentication exchange.
5. Certificate presented: During the EAP-TLS handshake, the device presents its certificate to the RADIUS server. The RADIUS server presents its own certificate to the device (mutual TLS). Both sides verify each other’s certificates against the trusted CA.
6. RADIUS validation: The RADIUS server checks the device certificate’s validity, confirms the signature traces to the trusted CA, checks the revocation status via OCSP or CRL and looks up the associated user or device identity in the connected IdP.
7. Access granted or denied: Based on the certificate attributes and IdP lookup results (group membership, device compliance status, user account state), the RADIUS server returns an Access-Accept or Access-Reject. For accepted connections, it assigns the appropriate VLAN and access policy. The device never sends a password. The private key never leaves the device. The RADIUS server never sees the private key. Authentication succeeds on cryptographic proof alone.

The Device Identity Lifecycle: Enrollment to Revocation

Device identity is not a one-time provisioning task. A certificate issued today needs to be tracked, renewed before expiration, and revoked promptly when the device is decommissioned or compromised. At enterprise scale, this lifecycle requires automation — manually managing hundreds or thousands of certificates is unsustainable and bound to break down within months.

The table below describes the full device identity lifecycle, from enrollment to revocation.

The Revocation Problem

Revocation is where many device identity programs break down. Issuing a certificate is straightforward. Ensuring that certificate loses network access the moment the device is decommissioned requires your RADIUS server to check revocation status in real time. There are two revocation mechanisms. Certificate Revocation Lists (CRLs) are files published by the CA that list all revoked certificate serial numbers. They are downloaded periodically, which means a revoked certificate may still pass authentication for hours or days until the RADIUS server refreshes its cached CRL. OCSP (Online Certificate Status Protocol) checks revocation status in real time with a query to the CA’s OCSP responder. A RADIUS server configured to use OCSP checks each certificate at the moment of authentication, not against a cached list. For environments where immediate revocation matters, such as a terminated employee’s device or a stolen laptop, OCSP is the right approach.

Device Identity in 802.1X and RADIUS Networks

802.1X is the IEEE standard for port-based network access control. It defines how a device (the supplicant), the network infrastructure (the authenticator — an AP or switch) and an authentication server (the RADIUS server) exchange authentication information before granting network access.

The Certificate-Based EAP Method EAP-TLS (Extensible Authentication Protocol-Transport Layer Security) is the strongest EAP method for 802.1X. It requires both the client and the RADIUS server to authenticate each other with X.509 certificates — no passwords or shared secrets between the device and the RADIUS server.

When a device running EAP-TLS connects to a network, the AP or switch forwards the authentication request to the RADIUS server. The RADIUS server presents its TLS certificate. The device verifies the RADIUS certificate against the trusted CA. The device presents its own device certificate. The RADIUS server validates the device certificate and performs a real-time lookup against the configured IdP (Entra ID, Okta, Google Workspace) to verify the associated user and group membership. The RADIUS server returns an Access-Accept with VLAN assignment, or an Access-Reject. The entire exchange is encrypted. The device’s private key is never transmitted. The access decision is made at the connection layer, before any application traffic flows.

RADIUS Policy: What Happens After Validation

A RADIUS server that validates device certificates can enforce a granular access policy based on certificate attributes and IdP data:

• VLAN assignment: Managed corporate devices get full network access; BYOD devices go to a limited-access VLAN; IoT devices are segmented to their own VLAN.
• Dynamic policy based on IdP groups: A device enrolled to a user in the “Engineering” group gets different access than a device enrolled to a user in “Guest.”
• Compliance gating: Integration with MDM compliance data allows the RADIUS server to deny access to devices that fail compliance checks, such as missing patches, disabled encryption, expired EDR agent.
• Real-time revocation enforcement: If a user account is disabled in the IdP, the next RADIUS authentication fails, even if the device certificate is still technically valid. This is the lane most machine identity vendors miss. Certificate issuance and lifecycle management are important, but the enforcement mechanism is at the RADIUS layer. A device certificate that can’t drive a RADIUS access decision is a credential without enforcement.

Device Identity for BYOD: The Unmanaged Device Challenge

BYOD (Bring Your Own Device) is the hardest device identity problem. When employees use personal laptops and phones for work, IT doesn’t have MDM control over the device. They can’t push certificate profiles, enforce policies, or verify OS configuration. But those devices still connect to Wi-Fi, access cloud applications, and send corporate email.

The common fallback is MAC address authentication. A BYOD device is added to an approved MAC list, and the network lets it through. This approach carries potential issues, though. MAC addresses are spoofable, and there is no cryptographic proof of device ownership, either. Even more troubling, the approved list becomes an unmanaged sprawl of personal devices with no lifecycle.

A better approach is to issue an X.509 certificate to the BYOD device through a self-service enrollment process that employees complete independently. That way, no IT intervention is required.

Self-Service BYOD Certificate Enrollment

A self-service enrollment flow works like this: The employee visits an enrollment URL or downloads a client application (or is redirected to one by the network’s captive portal). They authenticate with their corporate credentials through the organization’s IdP. The enrollment system verifies that the user is authorized for BYOD access. A device certificate is issued by the enterprise CA and installed into the device’s certificate store. The network profile (SSID configuration, RADIUS settings) is pushed to the device. On all future connections, the device presents its certificate via EAP-TLS. No password prompt. The device certificate issued here authenticates the device to the network, not the user to an application. The user’s IdP credentials remain the authentication mechanism for SaaS apps. Device identity and user identity are separate tracks.

BYOD Policy Separation

BYOD devices with certificates can be placed in a restricted VLAN or access tier that provides them with full internet access, limits their access to internal resources and blocks them from sensitive segments. The RADIUS server identifies the certificate as BYOD (based on a certificate attribute set during enrollment) and applies the appropriate policy. When an employee leaves, the IT team revokes the BYOD certificate in the CA. The next time the personal device attempts to connect, the RADIUS server checks OCSP, gets a “revoked” response and denies access. The device loses network access immediately, with no action required from the former employee.

SecureW2 JoinNow MultiOS handles this enrollment flow for every major operating system through a single self-service interface. Employees can complete enrollment in a few minutes without opening a helpdesk ticket, reducing the workload for IT and simplifying certificate issuance.

Device Identity Management Challenges

Running a certificate-based device identity program at scale surfaces operational challenges that paper designs don’t anticipate. These are the most common ones.

• Certificate sprawl at scale: A 5,000-person organization with one certificate per managed endpoint, plus BYOD devices, can easily manage 8,000-15,000 active device certificates. Each has an expiration date, an issuing CA and an assigned device. Without automation and a certificate inventory system, renewals get missed and devices lose access unexpectedly.
• MDM diversity: Enterprises rarely standardize on one MDM. Intune manages Windows and sometimes macOS. Jamf manages macOS and iOS. Kandji is common for macOS-first environments. Google Workspace covers Chromebooks. Each MDM has a different SCEP or ACME integration path. Certificate issuance systems need to accommodate all of them.
• Revocation lag: CRL-based revocation has inherent lag. If a RADIUS server caches a CRL with a 24-hour validity period, a revoked certificate may still authenticate for up to 24 hours after revocation. OCSP closes that gap, but it requires the CA to run a responsive OCSP responder, and the RADIUS server to be configured to use it.
• Decommissioned device certificates: Devices are constantly reimaged, reassigned, and retired. A certificate that was valid for a device assigned to a current employee is still technically valid after the device is reassigned or returned. Revocation processes need to be tied to device lifecycle events in the MDM, not just user offboarding.
• BYOD certificate scope: An employee’s personal device has a certificate that grants network access. When employment ends, the certificate needs to be revoked. This requires the offboarding process to trigger certificate revocation in the CA, a step that’s often missing from manual offboarding checklists.

The solution for each of these challenges is the same: automation tied to authoritative identity and device data sources. A PKI designed for enterprise network access handles issuance, renewal and revocation as automated workflows rather than manual processes. Device identity management is not a one-time configuration task. It is an operational discipline that runs continuously for the lifetime of every device in your environment.

Establish Certificate-Based Device Identity With SecureW2

Most organizations reach a point where MAC-based authentication and agent-based posture checks become insufficient. Devices are connecting from more locations, to more networks, using more operating systems than the original access control design anticipated. Originally, organizations are concerned with how to add devices to an approved list. But eventually, the focus changes to giving every device a cryptographic identity that the network can verify at connection time.

SecureW2 provides the infrastructure to build that model. JoinNow Dynamic PKI issues device certificates automatically through Intune, Jamf, Kandji and Google Workspace. No manual certificate requests, no scripting, and no per-device IT intervention.

For BYOD devices, JoinNow MultiOS delivers a self-service enrollment experience that provisions certificates across Windows, macOS, iOS, Android and Chromebook without requiring MDM management of the personal device.

JoinNow Cloud RADIUS enforces device identity policy at the network connection layer. On every 802.1X authentication, Cloud RADIUS validates the device certificate against the CA trust chain, checks revocation status via OCSP, and performs a real-time lookup against your identity provider to verify the associated user’s account status and group membership. If the user is disabled, the device is decommissioned or the certificate is revoked, access is denied during the next connection attempt.

The platform is vendor-neutral. It works with any Wi-Fi infrastructure, any firewall, any MDM and any IdP. No hardware lock-in, no on-premises RADIUS servers to maintain and no dependency on any single MDM vendor’s certificate issuing capability. Schedule a demo to see how SecureW2 Dynamic PKI and Cloud RADIUS establish certificate-based device identity across managed and BYOD devices or contact SecureW2 to discuss your specific environment.