Enterprise Browser Security Maturity Model

The browser is where most work now happens, yet many organisations still cannot say which browsers and versions their people run, which extensions sit inside them, or what data leaves through them. Plenty has been written about individual browser controls, from extension allow lists to remote isolation and enterprise browsers, but very little helps a team judge where it stands as a whole and what to fix next. This model scores browser and extension security on NHI Mgmt Group's five levels (Ad hoc, Developing, Defined, Managed and Optimised), from unmanaged consumer browsers to a governed, monitored browser estate. It is for endpoint and workplace engineers, security architects, CISOs and auditors. If you are choosing a product, read the Browser Security Buyer's Guide; for the controls themselves, read the Enterprise Browser and Browser Security Guide.

Key takeaways

Maturity is about governance, not product choice: a well-managed mainstream browser with enforced policy beats an enterprise browser that nobody configures or monitors. The model scores outcomes, not purchases.
Extensions are the largest unmanaged estate: they often can read and change data on every site a user visits, so Level 3 means a default-deny extension policy with an approved list, permission limits and an owner for each exception.
Versions decide exposure: mainstream browsers are largely secure by default, as the NCSC puts it, so the first job is keeping them updated and knowing which versions are running.
Data controls follow identity: controls on copy, paste, upload, download and print only work once you know which profile is a managed work profile and which is personal.
AI tools raised the stakes: AI browser extensions, AI chat sites and agentic browsers now handle sensitive text and session tokens, so Levels 4 and 5 add explicit rules for AI use in the browser.

The five levels

Level	Name	Description
1	Ad hoc	Users choose and install browsers themselves. No central policy, no extension control, updates left to the user. Nobody can produce a list of browser versions or extensions. Personal and work profiles mix freely.
2	Developing	One or two approved browsers are deployed and auto-update is on. A few policies are pushed (safe browsing on, password manager rules), and obviously risky extensions are blocked case by case. Inventory exists for some devices but not all.
3	Defined	A written browser standard and baseline is enforced through Group Policy, MDM or a cloud management console. Extensions are default-deny with an approved list and permission limits. Browser versions and extensions are reported centrally. Sign-in is restricted to work accounts on managed profiles.
4	Managed	Data protection rules run in the browser for sensitive applications (upload, download, paste and print controls), unmanaged devices reach sensitive apps only through a controlled path, and browser telemetry feeds the SOC. AI sites and AI extensions are covered by policy. Metrics are reported each quarter.
5	Optimised	Browser policy is managed as code with change review and staged rollout. Extension risk is reassessed continuously, controls adapt to device posture and user risk, and incident lessons feed back into the baseline. The browser is treated as a governed endpoint in its own right.

Score each capability area below separately. An organisation is at the level where all of its areas meet that level; the gap between the strongest and weakest area is usually the most useful finding.

Capability areas

Capability area	Level 2 looks like	Level 3 looks like	Level 4 to 5 looks like
Browser inventory and updates	Approved browsers deployed, auto-update on	Central report of browser, version and channel per device; version floor enforced	Out-of-date browsers trigger access restrictions; update compliance tracked as a KPI
Extension governance	Known bad extensions blocked	Default-deny with approved list, blocked permissions, request and review process	Continuous risk scoring, minimum versions, automatic removal, owner per approved extension
Configuration baseline	A handful of policies set	Documented baseline enforced through management tooling; users cannot override	Policy as code, staged rings, drift detection
Identity and session protection	Work sign-in encouraged	Browser sign-in limited to work accounts; managed profile separation	Device and session signals feed access decisions; token theft detection
Data protection	Downloads scanned	Download and file type rules; safe browsing warnings cannot be bypassed	Context-aware upload, paste, print and screenshot controls on sensitive apps
AI and agentic browser use	Ad hoc guidance	Approved AI tools listed; unapproved AI extensions blocked	Data rules on AI sites; agentic browsers governed with scoped access and logging
Monitoring and response	Reports pulled on request	Browser events collected centrally	Browser telemetry in the SOC with detection rules and a tested extension incident playbook

Browser inventory and updates

The NCSC's guidance on managing web browser security makes the starting point plain: major browsers are largely secure by default, and the administrator's job is to stop them becoming insecure, chiefly by keeping them updated and managing a small number of settings. It also advises monitoring which versions users actually run and choosing browsers supported for the whole period you plan to use them.

Level 1 to 2: pick the approved browsers, deploy them from a legitimate source through your normal software process, and turn on automatic updates for the browser and its extensions.
Level 3: enrol browsers in central management so that every managed device reports browser, version, release channel and installed extensions. Define a version floor (our suggestion: no more than one major version behind stable) and an exception route for legacy applications.
Level 4 to 5: make version compliance a condition of access to sensitive applications, and track time to update after each security release.

The NCSC also suggests that where a legacy web application needs an old browser you cannot replace, you confine that browser to that one application and use a modern browser for everything else. A legacy browser that is also used for general web browsing is a common reason organisations stall at Level 2.

Extension governance

