User certificates
The EAP-TLS Group type where the certificate identifies a person. Employees on MDM-enrolled devices authenticate with a per-user cert; the cert's bearer is matched to Entra group membership on every auth.
A User Certificate Group authenticates people. The certificate subject names an Entra user; the platform validates the cert chain, reads the user identity from the cert, asks the Entra Graph API whether that user belongs to the Group’s mapped Entra group, and on a hit returns Access-Accept with the Group’s Attribute Profile.
This is the right Group type for employees on managed laptops where every user has a distinct client certificate installed via your MDM.
When to use a User-Cert Group
Section titled “When to use a User-Cert Group”- Corporate staff with MDM-enrolled laptops. Your MDM (Intune, Jamf, Workspace ONE) enrolls each device, generates a key pair, and installs a user certificate signed by your corporate PKI.
- Employees who roam between their own devices. A single user’s cert can be installed on their laptop and their tablet and their loaner machine. All three authenticate as the same user.
- Audiences where the user is the security principal — compliance and attribution happen at the human level, not the device level.
Contrast this with EAP-TLS with Device cert, the standalone variant where the certificate identifies a device from your own PKI (the right choice for unattended kiosks, factory workstations, and anything where “this device” is the unit of authorization). To additionally gate this user-certificate path on Intune posture, see Device Compliance Check and Intune.
Typical User-Cert Groups
Section titled “Typical User-Cert Groups”Each User-Cert Group maps to an Entra user group — usually a Security group populated by your identity team. Typical shapes:
- Corporate Staff — mapped to an Entra group that contains every employee eligible for corporate Wi-Fi. Usually the broadest Group.
- Finance — mapped to the Entra Finance group. Attached Attribute Profile puts Finance users on a Finance-specific VLAN with extra controls.
- Engineering — mapped to the Engineering Entra group. Different VLAN, perhaps with additional egress rules enforced by the SGT in the Attribute Profile.
One Context easily hosts all three. Each gets its own Attribute Profile; each is mapped to its own Entra group. Employees in more than one Entra group (a Finance analyst who’s also in Corporate Staff) authenticate against whichever EntryPoint Group Entra evaluates first — which is an Entra-side concern about group precedence, not an EntryPoint one.
Prerequisites
Section titled “Prerequisites”- The Context has EAP-TLS enabled (Client Authentication Methods card) and Microsoft Entra ID as the Identity Store. See Entra connection.
- At least one Trusted CA is uploaded — see Trusted certificates.
- Users in scope have a per-user certificate installed that chains to one of those trusted CAs.
- The Entra group you want to map already exists.
Creating a User-Cert Group
Section titled “Creating a User-Cert Group”-
Open the Context's Groups tab
Click Add Group.
-
Pick 802.1X-TLS with User Certificate
From the Select Group Type dropdown.
-
Name and describe
Typically the Entra group’s purpose — Corporate Staff, Finance, Engineering. Description should reference the Entra group for audit reasons.
-
Pick the Entra Group
The Entra Group selector is populated from the Entra tenant connected on the Identity Store. Pick the matching Entra group.
-
Save and attach an Attribute Profile
On Group Settings, attach the Attribute Profile that holds this audience’s VLAN / SGT. See Attribute Profiles.
How the cert is read
Section titled “How the cert is read”EntryPoint reads the user identity from a specific field in the client certificate. Most corporate PKI / MDM setups put the user’s UPN (or equivalent identifier) in one of:
- The Subject Alternative Name (SAN) extension, as a
userPrincipalNameentry. - The Subject DN, in
CN=or a similar attribute.
Work with your PKI team to pick one and apply it consistently across the issuing templates. Once the identifier arrives cleanly, the Entra Graph lookup is straightforward.
If the cert can’t be resolved to an Entra user — malformed SAN, the UPN isn’t in the tenant, the user was deleted — authentication fails with Access-Reject and the audit row records a “principal-not-found” reason.
Getting certs onto devices
Section titled “Getting certs onto devices”EntryPoint does not issue certificates — that’s your PKI’s job. Typical flows for user-cert distribution:
- MDM-issued. Your MDM enrolls the device, generates the key pair on-device (hardware-backed if possible), and installs a user cert signed by your corporate PKI. Intune is the common path for Entra- integrated tenants.
- Corporate PKI + manual install. For smaller fleets, your PKI team issues a per-user cert and IT pushes it plus the Wi-Fi profile.
- SCEP / NDES. A scalable auto-enrolment flavour of the MDM path — still runs in your infrastructure; EntryPoint only sees the final signed cert at authentication time.
EntryPoint does not operate SCEP or enrol clients. It’s on the validation side.
User certs vs device certs — picking correctly
Section titled “User certs vs device certs — picking correctly”Use this cue to choose between this variant and the standalone EAP-TLS with Device cert variant:
- If the security story is “this person is allowed, on whichever machine they’re on” → a User-Certificate Group here. The user’s cert roams between their devices, and Entra group membership is the decision. Add Device Compliance Check if you also want the device to be Intune-compliant.
- If the security story is “this device is allowed, whoever is using it” → the standalone EAP-TLS with Device cert variant. The device’s own-PKI cert is the credential, routed by a Certificate Group Identifier with no Entra dependency.
Many Organizations run both, plus EAP-PEAP, on one Context; see Combining with EAP-PEAP.
Day-to-day operations
Section titled “Day-to-day operations”- A new employee joins. Your identity team adds them to the Entra group and your MDM issues them a cert. They authenticate successfully on their next attempt — you don’t do anything on EntryPoint.
- An employee leaves. Your identity team removes them from the Entra group. Next auth → Access-Reject. Revoke the certificate in your PKI / MDM to close the hole fully; update the CRL and EntryPoint stops accepting the cert on next auth regardless of group membership.
- An employee changes teams. Move them from Engineering to Finance in Entra; EntryPoint follows on the next auth.
- A cert expires. Your MDM renews the cert on-device; the user is unaffected. If the renewal fails, their next auth is rejected until the cert is fresh.
Troubleshooting
Section titled “Troubleshooting”- Chain-of-trust errors. The issuing CA isn’t uploaded on the Context, or the chain is incomplete (missing intermediate). Fix on Trusted certificates.
- “Principal not found in tenant.” The cert’s user identifier doesn’t resolve in the Entra tenant the Context connects to. Verify the UPN in the cert matches the user’s UPN in Entra.
- User authenticates but lands on the wrong VLAN. The Entra group membership maps to a different EntryPoint Group than you expected, or a Group’s Attribute Profile is misassigned. Start from the Context’s Audit Log and the Group’s Connected Devices tab.
- Everything was working yesterday. Has the Entra tenant secret on the Identity Store expired? Check Entra API Status on Entra connection.