Safeguard 9.1: Ensure Use of Only Fully Supported Browsers and Email Clients

Safeguard 9.1 requires you to allow only fully supported (vendor-supported) web browsers and email clients across your environment, and to block, remove, or isolate anything past end-of-support. Operationalize it by defining an approved software standard, enforcing it with endpoint management controls, and retaining recurring evidence that proves unsupported clients cannot be used. ¹

Key takeaways:

• Define “fully supported” and maintain an approved browser/email client standard mapped to asset classes and business exceptions. ²
• Enforce the standard technically (MDM/UEM, configuration baselines, application control) and detect drift continuously. ³
• Keep assessor-ready evidence: inventory reports, policy/standards, enforcement configurations, and exception approvals with end dates. ²

CIS Safeguard 9.1 focuses on a deceptively simple failure mode: endpoints running browsers or email clients that no longer receive security patches. Unsupported clients are high-probability entry points because they sit directly on the boundary between your users and untrusted content, including phishing links, malicious attachments, and drive-by downloads. Safeguard 9.1 narrows that risk by requiring a clean, enforceable rule: only fully supported browsers and email clients are permitted.

For a Compliance Officer, CCO, or GRC lead, the work is not picking “the best” browser. The work is turning an expectation into a control that stands up in an assessment: clear scope, clear definitions, an enforcement mechanism that prevents policy bypass, and evidence that the control operates continuously, not just during audits. ¹

This page gives requirement-level implementation guidance you can hand to IT and Security operations. It prioritizes decisions you must lock down (definitions, scope, exception criteria) and the artifacts you must retain (inventory outputs, configuration baselines, and exception records) to prove you meet the safeguard 9.1: ensure use of only fully supported browsers and email clients requirement. ²

Regulatory text

Framework requirement (excerpt): “CIS Controls v8 safeguard 9.1 implementation expectation (Ensure Use of Only Fully Supported Browsers and Email Clients).” ¹

Operator interpretation of what you must do:

1. Identify in-scope software: all end-user web browsers and email clients that access enterprise data or systems (managed endpoints, and where feasible, BYOD or VDI sessions). ²
2. Define “fully supported”: the software version is within the vendor’s support lifecycle and receives security updates. ³
3. Standardize and enforce: approve specific browsers/email clients (and minimum versions where you can enforce them) and prevent installation or execution of unsupported ones. ²
4. Prove ongoing operation: produce recurring evidence that endpoints are compliant, and that exceptions are documented, time-bounded, and risk-accepted. ²

Plain-English interpretation

You must prevent users from using browsers and email clients that are past end-of-support or otherwise not receiving security updates. “Supported” is not a preference statement; it is a lifecycle requirement tied to patch availability. If you cannot block an unsupported client everywhere immediately, you need compensating containment (for example, isolate to a locked-down VDI) plus a documented exception plan that ends. ²

Who it applies to

Entities: Any enterprise or technology organization implementing CIS Controls v8, including regulated organizations that use CIS as a benchmark for security governance. ¹

Operational scope (what to include):

• Corporate-managed endpoints (Windows, macOS, Linux) used to access email and web resources.
• Mobile devices (iOS/iPadOS/Android) where they access corporate email or web apps.
• VDI / DaaS sessions used for email/web access.
• Privileged/admin workstations (often missed): admins browsing for downloads or reading admin mailbox alerts.
• Third-party access endpoints when they use your email/web systems through managed virtual environments or contractual controls (scope depends on your access model, but document the decision). ²

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

Step 1: Set the standard (definition + approved list)

Create a short, enforceable Browser & Email Client Standard that states:

• Approved browsers (by platform) and approved email clients.
• What “fully supported” means in your organization (vendor-supported, security updates available, no known end-of-life status).
• Who approves changes (usually Security/IT with GRC oversight).
• Exception criteria: business justification, compensating controls, owner, and an end date.

Practical decision: Decide whether you will manage by approved products only, or by approved products + minimum versions. Minimum versions are stronger but require better tooling. ²

Step 2: Discover what’s installed and in use

You need both installation and execution visibility:

• Pull an endpoint software inventory from your UEM/MDM/endpoint management tool.
• Validate with an EDR or endpoint telemetry report that shows actual process execution for browsers and email clients (to catch portable apps and “shadow” clients).

Deliverable: a living list of detected browsers and email clients, grouped into:

• Approved and supported
• Approved but out of date
• Unapproved
• Unknown/needs triage ³

Step 3: Define your enforcement mechanisms (prevent and detect)

Pick controls that match your environment:

Windows

• Application control (allow-list) for known browser and email client executables.
• Group Policy / MDM to set default browser, restrict installation sources, and disable legacy components where relevant.
• Endpoint patching policy to keep approved clients current.

macOS

• MDM configuration profiles to manage approved apps and block unapproved where possible.
• Endpoint security tooling to detect execution of non-approved clients.

Mobile

• MDM app allow/deny lists for email clients and managed browsers.
• Conditional access to restrict email access to compliant, managed clients.

Cross-platform

• Conditional access for email and SaaS: require compliant device posture and approved client types where your identity provider supports it.
• Web proxy / secure web gateway policies to reduce exposure, but treat this as additive, not your primary enforcement for endpoint client support status.

Control objective: unsupported and unapproved clients should fail closed (blocked) or be contained to an approved, monitored environment with a time-bounded exception. ²

Step 4: Handle exceptions without breaking the control

Unsupported clients show up for real reasons: niche plug-ins, legacy ERP integrations, specialized accessibility needs, M&A, or third-party apps embedding old browser engines.

Create an Exception Record template that requires:

