Safeguard 9.4: Restrict Unnecessary or Unauthorized Browser and Email Client Extensions

To meet the safeguard 9.4: restrict unnecessary or unauthorized browser and email client extensions requirement, you must centrally control which extensions can run, block everything else by default (or by risk-based policy), and keep proof that the control operates on all in-scope endpoints. Operationally, this is a combination of allowlisting, technical enforcement, exception handling, and recurring review aligned to CIS Controls v8. ¹

Key takeaways:

• Enforce extension control technically (policy/MDM), not by user guidance alone. ¹
• Maintain an approved extension allowlist with owners, justification, and review cadence. ¹
• Keep auditor-ready evidence: policy settings, device compliance reports, and exception tickets. ¹

Browser and email client extensions are a common path for credential theft, session hijacking, data leakage, and unapproved data processing because they can read page content, intercept traffic, and interact with email or identity workflows. Safeguard 9.4 focuses on reducing that exposure by preventing users (and malware running as the user) from installing or running extensions that your organization has not explicitly approved. ¹

For a Compliance Officer, CCO, or GRC lead, the practical problem is rarely “Do we have a policy?” The exam problem is “Can you prove you technically restrict extensions across the fleet, and that exceptions are controlled?” This requirement page translates safeguard 9.4 into an implementable control: define scope, select an enforcement model (deny-by-default or allow-by-policy), implement centralized management for browsers and email clients, and establish an evidence loop that shows continuous operation. ¹

If you run a modern environment with Chrome/Edge/Safari/Firefox, plus Microsoft 365/Outlook or other email clients, you will need coordination across security engineering, endpoint management, IT, and app owners. The goal is straightforward: only necessary extensions run, and you can defend that statement with artifacts an auditor can test. ¹

Regulatory text

Framework requirement (excerpt): “CIS Controls v8 safeguard 9.4 implementation expectation (Restrict Unnecessary or Unauthorized Browser and Email Client Extensions).” ¹

Operator interpretation of what you must do:

1. Identify the extension-capable applications in scope (browsers and email clients used for business). ²
2. Restrict installation and/or execution of extensions so end users cannot add unapproved extensions, and unapproved extensions do not run. ¹
3. Allow only what is necessary for business purposes, with a defined approval process and periodic review to remove stale or risky extensions. ¹
4. Maintain implementation evidence that shows the restriction is enforced, not merely documented. ¹

Plain-English requirement interpretation (what an auditor expects)

Safeguard 9.4 expects you to treat extensions like software: you control them centrally, you approve them deliberately, and you can prove what is installed and allowed to run. “Unnecessary” maps to business justification (no owner, no use case, redundant). “Unauthorized” maps to lack of formal approval and technical permission. ¹

A practical pass/fail test an examiner may apply:

• Pass: Your organization can produce an allowlist (or policy-based allow rules), show the configuration that blocks non-approved extensions, and show a current report of extension state across endpoints with controlled exceptions. ¹
• Fail: You have a written policy but users can still install arbitrary extensions, or you cannot show evidence across the fleet. ¹

Who it applies to (entity + operational context)

Applies to:

• Enterprises and technology organizations using managed endpoints where web browsers and email clients access corporate data. ¹

Operational scope typically includes:

• Corporate-managed laptops/desktops (Windows/macOS/Linux) with Chrome, Edge, Firefox, Safari.
• Mobile devices if corporate email or browsing occurs through managed apps/browsers.
• Email clients with extension/add-in ecosystems (common example: Outlook add-ins).

Common scoping decisions you must document:

• Which browsers are “supported/managed” versus “not permitted.”
• Whether BYOD is in scope, and if so, what enforcement exists (containerized apps, MDM-managed profiles, or access restrictions).
• Whether VDI/Citrix sessions and shared kiosks are in scope.

What you actually need to do (step-by-step)

Step 1: Set the control objective and enforcement stance

Pick one of these stances and document it:

• Deny-by-default (preferred for high-risk roles): Block all extensions except an explicit allowlist.
• Allow-by-policy: Allow a limited catalog and block known high-risk categories, with tighter controls for privileged/admin users.

Write the “why” in one paragraph: extensions can access sensitive content; control reduces credential and data risk. ¹

Step 2: Build an inventory of extension-capable applications and current extensions

Create an initial baseline:

• Browsers: enumerate installed browsers and versions.
• Extensions: capture currently installed extensions per browser per endpoint (name, ID, version, permission set if available, install source).
• Email clients: identify add-ins/plug-ins/extension mechanisms, and current installed add-ins.

Output: a spreadsheet or CMDB export that your technical teams can reproduce on demand.

Step 3: Define approval criteria (what “necessary” means)

Create an “Extension Approval Standard” with enforceable fields:

• Business owner and technical owner
• Use case and data touched (credentials, PII, source code, finance)
• Permissions requested (read/modify sites, access mailboxes, access files)
• Source of extension (official store vs sideload)
• Support model (who updates it, who monitors issues)
• Sunset criteria (no owner, unused, replaced)

Keep the standard short. Auditors reward clarity and repeatability.

Step 4: Implement technical controls in endpoint management

Your implementation must be technical and testable. Common patterns:

• Browser policies: enforce extension allowlist/blocklist by browser identifier, block developer mode where relevant, prevent installation from unknown sources, and restrict user-level installation.
• Email client add-in controls: restrict add-ins to approved publishers or an approved list, and disable user-installed add-ins where feasible.
• MDM/endpoint configuration: deploy these settings via your authoritative endpoint management platform, not local scripts that drift.

Deliverable: configuration baselines for each platform plus a change record.

Step 5: Establish an exception process that does not become a loophole

Define a single intake path (ticket/workflow) with:

• Justification and data classification impact
• Security review outcome (approve/deny)
• Compensating controls if approved (role-based limitation, conditional access, narrower site allow rules)
• Expiration date and re-approval trigger
• Evidence of technical implementation (policy group assignment)

Goal: exceptions exist, but they are time-bound and observable.

Step 6: Monitor and measure control operation

You need recurring proof that the control works:

• A report showing endpoints compliant with extension policy (by OS, browser, business unit).
• A report of extension installations detected outside the allowlist (attempts and successes).
• A process to remove unauthorized extensions and to investigate repeated attempts.

If your organization uses Daydream to operationalize controls, map safeguard 9.4 to a documented control and schedule recurring evidence capture (policy exports, compliance reports, and exception logs) so audits are a retrieval exercise instead of a scramble. ¹

Step 7: Run a periodic access review for extensions

At a defined cadence, revalidate:

• Each approved extension still has an owner.
• The business case still exists.
• Permissions are still appropriate.
• Alternatives exist with less access.
• The extension remains supported and patched.

Tie removal to a standard change process to avoid business disruption.

Required evidence and artifacts to retain

Maintain artifacts that show design, implementation, and operation:

Policy and governance

• Extension management policy/standard (scope, roles, enforcement stance). ¹
• Approved extension catalog/allowlist with owners, justification, and review dates.
• Exception procedure and completed exception tickets (approved and denied).

Technical evidence

• Screenshots or exports of browser/email client extension control settings from your management console(s).
• Configuration profiles/baselines showing assignment to device groups.
• Reports proving enforcement coverage across in-scope endpoints (device compliance, configuration compliance, or equivalent).

Operational evidence

• Monthly/quarterly review records of the approved catalog (attestation, meeting notes, or sign-off).
• Incident or remediation tickets for unauthorized extension detections.
• Change records for allowlist updates.

Common exam/audit questions and hangups

