External vs Internal Scanning for Cyber Essentials Plus, the Per-Control Mapping

Net Sec Group is an IASME and NCSC certification body. The CE Plus assessment runs two distinct vulnerability scans, each evidencing a different subset of the five Cyber Essentials controls. Engineers approaching CE Plus for the first time tend to expect "the scan" to be a single artefact; the IASME CE Plus test specification runs both an external scan against the public perimeter and an internal authenticated scan against the host fleet, and the assessor reads each tier against a different set of pass/fail criteria.

This article is the per-control mapping drawn from our 800-plus engagement history. The two scan tiers, what each one evidences, the assessor's typical pass and fail evidence per control, and the four scope errors we see audit teams make at this point in the engagement.

For the broader CE Plus reference, see the CE Plus Assessment Guide on netsecgroup.io. For the related vulnerability-scanning content on this site, see the vulnerability-scanning hub.

The two scan tiers, in plain terms

External scan runs against your firm's public-facing IP addresses (the WAN side of the boundary firewall, the load balancers fronting in-scope cloud workloads, the VPN concentrators, the SMTP gateways, and any other internet-reachable component the in-scope estate exposes). The scanner runs unauthenticated; it cannot log into the host. The findings are services and CVEs visible from the internet to anyone who scans you.

Internal authenticated scan runs against your firm's host fleet (in-scope laptops, servers, hypervisors, containers, and IaaS workloads). The scanner authenticates into each host, reads the installed-software inventory, the registry or equivalent, the configuration files. The findings include configuration-level CVEs, missing patches, weak local accounts, and policy-level secure-configuration gaps that an unauthenticated scan cannot see.

The two scans are complementary, not redundant. Both are required at CE Plus; neither is sufficient alone.

The per-control mapping

Five Cyber Essentials controls; two scan tiers. Each row below names the control, the scan tier that evidences it, the assessor's typical pass evidence, and the typical fail evidence we see across engagements.

Boundary Firewalls and Internet Gateways

Scan tier: external perimeter scan.

What the scan evidences: the configuration of the boundary firewall as visible from the internet. Default-deny on inbound traffic. No services exposed beyond what is documented. No vendor-default management interfaces accessible.

Pass evidence: external scan report listing the public services (typically 80, 443, possibly 25 for mail), nothing else. Each exposed service is a documented business function (the website, the API, the mail server). Where a VPN is exposed, the VPN endpoint reports a current vendor build and no known CVEs older than 14 days.

Fail evidence: an open inbound rule the firm cannot account for ("0.0.0.0/0 to port 22" left open from a debugging session), a vendor-default admin interface (e.g. a router admin page reachable from the WAN), or a public service running a build with a known critical CVE published more than 14 days ago. See Firewalls and Gateways on this site for the configuration reference.

Secure Configuration

Scan tier: internal authenticated scan (primary), supplemented by external for exposed services.

What the scan evidences: each in-scope host runs the documented standard build, with default accounts removed, default passwords changed, and unnecessary services disabled. The scanner reads the configuration directly via authenticated access.

Pass evidence: per-host scan output showing the standard-build hash matches the documented build, no default local accounts present, no default services running, password policy meeting the IASME minimum.

