What Caused the Shared Chromebook ePHI Incident? Postmortem

The incident was caused by a shared Chromebook remaining signed in to a workforce member’s Google Workspace account after a telehealth shift, allowing a subsequent user to access ePHI in Gmail, Google Drive, and a browser-based patient portal. This shared Chromebook ePHI incident postmortem found that the underlying failure was not a single missed logout: the organization had no enforced shared-device session controls, no documented workstation-use procedure for that workstation class, and no operational verification that staff followed the intended workflow. Under HIPAA’s Workstation Use standard at 45 CFR § 164.310(b), the organization needed policies and procedures defining the permitted functions, manner of use, and physical surroundings for workstations that access ePHI.

What happened during the shared Chromebook ePHI incident postmortem?

This composite incident involved HarborLine Virtual Care, a 42-person provider group delivering behavioral-health and chronic-care telemedicine appointments. HarborLine used Google Workspace Business Plus, a Chrome Enterprise-managed Chromebook fleet, Google Drive, Gmail, Google Meet, and a cloud-based EHR accessed through Chrome. Two Chromebooks were located in a shared clinical operations room used by care coordinators to confirm appointments, send intake links, and assist patients with video-visit troubleshooting.

The devices were technically enrolled in Chrome Enterprise, but the enrollment configuration was designed for general office browsing rather than a workstation class that routinely accessed ePHI. Staff were told during onboarding to “sign out when finished,” but that instruction did not appear in a formal workstation-use policy, device signage, shift checklist, or management report.

Timeline of the event

The forensic scope was narrower than many organizations expect. Google Workspace audit logs could identify the user account, device, IP address, Drive download event, and Gmail message access. They could not independently prove whether the downloaded file was copied to removable media, photographed, or otherwise retained. That limitation mattered in the organization’s risk assessment and reinforced why prevention at the workstation is more reliable than reconstructing behavior afterward.

What did the root cause analysis identify?

The immediate cause was an unattended authenticated session on a shared Chromebook. The root cause analysis found four contributing conditions:

• Shared use was permitted without a shared-device design. HC-OPS-04 was treated as a convenience device, although it was routinely used to access ePHI. It had no kiosk workflow, no managed guest-session configuration, and no requirement to authenticate separately at the start of each task.
• ChromeOS session controls were too permissive. The Chromebook allowed a 30-minute idle period before lock. The device did not require users to sign out at shift changes, and staff could leave browser sessions accessible to the next physical user.
• Google Workspace access persisted after the business task ended. Gmail and Drive sessions remained available in the signed-in Chrome profile. Restricted shared-drive permissions limited access to authorized workforce accounts, but they did not protect against another person using an already authenticated account.
• The physical environment was not addressed. The operations room had intermittent traffic, shared desks, and no defined ownership of devices between shifts. The organization had not classified the room as a semi-public shared workspace requiring shorter lock periods and explicit handoff procedures.

For an MSSP analyst, this distinction is important: this was not primarily a failed Google Drive permission model. Drive permissions worked as configured. The failure was that an authorized identity remained available to an unauthorized physical user. Identity controls, endpoint settings, and workstation procedures must operate together.

Why did the HIPAA Workstation Use control fail?

HarborLine had a general acceptable-use policy and a HIPAA security-awareness training module, but neither met the practical intent of 45 CFR § 164.310(b) for this workstation class. The requirement calls for policies and procedures that specify proper workstation functions, how those functions must be performed, and the physical characteristics of the surroundings where ePHI-capable workstations operate.

The organization could describe what the Chromebook was used for—scheduling support and patient communications—but could not produce a procedure defining how shared use had to occur. There was no instruction requiring a user to sign out of ChromeOS before leaving the device, no prohibition on using another person’s active session, no rule for clearing local downloads, and no requirement for supervisors to inspect shared devices at shift end.

The organization also made an assumption common in smaller environments: because each worker had a unique Google Workspace account and multi-factor authentication, the Chromebook was sufficiently controlled. MFA protected initial authentication, but it did not protect an open session on a physically accessible device. The Chromebook ePHI event exposed that gap.

What corrective and preventive actions were taken?

Containment began with evidence preservation and access limitation. The MSSP exported relevant Google Workspace audit records, including Drive log events, Gmail log search results, Admin audit events, and Chrome device details. The organization documented who had physical access to the room during the exposure window and interviewed the contractor under its incident-response process.

Within 48 hours, HarborLine applied the following Chrome Enterprise and Google Workspace changes to all shared clinical-operations Chromebooks:

Chrome Enterprise settings for shared clinical devices
- Device sign-in restriction: Allow only @harborlinecare.com accounts
- Screen lock delay: 5 minutes
- Require password to wake from sleep: Enabled
- Guest mode: Disabled
- Incognito mode: Disabled
- Force re-enrollment: Enabled
- Auto-launch kiosk mode: Disabled for ePHI workflows
- Chrome profile sign-in: Required
- Download restrictions: Block dangerous downloads; review Downloads folder at shift close

Google Workspace controls
- Drive shared drives: Restrict content access to assigned operations groups
- Context-Aware Access: Require managed devices for Drive and Gmail access
- Gmail confidential mode: Enabled for outbound patient-document workflows where appropriate
- Alert Center rules: Alert on high-volume Drive downloads and suspicious OAuth activity
- Vault retention: Confirm Gmail and Drive retention supports incident investigation

Not every control was technical. HarborLine replaced the informal instruction with a workstation-use procedure specific to shared clinical devices. It defined permitted functions, prohibited personal browsing, required individual sign-in, required sign-out whenever the device was unattended or handed to another user, and required a visual check of the Downloads folder before shift completion. The procedure also defined the operations room as a controlled staff-only area: screens had to face away from doors, visitors required escorting, and devices could not be moved to waiting areas or patient-facing spaces.

A second worked example came from the remediation pilot at a 19-provider telemedicine practice using Google Workspace Enterprise Standard. Its front-desk Chromebook had been used by rotating staff to launch Google Meet links and verify patient identity. Rather than allowing a generic shared workflow, the practice assigned the device to a named role, required each employee to authenticate with an individual managed account, set a five-minute screen lock, and added a laminated shift-handoff card beside the device. The card did not replace policy; it made the required behavior visible at the moment it mattered.

What lessons generalize from this shared-device incident?

• Classify workstations by use and surroundings, not hardware type. A Chromebook in a locked executive office and a Chromebook in a rotating operations room need different controls even if they have identical technical specifications.
• “Shared” must be a deliberate operating model. If multiple people can physically use a device, design for separate authentication, short idle locks, documented handoffs, and auditability. Do not rely on courtesy logouts.
• Session security is part of access control. Unique accounts and MFA are incomplete when an authenticated session can be inherited by the next person at the keyboard.
• Test procedures through observation. During quarterly reviews, ask an employee to demonstrate what happens when they step away from a shared workstation. Policy acknowledgement alone will not expose a 30-minute lock timeout or an ambiguous handoff practice.
• Preserve evidence before making broad changes. In this shared Chromebook incident, Google Workspace logs established the access path and scope. Suspending sessions and isolating the device quickly reduced further exposure while preserving the records needed for the HIPAA assessment.

For MSSPs supporting SMB customers, the next step is to inventory every shared ChromeOS device that can reach ePHI and validate its technical settings, physical placement, and documented workstation-use procedure against 45 CFR § 164.310(b).