EAP-TLS with Microsoft Entra ID overview

EAP-TLS with Microsoft Entra ID is EntryPoint’s certificate-based 802.1X variant for managed corporate fleets. The client device presents a certificate on the supplicant; EntryPoint validates the chain against the Trusted CAs uploaded to the Context and, crucially, matches the certificate’s bearer to a Microsoft Entra ID group you mapped to an EntryPoint Group. No password is ever typed or stored. Membership in the right Entra group is the entire authorization decision.

It is designed for Organizations whose identity source is already Microsoft 365 / Entra ID and whose device posture is managed by Intune. The hero deployment shape is employees on corporate laptops with MDM-enrolled user certificates, mapped to the Entra groups you already maintain as part of your identity lifecycle, optionally gated by Intune compliance. For unattended equipment that carries a certificate from your own PKI with no Entra dependency, use the standalone EAP-TLS with Device cert variant instead.

The core idea — Groups mirror Entra groups

EntryPoint has a Group concept; Microsoft Entra has a group concept. The EAP-TLS-with-Entra variant ties the two together at authentication time:

• One EntryPoint Group mirrors one Entra group. When you create the Group in the admin UI, the form asks you to pick an Entra group. The Entra group ID is stored on the EntryPoint Group (in its Dot1x settings).
• Cert-bearer ↔ Entra user lookup. On authentication, EntryPoint validates the certificate chain, reads the user identifier (UPN) from the cert, asks the Entra Graph API which groups that user belongs to, and matches against the EntryPoint Group’s stored Entra group ID.
• Per-Group Attribute Profile drives the RADIUS response. Every member of the Entra group inherits the Group’s VLAN / Security Group Tag via its Attribute Profile.
• Entra is the source of truth. Add a user to the Entra group — they can authenticate to this Wi-Fi Group. Remove them from the Entra group — they can’t, starting on the next auth after the Graph API propagates the change.

You maintain the roster once, in Entra. EntryPoint follows.

One Group type, with an optional posture gate

The Entra-backed variant has a single Group type: 802.1X-TLS with User Certificate. The certificate names a person; EntryPoint matches that user against the Entra group the EntryPoint Group is mapped to. Its hero use case is employees on managed laptops where MDM enrolls a per-user certificate signed by your corporate PKI. The same user’s certificate can ride on their laptop and their tablet — they authenticate as the same user on each.

Typical Groups map one-to-one to Entra user groups: Corporate Staff, Finance, Engineering.

On top of that, Device Compliance Check adds an Intune posture gate (see below): when the certificate also carries a device identifier and the check is enabled, EntryPoint additionally verifies the user’s device is registered and compliant in Entra / Intune before accepting.

Note

Authenticating devices by a certificate from your own PKI, with no Entra tenant in the path (kiosks, factory workstations, managed laptops where the device is the unit of authorization)? That is a separate variant: EAP-TLS with Device cert. It routes each device to a Group by a Certificate Group Identifier, trusts certificates that chain to the Context’s Trusted CAs, and never consults Entra or Device Compliance Check. This page covers the Entra-backed path, where membership in a Microsoft Entra group is the authorization decision.

Device Compliance Check — Intune posture at the RADIUS layer

When the Context’s Identity Store is Microsoft Entra ID, a single checkbox on the Identity Store configuration — Enable Device Compliance Check — turns the RADIUS service into a posture-gated enforcement point. With it on:

• When the user’s certificate carries a device identifier, EntryPoint asks Entra whether that device is registered to the user and compliant (compliance is typically determined by Intune’s own policy). A device that isn’t compliant is rejected, even when the user’s group membership would otherwise accept it.

Net result: the certificate chain proves the user is authenticated, the Entra group match proves they’re authorized, and the compliance check proves their device is healthy — all on every authentication.

The compliance-check feature is specifically a Microsoft Entra / Intune integration — the signal is Entra’s isCompliant-style attribute, read via the Graph API on each auth. See Device Compliance Check and Intune.

Who operates EAP-TLS with Entra

Only Organization administrators. Unlike the PEAP variant, EAP-TLS Groups have no Self-Service portal — there’s nothing for an end-user to self-serve (no password, no personal account, no device to enroll themselves). Lifecycle stays in Entra.

The admin-side work is bounded:

1. Connect the Context to Entra — Entra connection.
2. Upload the Trusted CAs your certificates chain to — Trusted certificates.
3. Create one User-Certificate EntryPoint Group per Entra group that should have access.
4. Attach the right Attribute Profile to each Group for VLAN / SGT assignment.
5. (Optional) Enable Device Compliance Check on the Identity Store to gate access on Intune posture.

After that, all membership changes happen in Entra.

What EAP-TLS-with-Entra is NOT

• Not a certificate authority. EntryPoint validates certificates. It doesn’t issue them. Your corporate PKI (AD CS, SCEP, Intune cert-connector, a commercial CA) handles issuance; EntryPoint needs only the CA chain uploaded to the Context.
• Not for audiences without Entra. If your user population isn’t in Entra, the per-firm EAP-PEAP variant is a better fit — local Personal PEAP Accounts, Self-Service for delegation.
• Not a Self-Service product. EAP-TLS Groups have no Self-Service portal surface. If you want users to manage their own access, choose PEAP or iPSK.
• Not a RADIUS appliance. EntryPoint is the RADIUS service. Attach your WLAN controllers and switches via RADIUS clients.

Prerequisites

• An EntryPoint Context of type EntryPoint 2.0 (Dot1x PEAP, Entra) — see Creating a Context.
• EAP-TLS toggled on in Configuration → Basic Configuration → Client Authentication Methods.
• The Context’s Identity Store set to Microsoft Entra ID, with a working Directory (tenant) ID, Application (client) ID, and Client Secret pasted in. The Entra API Status card shows green. See Entra connection.
• At least one Trusted CA certificate uploaded to the Context, covering the issuer of the certificates your devices present.
• An Entra tenant with user-group or device-group memberships you can reference by Object ID. A user or device enrolled with a certificate signed by the trusted CA.