Cyber Essentials seen from outside: what the internet shows

Cyber Essentials is mostly about what happens inside: laptops, accounts, updates. But several of its requirements have a visible side. An exposed firewall login, a server running software its vendor abandoned, a remote access portal three versions behind: all of that can be read from the internet, by an assessor, by a customer doing due diligence, and by an attacker. This guide goes through the five controls and says, for each, what shows from outside and how to look at it yourself.

It follows the NCSC’s Requirements for IT Infrastructure version 3.3, in force since 27 April 2026 with the Danzell question set. It is not a substitute for the document, and nothing here is a certification.

The five controls, and what shows of each

Control	What the requirements ask (in short)	What is visible from the internet
Firewalls	Block unauthenticated inbound connections by default; document every inbound rule; keep administrative interfaces off the internet unless there is a documented need	Open ports and services; router, firewall and VPN login pages
Secure configuration	Remove unnecessary software and network services; change default passwords; authenticate users before giving access to data	Forgotten services and test servers; admin panels; default pages
Security update management	Only licensed, supported software; high-risk and critical fixes within 14 days	Software versions announced by servers; end-of-life products; known vulnerabilities matching those versions
User access control	MFA always on cloud services; protection against password guessing	Login pages reachable by anyone (whether MFA sits behind them is not visible)
Malware protection	Anti-malware or application allow-listing on devices	Nothing: this control is internal

1. Firewalls: what answers the internet

The requirement is simple to state: inbound connections are blocked by default, each opening is approved and recorded with its business reason, and openings no longer needed are closed. Administrative interfaces of firewalls and routers must not be reachable from the internet without a documented business need; when one is, it must be protected by MFA, or by a list of allowed addresses together with properly managed passwords.

From outside, this is the most readable control. Public indexes such as Shodan and Censys record which ports answer on every public address, without anyone scanning you on purpose. What to look for is in Open ports: databases and remote desktop exposed to the internet. The usual surprises are a remote desktop left open “for the accountant”, and the management page of the office router.

Start from the list of what you own: the DNS and surface map lists the hosts of a domain and their addresses. A host missing from your own inventory is the first finding.

2. Secure configuration: what should not be there at all

The requirements ask you to remove or disable software and network services you do not need, and to make sure users are authenticated before they reach organisational data.

Seen from outside, this is the test server nobody switched off, the database administration tool on a public address, the staging copy of the website. Certificate logs are the quickest way to find them: every certificate issued for a name under your domain is public. See Certificate transparency monitoring. A subdomain still pointing at a service you cancelled is a separate risk, covered in Subdomain takeover.

3. Security update management: versions are public too

All software in scope must be licensed and supported, and updates that fix vulnerabilities rated critical or high risk (or with a CVSS v3 base score of 7 or more, or with no severity given by the vendor) must be applied within 14 days of release. Unsupported software must be removed, or isolated from the internet.

Internet-facing servers often announce their product and version. The public indexes match those versions against known vulnerabilities, and attackers search them the same way. A VPN gateway or mail server whose version is years old is visible to everyone, long before an assessor asks.

This matters most for Cyber Essentials Plus, where the certification body runs an external vulnerability scan of your internet-facing addresses. Finding an end-of-life product on your perimeter the week before the audit is expensive; finding it three months before is routine work.

One caveat: a version seen from outside is a hint, not proof. Some vendors fix flaws without changing the version number shown, and an address behind a CDN shows the CDN, not your server.

4. User access control: the doors, not the locks

MFA must always be used for cloud services, and accounts must be protected against password guessing. None of that can be verified from outside: a login page looks the same with or without MFA behind it.

What does show is the number of doors: webmail, VPN portals, remote access gateways, administration logins of the website. Each is a place where passwords are tried all day. The outside view gives you the list to check against your MFA policy, one by one.

5. Malware protection

Nothing of this control is visible from the internet. It is checked on the devices.

What Cyber Essentials does not ask

The scheme is a baseline, deliberately short. The requirements document sets no rule for several things an outsider sees first:

• E-mail authentication. SPF, DKIM and DMARC decide whether anyone can send mail in your name. They are outside the five controls. See SPF, DKIM and DMARC explained, and test a domain with the free checker.
• Certificates and HTTPS settings, checked by the certificate and headers checker.
• DNS hardening such as DNSSEC and CAA.
• Look-alike domains registered to imitate yours.
• Backups: version 3.3 stresses their importance, without making them a requirement.

A certificate on the wall and a domain anyone can spoof can coexist. Customers who check suppliers from outside will see the second.

A check to run before the assessment

1. List every host under your domains, and every public address you use, cloud included: cloud services cannot be left out of scope.
2. For each address, note what answers. Every open service needs an owner and a reason; close the rest.
3. Look for administrative interfaces. Move them off the internet, or put MFA in front.
4. Note each product and version shown. Anything unsupported goes, or gets isolated.
5. List every login page, and confirm MFA on each.
6. Do it again after every change, and not only once a year: the certificate lasts twelve months, an open port is found within days.

Perimetry Cloud does this outside view continuously for the domains you add, from public sources and without scanning your systems, and tells you when something changes. It does not certify anything: certification is done by a certification body licensed through IASME.