Skip to main content
A Device Certificate Group authenticates devices rather than users. The certificate names the machine (not any person), EntryPoint validates the chain, resolves the device to an Entra device record, and matches against the Group’s mapped Entra device group. When the Context’s Device Compliance Check is on, EntryPoint additionally verifies the device’s Intune-driven compliance posture on every auth. This is the right Group type for any situation where the device itself is the unit of authorization — kiosks, factory workstations, unattended workstations, room-control panels — plus for the “compliant managed laptops” deployment shape where Intune-posture is enforced at the network layer.

​
When to use a Device-Cert Group

  • Unattended equipment. Reception kiosks, factory-floor workstations, building-automation panels, conference-room controllers — none of these have a logged-in user; the device’s identity is what the network is authorizing.
  • Managed fleets where Intune posture matters. Corporate laptops where the answer to “is this device allowed on the network” is “only if Intune says it’s compliant”. The device cert proves registration; Device Compliance Check proves health.
  • Audiences that need a per-Group VLAN regardless of who’s signed in. Factory workstations always on VLAN 510, kiosks always on VLAN 610 — the device-is-the-principal model makes this policy predictable.

​
Typical Device-Cert Groups

  • Managed Laptops — every Intune-enrolled laptop in the fleet. Mapped to an Entra device group that Intune populates based on compliance. Big Group, narrow VLAN, Intune posture enforced.
  • Reception Kiosks — a handful of unattended displays at each lobby. Mapped to a static Entra device group. Dedicated VLAN with egress restrictions.
  • Factory Workstations — the PCs in the fab. Mapped to a device-centric Entra group maintained by the ops team. Separate VLAN, different SGT.
Each Group’s Attribute Profile delivers the VLAN / SGT / tunnel settings for its audience.

​
Device Compliance Check — Intune posture at the RADIUS layer

The Context’s Identity Store has a checkbox: Enable Device Compliance Check. When turned on, every EAP-TLS authentication (user- or device-cert) gets a second Entra lookup after the chain and group match pass — Entra is asked whether the device is compliant.
  • Compliant → Access-Accept proceeds as usual, carrying the Group’s Attribute Profile.
  • Not compliant → Access-Reject. The authentication fails, even if everything else would have allowed it through.
“Compliant” is whatever your Intune compliance policy says it is — typically disk encryption is on, a password / PIN is set, the OS is patched within your policy’s window, and no jailbroken / rooted indicators are present. EntryPoint reads the Entra isCompliant-style signal; it doesn’t re-evaluate the compliance itself. Turn the checkbox on per-Context in the Identity Store configuration — see Entra connection.

​
How the cert is read

For a device cert, EntryPoint reads a device identifier from the certificate — typically:
  • The SAN, carrying a device name or device ID.
  • A custom extension or OU issued specifically for the device.
The platform resolves that identifier to an Entra device record via the Graph API, then checks group membership. Your PKI / MDM team picks which cert attribute carries the identifier; the choice is consistent per issuing CA.

​
The Certificate Group Identifier field

Each Device Certificate Group carries a Certificate Group Identifier on its Group Settings card. EntryPoint matches this identifier against a value in the client certificate — typically an OU in the subject DN, or a custom extension your PKI writes. The Certificate Group Identifier lets you map one issuing CA to several EntryPoint Groups. A single corporate PKI might issue certs for kiosks, factory workstations, and managed laptops all via the same intermediate; the Certificate Group Identifier on each Group is what says “this cert is for the Factory Workstations Group” or “this cert is for the Reception Kiosks Group”. The right EntryPoint Group gets picked up on authentication based on the identifier in the cert. If only one CA issues only one kind of device cert, the identifier is less important — but filling it consistently from day one avoids surprises when the PKI later expands.

​
Creating a Device-Cert Group

1

Open the Context's Groups tab

Click Add Group.
2

Pick 802.1X-TLS with Device Certificate

From the Select Group Type dropdown.
3

Name and describe

Managed Laptops, Reception Kiosks, Factory Workstations — names should read cleanly in audits.
4

Pick the Entra Group

From the Entra Group selector.
5

Save and open Group Settings

On the new Group’s Group Settings:
  • Attach an Attribute Profile for VLAN / SGT.
  • Set the Certificate Group Identifier if your PKI issues multiple device-cert types from the same CA.
The Group detail page has a Statistics card on top plus six tabs: Connected Devices, MAB Device List (see MAB fallback inside Device-Cert), Self-Service Users, PEAP Accounts (empty on a Device-Cert Group), Group Settings, and How to connect.

​
Pairing with MAB fallback

The same Device-Cert Group that authorizes your factory workstations via cert also carries a MAB Device List tab. Devices on that list authenticate by MAC — the right path for printers, VoIP phones, sensors, and BMS gear that can’t do 802.1X but share network infrastructure with certificate-auth’d devices. They land on the Group’s Attribute Profile just like the cert-auth’d devices do. See MAB fallback inside Device-Cert for the full list lifecycle and why MAB is not a separate Group type.

​
Revocation and device-retirement flows

  • Cert compromise. Revoke the cert in your PKI and ensure the CRL is refreshed. On next auth, EntryPoint rejects the cert regardless of Entra group membership. For immediate enforcement, also remove the device from the Connected Devices list on the Group — the current session drops on next re-auth.
  • Device retirement. Remove the device from the Entra group your EntryPoint Group is mapped to. Next auth → reject. Optionally revoke the cert too.
  • Intune marks the device non-compliant. If Device Compliance Check is on, the device is rejected at the next auth. No EntryPoint action needed; Intune’s signal drives the behaviour.
  • A user in a Managed-Laptops Group should be blocked without revoking the device. Remove that specific user in Entra from whatever user-group governs access — User-Cert Groups and Device-Cert Groups can co-exist on one Context, so a user can be blocked at user-level without retiring their device.

​
Troubleshooting

  • Cert validates, Entra lookup fails. The device’s identifier in the cert doesn’t resolve to an Entra device record. Check that the issuing CA is populating the identifier you configured on the Group’s Certificate Group Identifier (or the SAN / DN pattern EntryPoint expects).
  • Cert validates, group match fails. The device isn’t in the Entra group the EntryPoint Group is mapped to. Verify from the Entra admin; Entra dynamic groups often have evaluation lag after device enrollment.
  • Cert validates, group matches, Access-Reject with “compliance failed”. Device Compliance Check is on, and Intune has the device as non-compliant. Fix compliance on the device (install the missing update, enable encryption, etc.).
  • Reception Kiosks authenticate but all end up on the wrong VLAN. Check the Attribute Profile attached to the Kiosks Group — often a paste-error when swapping tunnel-group IDs between Profiles.

User certificates

The user-as-principal counterpart.

MAB fallback inside Device-Cert

The MAC-based list that rides on each Device-Cert Group.

Entra group mapping

How the mapping to an Entra device group is resolved.

Entra connection

Including the Device Compliance Check checkbox.