The Most Common Cyber Essentials Plus Failures, By Control

Net Sec Group is an IASME and NCSC certification body. Over 800 Cyber Essentials and Cyber Essentials Plus assessments later, the failure surface has a shape. The same patterns recur, the same controls trip up the same kinds of firms, and the same fixes work. This article walks the recurring failures control by control, with the technical reason each one fails and the typical fix.

If you are preparing for CE Plus, this is the list to defuse before the assessor logs in. If you have just failed and are scoping the remediation, this is the diagnostic.

How to read this article

The five Cyber Essentials Plus controls are:

  1. Firewalls and Internet Gateways
  2. Secure Configuration
  3. User Access Control
  4. Malware Protection
  5. Security Update Management

For each control, the section below lists the recurring failure patterns we see, what the assessor encounters on the live screen-share, the technical reason the pattern fails the IASME Cyber Essentials Plus test specification, the typical fix, and the typical time-to-fix in working days.

The order is rough frequency: User Access Control and Security Update Management produce the largest share of failures we see. Firewalls and Internet Gateways and Malware Protection produce the deepest fails (a hard fail in those two is harder to remediate on the day than a soft fail in account hygiene).

Firewalls and Internet Gateways

Pattern 1: cloud security group exposes admin services to the public internet

What the assessor sees: an external scan returns SSH on port 22 or RDP on port 3389 reachable from 0.0.0.0/0 on a cloud-hosted in-scope service.

Why it fails: the IASME Cyber Essentials Plus test specification requires inbound boundary controls to deny by default and to gate administrative access behind documented exception rules. Public exposure of admin services fails this irrespective of MFA being on.

Typical fix: lock the security group to a documented allow-list of source IPs (your office, your VPN, your bastion host), or place the service behind a private endpoint with a VPN front-door. Do not rely on changing the port.

Typical time-to-fix: same day for cloud-hosted services if the team has IAM access. 1 to 2 working days if vendor support has to action it.

Pattern 2: home router on a home-worker connection with no software firewall on the laptop

What the assessor sees: an in-scope laptop is on a residential connection, has a public-routable IP from the ISP for hours at a time, and the local software firewall is off because the user disabled it.

Why it fails: the laptop is the boundary. With the software firewall off, there is no default-deny.

Typical fix: enforce the software firewall via group policy or MDM, lock user disable, verify on the live sample.

Typical time-to-fix: same day for an MDM-managed estate. 2 to 3 working days for an estate with no MDM (the MDM rollout becomes the fix).

Pattern 3: boundary firewall admin interface reachable from the public internet

What the assessor sees: the management UI of the on-prem firewall (or the cloud firewall service) responds to a request from the assessor's external scan.

Why it fails: the test specification requires boundary admin interfaces to be unreachable from the public internet. MFA on the admin login does not change this; the surface is still reachable, which is what the test measures.

Typical fix: bind the admin interface to a management VLAN or a private network, route admin access through a VPN or a bastion. Same-day if the firewall vendor supports it.

Secure Configuration

Pattern 4: no documented standard build, no way to sample against it

What the assessor sees: the IT lead says "we have a standard" but cannot produce a current artefact. The assessor cannot sample devices against a standard that does not exist as a writeable thing.

Why it fails: the test specification requires the assessor to verify each sampled device matches the firm's standard. Without a documented standard, the test cannot be run.

Typical fix: produce a build standard document (a wiki page, a Confluence page, an Intune configuration profile export, a Jamf policy export), date it, name it, version-control it. The assessor accepts any format that an external reader could use to recreate the standard.

Typical time-to-fix: 1 to 3 working days. Most of the time is collating what already exists in tooling rather than writing new policy.

Pattern 5: AutoPlay enabled on Windows where removable media is in scope

What the assessor sees: a user inserts a USB stick on a sampled Windows device and AutoPlay launches.

Why it fails: the test specification requires AutoPlay to be off on platforms that ship it.

Typical fix: a group policy or Intune configuration profile disabling AutoPlay across the in-scope estate. Same-day push.

Pattern 6: screen-lock relying on user habit rather than enforced