The NCSC advises treating extensions like any other third-party software, noting that they often can read and change data on every site visited and that each one adds attack surface. MITRE ATT&CK tracks malicious browser extensions as T1176.001 Browser Extensions, alongside related techniques such as T1185 Browser Session Hijacking and T1539 Steal Web Session Cookie. CIS Controls v8.1 Safeguard 9.4 asks organisations to restrict unnecessary or unauthorised browser and email client extensions. See the Browser Extension Security Guide for the full control set.

Chromium-based browsers manage extensions through a single JSON policy, ExtensionSettings, with a default scope (*) for every extension without its own entry and individual scopes keyed by extension ID. Microsoft's Edge documentation describes the fields most programmes use:

Setting	What it does	Maturity use
`installation_mode`	Values `allowed`, `blocked`, `removed`, and per extension `force_installed` or `normal_installed`. `removed` also uninstalls existing copies	`blocked` or `removed` in the default scope is the Level 3 default-deny line
`blocked_permissions`	Stops extensions that require listed API permissions from installing or loading; optional permissions are declined at runtime	Block high-risk permissions even for approved extensions
`runtime_blocked_hosts`	Stops extensions injecting script, reading cookies or modifying requests on listed sites (up to 100 entries)	Protect identity provider, finance and admin consoles from all extensions
`allowed_types`	Limits installable types to extension, theme, user script or hosted app (default scope only)	Remove types you never use
`minimum_version_required`	Disables extensions older than a stated version, including force-installed ones	Level 4 response to a compromised or vulnerable extension release
`blocked_install_message`	Shows a custom message when installation is blocked	Point users to the request process, which keeps shadow workarounds down

Confirm field behaviour and supported platforms in each browser vendor's current policy documentation before rollout. Platform changes also move the baseline: Chrome's Manifest V2 timeline shows Manifest V2 extensions disabled everywhere from Chrome 138 in July 2025 and removed from the Chrome Web Store from 31 August 2026, with the enterprise exemption policy ExtensionManifestV2Availability removed in Chrome 139. Extensions that were kept alive by that policy need to be replaced or rebuilt. See the Chrome Manifest V3 Transition.

Firefox and Safari are managed through their own enterprise policy mechanisms; build the equivalent default-deny rule for every browser you approve, not only the main one.

Configuration baseline and enforcement

A Level 3 organisation has a written baseline per approved browser and enforces it through Group Policy, MDM or a cloud console so users cannot change it. The NCSC lists the areas worth managing: updates, malware protection on downloads, preventing users from bypassing certificate warnings, restrictions on syncing work data to personal browser accounts, extension policy, and disabling developer tools for users who do not need them. It explicitly advises against disabling JavaScript or password auto-fill, because doing so makes secure browsing very hard.

Safe browsing and reputation: keep reputation services on and stop users bypassing warnings. In Microsoft Edge, for example, Defender SmartScreen is on by default and users can bypass warnings unless policy prevents it (SmartScreenEnabled, PreventSmartScreenPromptOverride and PreventSmartScreenPromptOverrideForFiles, as documented on Microsoft Learn).
Exploit mitigation: browser features such as Edge enhanced security mode (off by default; Balanced or Strict, set with the EnhanceSecurityMode policy) disable JIT JavaScript compilation on unfamiliar sites and add Windows protections such as Arbitrary Code Guard and Control Flow Guard. Pilot Strict mode first: Microsoft notes it can disrupt normal work.
Developer tools and downloads: restrict developer tools for general users and set download rules for risky file types. See the Browser Security Hardening Guide.
Policy as code (Level 5): store browser policy in version control, review changes, and roll out in rings (IT, pilot, broad) with a documented rollback.

Identity, profiles and sessions

Most browser data controls depend on telling a managed work profile from a personal one. At Level 3, restrict browser sign-in to work accounts on managed devices and prevent work data syncing to personal accounts, as the NCSC suggests where that is a concern. At Level 4, feed device and browser posture into conditional access so that sensitive applications are reached only from a managed browser or through a controlled path such as remote browser isolation or a virtual desktop. See the Remote Browser Isolation Guide.

Session tokens and cookies in the browser are bearer credentials. Store passwords in an approved password manager (the NCSC considers built-in browser password managers acceptable), and protect session cookies by keeping extensions away from identity provider domains with runtime_blocked_hosts. See the Browser Storage Security Guide.

Data protection in the browser

Browser data protection moves through three stages. Level 2 scans downloads. Level 3 adds file type and download rules and blocks warning bypasses. Level 4 applies context-aware rules on sensitive applications: blocking upload of classified files to unapproved sites, limiting paste of sensitive data into web forms, and controlling print, screenshot and download on unmanaged devices. These rules can come from a DLP platform, a browser security extension, an enterprise browser or a secure access service; the maturity question is whether they are defined, enforced and measured, not which delivery model you chose. See the Data Loss Prevention (DLP) Guide.

AI and agentic browser use

AI chat sites, AI browser extensions and agentic browsers now process sensitive text and act inside authenticated sessions. Treat them as a distinct area:

Level 3: publish the list of approved AI tools and block unapproved AI extensions through the extension policy. See the AI Browser Extensions Security Guide.
Level 4: apply data rules to AI sites (for example blocking paste of classified content into unapproved AI tools), and log AI site use so shadow AI can be measured. See the Shadow AI Discovery Guide.
Level 5: govern agentic browsers and computer-use agents like other non-human actors: scoped accounts, approval steps for consequential actions, and logs of what the agent did. See the Agentic Browsers Security Guide.

Monitoring and measurement

From Level 3, collect browser management reports (versions, extensions, policy status) centrally; from Level 4, send browser security events to the SOC and keep a tested Malicious Browser Extension Incident Playbook. Metrics we suggest:

Metric	What it shows	Level 4 target (NHI Mgmt Group suggestion)
Managed browser coverage	Share of devices with enrolled, policy-managed browsers	95% or more of corporate devices
Version compliance	Share of browsers at or above the version floor	95% within 7 days of a security release
Extensions per device and unapproved extensions	Size of the extension estate and policy leakage	Zero unapproved extensions on managed profiles
Time to remove a flagged extension	Speed of extension incident response	Under 24 hours estate-wide
Sensitive app access from unmanaged browsers	Whether the controlled path is used	Only through the approved path
AI site data events	Blocked or warned paste and upload to AI tools	Trend reported quarterly

Self-assessment questions

Can you produce, today, a list of every browser, version and extension on managed devices?
Is your default extension policy deny, with a documented approval route and an owner for each approved extension?
Do you block high-risk extension permissions and keep extensions off your identity provider and admin consoles?
Can users bypass safe browsing or certificate warnings, change policy or sign in with personal accounts on work profiles?
How long would it take to remove a compromised extension from every device?
Are sensitive applications reachable from unmanaged browsers, and if so through what controls?
Do you have rules for AI tools in the browser, and can you measure their use?
Do browser events reach the SOC, and has the extension incident playbook been exercised?
Is browser policy version-controlled, with staged rollout and rollback?

Moving up: roadmap

Level 1 to 2 (first 30 days): choose approved browsers, deploy them centrally, turn on auto-update, keep safe browsing on, and block known malicious extensions.
Level 2 to 3 (one to two quarters): enrol every browser in management, publish the baseline, run an extension discovery report, agree the approved list with business owners, then switch the default scope to blocked in audit-friendly stages: pilot group, then one business unit, then estate-wide. Keep the change ready to revert by restoring the previous policy version.
Level 3 to 4 (two to four quarters): add data protection rules for the top sensitive applications, restrict unmanaged access to a controlled path, cover AI tools, connect browser telemetry to the SOC and start quarterly metrics.
Level 4 to 5 (ongoing): move policy to code with review, add continuous extension risk review and adaptive controls tied to device and user risk, and feed incident lessons into the baseline.

Smaller organisations can reach a solid Level 3 with built-in browser management and a short approved extension list; larger or regulated organisations usually need Level 4 controls for sensitive applications and contractors on unmanaged devices.

Framework mapping

Capability area	NIST CSF 2.0	NIST SP 800-53 Rev 5	CIS Controls v8.1	MITRE ATT&CK
Inventory and updates	ID.AM-02, PR.PS-02	CM-7, SI-3	9.1	T1189
Extension governance	PR.PS-01, PR.PS-02	CM-7(5), CM-11	9.4	T1176.001
Configuration baseline	PR.PS-01	CM-7, SC-18	9.1	T1204.001
Identity and sessions	PR.DS-02	AC-4	9.1	T1539, T1185, T1555.003
Data protection	PR.DS-02	AC-4, SC-7	9.3	T1185
Monitoring	DE.CM-09	SI-3	9.2, 9.3	T1176.001

Common failure patterns

Buying before governing: deploying an enterprise browser or extension security tool without an agreed baseline and approved extension list, so the new tool reproduces Level 1 behaviour.
One browser managed, others ignored: strong policy on the main browser while a second browser, installed for one application, runs unmanaged and becomes the default for some users.
Allow lists that never shrink: extensions approved once and never reviewed, with no owner and no check of later permission changes or ownership transfers.
Extensions on the crown jewels: approved extensions still allowed to run on the identity provider, finance systems and cloud consoles, where session cookies live.
Personal profiles on work devices: sync to personal accounts left on, so work passwords, history and session data end up outside corporate control.
AI tools treated as ordinary sites: no data rules for AI chat sites or AI extensions, so sensitive text flows out without any record.

Practitioner checklist

Name approved browsers and channels, and deploy them from a legitimate source with auto-update on.
Enrol every managed browser in central management and report versions and extensions.
Set the extension default scope to blocked, publish the approved list and assign an owner to each entry.
Block high-risk extension permissions and keep all extensions off identity provider and admin domains.
Stop users bypassing safe browsing and certificate warnings and restrict developer tools.
Limit browser sign-in to work accounts and stop work data syncing to personal accounts.
Apply data protection rules to sensitive applications and AI tools.
Route unmanaged device access to sensitive apps through a controlled path.
Send browser events to the SOC and exercise the extension incident playbook yearly.
Report the metrics above quarterly and reassess maturity every year.