Safeguard 9.4 browser and email extension restrictions: evidence

What Safeguard 9.4 asks for and why extensions are a real attack path

Safeguard 9.4 asks the enterprise to remove or disable browser and email client plugins, extensions and add-ons that are not authorized or not needed. If you are an IG2 or IG3 enterprise preparing for a CIS-based assessment, that is the whole requirement: you must be able to show that unapproved extensions are gone or switched off, and that the ones you keep are there for a reason. Safeguard 9.4 is not part of IG1. It sits in the Software asset class and the Protect security function in CIS Controls v8.1, so an assessor will expect it to be backed by your software inventory and your configuration decisions rather than by a one-time cleanup.

The risk is plain. A browser extension can read and change the content of every page a user opens, including banking, HR and cloud admin consoles, and it can capture typed credentials and session data. A mail client add-on can read message bodies, attachments and contact lists. Users install these tools to solve small problems, and the permissions are often granted in a single click. The hard part is visibility: users run many browser and mail profiles, some are personal and synced to accounts IT does not manage, and extensions are installed outside any central catalog. An extension that IT has never seen cannot be reviewed, and a removed one can return when a profile syncs again.

Before you plan the work, confirm three things with your own environment. First, which browsers and mail clients are approved for the enterprise, since 9.4 only makes sense once Safeguard 9.1 is in place. Second, whether managed browser and mail policies can block installation or force-remove extensions on each platform. Third, whether you can see installed extensions on every endpoint, including unmanaged or personal profiles, because the CIS measures depend on that data. Safeguards 1.1 and 2.1 (the enterprise asset and software inventories) are the prerequisites the CIS assessment specification names for measuring 9.4, so gaps there will show up here first.

Which browsers, mail clients, devices and profiles fall under 9.4

The scope of Safeguard 9.4 follows what the enterprise actually runs, so the work starts with the asset and software inventories rather than with a list of extensions. The cards below cover the decisions that change how much work the Safeguard becomes, and the inputs that must exist before any extension can be judged.

Managed and unmanaged devices

A managed device accepts policy pushed by a central tool, so extension rules can be enforced from one place. An unmanaged device, such as a contractor laptop or a personal phone used for mail, can only be checked if it reports into the environment at all. Decide early whether unmanaged endpoints are in scope, and if they are, confirm how they are discovered and whether they can be blocked from accessing enterprise mail or web applications until they comply.

Remote and on-premises endpoints

Safeguard 9.4 applies to devices wherever they sit, so remote staff and office workstations both belong in the measurement. Confirm that the tooling that checks extensions can reach remote devices over the internet or through an agent, not only over the office network. A device that is only checked when it joins the corporate network will show a clean result that does not reflect how most users actually work.

Browser profiles and webmail

Browsers store extensions per profile, so a user with a work profile and a personal profile on the same machine can run different add-ons in each. Webmail accessed through a browser also falls under the browser extension rules, because the extensions run in the same process that reads the mail. Ask whether the enterprise permits multiple profiles, whether managed policy applies to every profile, and whether webmail is treated as a mail client or a web application in the scope statement.

Mobile mail apps

Mobile mail apps are not extensions in the desktop sense, but they carry similar risk when they are unauthorized or outdated. Decide whether mobile mail clients are in scope for 9.4, and if so, record which apps are approved. Mobile device management usually controls installation of mail apps, so the check may be an allowlist rather than a scan of add-ons.

User-installed versus policy-pushed extensions

Extensions installed by users and those pushed by policy need different controls. A policy-pushed extension is part of the approved baseline and should appear as expected on every managed device. A user-installed extension is the usual source of unauthorized add-ons, so the scope must state whether users may install extensions at all, and whether the enterprise will remove them or only report them.

Inputs from Safeguards 1.1 and 2.1

