ChromeOS and Chromebook Security Guide: Policies, Enrolment and Data Protection

A Chromebook is secure by default only until someone signs in to it unenrolled, switches it into developer mode or lets it drift past its last update date. ChromeOS has a strong platform design: verified boot, a read-only root file system, sandboxed apps and automatic updates. Most of the risk in a fleet therefore comes from how it is enrolled and governed, not from the operating system itself. This guide covers the ChromeOS security model, enterprise enrolment and forced re-enrolment, the policies that matter in the Google Admin console, app and extension control, data controls, kiosk and shared devices, ChromeOS Flex, lifecycle and monitoring. It is written for endpoint, identity and workplace engineers who run Chromebooks alongside Windows and macOS fleets.

Key takeaways

• Enrol before first sign-in. A device must be enrolled before anyone signs in, otherwise it has to be wiped and enrolment restarted, and forced re-enrolment is what keeps a wiped or stolen device tied to your organisation.
• Developer mode is the off switch for the security model. Verified boot does not protect a Chromebook in developer mode, and forced re-enrolment is the control that keeps developer mode disabled on managed devices.
• Policy, not the operating system, is where fleets fail. Guest mode, open sign-in, unrestricted extensions, Linux virtual machines and unrestricted enrolment permissions are all choices made in the Admin console.
• ChromeOS Flex is not a Chromebook. Flex devices lack the Google security chip and verified boot, do not support forced re-enrolment and give weaker hardware-backed device trust signals.
• Track the "Automatic updates until" date. Google commits to 10 years of updates from platform release; after that, policies may not work as intended and the device stops receiving security fixes.

The ChromeOS security model

ChromeOS reduces the attack surface by design: users generally cannot run downloaded executables, the system partition is read-only and integrity checked, and apps run in sandboxes. The Australian Signals Directorate's small business guide summarises the built-in features as application control, automatic updates, a cloud-first design, a read-only root file system, restrictions on executables, sandboxes and verified boot.

Verified boot

The Chromium OS verified boot design describes a chain of trust. A small write-protected read-only firmware stub hashes the rewritable firmware and checks an RSA signature against a permanently stored public key before running it. The rewritable firmware then verifies the kernel. After the kernel starts, the root file system is checked on demand by dm-verity: each block (4 KB in the design) is checked against a hash tree whose root hash is fixed in the verified kernel. If verification fails, the device enters recovery. Google's own material describes two system partitions so the device can revert to a known-good image when tampering is detected.

Hardware and data protection

• Security chip: Google states that every Chromebook has a Google-designed Titan security chip that protects the credentials of users who sign in and the device policy binding.
• Encryption: user data is encrypted per user. The "User data" device setting can additionally erase all local user data at sign-out for shared devices.
• Sandboxing: websites, Google Play apps and the Linux development environment run in separate sandboxes. ASD notes that sandboxes do not stop an app from misusing permissions it was legitimately granted.
• Updates: ChromeOS updates automatically; Google describes a four-week major release cadence with security fixes as needed.

What the model does not cover

• Developer mode and Flex: verified boot does not apply to ChromeOS Flex or to Chromebooks in developer mode.
• The browser and the account: most attacks against Chromebook users arrive through the browser (phishing, malicious extensions, OAuth consent abuse) or through the Google or identity provider account, which verified boot cannot help with.
• Granted permissions: an approved extension or Android app with broad permissions can read data it was given access to.

ChromeOS attack surface

Enterprise enrolment and forced re-enrolment

Enrolment binds the device to your Google Admin console organisation and is what makes device policy, reporting and remote actions possible. Google's enrolment documentation is explicit that devices must be enrolled before anyone signs in; otherwise the device must be wiped and enrolment restarted.

Enrolment methods

• Manual enrolment: on the enrolment screen choose "Enroll the device" (Ctrl+Alt+E jumps to the enrolment step), sign in with an account that has enrolment permission and choose the licence type.
• Zero-touch enrolment: ChromeOS devices purchased through a participating reseller enrol automatically during initial setup. ChromeOS Flex uses automatic enrolment instead.
• User-driven enrolment: the "Initial sign-in" setting under Enrollment controls can be set to "Require users to enroll device" so a managed user signing in first on a new or reset device has to enrol it. The default is "Don't require users to enroll device".

Licences

Management requires a ChromeOS Enterprise Upgrade, ChromeOS Education Upgrade or Kiosk & Signage Upgrade. Kiosk & Signage devices cannot be used for user sign-in or managed guest sessions, so choose the licence for the use case before enrolling; changing it means deprovisioning and enrolling again.

Forced re-enrolment

