PKI for Education: Handling Certificate Revocation for Shared Devices

A 1:8 Chromebook cart can quietly break around the eighth or tenth student login, when the per-user certificate stops re-installing and the entire cart drops off Wi-Fi. The same break shows up in the enterprise: an Intune-managed laptop loses connectivity after the second user re-enrolls because the prior certificate has already been revoked. Both failures trace back to the same root cause, the “one user per device” assumption baked into most PKI deployments.

This article walks through PKI shared device certificate revocation as a design problem, not a bug. Education IT and identity teams need a model that issues, renews, and revokes certificates without breaking the connection that the next user depends on.

What Is PKI Shared Device Certificate Revocation?

PKI shared device certificate revocation is the lifecycle process by which a public key infrastructure issues, tracks, and revokes digital certificates on devices that are used by more than one person. On a single-user laptop, revocation is straightforward: when the user leaves, the certificate is added to a Certificate Revocation List (CRL) or marked invalid via Online Certificate Status Protocol (OCSP), and the device follows the user out.

On a shared device, revocation must be selective. The certificate tied to the departing student or shift worker must be revoked without invalidating the device certificate, the next user’s certificate, or the trust chain anchored in the device’s TPM.

Most PKI platforms model identity as a 1:1 binding between a user and a private key stored on a device. That binding is what breaks when the device is shared. Education environments and large enterprise deployments need an explicit multi-user model from day one.

Why the “One User Per Device” Assumption Breaks

Most certificate enrollment flows, whether SCEP, ACME, or PKCS, were originally designed for managed laptops issued to a single employee. Mobile Device Management (MDM) provisions a certificate, the user keeps it for the device’s life, and revocation happens once: at offboarding. That model maps poorly onto two common real-world scenarios.

Scenario 1: Chromebook Carts at a 1:8 Ratio

A K-12 school district with 1:8 Chromebook ratios runs into a predictable failure pattern. The first few students sign in, get their per-user certificate via SCEP, and connect cleanly. Around login eight or ten, certificates stop installing.

The cause is rarely a single bug. It is usually a combination of three issues: extension storage limits on ChromeOS, a SCEP gateway throttling repeated requests from the same device, and stale certs from prior users that have not yet been removed.

When the fix is applied incorrectly, IT revokes the device certificate to force a re-enrollment, which strips the network connection the device needs to fetch the next certificate. The cart now sits in a connectivity loop until someone manually re-enrolls each Chromebook.

Scenario 2: Intune-Managed Windows Devices Re-Enrolled Under a New User

In a hospital, manufacturing space, or training lab, a Windows device is sometimes re-enrolled in Intune under a different user account. Intune’s PKCS or SCEP profiles are by default scoped to the user, which means the prior user’s certificate is revoked the moment the device is re-associated.

Intune is doing exactly what it was configured to do. The problem is that the deployment never accounted for a device changing hands, so the certificate revocation cascades into an Active Directory join failure, a Wi-Fi drop, or a VPN re-prompt loop.

Scenario 3: Powerwash Strips TPM-Bound Trust

ChromeOS Powerwash and Windows reset operations strip the TPM-bound trust that the device certificate relied on. Even if the certificate authority still considers the device certificate valid, the private key is gone. From the network’s perspective, the device is now unauthenticated. Recovery requires a full enrollment from scratch, which on a shared cart can be hours of hands-on work per device.

Multi-User PKI for 1:Many Deployments

The fix for PKI shared device certificate revocation failures is to stop treating shared devices as single-user devices. A working multi-user PKI deployment issues two distinct certificate types and revokes each on its own trigger.

Device Certificate

A device certificate is issued once per physical endpoint and stays bound to the device’s TPM or secure element. It authenticates the device to the network whenever no user is logged in, which keeps Chromebook carts on Wi-Fi between student sessions so the next user can fetch their per-user cert at sign-in. The device certificate is revoked only when the device is retired, lost, or wiped, never when an individual user leaves.

User Certificate

A user certificate is issued at the moment a person logs in and is bound to that user’s directory identity, not the device. The user certificate is revoked when the user leaves the Student Information System (SIS) or directory. Because the device certificate keeps the network alive, the next user can sign in and get their own certificate without IT touching the cart.