The CIS Controls Assessment Specification lists the enterprise asset inventory (Safeguard 1.1) and the software inventory (Safeguard 2.1) as prerequisites for measuring Safeguard 9.4. The scope of 9.4 therefore follows those inventories: a device missing from the asset inventory cannot be measured for extensions. Before scoping, confirm that the asset inventory covers every device in scope and that the software inventory records browsers and mail clients with their versions.

How the CIS assessment specification measures 9.4

The CIS Controls Assessment Specification for v8.1 defines five measures for Safeguard 9.4, and those measures roll up into two metrics: browser plugin enforcement quality and email client plugin enforcement quality. The split matters for evidence. An assessor does not accept one blended score for the whole estate. Each browser and each email client in use is measured on its own enforcement results, so an organization running two browsers and one mail client should be able to show results for all three separately, including any unapproved extension found on each.

The specification says what to measure, not how. CIS does not prescribe a scanner, a policy language, a reporting cadence or a particular browser management method, so the method and tooling are the organization's choice and must be justified in its own documentation. Before testing, confirm that Safeguards 1.1 and 2.1 are in place, because the specification treats the enterprise asset inventory and software inventory as prerequisites. Without them, you cannot show which browsers and mail clients exist on which devices, and the enforcement numbers have no reliable denominator.

Read the five measure definitions on the CIS Assessment Specification page for Safeguard 9.4 before you design the evidence. Map each measure to a data source you can export, such as endpoint configuration results, extension inventories or policy compliance reports, and record how each browser and client is covered. Ask your independent assessor to confirm the measure definitions and the metric calculation you plan to use, so that the evidence you collect matches what they will test.

How an assessor tests Safeguard 9.4

This table compares how an assessor tests the browser plugin enforcement metric and the email client plugin enforcement metric against the same evidence categories. Read each row as a question the assessor will ask, then check whether your records answer it for both browsers and email clients. The main takeaway is that an approved list only counts if the endpoints show it is enforced.

Test area	Browser metric	Email client metric
Inventory reconciliation against Safeguard 2.1	Assessor compares the browser extension list from endpoints with the software inventory from Safeguard 2.1 and asks why any installed extension is missing from it.	Assessor compares installed mail client add-ons with the Safeguard 2.1 software inventory and asks why any add-on is missing from it.
Approved extension list	Assessor requests a written list of permitted browser extensions, with owner, business purpose and review date for each.	Assessor requests a written list of permitted mail client add-ons, with owner, business purpose and review date for each.
Sampling of endpoints	Assessor selects a sample of managed endpoints across departments and compares each browser's installed extensions with the approved list.	Assessor selects a sample of managed endpoints and compares each mail client's installed add-ons with the approved list.
Proof of removal or disablement	Assessor expects policy results, removal logs or configuration reports showing unauthorized extensions were removed or disabled, with dates.	Assessor expects policy results, removal logs or configuration reports showing unauthorized add-ons were removed or disabled, with dates.
Exception records	Assessor checks each exception for a documented business reason, an approver, an expiry date and compensating controls.	Assessor checks each add-on exception for a documented business reason, an approver, an expiry date and compensating controls.
Management of browser profiles	Assessor confirms that extension settings come from managed browser policies and that users cannot install extensions outside those policies.	Assessor confirms that add-on settings are centrally managed and that users cannot add components outside the managed configuration.
Common finding: unreviewed extensions	Extensions are present on endpoints but nobody has reviewed or approved them since they were first installed.	Add-ons are present in mail clients but nobody has reviewed them since deployment.
Common finding: unenforced approved lists	An approved list exists as a document, yet endpoints still run extensions that are not on it.	An approved add-on list exists, yet mail clients still load add-ons that are not on it.
Common finding: profiles outside management	Some users run personal browser profiles or sync accounts that bypass the managed policy and the endpoint records.	Some users configure personal mail accounts or add-on sources outside the managed client configuration.

Steps to enforce browser and email extension restrictions

This sequence moves from knowing which extensions exist to enforcing an approved list on every browser and email client, then keeping exceptions and enforcement results current. Each step produces a record that the next one depends on, so the measurements in the assessment specification can be traced back to a defined policy.

