Why Cyber Essentials Fails on the First Try, the Real Frequency-Ranked Causes

Net Sec Group is an IASME and NCSC certification body. Across our 800-plus engagement history, the same eight failure causes account for almost every first-attempt fail we see. This article is the frequency-ranked list, the fix per cause, and a pre-check the applicant can run themselves before booking the engagement. If you have just had a Cyber Essentials failed result and want to understand why Cyber Essentials fails on a first attempt, the same eight causes explain almost every case.

The fastest path to certification is the path that does not include rework. A clean first attempt is faster than any fast-track tier when the applicant arrives ready. This article is the diagnostic that reduces the rework risk to near zero by surfacing the failure shape before the applicant submits the SAQ. For a self-driven readiness pass before reading the rest, run the Cyber Readiness Check and the CE Self-Assessment Tool; together they surface most of the eight causes below in 15 minutes. For the deeper per-control fix detail, the Cyber Essentials Common Failures Guide on netsecgroup.io is the technical reference; this article is the founder-facing summary with the pre-check.

The eight failure causes, ranked by frequency

The ranking below comes from observing Cyber Essentials first-attempt outcomes across the 800-plus assessment history. The single highest-frequency cause sits within User Access Control, specifically MFA gaps on cloud admin. The categories that follow are also User Access Control, Secure Configuration, and Security Update Management heavy; Firewalls and Internet Gateways and Malware Protection produce smaller shares but harder fixes when they happen.

1. MFA missing on a cloud admin account

Control: User Access Control.

What the assessor sees: a Microsoft 365 administrator account, a Google Workspace super admin, an AWS root account, an Azure global admin, or a service account with administrative permissions, with MFA either disabled or configured but not enforced. At CE Basic the IASME requirement is MFA enforced and verifiable on every cloud admin account; per-user MFA at the account level is acceptable evidence at this tier. Conditional Access is the requirement at CE Plus.

The fix: enable MFA on every administrative account, including break-glass and service accounts. Where a service account cannot use interactive MFA, replace it with a managed identity (Azure managed identity, AWS IAM role, Google service account with workload identity federation) and document the substitution.

Before-you-book pre-check: list every administrator role in every cloud service in scope. Confirm MFA is enforced on every one. The list cannot have exceptions.

2. Patches outside the 14-day window

Control: Security Update Management.

What the assessor sees: a patch-management console export showing one or more in-scope devices with a critical or high-severity patch older than 14 days from vendor release date. The applicant believed their patch policy covered the estate; the export reveals that one MDM did not feed into the patch-management console, or that a feature update on Windows is gating a backlog of security patches that depend on it.

The fix: apply the missing patches today, re-export the console report, capture the post-remediation evidence. Where a feature update is gating, apply the feature update first; the security backlog clears with it.

Before-you-book pre-check: pull a patch-management console report covering the last 60 days. Filter for in-scope devices. Identify any device with an outstanding critical or high-severity patch over 14 days old. The result must be empty.

3. Unsupported operating system still in scope

Control: Secure Configuration.

What the assessor sees: an end-of-life Windows release on a server, an end-of-life macOS on a designer's laptop, an Android phone on a vendor-discontinued OEM build with corporate mailbox access, or a NAS running an unsupported Linux distribution. The IASME requirement excludes end-of-life software from in-scope estates.

The fix: upgrade the operating system to a supported version, or remove the asset from the in-scope estate (and document the exclusion in the scope statement). Neither is fast on assessment day; the right time to fix this is week 2 or week 3 of the prep plan, not the day before.

Before-you-book pre-check: list every operating system in your asset inventory. Confirm each is on the vendor's currently supported list. Any "no" pushes the engagement onto the 30-day prep plan at minimum.

4. Incomplete asset list

Control: Secure Configuration (and the foundation for every other control).

What the assessor sees: an asset list that is shorter than the device list in the MDM, the user list in the identity provider, or the cloud subscription list in finance. A device that is in scope by definition (it processes in-scope data) but absent from the asset list cannot be tested, and the SAQ answer that depends on it is unsupported.

The fix: pull the device list from MDM, the user list from the identity provider, and the cloud-services list from finance. Reconcile the three into a single master inventory. Resolve every flagged ownership question before booking.

Before-you-book pre-check: print the asset list, the MDM device list, and the identity-provider user list side by side. Reconcile them. The asset list must be the most complete of the three.

5. No documented leaver process

Control: User Access Control.

What the assessor sees: an applicant who can describe the leaver process verbally but cannot produce written evidence of a recent leaver being processed. The IASME requirement is that the applicant has a leaver process and runs it; the evidence is the worked example.

The fix: write down the leaver process in 5 to 10 lines (notification path, account disable timing, evidence retention, hardware return). Run the process for any leaver in the last 90 days; capture the screenshots showing the disabled account and the audit-log entry.

Before-you-book pre-check: produce one worked-example leaver record showing identity-provider account disabled, MDM record retired, hardware returned, and the timestamp of each. If you cannot, the leaver process is verbal only and will fail this control.

6. Shared administrative accounts

Control: User Access Control.

What the assessor sees: more than one human using the same administrator account on a cloud service, a server, or a hypervisor. The IASME requirement is that administrative actions are attributable to a named person; shared accounts break attribution.

