Device Compliance Check and Intune
An optional Intune posture gate on the EAP-TLS-with-Entra user-certificate path. When enabled, EntryPoint verifies on every authentication that the user's device is registered and compliant in Microsoft Entra / Intune, on top of the user's group match.
Note
Authenticating devices by a certificate from your own PKI, with no Entra tenant in the path, 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 performs an Entra lookup or Device Compliance Check. This page is about the Entra-backed path, where the certificate names a user and you want to additionally check the user’s device posture.
Device Compliance Check is an optional posture gate that sits on top of the EAP-TLS-with-Entra user-certificate flow. The certificate still identifies a user and the user is still matched to a mapped Entra group; with the check enabled, EntryPoint additionally asks Entra whether the user’s device is registered and compliant before returning Access-Accept. The certificate proves identity; Intune proves the device is healthy.
This is the deployment shape for “compliant managed laptops” — where the answer to “is this person allowed on the network” is “yes, but only from a device Intune considers healthy”.
How it works
Section titled “How it works”On an EAP-TLS-with-Entra authentication with Device Compliance Check on:
-
The certificate is validated and the user is resolved
EntryPoint validates the chain against the Context’s Trusted CAs and reads the user identifier (UPN) from the certificate.
-
Group membership is checked
The Entra Graph API confirms the user belongs to the Entra group the EntryPoint Group is mapped to. A miss is an Access-Reject before compliance is even considered.
-
The device is checked for compliance
With the check enabled, every authentication must carry a resolvable device identifier. EntryPoint asks Entra whether that device is registered to the user and reported compliant. A certificate with no device identifier, or a device that is unknown or non-compliant, produces an Access-Reject, even though the user’s group membership would have accepted them.
The certificate chain proves the user is authenticated, the group match proves they’re authorized, and the compliance signal proves their device is healthy — all three on every authentication.
What “compliant” means
Section titled “What “compliant” means”“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 there are no jailbroken / rooted
indicators. EntryPoint reads Entra’s isCompliant-style signal via the
Graph API on each authentication; it does not evaluate the compliance
itself. Intune owns the policy and the verdict; EntryPoint enforces that
verdict at the RADIUS layer.
Enabling Device Compliance Check
Section titled “Enabling Device Compliance Check”The setting is a single checkbox on the Context’s Identity Store configuration — Enable Device Compliance Check — and applies to the Context’s EAP-TLS-with-Entra authentication.
-
Open the Identity Store configuration
Configuration → Basic Configuration → Backend Identity Store, with the Identity Store set to Microsoft Entra ID. See Entra connection.
-
Confirm the Entra API Status is healthy
The compliance lookup uses the same Graph credentials (Directory ID, Application ID, Client Secret) as the group lookup. The Entra API Status card must be green.
-
Enable the check
Turn on Enable Device Compliance Check and save. From this point, every EAP-TLS-with-Entra authentication on the Context is posture-gated.
When to use it
Section titled “When to use it”- Regulated or sensitive environments where an authenticated user on an unmanaged or unhealthy device should still be kept off the network.
- BYOD-adjacent fleets where the certificate alone isn’t enough assurance and Intune already carries the compliance verdict.
Leave it off when the group match is sufficient assurance, or when not every in-scope device is enrolled in Intune (an un-enrolled device would be rejected as non-compliant).
Troubleshooting
Section titled “Troubleshooting”- User authenticates from one device but not another. The rejected device is not registered to the user in Entra, or Intune reports it non-compliant. Check the device’s compliance state in Intune.
- Everyone is suddenly rejected after enabling the check. Confirm the certificates actually carry a device identifier and that the fleet is Intune-enrolled — with the check on, a device Entra can’t resolve is a reject.
- Access-Reject with a “compliance failed” reason. Intune has the device as non-compliant. Fix the underlying issue on the device (install the missing update, enable encryption) and re-authenticate.
- Everything worked yesterday. Check whether the Entra tenant secret on the Identity Store expired — the compliance lookup fails with it. See Entra connection.