Stolen Clinical Chromebook with Local Data and a Client Certificate
A clinical research coordinator's Chromebook was stolen from a locked car. The device is enrolled, assigned to the coordinator, and last synced 14 hours before the theft. The coordinator was signed in and had downloaded a patient roster to the Downloads folder, mounted a client certificate for the research portal, and enabled Google Drive offline access for a folder containing consent PDFs. The device has a screen lock PIN, but the coordinator shared the PIN with a colleague two weeks earlier. The research portal uses SAML SSO with 12-hour sessions and the client certificate is issued by the organization's internal CA. The device model is still supported and has a TPM. The security team asks whether to deprovision, disable, or remote wipe, and what else to do before the next portal audit.
1. What immediate containment actions should be taken, and in what order?
Read the worked answer
Treat the device as compromised, not merely lost. First disable the device in the Admin console so it cannot be used to sign in or access managed resources when it reconnects. Next suspend or disable the coordinator's identity and revoke active sessions, then reset the password and require reauthentication. Issue a remote wipe command to the device, understanding that it will execute only when the device next connects; it is not a guarantee while the device is offline.
Revoke the client certificate through the internal CA and publish or refresh the revocation data used by the research portal. Because the PIN was shared, do not rely on screen lock as protection. Review the portal's session behavior: a 12-hour SAML session may still be valid, so explicitly terminate sessions at the portal if it supports administrative revocation. Preserve device, IdP, portal, and Drive audit logs before changing accounts or deprovisioning. Do not deprovision the device yet; deprovisioning removes management and does not wipe data, which would weaken containment.
2. What can remote wipe and ChromeOS encryption guarantee in this case, and what can they not guarantee?
Read the worked answer
ChromeOS encrypts user data at rest, and the TPM binds keys to the device and user account, so a thief cannot simply remove the drive and read files. That protection is meaningful, but it is not absolute here. The coordinator was signed in, the PIN was shared, and offline Drive files and a downloaded roster existed locally. If the device is unlocked or the PIN is known, an attacker may reach cached data before the wipe executes.
A remote wipe can remove the local profile and stored data once the device connects, but it cannot prove that data was never viewed while offline. It also cannot revoke a client certificate or terminate a portal session; those require CA and application action. Do not tell auditors that encryption plus a pending wipe equals no exposure. State the facts: device encrypted, PIN compromised, offline data present, wipe pending, certificate revoked, sessions terminated, and portal access logs under review.
3. What follow-up and reporting steps are needed before the portal audit?
Read the worked answer
Build a timeline from the last sync, theft report, disable action, wipe command, certificate revocation, session termination, and password reset. Review portal logs for access from the device or user after the theft, Drive activity for the offline folder, and any label or export events involving the patient roster. Confirm whether the stolen device had any local printer or USB configuration that could have moved data.
Notify privacy or compliance according to the organization's incident process, because patient data may have been present on the device. Document the shared-PIN policy violation and the decision to disable rather than deprovision. If the device is recovered, do not reissue it until it has been wiped, re-enrolled, and verified; if it is not recovered, deprovision only after the incident closure decision. Update the audit response with the certificate revocation proof and the exact limits of the remote wipe.