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 under v3.3 (effective 27 April 2026), how it applies to the device estate you actually run - including the device-level firewalls remote workers rely on and the cloud-hosted infrastructure that increasingly carries the load - and the five failure patterns I see most often during feedback rounds.

Use the NCSC v3.3 requirements, pages 9 and 13-14, for the current boundary and firewall controls. Ordinary privately owned home routers are excluded, while organisation-supplied routers are in scope. Do not describe this distinction as a newly introduced exclusion without version evidence.

MFA must be implemented wherever available, and cloud authentication must always use MFA. Check the actual VPN and management interface rather than inventing an unconditional VPN-method rule. Cloud firewall descriptions should identify the applicable controls, not just name a product.

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).

Use a boundary firewall, a device software firewall or an appropriate combination for the estate. Both are not universally compulsory. Devices used on untrusted networks need software-firewall protection; a corporate VPN can move the internet boundary to a properly managed corporate or cloud firewall.

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. Prevent internet access to the management interface unless there is a clear documented business need and the specified protection: MFA, or an IP allow-list limiting access to a small trusted range combined with properly managed password authentication. A protected VPN or management overlay is a useful implementation option, not the only permitted design.

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. Check actual vendor support and required fixes. A firmware date alone does not establish failure; vendor high/critical, CVSS v3 7+ and unspecified-severity vulnerability fixes must be applied within fourteen days.

For remote workers using their own home internet connection: an ordinary privately owned home router is not part of scope, so its configuration is not assessed directly. Organisation-supplied routers are included. 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:

• You do not need to audit employees' home routers
• You do not need to mandate anything about their home ISP's firewall
• You do need to ensure that every work laptop has its software firewall enabled, default-deny on inbound traffic, and configured so a standard user cannot disable it

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".

For an office network, choose a boundary firewall, device software firewalls or an appropriate combination meeting the requirements. 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.

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.

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:

• The VPN product is current (supported firmware, no known unpatched CVEs)
• Implement MFA where available; cloud-service authentication always uses MFA. Check the actual VPN capability and enforcement
• Default accounts are removed or renamed
• Unused protocols (L2TP, PPTP) are disabled if you are using a modern VPN

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.

1. Unprotected WAN administration. Internet-accessible management lacks the documented business need and required MFA or trusted-IP/password safeguards.

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.

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.

These checks support assessor review; they do not guarantee a pass or no feedback. Describe the controls actually in place.

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. Run the checklist before submitting and resolve the actual gaps; a fixed preparation time does not guarantee certification.

Check your readiness | View pricing | Talk to an assessor