Your Cyber Essentials Grace Period Ends Six Months After You Opened the Account. For Some of You That Was July.

01 Your date, not one national date

Four published notices set the calendar between them. None of them prints the date that governs you. You work it out.

IASME announced the changes on 12 February 2026, said the Danzell question set would be published the following day, and said the changes apply to all assessment accounts created after 26 April 2026 [ IASME Feb 2026 ] . The NCSC lists Cyber Essentials Requirements for IT Infrastructure v3.3 as effective from 27 April 2026 [ NCSC resources ] . The earlier IASME notice, from 3 November 2025, put it in the reader's terms: any active assessment account set up before 27 April continues to use the previous version of the assessment questions [ IASME Nov 2025 ] .

Then comes the sentence people are reading as a cliff. Organisations with an active account created before 26 April 2026 have six months to attain certification using the previous version of the requirements [ IASME Feb 2026 ] . Six months from when? From the account, not from the cutover. IASME published the same rule for every applicant in 2023: you get six months from the date of application for the verified self-assessment to pass and certify [ IASME 2023 ] . The November 2025 notice repeats it in one line. Once an assessment account is created, the applicant has six months to complete the assessment [ IASME Nov 2025 ] .

So work out your own date. Open the account, read the date it was created, add six months. An account opened on 10 January 2026 expired on 10 July. An account opened on 26 April 2026, the last day that was possible, reaches its six months around 26 October 2026. That final figure is derived, not published. Your own account date is the only one that governs you.

02 Three answers that fail you outright

Under Danzell, three things end the assessment on the spot. IASME states them plainly in its own announcement [ IASME Feb 2026 ] .

• MFA on cloud services. IASME: multi-factor authentication is a mandatory requirement for all cloud services where it is available, and organisations that fail to implement MFA for cloud services, whether it is free, included, or a paid option, will now automatically fail the assessment. Cost is not a defence.
• A6.4. As IASME published the question: are all high-risk or critical security updates and vulnerability fixes for operating systems and router and firewall firmware installed within 14 days of release?
• A6.5. The same question for applications, including any associated files and extensions.

IASME's wording on the last two is unambiguous. Non-compliance with either of these questions results in an automatic failure of the assessment, regardless of performance in other areas [ IASME Feb 2026 ] .

The requirements document backs the MFA line in two parts, one line apart. Version 3.3 asks you to implement MFA where available, and then says authentication to cloud services must always use MFA [ CE Requirements v3.3 ] . Two different standards sit in one line. Elsewhere MFA is conditional on availability. On cloud it is absolute.

Two details of the control itself catch people. The password element of the MFA approach needs at least 8 characters with no maximum length restriction. And the second factor has to be one of four named types: a managed or enterprise device, an app on a trusted device, a physically separate token, or a known or trusted account [ CE Requirements v3.3 ] .

03 The 14-day clock and its third trigger

Everyone quotes the 14 days. Fewer read what starts the clock. Version 3.3 lists three triggers, and software on an in-scope device must be updated, including vulnerability fixes, within 14 days of release where [ CE Requirements v3.3 ] :

1. the update fixes vulnerabilities the vendor describes as critical or high risk;
2. the update addresses vulnerabilities with a CVSS v3 base score of 7 or above;
3. the vendor provides no details of the level of vulnerabilities that the update fixes.

Read the third one again. Silence from a vendor starts the clock rather than stopping it. A patch that arrives with release notes saying "bug fixes and improvements" and nothing else is inside the 14 days by default. That third criterion appears in the requirements and, word for word in substance, in the Plus test specification [ CE Plus Test Spec v3.2 ] , so it is what an assessor will apply to your estate.

The scope of the rule is wider than the server room. It covers servers, desktop computers, laptops, tablets, mobile phones, firewalls, routers, IaaS, PaaS and SaaS [ CE Requirements v3.3 ] . The scheme also warns about bundled releases: where a vendor ships multiple issues of differing severity as a single update, and that update covers any critical or high-risk issue, the whole update must be installed within 14 days.

One relief, and one trap. The mandatory subset is only the three triggers above; v3.3 strongly recommends applying all released updates within 14 days and says plainly that this is not mandatory [ CE Requirements v3.3 ] . The trap is legacy kit. The Plus specification states that virtual patching is not an acceptable mitigation to the security vulnerabilities of legacy unsupported operating systems long term, and will not be recognised as a mechanism for compliance [ CE Plus Test Spec v3.2 ] . Unsupported software has to be removed from the device, or removed from scope through a defined sub-set that prevents all traffic to or from the internet [ CE Requirements v3.3 ] .

04 Cloud cannot be scoped out