Confirm the software inventory covers extensions
The IT or endpoint team checks that the software inventory built for Safeguard 2.1 lists browser extensions, add-ons and mail client plugins, not only the browsers and mail applications themselves. Many inventory tools report installed applications but not per-browser extension lists, so confirm this with the tool's vendor or by testing it on a sample of devices. The step is complete when a sample device's known extensions appear in the inventory with their browser profile, version and install source. Safeguards 1.1 and 2.1 supply the device and software data that the measurement later relies on.
Define the extension approval standard
The security function, with input from business owners, writes a standard that states how an extension is approved, who may approve it and what evidence is required. Typical criteria include publisher identity, permissions requested, data access, update channel, business need and whether the extension is still maintained. The output is a short approval standard signed by the accountable owner, stored with the other Control 9 policy documents.
Publish the approved list per client
Using the standard, the team builds a separate approved list for each supported browser and each email client, because the same extension can be acceptable in one product and not another. Each entry records the extension identifier, publisher, permitted version range and approved user groups. The output is a versioned approved list per browser and email client that is reviewed on a set cadence and linked from the software inventory, so a reviewer can trace each allowed item to an approval decision.
Configure enforcement through management policy
The endpoint or browser management team applies the approved lists through the enforcement mechanisms the enterprise already runs, such as browser enterprise policies, mail client administrative templates or endpoint management profiles. Confirm with each vendor which settings block installation, force removal or restrict permissions for a given product, since capabilities differ. The output is a documented policy configuration per browser and email client, exported or screenshotted, that shows which blocklist or allowlist mode is active and which devices receive it.
Remove or disable unapproved extensions
The team runs a first pass that removes or disables extensions that are not on the approved list, prioritizing those with broad permissions or unknown publishers. Users whose extensions are removed should receive a clear notice that explains how to request an exception. The step is complete when a fresh scan of the sample devices shows no unapproved items remaining, or when each remaining item has an open exception record.
Set the exception and review process
The security function defines how a user or manager requests an extension outside the approved list, who reviews the request against the approval standard, and how a time-limited or permanent exception is recorded. Expired or unused exceptions are removed, and the approved lists are updated when the standard changes. The output is an exception register with the requester, approver, justification, scope and review date for every item, which an assessor can sample during a review of the documented process.
Measure enforcement per device for both metrics
The team reports two results: browser plugin enforcement quality and email client plugin enforcement quality, each drawn from the five measures in the assessment specification for Safeguard 9.4. Results are recorded per device, not as a single organization-wide figure, so that failing devices can be identified and fixed. Compliance tooling such as a configuration assessment or a yes or no device policy query can produce the per-device pass or fail data, and the team should confirm which measures each tool can report before relying on it. The step is complete when both metrics are reported on a regular schedule and the results are retained as evidence.

Evidence that passes 9.4 and how to keep it current

An assessor testing Safeguard 9.4 will look for a defined list of approved extensions, proof that the list matches what runs on devices, and records of what was removed or excepted. Each artifact below answers one part of that question, and most need a scheduled export and a change record to stay accurate between assessments.

Approved extension list

This is the baseline the organization owns: each browser and email client extension it permits, the business purpose, a named owner and the date of the last review. Keep one list per browser and one per email client, since the enforcement measures are separate. Check that every entry has an owner who can approve changes, and that removed extensions are marked as removed rather than deleted, so the history stays readable.

Software inventory extract by device

The Safeguard 9.4 assessment relies on the software inventory from Safeguard 2.1 and the asset inventory from Safeguard 1.1. Export the extension entries for each browser and email client, grouped by device, with the extension identifier, version and installed date. Compare the export against the approved list to find unknown extensions. Schedule the export so the most recent one is never more than a short period old.

Enforcement policy configuration exports

Show the rules that block or remove extensions, such as browser management policies or allowlists, and the scope each rule applies to. Export the configuration with its version history and record who changed it and when. An assessor will ask whether the policy that exists is the policy that is enforced, so tie each export to the device group it governs and confirm that the group covers all in-scope endpoints.

