Skip to main content
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

  • 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 Device Certificates, where the certificate identifies a device (the right choice for unattended kiosks, factory workstations, and anything where “this device” is the unit of authorization).

​
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

  • 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

1

Open the Context's Groups tab

Click Add Group.
2

Pick 802.1X-TLS with User Certificate

From the Select Group Type dropdown.
3

Name and describe

Typically the Entra group’s purpose — Corporate Staff, Finance, Engineering. Description should reference the Entra group for audit reasons.
4

Pick the Entra Group

The Entra Group selector is populated from the Entra tenant connected on the Identity Store. Pick the matching Entra group.
5

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

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 userPrincipalName entry.
  • 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

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 vs Device certs — picking correctly

It’s easy to mix up the two EAP-TLS Group types. Use this cue:
  • If the security story is “this person is allowed, on whichever machine they’re on” → User-Cert Group. The user’s cert roams between their devices.
  • If the security story is “this device is allowed, whoever is sitting at it” → Device-Cert Group. The device’s cert is locked to the machine.
Many Organizations run both — User-Cert Groups for employee access on personal-issued laptops, Device-Cert Groups for unattended kiosks and factory workstations. A Context hosts both Group types side-by- side; see Combining with EAP-PEAP.

​
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

  • 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.

Entra group mapping

How the EntryPoint-to-Entra link is stored and resolved.

Device certificates & Intune

The device-as-principal counterpart.

Trusted certificates

Upload the CAs EntryPoint should validate against.

Attribute Profiles

VLAN / SGT per Group.