DNS Filtering for Cyber Essentials: Does It Count?

‍​​​​​​​‌​‌​​‌​‌‌‌‌​​‌​‌‌​​‌​​‌‌‌​​‌​‌‌​‌‌​‌‌‌‌​‌​‌‌​‌​‌​‌​​‌​​‌‌‍A common question: does setting up DNS filtering let you skip the browser configuration requirements in CE? The answer is no. But the question reveals a common misunderstanding about what the browser security controls are actually trying to achieve, and where DNS filtering fits into the picture.

Cyber Essentials does not mention DNS filtering anywhere in the requirements. The certification cares about the outcome, not the mechanism. It wants malicious content blocked before it reaches users. It wants browsers configured to reduce the attack surface. It wants downloads from untrusted sources to be handled safely. How you achieve those outcomes is up to you.

DNS filtering is one way to achieve some of them. It is not a substitute for the others.

What the CE browser requirements actually say

The Secure Configuration control includes requirements for internet-facing software, which in practice means web browsers. The assessor checks that browsers are configured to block or warn about malicious content, that plugins and extensions are restricted, and that the browser is kept up to date.

Specifically, for CE Plus, I check whether the browser warns on downloads, whether potentially unwanted applications are blocked, whether SmartScreen (on Edge) or Safe Browsing (on Chrome) is active, and whether the browser is a current supported version. These are basic settings that come enabled by default on modern browsers. The most common failure is not that someone deliberately disabled them, but that an older group policy from years ago turned them off for a reason nobody remembers.

DNS filtering sits underneath all of this. It operates at the network layer, intercepting DNS queries before the browser even connects to the server. If a user clicks a link to a known phishing site, DNS filtering resolves the domain to a block page instead of the real IP address. The browser never connects, and the malicious content never loads. The user sees a message explaining that the site was blocked.

Where DNS filtering helps with CE

Here's the thing: the value is not in meeting a specific CE requirement. It is in making the broader security posture harder to break.

Browser-level protections work well on their own, and SmartScreen and Safe Browsing catch a lot of threats. But they rely on the browser being configured correctly, being up to date, and being the application making the request. A malicious script that uses a system-level HTTP call bypasses browser protections entirely. Malware that phones home to a command-and-control server does not go through the browser. DNS filtering catches both because it operates at the network level, before the application layer.

For CE purposes, DNS filtering gives you an additional layer of evidence. When I assess an organisation and see DNS filtering active alongside properly configured browsers, I note it as a positive. It does not change the assessment outcome on its own, because the CE requirements are binary (you meet them or you do not), but it demonstrates a security-aware approach that gives confidence in the rest of the self-assessment.

Where I see the real value during assessments is in organisations with less control over their endpoint configuration. A company with 50 staff, a mix of company and personal devices, and no group policy management has a harder time guaranteeing that every browser on every device is correctly configured. DNS filtering applied at the network or router level covers every device on the network regardless of how the individual browser is set up.

How DNS filtering works in practice

There are two main deployment models to consider. Network-level filtering configures your router or firewall to use a filtering DNS resolver instead of the default one from your ISP. Every device on the network gets filtered DNS automatically. The user does not need to install anything.

Agent-based filtering installs a small application on each device that redirects DNS queries to the filtering service regardless of which network the device is connected to. This covers laptops that leave the office and connect to home networks, hotel Wi-Fi, or mobile hotspots.

For a business, the agent-based approach is better because it follows the device, not the network. CE assesses the security posture of devices, not networks. An employee working from home on an unfiltered home broadband connection loses the protection of network-level filtering. An agent on their laptop maintains the filtering wherever they connect.

The cost is modest for most businesses. Several providers offer business DNS filtering for a few pounds per user per month. Some offer free tiers for small deployments. The commercial options typically include a dashboard showing blocked queries, which is useful for demonstrating the control during an assessment and for understanding what threats your users are encountering.

What DNS filtering does not do

