Cyber Essentials v3.3: Every Change That Matters for UK Small Businesses in 2026
Let's get one thing straight before we start.
Cyber Essentials v3.3 is not a crisis. It's not a root-and-branch redesign of the scheme. The five controls are the same five controls they've always been. Most businesses that have been genuinely implementing CE, rather than gaming the edges of the question set, will find the path to v3.3 compliance is a series of targeted adjustments, not a rebuild.
But the adjustments matter. Because what v3.3 actually does is close the ambiguities that allowed businesses to certify against a version of their IT estate that bore a passing resemblance to the real one. Cloud services excluded because "that's the provider's problem". MFA switched on for IT and finance but nobody else. Scopes drawn to exclude anything awkward.
That era is over. This is what replaces it.
The Framework First: Willow, Danzell, and Why They're Not the Same Thing
Before getting into controls, you need to understand how the scheme is structured, because conflating the Requirements document with the question sets is where most preparation goes wrong.
The Requirements document is the actual standard. It defines what you must be doing across all five controls. There are currently two versions relevant to this transition: v3.2, which applies now, and v3.3, which applies from 26th April 2026.
The question sets are the self-assessment forms. Willow is the current question set, aligned to v3.2 Requirements. Danzell is the incoming set, aligned to v3.3. They cover the same five themes but the wording shifts to reflect the tighter v3.3 expectations.
The rule is straightforward: if you're purchasing certification before 26th April 2026, you use Willow and v3.2. If you're purchasing on or after that date, you use Danzell and v3.3.
IASME, who administer the scheme on behalf of NCSC, allow you to download the relevant question set in advance and complete a dry run in a spreadsheet before you pay for the portal. This is the right way to prepare. Complete that rehearsal, resolve any gaps, then pay for the portal and treat it as data entry rather than discovery.
One hard point on renewals: you do not get to recycle last year's answers. Assessors expect you to meet whatever Requirements are current at the time of purchase. If your renewal falls after 26th April, you are being assessed against v3.3 and the Danzell question set, regardless of what version you originally certified under.
Scope: The Part That Catches Everyone Out
Scope is the foundation of everything. Get it wrong and every other answer you give in the self-assessment is built on sand.
In CE, scope means the devices, software, and cloud services that form the boundary of your assessment. The Requirements are clear: organisations that certify their whole IT estate get the best protection and the most credibility with customers. A scope that excludes large chunks of your business because they're awkward to address is not a legitimate scope. It's a liability.
What Must Be In Scope
Devices include servers, desktops, laptops, thin clients, tablets, smartphones, and network equipment, whether physical or virtual. If a device can accept incoming connections from internet-connected devices, make outbound connections to the internet, or control traffic to or from the internet, and it is part of your business, it is in scope.
Software covers operating systems, off-the-shelf applications, browser extensions, interpreters, scripts, libraries, network software, and firewall and router firmware. If it runs on an in-scope device and could carry vulnerabilities, you are responsible for keeping it in shape.
Cloud services are explicitly defined in v3.3 and explicitly non-excludable. A cloud service is on-demand, scalable, hosted on shared infrastructure, accessible via the internet, and accessed through an account. It stores or processes your organisational data. Microsoft 365, Google Workspace, Dropbox, your CRM, your IaaS provider. All of it. The v3.3 wording is direct: cloud services cannot be excluded from scope.
Home Workers and BYOD
The default position on home and remote workers is that all corporate or BYOD devices they use for business purposes are in scope. If you issue a router to a home worker, that router is in scope. If they're using their own ISP router, that specific router sits outside the formal scope, but you must rely on software firewall controls on the endpoint device itself.
BYOD is where it gets complicated. Any user-owned device that accesses organisational data or services, including email, files, or SaaS applications, is in scope. The only exemptions are devices used exclusively for native voice calls, native text messages, or MFA authentication apps. If someone's personal phone receives MFA codes only, it's out. If that same phone also accesses work email, it's in.
There is one hard line that cannot be negotiated: you cannot define a scope that contains no end-user devices. Certifying "the servers" while the laptops and mobiles are magically excluded is not a compliant scope. Assessors know this and will challenge it.
Sub-Set Scoping
You can legitimately certify a sub-set of your organisation rather than the whole estate, but only if that sub-set is genuinely segregated by a firewall or VLAN and managed separately from the rest of your infrastructure. If you're carving out a sub-set because it's the only tidy part of your IT estate, expect scrutiny. The sub-set must have a documented business reason, a defined network boundary, and a physical or logical location. If you cannot explain the segregation clearly, you cannot defend the scope.
The Five Controls: What v3.3 Changes and What It Doesn't
1. Firewalls
The headline requirements haven't changed. Every in-scope device must be protected by a correctly configured firewall or a network device with firewall functions. What v3.3 sharpens is the expectation around administration and documentation.
Default admin credentials must be changed to something strong and unique, or remote administration must be disabled entirely. If you expose an admin interface to the internet, you need a documented business reason for doing so, and it must be protected by either MFA or an IP allow-list tied to a properly managed password. That documented business reason is not optional and it will be asked for.
All inbound connections are blocked by default. Every rule you open must be documented with a business justification, signed off by someone with authority to approve it, and removed when it is no longer needed. Rule sprawl, where firewall rules accumulate over years without review, is a common failure in self-assessments.
For remote workers on networks outside your control, software firewalls on the endpoint are mandatory. Most modern operating systems include them. They must be switched on.
2. Secure Configuration
Strip out default mode. That is the essence of secure configuration.
Remove or disable unused user accounts, particularly guest accounts and orphaned admin accounts from staff who have left. Change default and guessable passwords. Remove software and services you don't actively use. Disable auto-run features that execute code without deliberate user action. Require authentication before anyone accesses organisational data or services.
Device unlock has its own rules under v3.3. If someone is physically using a device, a PIN, password, or biometric must be required to unlock it. Brute-force protection applies: throttle login attempts, or lock the device after no more than ten failed attempts within five minutes, or apply the vendor's default lockout settings if the device doesn't allow custom configuration. Minimum six characters for a PIN or password used only for device unlock. If that same credential is also used for authentication to services, the full password rules from User Access Control apply.
3. Security Update Management
The 14-day rule is the one that generates the most questions, and the answer is less flexible than people hope.
All in-scope software must be licensed and supported. When software reaches end of support, it must be removed from the in-scope environment or isolated in a sub-set that genuinely blocks all internet traffic. Not "we're planning to retire it". Not "we're waiting for budget". Removed or properly isolated.
Automatic updates must be enabled where the software supports them.
For vulnerability fixes, the 14-day window applies to anything fixing a vulnerability rated critical or high by the vendor, anything with a CVSS v3 score of 7.0 or above, and anything where the vendor has not specified a severity rating. When in doubt, assume the clock is running.
The important v3.3 clarification: a vulnerability fix is not limited to a software patch. If a vendor prescribes a registry change, a configuration modification, or a script execution to mitigate a known vulnerability, that is a vulnerability fix and the 14-day window applies to it. The word "patch" in common usage understates the scope of what this requirement covers.
4. User Access Control
Three interlocking requirements: account management, authentication, and privilege control.
Account management means a documented process for creating user accounts with appropriate authorisation, authenticating with unique credentials, and removing or disabling accounts when people leave or go inactive. Leavers who still have active accounts are a common and straightforward audit failure.
Authentication requirements have been updated in v3.3 to reflect how authentication has evolved. The scheme now explicitly names FIDO2 and passkeys as a recognised authentication method, classifying them as both passwordless and multi-factor because they combine cryptographic keys with user verification. Biometrics, one-time codes via email, SMS, or authenticator app, and push notification approvals all sit under the passwordless or MFA umbrella.
On SMS: the guidance notes it is not the most secure option but acknowledges it is a significant improvement on no MFA. If SMS codes are what you have today, they count. If you have the option to move admins and high-value accounts to app-based prompts or hardware keys, you should do so.
The critical rule for cloud services: authentication to cloud services must always use MFA. This is not a recommendation. The v3.3 wording is clear on this point. If you've been running MFA for your IT administrator and assuming that covers the requirement, it does not.
For passwords where they remain in use, the scheme requires brute-force protection through MFA, throttling, or lockout; and either MFA in place, or a minimum of 12 characters, or a minimum of 8 characters combined with an automatic block-list of commonly used passwords.
No mandatory password expiry. No arbitrary complexity rules. Stop enforcing monthly password changes. It does not improve security and the guidance explicitly moves away from this practice.
Privilege control: separate admin accounts for admin tasks. No email, no web browsing, no general use on admin credentials. Special privileges must be removed when no longer required. Admin accounts exist for administration, not convenience.
5. Malware Protection
Every in-scope device needs a malware protection mechanism. The scheme recognises two valid approaches.
The first is anti-malware software that automatically updates its signatures, actively blocks malware from running, prevents execution of malicious code in documents and scripts, and blocks connections to known malicious websites. On Windows and macOS, this usually means the built-in platform security tools plus possibly an additional EDR layer for higher-risk environments.
The second is application allow-listing: only approved, code-signed applications are permitted to execute, and users cannot install or run unsigned or poorly-signed software. This is the stricter option and more resource-intensive to maintain, but it is a valid and often preferable approach for controlled environments.
Whichever approach you use, it must actually be functioning. Enabled, updated, and actively blocking. An anti-malware icon in the system tray that hasn't updated its signatures in three months does not meet the requirement.
The Updated Definitions That Change How You Think About Authentication
v3.3 updates the glossary in ways that matter for how you describe and document your authentication approach.
Cloud services now have a formal definition: on-demand, scalable, hosted on shared infrastructure, accessed via the internet using an account, storing or processing organisational data. This definition makes it clear that the controller's convenience does not affect whether a service is in scope. If your data lives there, you have responsibilities there.
Passwordless authentication is explicitly defined and FIDO2 authenticators are named. The category includes FIDO2 security keys and passkeys, biometrics including fingerprints and facial recognition, one-time codes via any channel, and push notification approvals. If your Microsoft 365 or Google Workspace environment is already using any of these, you can now point directly to the scheme's language and describe your setup in terms it recognises.
The practical implication for most SMBs: if you're running Microsoft 365 or Google Workspace and have turned on the authentication features those platforms offer, you are probably already meeting the spirit of v3.3's authentication requirements. Your job is to document it clearly so you can demonstrate it.
What You Must Do Before 26th April 2026
If your renewal falls before 26th April: you're working to v3.2 Requirements and the Willow question set. The risk is complacency. Treat this cycle as the opportunity to close the gaps that v3.3 will formalise, so your next renewal is straightforward.
If your renewal falls on or after 26th April: you need to prepare against v3.3 Requirements and the Danzell question set. Download both from the IASME website now. Run the dry-run self-assessment in a spreadsheet. Resolve every gap before you pay for the portal.
Regardless of timing, do these things:
Bring your cloud services into scope properly. No exceptions for Microsoft 365, Google Workspace, your CRM, or any other service where organisational data lives or is processed.
Extend MFA beyond your admin accounts. Everyone accessing cloud services needs it. Run the rollout now, before you're under assessment pressure.
Update your scope document to reflect your actual IT estate. Home workers, BYOD devices, cloud services. If it touches your business data, it belongs in scope.
Document your firewall rules with business justifications and owners. Anything without a current business reason should be removed.
Clean up user accounts. Run an audit of all active accounts, check every one against your current staff list, and disable anything that shouldn't be there.
Verify your patching process covers configuration changes and registry modifications prescribed by vendors, not just software updates. The 14-day clock runs on all of them.
How to Turn This Into a Competitive Advantage
CE v3.3 compliance, done properly and documented clearly, is a sales tool.
Customer conversations: when a larger customer asks about your security posture, a current, accurately scoped Cyber Essentials certificate is a credible answer. It demonstrates you're not just claiming security, you've been assessed against a government-recognised standard and passed. That is meaningfully different from a self-declaration.
Contract qualification: public sector contracts require Cyber Essentials as a minimum. A certificate that lapses, or a scope so narrow it wouldn't survive scrutiny, puts those contracts at risk. A current, accurately maintained certificate keeps the door open.
Insurance positioning: underwriters are increasingly granular about security controls. MFA on cloud services, documented patch management, user access reviews. These are v3.3 requirements and also the controls insurers are asking about. Aligning the two is not a coincidence.
How to Sell This to Your Board
The financial exposure is concrete. An ICO investigation following a breach where the business was claiming CE certification it couldn't substantiate is expensive. The certification itself costs a few hundred pounds. The gap between those two numbers is the business case.
The contract risk is immediate. If your organisation relies on public sector work or supply chain relationships with larger businesses, an inaccurate or lapsed certification creates a contractual vulnerability that can surface without warning.
The reputational risk is asymmetric. Being able to say "we are currently Cyber Essentials certified" builds confidence incrementally. Being exposed as having claimed certification against a scope that didn't reflect your actual estate destroys trust quickly and thoroughly.
The ask is proportionate. Getting to v3.3 compliance is not a major infrastructure project. It's a focused review of scope, cloud service access, authentication settings, and account management. For most businesses already holding CE, it's measured in days of effort, not months.