What the assessor sees: a sampled device's screen-lock is configured at the user level, not enforced via group policy or MDM.

Why it fails: the control is "enforced", not "enabled". User-level configuration can be removed by the user.

Typical fix: enforce inactivity screen-lock at 10 minutes or less via group policy or MDM. Lock user disable. Same-day push.

User Access Control

This control produces the largest share of CE Plus failures we see. The patterns below cluster around four root causes: per-user MFA in Microsoft 365 admin where Conditional Access is the right configuration, leaver accounts left active for handover, shared administrative accounts, and contractor BYOD with no documented scope.

Pattern 7: per-user MFA enabled in Microsoft 365 admin, no Conditional Access policy

What the assessor sees: the Microsoft 365 admin console shows "Multi-factor authentication is enabled" at the per-user level. The assessor asks for the Conditional Access policy. There is none.

Why it fails: per-user MFA in Microsoft 365 only enforces on modern auth. Legacy authentication protocols and basic auth bypass it. The IASME test specification expects MFA that cannot be bypassed.

Typical fix: a Conditional Access policy targeting the administrative role group, requiring MFA, with "Block legacy authentication" enforced in a sibling policy. Same-day to deploy, plus a 24-hour observation window to confirm no legacy-auth sign-ins are now blocked.

For the deeper drill on MFA failure cases, see The CE Plus MFA failure cases on this site.

Pattern 8: leaver still active because their email was kept open for handover

What the assessor sees: the IT lead opens the Microsoft 365 admin console live; the assessor spots a former employee still active. The IT lead explains the email was kept open for handover.

Why it fails: an active account is an active account. The test specification expects the joiner/mover/leaver process to remove access, not preserve it. A handover-mailbox-shared inbox is acceptable; the leaver's user account staying active is not.

Typical fix: convert the leaver's mailbox to a shared mailbox or forward to the handover destination, then disable the leaver's user account. Same-day.

Pattern 9: shared administrative account

What the assessor sees: an account named "admin", "support", "ops", or similar. Multiple humans know the password.

Why it fails: the test specification requires administrative accounts to be individually accountable. Shared credentials defeat the audit trail.

Typical fix: create a per-human admin account for each person who needs admin rights. Move the shared credential into a vault as a break-glass account, document the vault rotation, alert on use. 1 to 2 working days.

Pattern 10: contractor on Bring-Your-Own-Device with admin rights, no documented scope

What the assessor sees: the in-scope tenant has an external contractor as an admin. The contractor uses their own laptop, which is not enrolled in the firm's MDM.

Why it fails: the contractor's device is in scope under BYOD rules unless the firm scopes them out via documented technical controls (Conditional Access app-protection, sign-in risk policy, device compliance enforcement). Without a documented scope statement, the contractor's laptop is in the test scope and likely fails.

Typical fix: either enrol the contractor's laptop under a contractor MDM tier with the firm's standard build applied, or apply Conditional Access app-protection that satisfies the test without enrolling the device, or scope the contractor out (transfer their work onto a managed device). 2 to 5 working days depending on which path.

Malware Protection

Pattern 11: anti-malware agent installed but not reporting to its management console

What the assessor sees: the management console shows "0 / 87 agents reporting" or the assessor's live screen-share on a sampled device shows the agent is on but the cloud console disagrees.

Why it fails: an orphan agent cannot be verified centrally. The test specification expects centralised verification.

Typical fix: re-register the agent, or push a fresh deployment, or roll the agent forward to a current version that reports to the current console. 1 to 2 working days for a small estate, longer for a fragmented one.

Pattern 12: tamper protection off on Microsoft Defender so users can disable it

What the assessor sees: Defender is on, but tamper protection is off. The user has previously disabled Defender to "fix a slow system" and re-enabled it before the assessor arrived.

Why it fails: the test specification expects the anti-malware mechanism to be locked from user disable.

Typical fix: enable tamper protection via Intune or the Microsoft Defender for Endpoint console, push to the estate. Same-day.

Pattern 13: macOS Gatekeeper disabled on a sampled Mac

What the assessor sees: Gatekeeper is off, or the developer-ID and notarisation requirement is off, on a sampled Mac.