The device setting for forced re-enrolment has three options: "Force device to automatically re-enroll after wiping" (the default), "Force device to re-enroll with user credentials after wiping" and "Do not force device to re-enroll after wiping". Keep it on. Google's device settings documentation notes that developer mode is disabled when forced re-enrolment is on, and its retirement documentation warns that disabling a lost device may fail unless forced re-enrolment is on. Once a device has enrolled in another organisation, you can no longer disable it.

Enrolment permissions

Restrict "Enrollment permissions" so that standard users can only re-enrol existing devices ("Only allow users in this organization to re-enroll existing devices") and only device administrators can enrol new devices, as ASD recommends. Turn on asset ID and location capture during enrolment so the inventory is usable from day one.

Policies that matter in the Admin console

Design organisational units (OUs) first. ASD recommends a top-level OU with baseline settings, a standard user OU for everyday work and an admin OU for privileged staff. Child OUs inherit and can override; group-based settings override OU settings, which is useful for exceptions but easy to lose track of.

Identity on the Chromebook

The device is only as trustworthy as the account that signs in to it. ASD recommends enforcing 2-Step Verification with any method except SMS or voice codes for the standard OU, and security keys only for the admin OU, with at least two super admin accounts including a break glass account protected by a security key. See the Phishing-Resistant MFA Guide and the Passkey Rollout Guide.

Apps, extensions and the Chrome browser

On ChromeOS the browser is the main workspace, so extension governance is endpoint security. ASD recommends "Block all apps, admin manages allowlist" for the Play Store and "Block all apps, admin manages allowlist, users may request extensions" for the Chrome Web Store, with external extensions blocked unless an OU needs them.

• Removal needs a blocklist: removing an app from the allowlist does not uninstall it; add it to the blocklist to force removal (ASD).
• Review permissions, not just names: an approved extension with access to all sites can read every page the user opens. Prefer extensions with narrow host permissions.
• Updates arrive automatically: an allowlisted extension can change behaviour in a later version without any admin action, which is why allowlisting alone is not enough (see Lessons from incidents).
• Alternative browsers: if users are allowed another browser, it needs equivalent controls (ASD).

See the Browser Extension Security Guide and the Enterprise Browser and Browser Security Guide.

Data controls and data protection

ChromeOS data controls let administrators govern data movement on the device itself, complementing Workspace and browser data loss prevention. They require ChromeOS 103 or later (file actions need 120 or later) and apply in user sessions and managed guest sessions.

Each rule uses one of four levels: Allow (overrides other rules, not reported), Report, Warn or Block. Reports show the rule, action, source, destination and metadata such as file name or page title, but not the content. Start every new rule in Report, review a few weeks of events, then move to Warn and Block. See the Endpoint DLP Guide.

Because most data lives in the cloud, backup is a cloud question. ASD advises against relying on Google Drive alone, notes its limited recovery windows, and recommends a dedicated backup with tested restores.

Kiosk, shared and managed guest devices

Chromebooks are widely used as kiosks, signage, frontline shared devices and exam machines, each with a different risk.

• Kiosk and signage: enrol with a Kiosk & Signage Upgrade, run a single app, set the "Action on idle" for kiosk power and turn on "Report kiosk session status" and "Report the running kiosk app". Only enable "Allow Kiosk app to control OS version" when the app vendor genuinely requires it, because it can hold the device back from security updates.
• Managed guest sessions: use "Allow managed guest sessions" for shared public devices so policy applies without named accounts; data controls still apply in managed guest sessions.
• Shared staff devices: set "User data" to "Erase all local user data" so nothing persists between users, and keep guest mode off.
• Peripherals: on kiosks, restrict "WebUSB API allowed devices" and "WebHID API allowed devices" to the hardware the app needs.

See the Kiosk and Shared Device Security Guide.

ChromeOS Flex and choosing hardware

ChromeOS Flex extends ChromeOS to existing PCs and Macs, which is attractive for reuse. Google's own documentation lists the security differences.

Decision guidance: Flex is reasonable for low-risk browser-only roles, labs and bridging hardware until refresh. For privileged users, regulated data or anywhere conditional access depends on hardware-backed device trust, use Chromebooks. Small organisations without zero-touch can still get most of the benefit by enrolling manually, enforcing forced re-enrolment and using the ASD baseline; large fleets should buy through zero-touch resellers so devices are never in user hands unenrolled.

Lifecycle: updates, loss and retirement

