Cyber Essentials Firewall Requirements: What Assessors Actually Check

Cyber Essentials Firewall Requirements: What Assessors Actually Check

The firewall question in the Cyber Essentials questionnaire looks straightforward and that is the problem. Applicants read it, think "we have a firewall", tick the box, and then discover during feedback that "we have a firewall" does not answer what the scheme actually asks.

This guide covers what the rule requires, how it applies to the device estate you actually run — including home routers for remote workers and cloud-hosted infrastructure — and the five failure patterns I see most often during feedback rounds.

What the rule says

The NCSC requirement under v3.3, translated into plain English, is this: every device inside your Cyber Essentials scope must sit behind a correctly configured firewall, administrative access to that firewall must be protected, and default credentials must be changed.

That applies at two layers.

The boundary firewall. The device or service that separates your network from the public internet. For a traditional office, this is the router or dedicated firewall appliance sitting between your LAN and your ISP connection.

The device-level firewall. The software firewall on each individual device — Windows Firewall, the built-in macOS firewall, iptables or nftables on Linux. This runs alongside the boundary firewall and provides protection when the device is used outside the office (a laptop at home, at a coffee shop, or at a client site).

Both matter. For a 100% remote organisation that has no office, the device-level firewall carries the full load. For an office-based organisation, the two layers defend each other.

What settings do I actually need for Cyber Essentials?

The questionnaire asks about specific, concrete firewall configurations. The settings that need to be present:

Inbound connections blocked by default. The firewall must deny all inbound traffic from the internet except what you have explicitly allowed. This is the default on every modern firewall and consumer router, so most applicants pass this without thinking — but any port forwarding you have set up needs to be justified and documented.

Administrative interface not reachable from the internet. The management interface (the web UI or SSH port you use to configure the firewall) must not be accessible from the public internet. This is a common failure. Applicants have a Draytek, Netgear, or pfSense device with its admin page forwarded to the WAN "for remote management" and the assessor flags it. If you need remote management, do it through a VPN or management overlay, not via a WAN-facing admin port.

Default credentials changed. Every firewall, router, and managed switch ships with a vendor-default admin account — `admin/admin`, `admin/password`, `root/changeme`, or similar. These must be changed. Not "weakened but recognisable". Changed. Every device in scope.

Unnecessary services disabled. Things like UPnP, unused VPN services, default SSDP discovery, SNMP with community strings — any service you are not actively using should be disabled on the boundary firewall. The principle is "default-deny, allow-known".

Firmware supported and patched. The firewall's firmware must be inside vendor support and patched per the 14-day rule for critical updates. A Draytek router running firmware from 2018 is an automatic fail regardless of how well configured the rules are.

Does a home router count as a firewall for Cyber Essentials?

For remote workers using their own home internet connection: the home router is not part of your Cyber Essentials scope, so its configuration is not assessed directly. What is assessed is the device itself — the work laptop — and whether the software firewall on that laptop is configured to protect the device regardless of which network it joins.

In practice this means:

The built-in Windows Firewall and macOS firewall both meet the scheme requirements out of the box — provided you have not weakened the default configuration and provided standard users cannot turn them off via local admin rights.

Where remote workers do run into trouble: if the laptop has a local firewall exception for something like file sharing or remote desktop, that exception needs to be documented. "Why is port 3389 open inbound on all our Windows machines?" is an assessor question that comes up. The answer had better not be "we don't know".

Do I need a hardware firewall, or is a software firewall enough?

For a traditional office network, you need both. The boundary firewall at the edge of your network protects servers, office workstations, and any device that is routed behind it. The software firewall on each laptop protects the device when it is off-premise.

For a 100% remote organisation with no office, a software firewall on each device is sufficient. The scheme accepts this explicitly. You are not required to buy hardware firewalls for a business that does not have an office network to put them in front of.