The old way through an awkward assessment was to draw the boundary around the easy part of the estate. Version 3.3 closes that. One of the six changes listed in the document's own "what's new" section is a definitive statement that cloud services cannot be excluded from scope [ CE Requirements v3.3 ] . The scope section repeats it: if your organisation's data or services are hosted on cloud services, those services must be in scope.

Version 3.3 also defines what counts, and the definition is broad. A cloud service is an on-demand, scalable service, hosted on shared infrastructure and accessible via the internet, accessed through an account, storing or processing data for your organisation. The account can be credentials your organisation issued, or an email address used for business purposes. The scheme's list of organisational services names the usual suspects: web applications, Microsoft 365, Google Workspace, mobile device management containers, Citrix Desktop, virtual desktop solutions, IP telephony [ CE Requirements v3.3 ] .

Three more scope lines decide most borderline cases. A scope that does not include end-user devices is not acceptable. Where you have excluded part of the infrastructure, you justify that partial scope to your assessor. And the default position on home working is that all corporate and BYOD home or remote devices used for your business are in scope, along with any router you gave the home worker [ CE Requirements v3.3 ] .

Then there is the assumption that Microsoft or Google handles this for you. The shared responsibility table in v3.3 assigns User Access Control to your organisation across IaaS, PaaS and SaaS alike. No provider carries it at any service model. The applicant is always responsible for ensuring all controls are implemented, and where a provider implements one on your behalf you must show it has committed to doing so through contractual clauses or documents referenced by contract, such as a security or privacy statement [ CE Requirements v3.3 ] . A vendor marketing page is not that document.

05 What the assessor verifies, and what it leaves open

Cyber Essentials Plus adds a hands-on audit on top of the self-assessment. The published method is worth reading, because it tells you exactly how far the verification goes. The NCSC still lists the Cyber Essentials Plus Test Specification v3.2, effective 28 April 2025, as the current version [ NCSC resources ] . So the document governing how MFA gets verified predates the requirements version that made cloud MFA absolute.

The audit runs five test cases: a remote vulnerability assessment, an authenticated scan for patching, a malware protection check, an MFA configuration check, and an account separation check. Any single fail is a fail for the assessment as a whole unless the specification states an exception [ CE Plus Test Spec v3.2 ] . On the patch test the criteria match v3.3 exactly, and a vulnerability whose fix has been available for more than 14 days records a fail.

Read the sampling rules and the shape of the check becomes clear. The specification tells the assessor that on all but the smallest networks it is impractical to test every device in scope, so the assessor tests a representative sample, and standardised configurations mean a small number of samples can cover much of the equipment. For cloud, the specification requires at least one normal user and one administrative user for every cloud service, and the same users can be used across multiple cloud services [ CE Plus Test Spec v3.2 ] .

Test case 4, the MFA check, is performed on all cloud services, and the method is three steps. The assessor observes users accessing cloud services with their organisation-issued accounts on an untrusted device or from an incognito browser session. If that is not possible, the assessor shares an incognito session from their own device and watches the user sign in. The test repeats for each authentication service in use. A prompt for a form of MFA before access is granted scores a pass; anything else records a fail. And where multiple cloud services share an authentication service, the test only needs to run once for that authentication service [ CE Plus Test Spec v3.2 ] .

Now look at what that method reaches. It observes one sampled standard account and one sampled administrative account, on one authentication path, being prompted. It is a sound check of whether MFA is configured and working. It is not a review of every policy that decides who gets prompted. If your identity platform holds a conditional access policy with a named exclusion group, and nobody in the sample sits in that group, the published method does not reach it. The certificate is still correctly issued. The group is still excluded.

So go and read your exclusion lists. Open each conditional access or MFA enforcement policy, list every excluded user, group and service principal, and put a name and a reason against each one. Break-glass accounts belong there and should be monitored. The service account somebody exempted for a 2023 migration does not. Do the same for legacy authentication protocols left enabled, and for guest and external identities, which sit outside most sampling by definition.

The boundary here is the scheme's own design, and it is not a criticism of it. Cyber Essentials sets a floor of simple technical controls that protect against common types of attack [ CE Requirements v3.3 ] , and the certificate opens procurement doors that stay shut without it. Our page on what Cyber Essentials covers and what it does not test walks through the controls and the attacks the five were never designed to stop.

Two jobs, then. Find your account date and work back from it, because that is the deadline that applies to you. Then close the gap between the answer you gave and the estate you run: the exclusion lists, the firmware dates, the vendors who ship patches with no severity note, the cloud tenant somebody hoped was out of scope.

We do not issue Cyber Essentials certificates. We are the team that attacks what the certificate does not verify. CREST-certified operators take your external surface, your identity tenant and your cloud services from the position a real intruder starts in, prove which paths open, and hand you each one with a plain fix and a named owner in the portal. Every finding gets a re-test for twelve months, so the answer holds at your next renewal. Book the free audit and find out which door opens first.