Device security guidance

For an enterprise deployment of ChromeOS devices, you should:

• Decide which ChromeOS devices your organisation will use.
  • Once a device has reached its Auto Update Expiration (AUE) date, it will no longer receive updates, policies may not work as intended, and technical support will cease, so you should purchase new devices.
  • The exact dates of AUE for different vendors and models of ChromeOS devices are published on Google's website.
  • Typically, ChromeOS devices manufactured after 2021 come with 10 years of support from the date of initial manufacture.
• Update your devices to the latest stable channel ChromeOS version and apply any Trusted Platform Module (TPM) updates. Install any available TPM firmware updates during the device provisioning stage.
• Use one of our recommended network architectures to enable remote access to enterprise services.
• Use a Mobile Device Management (MDM) service to manage your organisation’s devices. This will give you maximum control over which policies to enforce on your devices. For ChromeOS devices that are enrolled into an MDM solution, you need the Chrome Enterprise Upgrade licence to unlock all managed capabilities.
• Decide if you want to enable the Linux Developer subsystem (known as Crostini) in the MDM, noting it is disabled by default. If you enable it, you should put separate controls in place to manage it.
• Configure the logging and monitoring capabilities of the MDM, as appropriate for your organisation.
• Configure a virtual private network (VPN) where required:
  • ChromeOS supports the use of NCSC recommended protocol IPSec IKEv2 which can be configured using the built-in client. This can  be deployed via an MDM (such as Google Workspace).
  • If a third party VPN is required, use an official Android app deployed by the Google Play Store to manage and configure the connection on ChromeOS.
  • When using third party VPN solutions, you should test that ChromeOS, Crostini and Android traffic are protected by the VPN (where required) and that the VPN is automatically started.
• Centrally approve third-party apps for work use (managed apps) in an enterprise app catalogue. Either automatically install them during setup, or make them available in the Managed Google Play Store.
• Centrally manage the user accounts via an MDM service such as Google Workspace, or configure third party identity federation via Google Workspace and link to an existing identity service such as Microsoft Entra ID.
• Avoid deploying antivirus and other security software to the core ChromeOS as this is not necessary. Consider instead the use of security protections for Crostini and the Android subsystem used in ChromeOS.

You may want to offer your organisation’s users a range of productivity and business applications to enable collaborative and remote working. We recommend the use of built-in apps, or the functionality provided by your cloud infrastructure, wherever possible as they provide greater trustworthiness and security. 

You should exercise caution with high-privilege applications, such as third-party keyboards, network extensions, assistive and accessibility apps. These types of application typically request high-privileged access permissions, including access to large amounts of work data, thereby posing a higher risk to your organisation.

Chrome apps

Chrome apps are no longer being developed and between July 2025 and February 2028 Google will be phasing out all support for existing installations of them. Chrome apps can be managed and deployed via Google Workspace or other supported MDM by default.

We recommend that organisations:

• Block the installation and execution of Chrome apps unless they are listed on an allow list.
• Consider alternatives to Chrome apps if users need custom built applications for their ChromeOS devices. Developing an Android app or Progressive Web App (PWA) for deployment via the MDM is a suitable alternative solution.

Browser extensions

Browser extensions in ChromeOS apply to the Chrome browser and can be managed via Google Workspace or a supported MDM, as for Chrome apps.

Be aware of the permissions requested by browser extensions, as they can potentially read and access all web data in the browser and interact with the webpages accessed by users.

Administrators should block unknown extensions and use an allow list for trusted extensions. Chrome extensions (like other popular browser extensions) have been found to contain spyware, advertising injections and crypto currency mining code even if the extension has been trusted previously. We advise that administrators regularly monitor updates to any extensions on the allow list.

Android apps

You can install and manage apps from the Google Play Store whilst the device is enrolled into Google Workspace or other supported MDM solution. From Google Play Store an administrator can choose to:

• allow all Play apps but enforce a deny list
• only allow the search and installation of approved apps via an allow list

Android apps are run in a separate Android container within the ChromeOS core and do not have access to the OS itself. This ensures that the data stored within ChromeOS remains sandboxed.

