Skip to content
Support
EAP-TLS with Device cert

EAP-TLS with Device Certificate overview

Certificate-based 802.1X for managed and unattended devices that present a certificate from your own PKI. EntryPoint trusts certificates that chain to the Trusted CAs you upload, routes each device to a Group by its Certificate Group Identifier, and applies the Group's Attribute Profile. No Entra tenant, no passwords, no Self-Service portal.

EAP-TLS with Device Certificate is EntryPoint’s certificate-based 802.1X variant for devices that carry a certificate from your own PKI — issued by AD CS, a SCEP service, an MDM certificate connector, or a commercial CA. The device presents its certificate on the supplicant; EntryPoint trusts certificates that chain to the Trusted CAs you upload to the Context (with optional CRL revocation checking) and routes each certificate to the right Group by a per-Group Certificate Group Identifier. No password is typed, no Microsoft Entra tenant is involved, and there is no Self-Service portal. The certificate plus its identifier is the whole authorization decision.

It is designed for Organizations that already run a PKI and want certificate-strength Wi-Fi without binding it to a cloud identity provider — managed laptops, kiosks, factory workstations, and other equipment where the device is the unit of authorization.

The core idea — the certificate and its identifier

Section titled “The core idea — the certificate and its identifier”

EntryPoint resolves a Device Certificate authentication in three moves:

  • Trust the chain. A presented certificate is trusted only if it chains to one of the Context’s Trusted CAs. An optional Cert Revocation URL (CRL) lets you reject revoked certificates.
  • Route by the Certificate Group Identifier. Each Device-Cert Group carries a Certificate Group Identifier. EntryPoint reads the matching value from the presented certificate and routes the device to that Group. One issuing CA can therefore serve many Groups — kiosks, factory workstations, and managed laptops can all chain to the same intermediate, with the identifier on each certificate selecting the Group.
  • Apply the Group’s policy. The Group’s Attribute Profile (VLAN / Security Group Tag / tunnel attributes) is returned on the RADIUS Access-Accept.

There is no directory lookup in this path — no Entra, no Graph API, no per-user account. The certificate is the credential and the Certificate Group Identifier is the routing key.

When to use Device Certificate

Section titled “When to use Device Certificate”
  • You run your own PKI / MDM. AD CS, Intune’s certificate connector, a SCEP service, or a commercial CA already issues device certificates; you want the Wi-Fi to trust them directly.
  • The device is the unit of authorization. Reception kiosks, factory-floor workstations, building-automation panels, conference-room controllers, and managed laptops where the network is authorizing the machine, not a signed-in person.
  • Certificate strength without an Entra dependency. You want no-password 802.1X but don’t want authentication to depend on a Microsoft Entra tenant or the Graph API.
  • Headless gear on the same infrastructure. The MAB Device List inside each Device-Cert Group catches printers, VoIP phones, and sensors that can’t present a certificate but should land on the same policy.

What Device Certificate is NOT

Section titled “What Device Certificate is NOT”
  • Not Entra-backed. Device-Cert Groups never call Microsoft Entra. If membership in an Entra group should be the authorization decision, or you want Device Compliance Check (Intune posture) on every authentication, use EAP-TLS with Entra instead.
  • Not username and password. For audiences that authenticate with credentials rather than a certificate, see EAP-PEAP.
  • Not a certificate authority. EntryPoint validates certificates; it doesn’t issue them. Your PKI / MDM handles issuance and renewal; EntryPoint needs only the CA chain uploaded to the Context.
  • Not a Self-Service product. There is no end-user portal on a Device-Cert Group. Lifecycle lives in your PKI / MDM plus the admin UI.

Prerequisites

Section titled “Prerequisites”
  • A Dot1x Context — see Creating a Context.
  • EAP-TLS toggled on under Configuration → Basic Configuration → Client Authentication Methods, with the Device Certificate sub-option enabled and saved.
  • At least one Trusted CA uploaded under Configuration → 802.1x Authentication → EAP-TLS, covering the issuer of the certificates your devices present. Optionally a Cert Revocation URL. See Trusted certificates.
  • Your PKI / MDM issues device certificates that carry the Certificate Group Identifier you set on each Group.

Next

Device-Cert Groups and the Certificate Group Identifier

Upload the Trusted CAs your devices chain to, create an 802.1X-TLS Device Certificate Group, set its Certificate Group Identifier so the right certificates land in it, and attach an Attribute Profile for VLAN or Security Group Tag. All without Entra.

MAB fallback inside Device-Cert Groups

MAC Authentication Bypass appears as a MAB Device List tab on every Dot1x Group; Device-Cert Groups are its most common home. Listed MACs authenticate by MAC and inherit the Group's Attribute Profile alongside the certificate-authenticated devices.