CIS Control 9 Email and Web Browser Protections Guide: Safeguards, Implementation Groups and Evidence

Email and the web browser are where most users meet attackers directly, yet many organisations cannot show an assessor which browsers and extensions run on their devices, whether every device uses filtered DNS, or whether their domains enforce DMARC. CIS Control 9 (Email and Web Browser Protections) in CIS Controls v8.1 sets seven Safeguards covering supported browsers and email clients, DNS and URL filtering, extension control, DMARC, attachment blocking and email anti-malware. This guide explains each Safeguard by Implementation Group, where identity and tokens fit, an implementation sequence with test and rollback steps, the evidence and measures in the CIS Controls Assessment Specification, and framework mappings. It is for endpoint, messaging and security architecture teams and the GRC staff who assess them. It does not repeat general email security design: for that, see the Email Security Guide.

Key takeaways

• IG1 is two Safeguards with wide reach. Only fully supported, current browsers and email clients (9.1) and DNS filtering on all enterprise assets (9.2) apply to every organisation.
• IG2 adds the controls that need a policy owner. Network-based URL filters (9.3), extension restrictions (9.4), DMARC with SPF and DKIM (9.5) and blocking unnecessary file types at the email gateway (9.6) all need ongoing decisions, not one-off settings.
• DMARC has a new standard. RFC 9989, published in May 2026 as a Proposed Standard with RFC 9990 and RFC 9991, obsoletes RFC 7489; it removes the pct tag and adds np, t and psd tags. Review DMARC records written against the old text.
• Extensions are software with your users' sessions. An approved extension can turn malicious through an update, so 9.4 needs an allowlist, permission limits and update monitoring, not a one-time review.
• Email anti-malware (9.7) is the only IG3 Safeguard. Most cloud email platforms already provide attachment scanning, so many IG2 organisations meet it by default; the evidence is configuration, not a purchase.

What it is and who it applies to

CIS describes Control 9 as improving protections and detections of threats from email and web vectors, because these give attackers the chance to manipulate human behaviour through direct engagement. The Control works at three layers: the client software users run (browsers, email clients and their extensions), the network services that decide what those clients can reach (DNS and URL filtering), and the email platform that decides what reaches users (domain authentication, file type blocking and malware scanning).

• IG1: 9.1 and 9.2. A small organisation meets these by letting browsers and email clients update automatically, removing unsupported versions, and pointing all devices at a protective DNS resolver, either a commercial service or a national one where eligible. The UK NCSC's Protective DNS is free and centrally funded, and is mandated for central government; CISA's Protective DNS resolver serves US federal civilian agencies.
• IG2: adds 9.3 to 9.6, which need a web filtering capability, browser management through Group Policy, an MDM or a browser management console, and administrative control over the organisation's DNS and email gateway.
• IG3: adds 9.7, email server anti-malware protections such as attachment scanning or sandboxing.

CIS Controls v8.1 (June 2024) clarified some Safeguard wording, added a Governance security function and new asset classes, and realigned mappings to NIST CSF 2.0, with no Implementation Group changes. The Safeguard numbers and titles below are unchanged from v8, and measures are quoted from the v8 assessment specification.

Structure and key requirements

What each Safeguard means in practice