The fix: replace the shared account with named admin accounts, one per human. Where a vendor account is the only path to a function (a vendor support login, for example), document the shared use and put a break-glass procedure around it.

Before-you-book pre-check: list every administrative account on every in-scope service. Confirm each maps to one named human. Any "shared" entry is a fail.

7. No boundary firewall evidence for cloud-only firms

Control: Firewalls and Internet Gateways.

What the assessor sees: a fully cloud-based firm with no on-premises network, claiming the boundary firewall control "does not apply". The IASME requirement is that the boundary control is satisfied by the cloud platform's native firewall, not waived. The evidence is the cloud platform's firewall configuration, not absence.

The fix: capture screenshots of the AWS security groups, Azure network security groups, or Google Cloud firewall rules covering the in-scope workloads. Document the default-deny posture and the rule set. The evidence pack matches what an on-premises firm would provide for an appliance.

Before-you-book pre-check: if your firm is cloud-only, can you produce screenshots of every cloud-platform security group covering in-scope workloads? If no, this fails.

8. Default-allow application configuration

Control: Secure Configuration.

What the assessor sees: a standard build that allows users to install any application from any source, with no application-control policy and no allow-list. The IASME requirement at CE Basic is that the applicant prevents users running unauthorised software; the evidence is the configured policy, not the verbal statement.

The fix: configure an application-control policy in MDM (Intune AppLocker, Jamf restricted software, Google Workspace Chrome management). Document the policy and the categories of unauthorised software it blocks. Capture the screenshot showing the policy in force.

Before-you-book pre-check: produce the screenshot of your MDM application-control policy. If you have no MDM at all, this control will need work before booking; an MDM purchase is one of the week 2 decisions in the 30-day prep plan.

What ties the eight failure causes together

Six of the eight failures are evidence-format failures, not control absence. The applicant runs the control; they cannot prove it on the day. The single best preparation time investment is evidence capture, not new control implementation. An applicant who arrives with screenshots, configuration exports, written processes, and worked examples for every SAQ question rarely fails. The applicant who arrives with the controls in place but only verbal descriptions of them, fails for evidence-shape reasons.

The other two failures (unsupported OS, MFA gaps on cloud admin) are control absence and require remediation work, not just evidence capture. Both are surfaced by the pre-checks above; both fail loudly on day 1 of any prep plan.

The 8-item before-you-book pre-check, summary

  1. Every administrator role in every cloud service has MFA enforced
  2. Patch-management console export shows zero in-scope devices outside the 14-day window for critical and high-severity patches
  3. Every operating system in the asset inventory is on its vendor's currently supported list
  4. The asset list reconciles against MDM device list and identity-provider user list with no gaps
  5. One worked-example leaver record is on file from the last 90 days
  6. Every administrative account maps to one named human
  7. Cloud-only firms have screenshots of every cloud-platform security group covering in-scope workloads
  8. MDM application-control policy is configured and the screenshot is on file

If all eight return yes, book the 12-hour fast-track engagement. If three or four return no, book the 7-day prep plan and use the week to close the gaps. If five or more return no, book the 30-day prep plan.

What happens after a first-attempt fail

A 30-day reassessment window opens. NetSec Plus engagements include unlimited re-tests inside the window with no re-test fee. The intake evidence carries forward; only the failed control's evidence needs refreshing. For the formal rules see the netsec Failed Cyber Essentials, What Next guide and the Cyber Essentials Marking Scheme Explained reference.

Common questions

Is the frequency ranking based on actual data, or generic?

The ranking comes from observing Cyber Essentials first-attempt outcomes across the 800-plus assessment history at Net Sec Group. The categories at the top of the list match what we see most often; the categories at the bottom match the rarer but harder-to-fix failures. The ranking would be similar at any IASME-accredited certification body, because it reflects how the IASME requirements interact with how UK SMEs run cloud services.

My self-assessment looks clean, but I have not booked yet. What should I do?

Run the 8-item pre-check above. If anything returns no, the SAQ is not yet ready and the booking should wait. The pre-check is the most useful 30 minutes of work the applicant can do before any engagement.

What does the assessor do if I fail on the day?

The assessor flags the failure, captures the evidence of why it failed, and walks you through the remediation path. The 30-day reassessment window opens; you fix what failed, refresh the evidence, and resubmit. NetSec Plus engagements include the reassessment at no additional fee.

What if more than one control fails?

The remediation work is per-control, but the engagement clock is one window. Two or three control failures all remediate inside the 30-day reassessment window if the structural fixes are achievable in that time. Five or more control failures usually means the applicant should have booked a longer prep plan in the first place.

Where do we book?

Book a Cyber Essentials assessment with Net Sec Group when the 8-item pre-check returns yes on every line. The booking form lets you nominate the SAQ-ready date, and the assessor schedules the engagement to start that day.

Reference material

For the deeper Net Sec Group references on failures and remediation:

Where this fits on this site

This article is the diagnostic companion to the three speed-pillar paths. The faster paths are the 12-hour fast-track engagement, the 7-day prep plan, and the 30-day prep plan. All three end at the same IASME certificate. The timelines hub indexes the four pieces, with the pre-check above as the deciding factor for which path to pick.