Why it fails: Gatekeeper is the launch-time signature and notarisation gate on macOS, which is the malware-protection mechanism the assessor verifies on Mac. Gatekeeper off means the gate is open at launch.

Typical fix: a Jamf or other MDM configuration profile enabling Gatekeeper with the developer-ID and notarisation requirement on, locked from user disable. Same-day push.

Security Update Management

This control produces the second-largest share of CE Plus failures we see. The patterns below cluster around three root causes: a critical patch outside the 14-day window, an end-of-life operating system or application in scope, and a long-running production system with no compensating control documented during the patch window.

For the deeper drill on patching failure cases, see The CE Plus patching failure cases on this site.

Pattern 14: critical patch on a sampled device outside the 14-day window

What the assessor sees: the live patch scan finds a critical CVSS finding on a sampled device, the patch was released 30+ days ago, the device has not picked it up.

Why it fails: the IASME Cyber Essentials Plus test specification requires high and critical patches to be installed within 14 days of release.

Typical fix: install the patch on the failed device, then audit the rest of the estate for the same gap, then chase the patch-management tooling to find why the patch did not deploy on time. 1 to 5 working days depending on whether the gap is one device or systemic.

Pattern 15: end-of-life software in scope (out-of-support Windows, end-of-life Office, end-of-life browser)

What the assessor sees: a Windows 10 device, an Office version that has fallen out of support, a browser version that no longer receives security updates.

Why it fails: end-of-life software does not receive security patches. It cannot satisfy the 14-day rule.

Typical fix: upgrade to a supported version, or scope the device out of CE Plus (which usually means scoping the user out of the in-scope work). 5 to 20 working days depending on the upgrade path and dependent applications.

Pattern 16: long-running production server with no compensating control documented

What the assessor sees: a Linux server in scope cannot reboot for the patch window. The IT lead says "we will get to it next quarter".

Why it fails: the test specification allows compensating controls during the patch window. It does not allow no controls.

Typical fix: document the compensating controls (network segmentation, application-level WAF, monitoring with paged response), time-box the patch window, demonstrate the compensating controls are in effect on the live screen-share. 2 to 5 working days for the documentation; the technical controls usually exist already.

What happens when a CE Plus engagement fails

A failure on the day is not the end of the engagement. The applicant gets the report, fixes the underlying control across the scope (not just the failed device), and the assessor re-tests on a fresh sample. NetSec Plus engagements include unlimited retries with no re-test fee.

The remediation cycle typically runs 1 to 10 working days depending on which patterns failed. User Access Control failures (Patterns 7 to 10 above) usually remediate inside 1 to 3 working days. End-of-life software (Pattern 15) is the slowest to remediate.

For the formal re-attempt rules, see The CE Plus second-attempt rules on this site.

For the procedural reference covering scoping, day, and remediation, see the Cyber Essentials Plus Assessment Guide on netsecgroup.io.

Common questions

What is the single highest-volume failure pattern?

Pattern 7, per-user MFA in Microsoft 365 admin without Conditional Access. The control state is correct in the firm's mind, the configuration does not enforce as the IASME test specification requires.

What failure pattern is most likely to be a hard fail rather than a soft fail?

Pattern 15, end-of-life software in scope. The fix is an upgrade or a scope change; neither is a same-day fix.

What if our scope changes between booking and the day?

Re-scope. The assessor adjusts the sample to match the new scope. Do not arrive on the day with a different in-scope device list than was agreed at booking.

Does NetSec offer a pre-assessment dry run?

Yes. We routinely run a pre-assessment review against the per-control patterns above, so the firm can defuse the recurring fails before the formal engagement starts. For deeper coverage of common failures including CE Basic patterns, see the Cyber Essentials Common Failures Guide on netsecgroup.io.

What if our engagement just failed and we need to remediate?

Read the per-pattern fixes above, then read Failed Cyber Essentials, What Next on netsecgroup.io for the structured recovery path.

Next steps

For the deeper netsecgroup.io references:

When you are ready to book or want a per-control diagnostic against your own estate before booking, contact Net Sec Group or book a Cyber Essentials Plus assessment directly.