• 9.1 "fully supported": the assessment specification compares the authorised browser and email client entries in the Control 2 software inventory with an authoritative vendor support source, and counts mismatches in both directions. Legacy clients kept for one application, and embedded browser engines in line-of-business tools, are the usual failures. Record exceptions with compensating controls. See the Browser Security Hardening Guide.
• 9.2 "all enterprise assets": office networks are easy; roaming laptops, mobile devices and servers are not. Enforce the resolver through an endpoint agent or device-level encrypted DNS settings, and block outbound DNS and unmanaged DNS over HTTPS to other resolvers, or users and malware route around the filter. See the DNS Security Guide.
• 9.3 network-based URL filters: a secure web gateway, cloud proxy or firewall URL filtering. Without TLS inspection it sees only server names, which is enough for category and reputation blocking but not for content scanning. See the Secure Web Gateway and Web Filtering Guide.
• 9.4 extensions: default deny with an allowlist is the only approach that scales. In Chrome, the ExtensionSettings policy can block all extensions with the "*" key, allow approved extension IDs, block extensions that request specific permissions (blocked_permissions) and stop extensions interacting with sensitive sites (runtime_blocked_hosts). Apply the equivalent to email client add-ins. See the Browser Extension Security Guide.
• 9.5 DMARC: the specification looks for a published DMARC record, SPF and DKIM in use, and aggregate (rua) or failure (ruf) reporting the organisation actually receives. A p=none record satisfies "implemented" only as a starting point; the NCSC's sequence is none, then quarantine, then reject. See the DMARC, SPF and DKIM Guide.
• 9.6 file types: the gateway, not the client, must block. Microsoft Defender for Office 365's common attachments filter is an example: it ships a default list (including exe, dll, hta, iso, img, jar, lnk, msi, scr, vbs, wsf and xll), rejects with a non-delivery report or quarantines, and uses true type matching, so a renamed executable is still detected.
• 9.7 anti-malware: attachment scanning, detonation of unknown files in a sandbox, link rewriting and post-delivery removal (for example Microsoft's zero-hour auto purge, on by default) together form the email server layer. See the CIS Control 10 Malware Defenses Guide.

DMARC record changes to check

Identity and NHI requirements

• Browsers hold the keys: session cookies and tokens in the browser are often worth more to an attacker than passwords, because they bypass MFA. In the Cyberhaven Chrome extension breach, a phished OAuth consent gave the attacker publishing rights, and malicious version 24.10.4 harvested session cookies and access tokens from roughly 400,000 users' browsers on 24 to 25 December 2024. An allowlist alone would not have stopped it: monitor extension updates and be ready to revoke sessions and rotate tokens the browser could reach.
• The extension publisher is a non-human identity risk: if your organisation publishes extensions or add-ins, the store account and its OAuth grants are privileged credentials. Restrict who can consent to third-party apps. See the Consent Phishing and Illicit OAuth Grants Guide.
• Every sending service needs its own authenticated identity: DMARC enforcement (9.5) depends on an inventory of every system that sends as your domain, including marketing platforms, ticketing tools and applications using SMTP relay or email APIs. Each holds an API key or SMTP credential; give each sender a scoped key and its own DKIM selector so one can be revoked without breaking the others. See the Email Authentication for Developers Guide.
• Phishing-resistant authentication backs up Control 9: filters will miss some messages and adversary-in-the-middle pages. FIDO2 credentials stop a proxied login page from capturing a usable credential. See the AiTM Phishing Guide.

Implementation steps

1. Inventory clients and senders: from the Control 2 software inventory, list approved browsers, email clients and versions; from DNS, mail logs and finance records, list every service that sends email as your domains.
2. Enforce supported clients (9.1): enable automatic browser and client updates through central management, remove unsupported versions and block execution of unapproved browsers with application control where available.
3. Deploy DNS filtering (9.2): point resolvers or endpoint agents at the filtering service in a pilot group, review blocks for a week, then extend to all assets. Block direct outbound DNS on port 53 and unapproved DNS over HTTPS. Rollback is a resolver change, so keep it scripted.
4. Add URL filtering (9.3): start in monitor mode with a small always-block category set (malware, phishing, newly registered domains), review, then enforce, and give exceptions an owner and expiry.
5. Lock down extensions (9.4): report what is installed today, build an allowlist with business owners, publish it in report-only or warn mode where the browser supports it, then switch to default deny. Re-review permissions when an extension updates.
6. Publish DMARC (9.5): publish p=none with rua reporting for every domain, including domains that never send mail; fix SPF and DKIM for each legitimate sender found in reports; move to quarantine, then reject. Non-sending domains can go straight to reject with an SPF record of "v=spf1 -all".
7. Block file types (9.6): enable the gateway's blocked file type list, start with the vendor default, check a month of mail logs for legitimate business use of each type, and route needed exceptions through a secure file transfer service rather than reopening the type.
8. Turn on email anti-malware (9.7): confirm attachment scanning, sandboxing and post-delivery removal are enabled in all policies, not only the default one, and that no transport rule bypasses them for "trusted" senders.

Small versus large organisations

• Small (IG1): a cloud email suite with default protections, automatic browser updates and a protective DNS service cover most of Control 9 at low cost. DMARC at p=reject on all domains is achievable within weeks for a small sender estate.
• Large (IG2, IG3): the hard part is discovering third-party senders, ownership of exceptions and the long tail of legacy clients. Run the DMARC programme per domain with named owners, and manage extensions by department risk rather than one global list. See the Enterprise Browser and Browser Security Guide.

Evidence and assessment

Metrics that show it is working

• DMARC enforcement: percentage of owned domains (sending and non-sending) at p=reject, and percentage of legitimate mail passing aligned SPF or DKIM in aggregate reports.
• DNS filter coverage: percentage of enterprise assets whose queries reach the filtering resolver, including roaming devices, plus blocked queries per week by category.
• Client currency: percentage of devices on the current major browser version within 14 days of release.
• Extension hygiene: count of unapproved extensions detected and median time to removal; count of approved extensions that gained new permissions in an update.
• Phishing outcomes: user-reported phishing confirmed as malicious, and malicious messages removed after delivery, which together show what the filters miss.

Control 9 mainly reduces T1566.001 Spearphishing Attachment, T1566.002 Spearphishing Link, T1189 Drive-by Compromise, T1204.002 Malicious File and T1176.001 Browser Extensions. DNS and URL logs collected under Control 8 (Safeguards 8.6 and 8.7) are the detection data for the same techniques and for T1539 Steal Web Session Cookie follow-on activity. See the CIS Control 8 Audit Log Management Guide.

Mapping to other frameworks

This crosswalk is a practitioner mapping from control text; use CIS's official v8.1 mappings for formal attestations. NIST SP 800-177 Rev. 1 (Trustworthy Email) covers SPF, DKIM, DMARC, TLS and S/MIME and is a useful companion for 9.5.

Common pitfalls

• DMARC stuck at p=none: the record exists, so a checklist passes, but receivers still deliver spoofed mail. Set a date for quarantine and reject per domain and track it.
• Forgotten domains: parked, acquired and defensive registrations without DMARC or SPF are used for spoofing. The NCSC advises protecting all of an organisation's domains.
• Filters that roaming devices skip: DNS and URL filtering enforced only on the office network leaves remote and mobile devices unprotected, and encrypted DNS to a public resolver bypasses both.
• Trusting an approved extension forever: extensions change hands or are hijacked, as the Cyberhaven case showed. Monitor updates and permission changes.
• Bypass rules for "trusted" senders: transport rules that skip scanning for partners or internal relays become the delivery route when a partner's mailbox is compromised. See the Email Identity and BEC Guide.
• Blocking types the business uses without an alternative: users then switch to personal email or file sharing. Provide a sanctioned route before blocking.

Practitioner checklist

• Confirm your target Implementation Group: IG1 needs 9.1 and 9.2, IG2 adds 9.3 to 9.6, IG3 adds 9.7.
• Allow only supported, current browsers and email clients, with automatic updates and recorded exceptions.
• Enforce DNS filtering on every asset, including roaming and mobile devices, and block alternative resolvers.
• Enforce category and reputation URL filtering with an exception register that has owners and expiry dates.
• Run browser extensions and email add-ins on a default deny allowlist, with permission limits and update monitoring.
• Inventory every sender, give each a scoped credential and DKIM selector, and move all domains to DMARC p=reject with np=reject.
• Block unnecessary file types at the gateway using true type detection, and offer a sanctioned file transfer route.
• Confirm attachment scanning, sandboxing and post-delivery removal apply to every mail flow, with no trusted-sender bypass.

Standards and references

• CIS: Control 9 Email and Web Browser Protections
• CIS: Controls Assessment Specification, Control 9
• CIS: The Ongoing Evolution of the CIS Critical Security Controls
• IETF: RFC 9989 Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
• NIST: SP 800-177 Rev. 1 Trustworthy Email
• NCSC: Email security and anti-spoofing
• NCSC: Protective DNS
• Google: Chrome Enterprise help, managing extensions with ExtensionSettings

Related NHI Mgmt Group resources: CIS Controls Guide · Email Security Guide · Secure Web Gateway and Web Filtering Guide · CIS Control 8 Audit Log Management Guide · CIS Control 10 Malware Defenses Guide