Per-device pass and fail results

Keep results that show each device passing or failing the extension policy, reported separately for browsers and email clients. This is the evidence behind the two metrics the assessment specification uses for Safeguard 9.4. Review the trend, not only the latest snapshot, and confirm that failing devices are either remediated or covered by a documented exception.

Remediation tickets

Each failing device or unauthorized extension should produce a ticket that records what was found, when it was detected, who removed or disabled it and how the removal was verified. Close the ticket only after a fresh check passes. Assessors often sample tickets to confirm the team acts on findings, so a clear closure date and verification step matter more than the number of tickets.

Signed exception records

Where a business need requires an extension outside the approved list, record the exception with the extension, the affected users or devices, the justification, a compensating control, an expiry date and the signature of the approver. Review exceptions on a schedule and remove any that have lapsed. Undated or unsigned exceptions are the most common gap an assessor finds in this area.

What meeting 9.4 costs in money and effort

The table lists each cost component of meeting Safeguard 9.4, who is paid for it, whether it is one-time or recurring, and what pushes it up or down. Use it to build a quote request and to see where open-source tooling removes license spend while effort stays with your team.

Cost component	Who carries it	One-time or recurring	Main drivers and what to ask for
Extension monitoring tooling or licenses	Your organization, or a vendor if you buy a commercial endpoint or browser management product	Recurring if licensed per device or user	Device count and whether browser and mail client data is collected centrally. Open-source endpoint tools such as Wazuh or Fleet can remove license spend, but ask the partner to confirm hosting and storage needs.
Asset and software inventory prerequisites (Safeguards 1.1 and 2.1)	Your team, with an implementation partner if the inventory is incomplete	One-time build, recurring upkeep	Whether browsers, mail clients and their extensions already appear in the software inventory. Missing inventory data usually adds the most effort before any extension rule is written.
Engineering time to define the authorized extension list and policies	Your platform or endpoint team, or a fixed-scope implementation partner	One-time, with periodic revision	Number of browser and mail client types in use, and how many extensions are already installed. Ask for the scope of policies, the platforms covered and the deliverables in writing.
Policy and query build for each browser and email client	Your endpoint engineers or an implementation partner	One-time per platform, then recurring when versions change	Number of browsers and mail clients, and differences between Windows, macOS and Linux. Each platform needs its own check for extension directories and settings.
Extension churn review and exception handling	Your security or IT operations staff	Recurring	Rate at which users request new extensions and how often vendors update them. A documented approval path with a named owner keeps this predictable.
Evidence upkeep (pass and fail records, removal logs, exception records)	Your compliance or security team, supported by tooling	Recurring	How long records must be kept and how often the assessor samples them. Dashboards that show passing and failing devices reduce manual collection, but someone still needs to file and explain the results.
Remediation of non-compliant devices	Your IT support staff	Recurring, spikes after new policies	Number of unmanaged or personal devices and the share of users who run unapproved extensions. Plan a grace period and user communication before enforcement starts.
Independent assessment sampling	Your organization pays the independent auditor or assessor	Recurring per assessment cycle	Number of devices and extension exceptions in scope, and how many samples the assessor selects. Ask the assessor how sampling is set and what records they expect to see.
External review of the implementation	Your organization, through an implementation partner or a consultant	Optional, one-time or periodic	Whether internal staff have time to test enforcement and explain the design. Ask for a written scope, deliverables and a fixed-scope estimate before work starts.

Open-source tools that produce 9.4 evidence

Wazuh's Security Configuration Assessment (SCA) module scans monitored endpoints for misconfigurations using YAML policy files. Its policies are shipped mostly based on CIS benchmarks and can be extended with custom policies, so an enterprise can write rules that describe the extensions it has authorized and flag anything else found on a browser or mail client. The module checks files, directories, registry keys and running processes, and it recommends remediation for each failed check. That combination matters for 9.4 because extension presence is often recorded in profile directories, configuration files or Windows registry keys, which SCA can inspect directly.

