Enterprise Browser and Browser Security Guide

The browser now holds the credentials, session cookies and data that attackers want, yet in many organisations it is the least managed application on the endpoint. Saved passwords, long-lived session cookies, unvetted extensions and personal profiles syncing work data all sit inside it, and infostealer malware is built to harvest them. This guide compares the options (a hardened managed browser, a browser security extension, an enterprise browser and remote browser isolation), sets out baseline Chrome and Edge policies, covers extension control, credential and cookie theft and browser DLP, and gives a phased rollout with metrics. It is written for endpoint, identity and security operations teams choosing or tightening browser controls.

Key takeaways

• Manage the browser you already have first. Chrome and Edge both offer free cloud or Group Policy management with well over 100 policies; most organisations get the largest risk reduction from enforcing them on managed devices.
• Block all extensions, then allow by ID. A default-deny ExtensionSettings policy with permission and host restrictions is the single most effective browser control, because extensions can read pages, cookies and tokens.
• Treat the browser profile as a credential store. Disable the built-in password manager where an enterprise one exists, keep App-Bound Encryption on, prevent personal profiles and sync on work devices, and shorten session lifetimes.
• Use an enterprise browser where you do not own the device. Contractors, BYOD and third parties are where a secure enterprise browser or isolation earns its cost; on fully managed devices a hardened managed browser often suffices.
• Measure it. Track policy coverage, extension inventory against the allowlist, password reuse events and DLP blocks, and send browser telemetry to the SIEM.

Why the browser is a priority control point

• Credentials at rest: MITRE ATT&CK T1555.003 describes how attackers read Chrome's AppData\Local\Google\Chrome\User Data\Default\Login Data database and decrypt passwords with the Windows CryptUnprotectData API, which uses the logged-on user's context.
• Sessions after MFA: T1539 Steal Web Session Cookie notes that stolen cookies can let an attacker act as the user and sometimes bypass multi-factor authentication. The Snowflake breach and the Scania portal breach both began with credentials harvested by infostealers.
• Extensions as persistence: T1176.001 Browser Extensions covers malicious extensions that capture data entered in the browser, and attackers editing Chromium's Preferences or Secure Preferences files so an extension loads without consent.
• Session hijacking in place: T1185 Browser Session Hijacking covers injecting into the browser to inherit the user's cookies and authenticated sessions to internal sites.
• Data leaves through the browser: uploads, pastes into AI assistants and personal webmail, and printing are all browser actions that network DLP may never see.

Browser security options compared

The terms overlap in vendor marketing. A managed browser is a mainstream browser (Chrome, Edge) controlled by enterprise policy. An enterprise browser is a browser built for corporate use, usually on Chromium, with security, data controls and logging inside the browser itself. A browser security extension adds similar controls to an existing browser. Remote browser isolation (RBI) runs the page on a remote server and sends only a rendered or sanitised version to the user.

Choosing between them

• Managed devices, Microsoft or Google centred: start with a hardened managed browser. Edge's policies sit under HKLM\SOFTWARE\Policies\Microsoft\Edge and can also be set in the Microsoft 365 admin center through the Edge management service; device GPO or MDM settings override it by default. Chrome Enterprise Core gives cloud management of Chrome on Windows, macOS, Linux, iOS and Android at no additional cost, including extension reporting.
• Unmanaged devices and third parties: an enterprise browser lets you grant access to specific applications with data restrictions without enrolling the device. Pair it with conditional access so the protected applications accept sessions only from that browser. See the Third-Party Access Guide.
• Extension vs enterprise browser: choose the extension when the browser estate is already managed and you mainly need visibility and DLP; choose an enterprise browser when you need controls on devices you do not manage, or controls an extension cannot enforce, such as screenshot blocking.
• Small organisations: enforce Chrome or Edge policies, block extensions by default and turn on SmartScreen or Safe Browsing protections. That covers most of the risk without new spend.
• Large or regulated organisations: combine managed browsers for employees, an enterprise browser or isolation for third parties and high-risk roles, browser DLP for regulated data, and central telemetry.

Baseline browser hardening policies