• Update end dates: Google's Auto Update policy gives 10 years of updates from the platform release date, and publishes an "Automatic updates until" date per model. After that date policies may not work as intended and support ends. Report on it and plan replacement a year ahead.
• Staged updates: use a pilot OU on Beta or the default Stable rollout one cycle ahead, then the main fleet. For change-sensitive kiosks consider LTS. If a release breaks something, set a specific "Target version" for the affected OU to stop further updates while the issue is fixed, then return it to "Use latest available version" quickly so security fixes are not held back.
• Lost or stolen: use "Disable with lock screen" (blocks use until re-enabled) or "Disable with factory reset" (also wipes user profiles, policies and enrolment data). Disabled devices stay enrolled and keep their licence.
• Retirement: deprovision with the right reason ("Retiring from fleet", "Same model replacement" and so on) and choose the factory reset option, so policies, printers and kiosk capability are removed and the device is wiped.
• Inactive devices: configure inactive device notifications (inactive range and cadence) so unused devices are found, recovered or deprovisioned.

Detection and measurement

ChromeOS devices do not run traditional EDR agents, so visibility comes from Admin console reporting, Chrome browser event reporting, identity provider sign-in logs and data control events. Forward them to your SIEM. See the Endpoint Telemetry Guide.

• Device reporting: OS version, hardware, telemetry and system logs to spot devices behind on updates or in an unexpected state.
• Browser events: managed browser cloud reporting and event reporting (ASD) for malware transfer, password reuse warnings and unsafe site visits.
• Data control events: Report and Warn hits show where sensitive data is moving before you block it.
• Admin audit: changes to enrolment permissions, forced re-enrolment, extension allowlists and OU moves.

Implementation roadmap

1. Inventory and licences: list every ChromeOS and Flex device, its "Automatic updates until" date and licence type.
2. OU design and admin hardening: create baseline, standard user, admin and pilot OUs; move administrators to security keys; create a break glass super admin.
3. Enrolment controls: turn on forced re-enrolment, restrict enrolment permissions, require enrolment at initial sign-in and set return instructions.
4. Pilot the baseline: apply the policy table to the pilot OU for two to four weeks, with data control rules in Report mode only. Roll back by moving the device or user back to the previous OU.
5. Extensions and apps: inventory installed extensions from reporting, build the allowlist, then switch to allowlist mode with a request process.
6. Fleet rollout: apply the baseline OU by OU; move data controls from Report to Warn to Block as evidence supports.
7. Monitor and refresh: wire reporting to the SIEM, review metrics monthly and retire devices before their update end date.

Framework mapping

Common failure patterns

• Signing in before enrolling: devices handed out unenrolled run with the user's consumer defaults and must be wiped to fix. Use zero-touch or require enrolment at initial sign-in.
• Forced re-enrolment turned off: a wiped or stolen device leaves management, developer mode becomes available and the "Disable" action may fail.
• Extension sprawl: leaving the Chrome Web Store open means any extension, and any future version of it, runs inside the managed session.
• Treating Flex like a Chromebook: applying conditional access rules that assume hardware attestation to Flex devices, which cannot provide it.
• Forgotten update end dates: devices past their "Automatic updates until" date stay in use because they still appear to work.
• Exceptions that never end: group-based overrides for Linux VMs, developer tools or guest mode created for a project and never removed.

Lessons from incidents

The Cyberhaven Chrome extension breach shows why extension control needs more than an allowlist. An attacker phished a publisher's OAuth consent, pushed a malicious version of a legitimate extension, and Chrome updated it automatically on users' devices; it was live for roughly 30 hours. Organisations that had allowlisted the extension received the malicious version too. Pair allowlists with permission review, monitoring of extension version changes in browser reporting, and a fast path to block an extension ID fleet-wide.

Practitioner checklist

• Enrol every device before first sign-in, by zero-touch where possible, and require enrolment at initial sign-in.
• Keep "Force device to automatically re-enroll after wiping" on and set disabled device return instructions.
• Restrict sign-in to your domain, disable guest mode and restrict enrolment permissions to re-enrolment for standard users.
• Enforce phishing-resistant 2-Step Verification, with security keys only for administrators and a break glass account.
• Run the Play Store and Chrome Web Store in allowlist mode and block external extensions.
• Block Linux virtual machines, developer tools, chrome://flags and Crosh for standard users.
• Deploy data control rules in Report mode first, then Warn and Block.
• Stage updates through a pilot OU and track each model's "Automatic updates until" date.
• Treat ChromeOS Flex as lower assurance: UEFI Secure Boot, firmware password, no external boot, and no high-trust access.
• Forward device, browser and data control reporting to the SIEM and review the metrics monthly.

Standards and references

• Google: Enroll ChromeOS devices
• Google: Set ChromeOS device policies
• Google: Set ChromeOS data controls
• Google: Auto Update policy
• Google: ChromeOS Flex security
• Chromium: Verified Boot design document
• Australian Signals Directorate: Small business Google Chromebook and ChromeOS security guide
• MITRE ATT&CK: Browser Extensions

Related NHI Mgmt Group resources: Endpoint Security Guide · Device Trust and Posture Guide · UEM Buyer's Guide · Windows Endpoint Hardening Guide