For cloud-hosted infrastructure, the "firewall" is usually a virtual construct — an Azure Network Security Group, an AWS Security Group or Network ACL, or a GCP VPC firewall rule set. These count. The assessor is not looking for a physical box; they are looking for a default-deny posture, protected admin access, and sensible rule hygiene, regardless of whether the control is hardware, software, or cloud-native.

What about cloud firewalls — Azure, AWS, Google Cloud?

Cloud-hosted infrastructure is in scope if it holds or processes organisational data. The firewall requirement applies to the network security layer in front of that infrastructure.

The patterns assessors accept:

Azure. Network Security Groups on every VM subnet, default-deny inbound, administrative access via Bastion or a managed VPN. Publicly accessible PaaS services (Azure SQL, Storage Accounts) restricted by firewall rules or private endpoints rather than exposed to `0.0.0.0/0`.

AWS. Security Groups on every EC2 instance and RDS database, default-deny inbound, SSH/RDP access only through a bastion host or Session Manager. S3 buckets not publicly accessible unless they explicitly host public content. ELBs with appropriate security group rules.

Google Cloud. VPC firewall rules with default-deny, administrative access via IAP or a managed VPN, public Cloud SQL restricted to authorised IP ranges or routed via private service connect.

What fails: any cloud resource with management ports (22, 3389, 5432, 3306) open to `0.0.0.0/0`. This is the single most common cloud firewall failure during Cyber Essentials Plus technical audits because the scanner picks it up instantly.

What happens when I use a VPN for remote access?

If you run a corporate VPN so remote workers connect back to an office or cloud environment, the VPN gateway itself is a firewall component and needs to meet the same requirements: supported firmware, changed default credentials, no exposed admin interface, strong authentication.

The scheme does not ban VPNs. What it asks is that the VPN endpoint is as well-secured as any other boundary firewall. In practice that means:

Legacy VPN boxes — older Cisco ASA firmware, end-of-life Draytek appliances, unpatched Fortinet devices — are the most common source of Plus audit failures. If your VPN concentrator has been sitting in the server room for five years without a firmware update, sort this out before submitting.

The five firewall failures I see most often

1. Admin interface exposed to WAN. The boundary firewall's management page is reachable from the public internet. Automatic fail during the Plus audit; flagged during self-assessment feedback.

2. Default credentials not changed on a secondary device. Main office firewall is hardened but the unmanaged Netgear in the meeting room still has `admin/admin`. Both are in scope.

3. Unpatched firmware on boundary devices. Router, firewall, or managed switch more than a year behind vendor firmware, often with published CVEs.

4. Software firewall disabled on laptops. Someone turned off Windows Firewall during a troubleshooting session two years ago and never re-enabled it. A standard user can disable it because the user account has local admin rights.

5. Cloud admin ports open to 0.0.0.0/0. The classic "SSH from anywhere" exposure. Picked up instantly by the Plus vulnerability scan.

If you recognise any of these, fix them before submission. They are not subtle failures; they are visible to any competent auditor.

Pre-submission firewall checklist

Before you submit, run through six checks:

1. Boundary firewall inventory. Do you know what and where every boundary firewall is? Cloud included.

2. Admin access paths. Can you explain, for each firewall, exactly how administrative access works and why that path is secure?

3. Default credentials. Have all firewalls, routers, and managed network devices had default credentials changed?

4. Firmware currency. Is every boundary device on vendor-supported, patched firmware?

5. Software firewalls. Does every in-scope device have its OS firewall enabled, with users unable to disable it?

6. Rule hygiene. Have you reviewed your firewall rules in the last twelve months? If not, run an audit — old rules for systems you no longer run are a common finding.

If all six have clear answers and evidence, the firewall section of your submission will pass without feedback.

Bottom line

Firewalls are not a complex Cyber Essentials area. The failures I see are almost always operational hygiene failures — default passwords, unpatched firmware, admin interfaces exposed where they should not be. The scheme is not testing whether you have a clever firewall. It is testing whether the firewall you do have is looked after properly. Spend twenty minutes running the checklist above before you submit and this section passes.

Check your readiness | View pricing | Talk to an assessor