License and deployment: Wazuh is licensed under GPL-2.0-only, so review the license terms with your legal team before you embed it in a managed service or redistribute it.
Custom policies: Write YAML checks that look for each authorized extension identifier and fail when an unlisted one appears in a browser profile or mail client configuration path.
Registry and file coverage: Use registry and file checks for Windows endpoints and file path checks for macOS and Linux profiles, since the placement of extension data differs by platform.
Remediation output: Each failed check carries a recommendation, which gives the operations team a documented corrective step to attach to the ticket.
Per-endpoint results: Results are tied to each monitored agent, so the enforcement record shows which endpoints failed and when they were remediated.

Confirm with Wazuh's documentation which browser and mail client extension settings a given policy can read on your operating systems, because some extension state may live in places a file or registry check cannot reach.

Where organizations fall short on extension control

Most extension programs fail in predictable places: the approved list is missing, the inventory is incomplete, enforcement stops at managed devices, exceptions never expire, and nobody measures the result per device. Each card below names one gap and the check that closes it, so the browser and email client controls can be tested the way the assessment specification expects.

No approved list per client

Many organizations approve a browser or mail client but never list which extensions, plugins and add-ons inside it are authorized. Safeguard 9.4 asks for removal or disabling of anything not authorized or not needed, so the browser and the email client each need their own written list. Keep the two lists separate, because a Chromium extension and an Outlook add-in carry different risks and owners. Close the gap by publishing one approved list per client, with a named owner and a review date for each entry.

Extensions missing from inventory

Extensions often appear in no inventory, so they cannot be checked against an approved list. Safeguard 2.1 (the software inventory) and Safeguard 1.1 (the enterprise asset inventory) are prerequisites for measuring Safeguard 9.4, because they supply the data the measurement needs. Confirm that the software inventory records browser and email client add-ons as their own items, linked to the device and user that hold them. Close the gap by feeding extension data from endpoint tooling into the same inventory that tracks other software.

Enforcement blind to unmanaged profiles

Policies often apply to managed devices and corporate browser profiles, while personal profiles signed into the same browser on a corporate laptop stay open. Users can also install extensions in a browser that the management agent never touches, such as a second build on the same endpoint. Ask whether your controls cover every installed profile on every enterprise device, and whether remote and contractor devices are inside that scope. Close the gap by testing the policy on a profile the management tooling does not own and recording the result.

Exceptions with no expiry

A single business exception for a plugin often becomes permanent because nobody tracks it. Over time the exception list grows, the reason for each entry is lost, and the approved list no longer reflects what runs in production. An assessor testing Safeguard 9.4 will look for documented authorization and a way to show that unneeded extensions were removed. Close the gap by requiring each exception to record the owner, the business reason, and an expiry date that triggers a re-approval or removal.

Enforcement never measured per device

Some teams deploy a removal policy and assume it works everywhere. Without per-device results, nobody knows which endpoints still run a blocked extension. The CIS Controls Assessment Specification defines measures for Safeguard 9.4 and combines them into browser and email client enforcement metrics, so the results should be kept separately for each client type. Close the gap by reporting pass and fail counts per device for browsers and for email clients on a regular schedule, and by keeping the history that shows the trend.

Questions buyers ask about Safeguard 9.4

Does Safeguard 9.4 apply to organizations in Implementation Group 1 only?

No. Safeguard 9.4 is assigned to Implementation Groups 2 and 3, not Implementation Group 1. IG1 covers essential cyber hygiene, and the browser and email extension control sits in the broader set that IG2 adds for enterprises with more operational complexity. An IG1 organization can still apply the practice voluntarily, but it is not part of the IG1 baseline. Confirm your Implementation Group against the CIS Controls Implementation Groups pages before you scope the work, since that decides whether 9.4 is required for your assessment.

How long does Safeguard 9.4 take, and what does it need from our team?