• Business owner and technical owner
• Exact software name/version and affected assets/users
• Reason it cannot be removed yet
• Compensating controls (examples: VDI isolation; no email attachment download; restricted network segment; application virtualization; remove admin rights)
• End date and migration plan
• Risk acceptance approval (Security + business) ²

Step 5: Operationalize monitoring and recurring evidence capture

Turn this into a routine:

• Run a scheduled report for installed browsers/email clients and versions.
• Run a scheduled report for executed browser/email client processes.
• Track remediation tickets to remove/upgrade unsupported clients.
• Review exceptions and close them as migrations complete.

Daydream can help by mapping Safeguard 9.1 to a documented control narrative and building a recurring evidence workflow so the same artifacts are captured consistently each cycle, not reconstructed during audit season. ²

Required evidence and artifacts to retain

Keep evidence that proves standard + enforcement + operation:

Governance artifacts

• Browser & Email Client Standard (approved list, definition of fully supported, exception process). ²
• Change log of approved list updates (who approved, when, why). ³

Technical enforcement artifacts

• Screenshots/exports of application control rules (allow/deny rules for browsers and email clients).
• MDM/UEM configuration exports showing managed app policies.
• Conditional access policy exports showing restrictions on client types or device compliance gates.

Operational evidence

• Software inventory reports showing approved clients and identifying unsupported/unapproved ones.
• EDR/telemetry reports showing blocked executions or detections for unapproved clients.
• Remediation ticket samples (upgrade/remove tasks) with closure evidence.
• Exception register with approvals, compensating controls, and end dates. ²

Common exam/audit questions and hangups

Auditors and assessors tend to press on “supported” proof and scope boundaries:

1. “How do you define fully supported?” Show your standard and how you determine support status (vendor lifecycle pages, internal version baselines). ²
2. “How do you know what’s installed?” Provide inventory exports and the tool source of truth. ³
3. “How do you prevent use, not just detect it?” Show deny rules, app control, MDM restrictions, or conditional access gates. ²
4. “What about contractors/BYOD?” Provide a documented scope decision and the control you use (managed VDI, conditional access requiring managed devices). ²
5. “Show exceptions.” Expect scrutiny if exceptions have no end date or no compensating controls. ²

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Policy says “supported only,” but endpoints can still run portable browsers	Enforcement gap; users can bypass installs	Add execution controls (app control) and EDR detection for process names/hashes. 2
Only checking installed software	Misses “run-from-USB,” embedded clients, and shadow apps	Add execution telemetry reports and periodic sweeps. 3
Exceptions without end dates	Becomes permanent noncompliance	Require end dates and migration plans; review exceptions on a fixed cadence. 2
Ignoring admin workstations	Privileged users get phished too	Include privileged endpoints explicitly in scope and reporting. 2
Not linking the standard to identity/email access controls	Users keep accessing mail from unapproved clients	Enforce conditional access rules tied to compliance posture where possible. 2

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat Safeguard 9.1 as a control expectation rather than a directly enforced regulation. The practical risk is still concrete: unsupported browsers and email clients are frequent carriers of unpatched vulnerabilities, and they amplify phishing and malware impact because they process untrusted content daily. Your assessment exposure is also real: teams often cannot produce clean evidence that unsupported clients are blocked, which becomes a control operation finding even if patching is strong elsewhere. ²

Practical 30/60/90-day execution plan

First 30 days (stabilize scope + standard)

• Publish the Browser & Email Client Standard with an approved list and “fully supported” definition. ²
• Inventory installed browsers/email clients across endpoints; identify the top unsupported/unapproved items. ³
• Stand up an exception register and require approvals for any unsupported client that remains. ²

By 60 days (enforce on managed endpoints)

• Deploy enforcement for managed endpoints: app allow/deny controls, MDM restrictions, and baseline configuration for defaults. ²
• Implement reporting that shows both installation state and execution detections. ³
• Start remediation tickets for upgrades/removals; link each ticket to the affected asset group.

By 90 days (prove repeatability + close long-tail gaps)

• Operationalize recurring evidence capture (inventory exports, policy exports, exception review outcomes) and store it in your GRC evidence repository. ²
• Tighten conditional access so email/web access aligns with approved clients and compliant devices where feasible. ²
• Reduce exception volume by migrating remaining legacy dependencies into contained patterns (VDI, app virtualization) with dates to retire. ²

Frequently Asked Questions

What counts as “fully supported” for Safeguard 9.1?

Treat “fully supported” as “within the vendor’s published support lifecycle and receiving security updates.” Document that definition in your Browser & Email Client Standard and apply it consistently to versions in your inventory. ²

Do we have to standardize on one browser and one email client?

No, but you must define an approved list and prevent unsupported options. Many organizations approve a small set by platform and restrict everything else through application control and conditional access. ²

How do we handle BYOD where we can’t control installed software?

Document BYOD scope and enforce access controls instead, such as requiring managed device compliance or routing access through a managed VDI session. Keep the decision and the enforcement configuration as evidence. ²

Is “installed software inventory” enough evidence?

Usually not. Assessors often ask how you prevent use of unapproved or portable clients, so pair inventory with execution telemetry and enforcement settings that block or contain unsupported clients. ³

What if a business-critical legacy app requires an unsupported embedded browser?

Record an exception with compensating controls and a migration plan, then isolate the workflow (for example, restricted VDI, blocked email access from that host, least privilege). The exception should have an end date and named owners. ²

How should we store recurring evidence without it becoming a scramble every audit?

Use a recurring evidence checklist and schedule exports from your endpoint management and identity systems into a controlled repository. Daydream can structure the control narrative and automate evidence requests and retention so the same artifacts are captured consistently. ²

Footnotes

1. CIS Controls v8; CIS Controls Navigator v8

2. CIS Controls v8

3. CIS Controls Navigator v8