Device-Cert Groups and the Certificate Group Identifier

The natural unit of Device-Certificate administration is one Group per device class. Each Group carries a Certificate Group Identifier that selects which certificates land in it, an Attribute Profile that sets its network policy, and a MAB Device List for headless gear on the same infrastructure. This page covers the admin-side lifecycle: trust the issuer, create the Group, set the identifier, attach policy.

Prerequisites

• The Context is a Dot1x Context with EAP-TLS enabled and its Device Certificate sub-option toggled on under Configuration → Basic Configuration → Client Authentication Methods.
• Your PKI / MDM issues device certificates and can embed a per-Group identifier value in them (commonly in the subject CN or OU, or a SAN / certificate extension — your PKI team picks which, consistently per issuing CA).
• At least one Attribute Profile exists on the Context if you want per-Group VLAN or Security Group Tag assignment.

Upload the Trusted CAs

EntryPoint trusts a presented certificate only if it chains to a CA you have uploaded to the Context. This trust store is shared by both EAP-TLS sub-options, so it is the first thing to set up.

1. Open Configuration → 802.1x Authentication → EAP-TLS

   The EAP-TLS sub-tab holds the trust store and the revocation setting.

2. Click Add Trusted CA

   Upload the PEM for each root or intermediate CA that issues your device certificates. The list shows each certificate’s name and expiry.

3. (Optional) Set the Cert Revocation URL

   Point it at your CA’s published CRL. With it set, EntryPoint rejects certificates the CRL marks as revoked, then click Update Cert Revocation URL.

Create a Device Certificate Group

1. Open the Context's Groups tab

   From the Context overview, click Add Group.

2. Pick 802.1X-TLS with Device Certificate

   From the Select Group Type dropdown. The Device Certificate option appears once EAP-TLS and its Device Certificate sub-option are enabled on the Context.

3. Name the Group after the device class

   The name shows in breadcrumbs and on the Context’s Groups list. Pick the class the Group serves:

   • Managed Laptops
   • Reception Kiosks
   • Factory Workstations
   • Room-Control Panels

4. Create the Group

   The Group lands on its own detail page with a Group Type card showing 802.1X-TLS Device Certificate and its Certificate Group Identifier, plus the Connected Devices, MAB Device List, and Group Settings tabs.

The Certificate Group Identifier

Each Device Certificate Group has a Certificate Group Identifier on its Group Type / Group Settings card. EntryPoint matches this identifier against a value carried in the presented certificate, and that match is what routes a device to this Group rather than another.

The identifier is what lets you map one issuing CA to several Groups. A single corporate PKI might issue certificates for kiosks, factory workstations, and managed laptops all from the same intermediate; the Certificate Group Identifier on each Group is what says “this certificate is for the Factory Workstations Group” or “this one is for Reception Kiosks”. The right Group is selected on every authentication from the identifier in the certificate.

Your PKI / MDM team configures the certificate template so that each device’s certificate carries the identifier for the Group it belongs to. Keep the value consistent per issuing CA, and fill it in from day one even if you start with a single device class — it avoids surprises when the PKI later expands to more Groups.

How the certificate is read and matched

On each authentication EntryPoint:

1. Validates the chain of the presented certificate against the Context’s Trusted CAs, and rejects it if a configured CRL marks it revoked.
2. Reads the Certificate Group Identifier from the certificate and routes the device to the Group whose identifier matches.
3. Returns the Group’s Attribute Profile on the Access-Accept, placing the device on the Group’s VLAN / Security Group Tag.

No directory is consulted — there is no Entra lookup, no Graph API call, and no per-user account. If you need an Entra group to be the authorization decision, that is the EAP-TLS with Entra variant, not this one.

Attach an Attribute Profile

Per-Group VLAN or Security Group Tag assignment is where one Group per device class pays off: kiosks always on the kiosk VLAN, factory workstations always on the OT VLAN, managed laptops on the corporate VLAN.

1. Create the Profile first, if it doesn't exist

   On the Context, Configuration → Attribute Profiles → Add attribute profile. Name it for the treatment (VLAN 510 — Factory, VLAN 610 — Kiosks) and add the tunnel attributes that assign the VLAN. See Attribute Profiles.

2. Open the Group's Settings tab

   The Dot1x settings card lists the Attribute Profiles attached to the Group.

3. Attach the Profile

   Pick the Profile from the dropdown and save. Every successful authentication for a device in this Group now returns the Profile’s attributes on the RADIUS Access-Accept.

A Group can attach more than one Profile (stacking, say, a Cisco AV-pair SGT alongside the VLAN), and several Groups can share one Profile — Profiles are Context-scoped and don’t have to mirror Group count.

MAB fallback for headless gear

The same Device-Cert Group carries a MAB Device List tab. Printers, VoIP phones, sensors, and other gear that can’t present a certificate authenticate by MAC and inherit the Group’s Attribute Profile alongside the certificate-authenticated devices. See MAB fallback inside Device-Cert Groups for the full lifecycle.

Day-to-day and revocation

• Certificate compromise. Revoke the certificate in your PKI and ensure the CRL is refreshed; with a Cert Revocation URL set, EntryPoint rejects it on the next authentication. For immediate enforcement, also remove the device from the Group’s Connected Devices list — the current session drops on next re-auth.
• Device retirement. Stop issuing / renewing the device’s certificate in your PKI; once the certificate expires or is revoked, the device can no longer authenticate.
• Re-homing a device class. Change the Certificate Group Identifier your PKI embeds (and the matching value on the target Group) to move a class of devices from one Group’s policy to another.
• Retiring a Group. On Group Settings, delete the Group. Devices whose certificates carried that Group’s identifier stop matching and are rejected on the next attempt. Attribute Profiles are Context-scoped and are not deleted with the Group.

Operational tips

• One Group per device class, not per device. The Certificate Group Identifier routes a whole class; splitting finer than the policy boundary adds Groups without adding control.
• Fill the identifier from day one. Even with a single CA and a single device class, a consistent identifier avoids re-issuing certificates when you later add Groups.
• Attribute Profile per policy, not per Group. If three device classes share one VLAN, one Profile attached to all three Groups is the right shape.

Related

EAP-TLS with Device Certificate overview

The concept, when to use it, and how it differs from PEAP and Entra.

MAB fallback inside Device-Cert Groups

The MAC-based list that rides on each Group.

Attribute Profiles

VLAN, SGT, and tunnel attributes — reusable across Groups.

Trusted certificates

The Context trust store every device certificate chains to.