What's New - CIS Google Chrome Browser for Intune Benchmark v1.1.0

Update: Thanks to SkiptotheEndpoint for the feedback and insights that improved the Intune deployment guidance below.

CIS released version 1.1.0 of the Google Chrome Enterprise Core Browser Benchmark on 3rd August 2026. It adds two hardware-backed controls that fight credential theft, a set of generative-AI governance settings, and drops a couple of deprecated recommendations. If infostealer malware and session-token theft are on your radar, it's worth a look.

What is the benchmark?

CIS benchmarks are consensus-driven hardening guidelines. The Google Chrome Enterprise Core Browser Benchmark hardens Chrome through Chrome policies, each rated Level 1 (baseline) or Level 2 (stricter, may affect functionality).

There is no official CIS Intune edition for Chrome. The benchmark targets Chrome Enterprise Core (the Google Admin console), but the policies are the same ones defined in the Chrome ADMX templates. So in a Microsoft-first estate you deliver that ADMX config through Intune: same controls, different delivery.

What's changed in v1.1.0?

The benchmark grows from 111 to 120 recommendations: 11 new, 2 removed, plus a handful of updates. A new Accessibility section shifts the numbering of everything below it down by one.

Tip: track controls by title or policy name, not section number, as most numbers from 2.11 onwards have moved.

New controls

Credential and session protection

• Application bound encryption (2.4.26, L1): locks Chrome's saved-password and cookie encryption keys to Chrome's own identity, so other processes can't read them.
• Device Bound Session Credentials (2.4.25, L1): uses the TPM to bind sessions to the device, making a stolen cookie useless elsewhere.
• Allow Basic authentication for HTTP (2.6.3, L1): requires HTTPS before Basic auth credentials are sent.

Generative-AI governance

• Translator API (2.8.3, L1): disallow the on-device Translator API.
• Local foundational model settings (2.14.6, L1): stop Chrome downloading and running Google's local model (Gemini Nano).
• Built-in AI APIs (2.14.8, L1): block sites from calling Chrome's built-in LanguageModel, Summarization, Writer and Rewriter APIs.
• Live translate (2.11.1, L2): disable the Live Translate accessibility feature.

General hardening

• Origin-keyed process isolation (2.3.2, L1): isolate per-origin rather than per-site.
• Proxy socket pool size randomization (2.6.14, L1): randomise socket-pool limits to frustrate abuse.
• Dynamic Code (2.4.27, L2): enable Arbitrary Code Guard on the browser process.
• File system write access (2.12.6, L2): stop sites requesting write access to local files.

Removed controls

• Manifest v2 extension availability (was 2.2.1, L2): Manifest V2 is being phased out, so it's deprecated.
• Firewall traversal, 'Disable the use of relay servers' (was 2.5.3, L1): redundant with the broader 'Disable firewall traversal' (2.5.2).

Notable updates

• Browser sign in settings (2.1.1): raised from L2 to L1, and now accepts either 'Disable browser sign-in' or 'Force users to sign in'.
• Enable leak detection for entered credentials (2.4.13, L1): no longer depends on Safe Browsing being enabled first.
• Help me read (moved to 2.14.7): reclassified from a manual check to an automated one.

Deploying through Intune

Most of these settings are available natively in the Intune Settings Catalog, which now includes Google Chrome out of the box. That is the primary and cleanest way to deploy them. However, the native catalog does lag Chrome's release cadence, so the very newest policies in v1.1.0, along with Google Update settings that aren't in the catalog at all, may not be there yet. For those, you can import the Chrome ADMX templates.

A few things to know about Microsoft Best Practice before you import:

• It's still in public preview. ADMX import into Intune remains a public preview feature, so factor that into any production rollout.
• Updates are painful. You can't just re-upload a newer ADMX over an existing one as it will fail with a namespace error. To replace one you must delete every profile using it, delete the ADMX, then re-import, which makes ongoing maintenance awkward.
• Don't import in-box Windows ADMX. Microsoft advises against uploading built-in files like windows.admx, as those settings are delivered through CSPs. chrome.admx declares the Windows namespace but never actually uses it, so the clean fix is to delete that line rather than import windows.admx

<using namespace="Microsoft.Policies.Windows" prefix="windows"/>

You'll still need to import google.admx first, as that's a genuine dependency for both chrome.admx and googleupdate.admx.

You can download the official templates from Google's Chrome Enterprise and Education Help, then import via Devices > Configuration > Import ADMX in the Intune admin center.

The policy value names for the key new controls are:

Confirm the accepted values at chromeenterprise.google/policies before building the profile.

Top 3 to implement first

All three tackle the same shift: attackers steal live sessions instead of passwords.

1. Application Bound Encryption (2.4.26, L1)

Infostealers grab Chrome's saved passwords and session cookies to walk straight past MFA. The old DPAPI protection stops other user accounts but not another process running as the same user. App-Bound Encryption locks the keys to Chrome's own identity, so same-user malware can't read them. It won't stop an attacker who already has local admin, but it closes the path being exploited at scale today.

Deploy: set ApplicationBoundEncryptionEnabled to Enabled.

Watch out: keys are bound to the hardware, so data won't roam between machines. Test with roaming-profile users before rolling out.

2. Device Bound Session Credentials (2.4.25, L1)

If App-Bound Encryption protects the cookie, DBSC protects the session. Chrome uses the TPM to bind a session to the device and re-checks on every token refresh, so a stolen cookie won't work on another machine. Together they make a cookie both hard to steal and useless if stolen.

Deploy: set BoundSessionCredentialsEnabled to Enabled.

Watch out: only works where the identity or SaaS provider supports it (Google Workspace and Okta are early adopters) and needs a working TPM. Little downside to enabling it now.

3. Disable Basic authentication over HTTP (2.6.3, L1)

The easy win. Basic auth over plain HTTP sends credentials in near-cleartext; this forces HTTPS first.

Deploy: set BasicAuthOverHttpEnabled to Disabled.

Watch out: legacy apps, appliances and printer admin pages on HTTP will break. Inventory them first, since anything it breaks was already leaking credentials.

In summary

v1.1.0 is a threat-driven release. App-Bound Encryption and DBSC move Chrome's baseline to where attacks actually happen: stolen sessions, not cracked passwords. The AI controls rein in Gemini and the built-in AI APIs, and the two removals clear out dead settings.

If you're not already hardening Chrome through Intune, take this as your prompt to start, and keep your ingested ADMX current so the newest policies are there to deploy.

Resources

• CIS Google Chrome Benchmarks
• Chrome Enterprise policy list
• Import custom ADMX templates into Intune (public preview)
• Download the Chrome ADMX templates (Google)