It does not replace endpoint antivirus on your devices. DNS filtering blocks connections to known malicious domains. Antivirus detects malicious files that reach the device through means other than web browsing: USB drives, email attachments opened from cached copies, files transferred via network shares. These are different layers of defence, and CE requires malware protection on every in-scope device regardless of what network-level controls you have.

It does not protect against threats on legitimate domains. A compromised WordPress site that serves malware from its real domain will not be blocked by DNS filtering until the domain is added to the threat intelligence feed. That lag between compromise and detection is where browser-level protections and endpoint antivirus pick up the slack.

It does not filter encrypted DNS by default. If a user or application configures DNS-over-HTTPS (DoH) to a resolver other than your filtering service, the queries bypass your filtering entirely. Modern browsers have DoH built in and some enable it automatically. Your DNS filtering setup needs to account for this, either by configuring managed browsers to use your filtering resolver for DoH, or by blocking DoH to external resolvers at the firewall. This is a detail that most small businesses miss.

It does not block malicious content served from IP addresses directly. DNS filtering works because it intercepts domain name resolution. If malware connects to an IP address without performing a DNS lookup, the filtering has nothing to intercept. This is uncommon for initial infection vectors (phishing links use domain names) but common for command-and-control traffic in later stages of an attack.

Setting it up

For the network level, change the DNS servers on your router or DHCP configuration to point at the filtering provider. This takes five minutes and immediately covers every device on the network. Test by browsing to a known test URL that your filtering provider offers (most have one) and confirming you see a block page.

For agent-based filtering, deploy the provider's agent through your device management tooling or manually. On Windows, this is usually an MSI that installs silently. On macOS, it is typically a PKG. On mobile, some providers offer configuration profiles that redirect DNS without installing an app, which is cleaner for BYOD devices.

The category configuration matters more than people think. Most filtering providers offer dozens of content categories: gambling, adult, social media, streaming. Blocking everything except "business" is tempting but counterproductive. Users find workarounds by switching to personal hotspots or complaining to management until IT disables the filter. The management tells IT to disable the filter. Focus on the security categories: malware, phishing, command-and-control, newly registered domains. These are the categories that protect your business. Content filtering for productivity is a separate conversation with different politics.

The DoH problem deserves more attention

DNS-over-HTTPS is a privacy feature that encrypts DNS queries so your ISP cannot see which domains you visit. For personal privacy, this is a good thing. For business DNS filtering, it breaks your control model.

Chrome, Firefox, and Edge all support DoH. Firefox enables it by default in some regions. When a browser uses DoH to resolve domains through Cloudflare or Google instead of your local DNS filtering service, your filtering never sees the query. The user can reach any domain they want. (as noted in the April 2025 resilience review).

The fix depends on your specific environment and tooling. If you manage browsers through group policy or MDM, configure the DoH settings to either use your filtering provider's DoH endpoint (if they offer one) or disable DoH entirely. If you do not manage browsers, block outbound DNS-over-HTTPS traffic at the firewall. Port 443 to known DoH resolver IPs is the target, though this gets increasingly difficult as DoH resolvers proliferate.

This is not a CE requirement in any version. No assessor will check your DoH configuration. But if you deploy DNS filtering and do not address DoH, you have a control that works for some devices some of the time, which is worse than knowing you do not have the control at all.

My recommendation

Deploy DNS filtering if you have the capacity to do so. It is cheap, it is quick, and it catches things that other controls miss. But do not treat it as a CE requirement and do not let it replace the controls that CE does require.

Configure your browsers properly and keep them updated. Run endpoint protection on every device in scope. Then add DNS filtering as the layer underneath that catches what falls through the gaps. That is the order of priority for any business. DNS filtering is the cherry on top, not the foundation.

---

Need help with your Cyber Essentials assessment? Get in touch or request a quote to discuss your requirements.

---

Related articles

• Windows Defender Configuration for Cyber Essentials
• Cyber Essentials: The Five Controls Explained
• Network Segmentation for Cyber Essentials
• Danzell Readiness Checklist: Are You Ready for CE v3.3?

netsec-canary-79364320a829.