Fail evidence: a host with a vendor-default local administrator account still enabled, a host running services not documented in the standard build (e.g. a developer's laptop running a local Postgres instance with default credentials), or a host whose installed-software inventory diverges from the documented standard build without justification. See Secure Configuration on this site for the per-control reference.

User Access Control

Scan tier: internal authenticated scan, supplemented by cloud admin console review.

What the scan evidences: each in-scope host's local-account state, including which accounts have administrative privilege, MFA configuration where applicable on local accounts, and account-naming hygiene. The scan reads the local SAM database on Windows, the directory services on Linux/macOS, and the cloud-platform admin console state via the assessor's review of the export.

Pass evidence: per-host local-admin account list mapped to one named human, no shared local-admin accounts, no service accounts with interactive logon rights, and the cloud-admin MFA report showing every cloud admin account enforced.

Fail evidence: a shared local-admin account on multiple hosts, a service account with administrative permissions on the local host plus interactive logon, or a cloud admin account without MFA enforcement. See User Access Control on this site.

Malware Protection

Scan tier: internal authenticated scan.

What the scan evidences: each in-scope host runs anti-malware with current definitions and reports healthy to the management console. The scanner reads the anti-malware service state directly.

Pass evidence: per-host scan output showing the anti-malware service running, definitions updated within vendor-recommended frequency (typically daily), and the device reporting to the management console.

Fail evidence: an in-scope host with anti-malware disabled, a host with anti-malware running but stale definitions older than the vendor-recommended frequency, or a host installed but not reporting to the management console (an orphan agent, the assessor's term). See Malware Protection on this site.

Security Update Management

Scan tier: internal authenticated scan.

What the scan evidences: each in-scope host has critical and high-severity CVEs at the patch level the IASME 14-day window allows. The scanner enumerates installed software with versions, compares against the NIST NVD database for known CVEs, and reports CVSS scores.

Pass evidence: per-host scan output showing zero critical or high-severity CVEs older than 14 days from vendor patch release date. The scan timestamp is recent (typically within 48 hours of the assessment day).

Fail evidence: an in-scope host with a high-severity CVE older than 14 days. The fail does not depend on whether the CVE is exploitable in the host's specific configuration; the IASME requirement is the patching window. See Patching and Updates on this site and the Cyber Essentials 14-day Patching Guide for the window mechanics.

The four scope errors we see at this point

Across our engagement history, four scope errors recur on the day. Each is preventable; none should reach the assessor.

Error 1, external scan against shared hosting IP

The applicant's public website is hosted on a shared hosting platform; the IP returns scan findings that belong to other tenants on the same IP. The applicant cannot remediate findings that are not theirs to remediate. The fix is to scope the external scan against the applicant's own owned-or-controlled infrastructure (a dedicated load balancer, an Anycast IP, a managed CDN with origin shielding) and to document the shared-hosting boundary in the scope statement.

Error 2, internal scan with insufficient credentials

The internal authenticated scan runs with credentials that do not have read access to all the registry keys, configuration files, or installed-software inventory the scanner needs. The scan completes "successfully" but reports a thin set of findings because the scanner could not read what it needed to. The assessor flags the thin output and asks for re-scan with proper credentials. The fix is to provision a dedicated scan service account with the read-level privileges the scanner documentation specifies, and to validate the credential coverage on a test host before scanning the fleet.

Error 3, missing endpoints from the authenticated inventory

The asset list says 80 hosts; the authenticated scan covers 60. The 20 missing hosts are mobile devices not enrolled in MDM, contractor laptops on the corporate VPN that the asset list captured but the scanner did not, or hosts that were powered off during the scan window. The assessor sees the gap and the SAQ goes back. The fix is to reconcile the authenticated-scan host list against the asset list before submitting; every gap is justified in the scope statement (out-of-scope, MDM-managed-only via separate evidence) or remediated.

Error 4, scan timing outside the patch window

The internal authenticated scan runs on day 1 of the assessment week; patches issued during the assessment week land too late to be reflected in the scan output. By assessment day, the scan output is technically correct but does not reflect the live state. The assessor reviews patch evidence dated after the scan and decides per-CVE whether the patching control passes. The fix is to run the scan within 48 hours of the assessment day, after the assessment-week patch cycle completes.

Reading the scan output as the assessor

The CE Plus assessor reads scan output not for a clean bill of health (no scan output from a real estate is empty), but for the specific failure conditions named per control above. The applicant's evidence pack should include the scan output, the per-finding remediation evidence (patches applied, configurations changed, suppressions documented), and the timeline showing remediation completed within the IASME window.

For the scanner-comparison decision (which scanner produces output the assessor accepts cleanly), see CE Plus Vulnerability Scanners Compared. For the false-positive triage workflow, see False positives in CE Plus vulnerability scans. For cloud-only and mixed-estate scope considerations, see Scanning cloud vs on-premises CE Plus.

Common questions

Does CE Basic require external and internal scans the same way?

No. CE Basic is a self-assessment with no required scan; the SAQ asks the firm to attest to the controls. CE Plus is the technical assessment that adds the two scans plus the email and browser test on top of the SAQ. The two scan tiers in this article apply to CE Plus only.

Can the same scanner run both external and internal scans?

Yes. Tenable Nessus, Qualys VMDR, Rapid7 InsightVM, and Greenbone Community Edition all support both scan modes. The configuration differs (target list, authentication, scan policy template), and the output reports are typically separated for evidence-pack clarity. See CE Plus Vulnerability Scanners Compared for the per-scanner detail.

Does an internal scan replace the email and browser test?

No. The email and browser test is a separate CE Plus test the assessor runs on the day to verify malware-protection enforcement and browser hardening. The internal authenticated scan covers the host-side configuration; the email and browser test exercises the malware controls in the user-facing path. Both are required.

What if our public services are entirely behind a managed CDN?

The external scan still applies; the scope shifts to the CDN's exposed origins where applicable, and to the managed-CDN configuration where the firm controls it. Discuss with the assessor on the scoping call; the answer depends on the architecture.

Where do we book CE Plus?

Book a Cyber Essentials Plus assessment with Net Sec Group. The booking form lets you describe the scope (perimeter shape, host fleet, cloud architecture); the assessor confirms the scan tiers and engagement timeline.

Reference material

Where this fits on this site

This article is the scan-tier-mapping spoke under the vulnerability-scanning hub. The other vulnerability-scanning spokes are CE Plus Vulnerability Scanners Compared, False positives in CE Plus vulnerability scans, and Scanning cloud vs on-premises CE Plus. For the per-control foundation references, see Firewalls and Gateways, Secure Configuration, User Access Control, Malware Protection, and Patching and Updates on this site.