Permissions for Android apps within the ChromeOS system adhere to standard Android app controls and can access certain services, such as the camera, through dedicated services. When deploying an Android app via Google Workspace, administrators should note that all specified permissions will be granted to the app on the client machine unless the user manually revokes them.

The ChromeOS core and the Android subsystem do not share a file system but users are able to move data between them using the built-in Files app within ChromeOS.

Whilst Android apps on ChromeOS cannot access the core of the ChromeOS they may use Intents, Content Providers or shared files within the Android subsystem to exchange data between Android apps (in the same limited way they can on an Android phone).

Android apps running on ChromeOS have the same permission management built into Android. The end user has full control over the permissions an app is granted when installing from the Google Play Store.

Progressive Web Applications (PWAs)

PWAs can be installed on ChromeOS by the user via the Chrome browser or via an MDM.

Once installed, they can be accessed via the application menu and pinned to the user interface (UI) taskbar.

They are supported via the built-in Chrome web browser and have the same protections (such as sandboxing) as those implemented on standard webpages.

Whilst a PWA cannot directly interact with the core ChromeOS, administrators should be aware that users may seek to install unauthorised PWAs and therefore use web filtering to block their installation.

PWAs can be removed from ChromeOS devices but reinstallation cannot be blocked. If a PWA is removed from the ChromeOS deployment, the user can manually reinstall it. Administrators should block the URL of an unwanted PWA to prevent users accessing it.

If a malicious PWA were installed there may be a minimal impact on user data and the integrity of the device. However, it is worth noting that a PWA can be used as part of a phishing attack.

Since PWA update mechanisms are not centrally managed, it is possible for a developer to change the purpose & identity of a PWA without needing to verify the change.

Crostini apps

Crostini is the product name of the virtual machine (VM) based subsystem within ChromeOS which by default installs a Google-modified version of Debian. You can use Crostini to install custom VMs by enabling additional flags, but we will not cover this here.

Crostini is considered a development environment tool within ChromeOS and can enable the installation of .deb packages – as well as other Debian supported applications – in its default state.

Whilst Crostini is available to all Chromebook (and select ChromeOS Flex) devices, it remains in beta^[1] for managed ChromeOS users.

There is very little control inside of the default Debian instance and as a result, there are no fine-grained controls of Crostini inside existing MDM solutions (including Google Workspace).

Unless explicitly required we recommend you disable Crostini via the MDM.

If your users need access to development VMs via Crostini, we recommend investigating MDM solutions that support Linux and allow management of the entire Crostini core.

Crostini is sandboxed from the core ChromeOS. This means the Crostini cannot communicate with ChromeOS except for the allowed resources via dedicated pre-built services within the default installation. Applications running within the Crostini system can access each other within the VM containers, including the system files of that container.

The default user of Crostini can use the sudo to root command to obtain root privileges.

Deploying antivirus and other security software on the core of ChromeOS is unnecessary, as Google does not recommend it. The OS manages security using built-in controls like sandboxing.

Administrators should be aware that the Crostini & Android subsystem is not managed in the same way as the core ChromeOS. As a result, you should:

• Consider the use of an anti-virus solution on your Crostini instance.
• Either enable Google Play Protect or install a third party solution within the Android subsystem.

Once you have chosen your MDM service, architecture and approach to applications, you should develop a device configuration which will enforce your technical controls.

In particular, you should include policies that manage:

• External interfaces, including wired and wireless peripherals (for example, disabling USB accessories when the device is locked).
• The use of biometrics (where available), as well as configuring password and authentication policies including support of passkeys on supported applications.
• Google Cloud services that you want to enable or disable.
• Device OS and application updates, including automatic updates.
• Disabling (or enabling where needed) developer, sideloading and beta functionality, such as Crostini and Google Assistant (including Gemini).
• Verified Boot, which should be enabled and enforced by the MDM as a requirement to access company resources.
• User data stored on the ChromeOS device. User data is encrypted from the point where the user logs into the device. There is no need to apply additional disk encryption to a ChromeOS device. Administrators should consider controls around the storage, retention and uploading of data to third party services (including Cloud storage and backup).
• Access to experimental features under the `chrome://flags` settings. Typically, these should be disabled to prevent access to untested or unmanaged features that might bypass MDM controls.