Duration depends on how many browser and email client profiles you run, how well your software inventory is maintained, and whether enforcement is already configured through a management tool. The work is mostly defining an approved extension list, deploying policy that removes or blocks everything else, and then checking results on each device class. It needs an endpoint administrator who can write policy, a security owner who approves extensions, and time from a team that can review exceptions. Ask any partner to show the plan and the dependencies in writing before agreeing a timeline.

Can our team implement Safeguard 9.4 in-house?

Yes, if you have the endpoint management skills and the time to maintain them. Most of the effort is not the initial configuration but the ongoing approval process: reviewing extension requests, retiring stale entries and proving that enforcement holds across devices. An internal team should confirm it can produce the measurement evidence the CIS assessment specification describes, including the browser and email client enforcement results. A partner can take on the build and documentation, while your staff keep ownership of the approval decisions.

What does an implementation partner's fee depend on?

The fee follows the written scope, so the main drivers are the number of devices in scope, the number of browsers and email clients you run, how many distinct extension policies you need, the state of your existing inventory and tooling, and how much documentation and evidence you want produced. Each of these changes the effort. Ask for a quote that separates one-time build work from any recurring support or retained monitoring, and that names which deliverables are included. DeployOpen does not publish a price list, and a quote follows from the agreed scope.

Do open-source tools like Wazuh or Fleet replace commercial endpoint licenses?

They can cover parts of the evidence work, but they do not replace every commercial license automatically. Wazuh's Security Configuration Assessment checks endpoints against YAML policies, mostly based on CIS benchmarks, and can be extended with custom policies. Fleet policies ask yes or no questions of devices through osquery and show which devices pass or fail. Together these can show whether unauthorized extensions are present and whether enforcement is working. Whether they fit your environment depends on whether they can enforce removal on your browsers and clients, so confirm that capability during evaluation.

How does Safeguard 9.4 relate to Safeguards 9.1 and 2.1?

Safeguard 9.4 depends on the other two in practice. Safeguard 9.1 requires that only fully supported browsers and email clients run in the enterprise, so you first know which clients are approved. Safeguard 2.1 requires a software inventory, which shows which extensions and add-ons are installed. The CIS assessment specification lists 1.1 and 2.1 as prerequisites for measuring 9.4 because they produce the data the measurement needs. Without an accurate inventory, you cannot tell which extensions are unauthorized or whether removal worked.

Which evidence should we keep to show Safeguard 9.4 is met?

Keep records that show the approved extension list, the policy that enforces it, the inventory that lists installed extensions, and the results of enforcement checks on each device group. Browser and email client enforcement are measured separately under the assessment specification, so keep evidence for each. Ask your assessor which format they accept and how long they expect records to cover. An independent auditor or certification body decides whether the evidence is sufficient, not the partner that prepared it.

How DeployOpen prepares Safeguard 9.4 evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, including the inventories and enforcement tooling that Safeguard 9.4 evidence depends on. Our work prepares systems and evidence for assessment, while the organization owns its controls and an independent assessor or auditor decides what passes.

How we scope

Engagements are fixed-scope, with the browser and email client extensions in scope agreed in writing before work starts.
The written scope lists which browsers and email clients, which extension stores and which authorized extension lists are covered.
Scope names the Safeguard 1.1 asset inventory and Safeguard 2.1 software inventory that the measurement relies on.

How we build

We configure a baseline of authorized extensions and document the approval process for adding or removing one.
We deploy configuration scanning or endpoint policy checks that flag unauthorized or unneeded browser and email client add-ons.
We set up separate enforcement checks for browsers and for email clients, matching the two metrics in the assessment specification.

How we hand over

We document the extension policy, the exception process and the owner for each approved extension.
We deliver evidence exports showing per-device pass and fail results, with dates, for the enforcement measures in scope.
We walk your team through the tooling so the evidence can be reproduced during an independent assessment.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover updates to the authorized extension list as browsers and email clients change.
Confirm with your assessor which evidence format and retention period they expect before we finalize the handover.