This split is what keeps a 1:8 Chromebook cart healthy past the tenth login. It is also what allows an Intune-managed Windows device to be re-issued to a new user without an outage. The prior user’s certificate is revoked, the new user’s certificate is enrolled, and the device certificate is unaffected.

Configuring Multi-User Support

In Google Workspace, the SCEP profile for ChromeOS exposes both Chromebook (user) and Chromebook (device) certificate types. Both should be enabled for shared cart deployments. In Intune, separating user-scoped and device-scoped PKCS or SCEP profiles produces the same result. Most schools and enterprises that hit shared-device failures had only one of the two profile types deployed.

Separating User and Device Authentication Strategies

The certificate split needs a matching authentication strategy on the network side. A RADIUS server that only does user-based EAP-TLS lookups will treat a device certificate as a user that does not exist. A RADIUS server that only does device-based lookups will block per-user network access policy.

Cloud RADIUS supports both lookups at the moment of authentication, so a shared device can present a device certificate before login and a user certificate after, and the policy applied matches whichever entity authenticated. That capability is what makes the multi-user PKI model practical in production.

For 802.1X EAP-TLS deployments specifically, the 802.1X authentication configuration should be set up to validate certificates against the directory at every authentication, not just on the first connect. This is the difference between a stale revocation that grants access for hours after a student leaves and a revocation that takes effect on the next association.

Common Revocation Triggers in Education and Shared Environments

The triggers that revoke a certificate in a shared deployment are not the same as in a 1:1 environment. The most common are:

• User removal from the SIS or directory: revokes the user certificate, leaves the device certificate intact.
• Device retirement, wipe, or loss: revokes the device certificate and any active user certificates on it.
• Re-enrollment under a different user: in Intune, this is the documented behavior and revokes the prior user’s certificate.
• Powerwash or factory reset: strips TPM-bound keys; the certificate is technically still valid on the CA but unrecoverable on the device.
• Suspected key compromise: an explicit administrative revocation, propagated via CRL or OCSP.

Each trigger should map to a specific lifecycle action in the certificate authority. Mapping them informally, or mapping multiple triggers to the same action, is what produces the connectivity loops described above.

Simplifying Shared Device PKI with SecureW2

Dynamic PKI is built for shared and multi-user deployments. It issues device and user certificates from a single managed cloud CA, integrates with Google Workspace, Intune, Jamf, and other major MDMs, and pairs natively with Cloud RADIUS for both user-based and device-based authentication. Schools running 1:many Chromebook carts and enterprises with shift-worker laptops use it to keep shared devices on the network without manual intervention every time a user changes.

To see how the multi-user model works on real devices, schedule a demo with the SecureW2 team.

---

Frequently Asked Questions

How does certificate revocation work for shared devices?

Revocation works at two layers. The user certificate is revoked when the user leaves the directory or SIS, which removes that person’s access without disturbing the device or other users. The device certificate is revoked separately when the endpoint is retired, wiped, or lost. Both revocations propagate via the Certificate Revocation List or OCSP, and a properly configured RADIUS server checks one or both at every authentication.

Can multiple users have certificates on the same Chromebook?

Yes, when both Chromebook (user) and Chromebook (device) certificate profiles are enabled in Google Workspace. Each student who logs in receives a per-user certificate bound to their identity, and the Chromebook holds a separate device certificate that authenticates to Wi-Fi between sessions. This is the supported configuration for 1:many cart deployments.

What happens to a certificate when a user is removed from a school’s SIS?

The user certificate tied to that student is revoked automatically when the SIS removal syncs to the certificate authority and the directory. Network access is terminated on the next 802.1X authentication. The device certificate on whatever Chromebook the student last used is not affected.

Why does my certificate stop installing after several student logins on a Chromebook?

The most common causes are a SCEP gateway rate-limiting repeated requests from the same device, ChromeOS extension storage limits accumulating stale certificates, or a device certificate that was revoked when only the user certificate should have been. Check whether device-level SCEP is enabled and whether prior user certificates are being cleaned up at logout.

Does Intune revoke a certificate when a device is re-enrolled under a different user?

Yes, by design. Intune’s user-scoped PKCS and SCEP profiles bind the certificate lifecycle to the user object, so re-enrolling the device under a new user revokes the prior certificate. To support shared Windows devices, deploy a separate device-scoped certificate profile so the endpoint stays authenticated to the network regardless of which user is signed in.