1. “Show me that users cannot install unapproved extensions.” Expect a request for policy exports plus a test on a sample endpoint.
2. “How do you know what extensions are installed today?” You need a current report, not a one-time spreadsheet.
3. “Do you control both browsers and email clients?” Auditors may treat Outlook add-ins as in scope if email is a primary data channel.
4. “What about contractors/BYOD?” If you exclude them, document the compensating access controls (VDI, conditional access, limited data access).
5. “How do you review and remove unnecessary extensions?” You need a defined review event and evidence it occurred. ¹

Frequent implementation mistakes (and how to avoid them)

• Mistake: Policy-only control. Fix: enforce via MDM/browser enterprise policies and produce compliance reports. ¹
• Mistake: Allowlist without ownership. Fix: require a named business owner and a technical owner for every approved extension.
• Mistake: Exceptions with no expiry. Fix: require time-bound exceptions and track them like access exceptions.
• Mistake: Ignoring privileged users. Fix: apply the strictest extension policy to admins, developers with prod access, finance, and security teams.
• Mistake: Store-only assumption. Fix: explicitly block sideloading/developer mode where relevant and monitor for manual installs.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this safeguard, so treat this as a control expectation under CIS Controls v8 rather than a standalone enforcement trigger. ¹

Operational risk remains concrete:

• Extensions can exfiltrate data visible in the browser or email client, including customer data, credentials, and internal documents.
• Uncontrolled extensions increase third-party risk because the extension developer becomes a de facto third party with code execution in your environment.
• Weak control evidence is a recurring audit failure mode: teams “know” they restrict extensions, but cannot demonstrate coverage and ongoing operation. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and stop the bleeding)

• Confirm in-scope browsers and email clients; publish a supported software list.
• Pull a baseline inventory of installed extensions and email add-ins.
• Decide enforcement stance by user group (standard vs privileged).
• Implement quick wins: block known-unapproved install paths (sideloading/developer mode) where feasible; require admin approval workflow for new extensions.

By 60 days (enforce and document)

• Roll out centralized extension policies to managed endpoints (pilot then broader deployment).
• Publish the approved extension catalog with owners and approval criteria.
• Stand up an exception workflow with expirations and required fields.
• Produce your first compliance report (coverage, noncompliance, remediation actions).

By 90 days (operate like a control, not a project)

• Expand enforcement to all business units and remote users; close coverage gaps (legacy endpoints, special groups).
• Run the first periodic review of the allowlist and prune unused/unowned extensions.
• Add monitoring/alerting for unauthorized extension install attempts and recurring offenders.
• In Daydream, map safeguard 9.4 to a recurring evidence schedule so each review produces a dated, auditor-ready package. ¹

Frequently Asked Questions

Do we have to block every extension to comply with safeguard 9.4?

No. You must restrict unnecessary or unauthorized extensions, which most organizations implement as an allowlist (or tightly controlled catalog) plus technical blocking of everything else. Your evidence should show enforcement and a rational approval process. ¹

Are Outlook add-ins considered “email client extensions” for this requirement?

If your email client supports add-ins that can access mailbox content or user context, treat them as in scope. Document the control boundary and enforce approval and restriction the same way you do for browser extensions. ¹

What counts as “unnecessary” in practice?

“Necessary” should map to a documented business use case with an accountable owner. If the extension has no owner, duplicates an existing tool, or requests broad permissions without need, treat it as unnecessary and remove or block it. ¹

How do we handle BYOD where we cannot enforce browser policies?

Document BYOD as out of scope for technical enforcement and apply compensating controls such as restricting access to corporate data through managed applications or virtual desktops. Keep that scoping decision and the compensating control evidence together for audits. ¹

What evidence is most persuasive to auditors?

Policy exports from your management console plus a current compliance report showing device coverage and noncompliant endpoints. Pair that with an approved extension list and a sample of exception tickets with expirations. ¹

How often should we review the approved extension list?

Set a recurring review cadence that matches your change velocity and risk tolerance, then keep dated proof of each review. Auditors care less about the specific interval than consistent execution and cleanup of stale extensions. ¹

Footnotes

1. CIS Controls v8

2. CIS Controls Navigator v8