These settings apply to Edge and, with the same or equivalent names, to Chrome. Validate them on a test device at edge://policy or chrome://policy before wider rollout.

Keep browsers on supported, current versions (CIS safeguard 9.1). Auto-update should be on and its success measured, since every hardening setting assumes a patched engine.

Extension control

Extensions run inside every page they are allowed to access. The Cyberhaven extension breach showed the supply chain risk: according to SecurityWeek, an employee approved a malicious OAuth app called "Privacy Policy Extension" after a phishing email posing as Chrome Web Store support, and attackers published malicious version 24.10.4, which was available on 25 and 26 December 2024 and reached users through auto-update. Other extensions were compromised in the same campaign. An allowlist would not have stopped an approved extension updating, which is why permission and host limits matter as much as the allowlist itself.

• Default deny: in ExtensionSettings set the * scope to blocked with a blocked_install_message pointing to the request process. Use removed to uninstall extensions already in place. ExtensionSettings overrides ExtensionInstallBlocklist, ExtensionInstallAllowlist and ExtensionInstallForcelist.
• Allow by ID with a full scope: an extension with its own scope does not inherit anything from *, so define every restriction for each approved ID. Extension IDs are 32 characters and stable across versions.
• Restrict permissions: use blocked_permissions to reject extensions requesting sensitive APIs, so a new version that adds a permission is not loaded.
• Keep extensions away from crown-jewel sites: use runtime_blocked_hosts (up to 100 entries, such as *://*.yourcompany.com) so even approved extensions cannot inject scripts, read cookies or modify requests on your identity provider, admin consoles and finance applications.
• Force-install required security extensions with force_installed and the store update URL, and set minimum_version_required to disable known-bad old versions.
• Review on change: treat new permissions or a change of publisher as a fresh approval. Remove extensions with no owner or no recent use.
• Do not forget other extension ecosystems: IDE extensions carry the same risk, as the GlassWorm campaign showed.

Credential and session theft

The browser's password store and cookie jar are the main targets of commodity infostealers. Controls work at three levels: what is stored, how it is protected on disk, and how useful a stolen copy is.

• Store less: MITRE's mitigation M1027 asks organisations to weigh the risk of storing credentials in browsers. Disable the browser password manager for work profiles if you provide an enterprise password manager, and never allow service account or admin credentials to be saved in a browser. See the Password Security Guide.
• Keep work and personal apart: the Okta support system breach began with a service account's credentials saved to a personal Google profile on a work laptop, and the Cisco 2022 breach with a password synced through a personal browser account. Force corporate sign-in, restrict allowed accounts, and restrict personal profiles and sync on managed devices.
• Protect at rest: Chrome's App-Bound Encryption (Windows, Chrome 127 onwards, cookies first) has a privileged service check which application is asking before decrypting. Google notes that malware then needs administrator or system privileges, or code injection into Chrome, which is noisier. It benefits most where users cannot run downloads as administrator, and it does not work with roaming profiles. Chrome logs Event ID 257 (source "Chrome", Application log) when verification fails.
• Make stolen sessions less useful: Device Bound Session Credentials (DBSC) bind a session to a key held in the TPM where available and replace long-lived cookies with short-lived ones refreshed by a signed challenge. It needs the website to support it. Until your applications do, use short session lifetimes, re-authentication for sensitive actions and token binding offered by your identity provider. See the Token and Session Security Guide.
• Detect replay: MITRE suggests watching for session cookies used from unusual user agents or locations and token reuse without re-authentication. That detection lives in the identity provider and SaaS logs, not the browser.
• Respond as a credential incident: when an infostealer is found, revoke sessions and rotate every credential the browser held, not just the user's password. See the Leaked Credential Response Playbook.

Browser DLP and data controls

Browser DLP means inspecting and controlling data as it moves through the browser: file uploads and downloads, pastes, printing and visits to particular URLs. It sees traffic to SaaS and AI tools that network DLP may miss because of encryption or remote working.

• Start in audit: run rules as audit only, review the matches, then move the precise ones to warn and finally block.
• Control the account, not just the site: conditions on the signed-in web account stop uploads to a personal tenant of the same SaaS service. This is also where shadow AI shows up. See the Shadow AI Discovery Guide.

How to implement

1. Inventory browsers, profiles and extensions. Enrol browsers in Chrome Enterprise Core or the Edge management tooling in reporting mode only, and list versions, installed extensions with their permissions, and whether personal profiles are in use.
2. Pick a primary browser per device class and decide which applications must only be reached through a managed or enterprise browser, using conditional access to enforce it.
3. Apply the baseline to a pilot ring (IT and security staff) through Group Policy, Intune or the cloud console: sign-in restrictions, SmartScreen or Safe Browsing, download restrictions, developer mode off.
4. Build the extension allowlist from the inventory, with an owner and business reason per extension, and agree an approval service level with the help desk.
5. Switch extensions to default deny for the pilot, then by ring. Use blocked first so existing extensions keep working while you review them, then removed for anything not approved.
6. Move credentials out of the browser: roll out the enterprise password manager, import passwords, then disable the browser password manager and personal sync.
7. Add DLP in audit mode for regulated data and AI destinations, tune, then enforce.
8. Roll back safely: every policy is a setting that can be reverted centrally; keep the previous policy export and remember that some policies (for example BrowserSignin and ApplicationBoundEncryptionEnabled) need a browser restart to take effect or revert.

Detection and measurement

• Policy coverage: percentage of browsers enrolled in management and reporting the current baseline.
• Extension conformance: percentage of installed extensions that are on the allowlist, with a target of 100 per cent on managed devices.
• Browser currency: percentage of browsers within one major version of the current stable release.
• Credentials in browsers: number of managed profiles with the built-in password manager in use or personal sync enabled, trending to zero.
• Phishing signal: password reuse events per month and the time to reset the affected credential.
• DLP effectiveness: blocked or warned sensitive transfers, and the share of content left unscanned.

Common failure patterns

• Managing Chrome but not Edge, or the reverse. Users move to the unmanaged browser. Manage every installed browser or remove the ones you do not support.
• Allowlisting an extension and never looking again. Ownership changes, OAuth-phished developer accounts and new permissions turn approved extensions malicious, as Cyberhaven showed.
• Letting personal accounts into work browsers. Personal profiles and sync move corporate credentials to devices you cannot see, the pattern behind the Okta and Cisco incidents.
• Treating MFA as the end of the problem. Session cookies stolen after sign-in bypass it; session lifetimes, device binding and replay detection are needed too.
• Leaving users as local administrators. App-Bound Encryption and browser policies are weaker when malware can run elevated or edit policy keys.
• An enterprise browser that is optional. If sensitive applications still accept any browser, users and attackers will use another one. Enforce it with conditional access.

Framework mapping

Practitioner checklist

• Enrol every supported browser in central management and remove unsupported ones.
• Set ExtensionSettings to default deny, allow by ID, and restrict permissions and hosts for approved extensions.
• Block extensions from your identity provider, admin consoles and finance applications with runtime_blocked_hosts.
• Force corporate sign-in and block personal profiles and sync on managed devices.
• Move work passwords to an enterprise password manager and disable the browser's own.
• Keep App-Bound Encryption on and remove local admin rights.
• Shorten session lifetimes for sensitive applications and detect cookie replay in identity logs.
• Use an enterprise browser or isolation, enforced by conditional access, for unmanaged and third-party devices.
• Run browser DLP in audit, then enforce, for regulated data and AI destinations.
• Send browser and extension telemetry to the SIEM and report coverage monthly.

Standards and references

• CIS: Critical Security Controls Version 8.1
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• MITRE ATT&CK: T1176.001 Software Extensions: Browser Extensions
• MITRE ATT&CK: T1539 Steal Web Session Cookie
• Microsoft Learn: Detailed guide to the ExtensionSettings policy
• Google: Manage extensions in your enterprise (Chrome Enterprise)
• Google Security Blog: Improving the security of Chrome cookies on Windows
• Chrome for Developers: Device Bound Session Credentials

Related NHI Mgmt Group resources: Token and Session Security Guide · Password Security Guide · Third-Party Access Guide · Browser and Computer-Use Agent Guide