Cyber Essentials v3.3 (28 April 2026): The MFA Mandate UK SMEs Cannot Defer
IASME shipped Cyber Essentials v3.3 on 27 April 2026. The single biggest change: MFA mandatory across every cloud service in the boundary. Here is the 14-day prep checklist designed for UK SMEs renewing this year.
Bottom line up front. From 28 April 2026, Cyber Essentials v3.3 requires multi-factor authentication enforced for every user on every cloud service inside the certification boundary. Not just administrators. Not just sensitive systems. Every cloud service, every user. If your IASME assessor finds a single cloud-service user without MFA enforced, the certification fails. This article walks UK SMEs through the practical prep — what falls in scope, the 14-day sequence to remediation, the failure modes that surface most often in initial assessments, and how the Cyber Essentials Plus on-site test differs in v3.3.
The Single Sentence That Matters
From 28 April 2026, every cloud service inside the Cyber Essentials boundary must have multi-factor authentication enforced for all users — not just admins, not just sensitive systems. The IASME requirements document version 3.3 is the binding reference; the certifying body and NCSC published the v3.3 transition timeline in advance of the effective date, with assessments booked after 28 April 2026 evaluated against the new criteria.
Why This Change Was Predictable
IASME and NCSC have been signalling the cloud-MFA tightening since the v3.2 transition in 2024. The earlier requirement applied MFA to administrative accounts and to remote-access scenarios, leaving a meaningful gap: cloud-first SMEs were running entire workforces on SharePoint, Microsoft 365, Google Workspace, Slack, file storage SaaS, payroll platforms and customer relationship management tools where standard-user accounts could authenticate with a password alone. Threat actors targeted exactly that gap. The 2024-2025 incident reporting from NCSC and from credential-stuffing trend analyses repeatedly surfaced standard-user cloud-account compromise as the entry point.
v3.3 closes the gap by removing the administrative-only carve-out. Every cloud-service user account, whatever the role, requires a second factor. The transition is significant for SMEs that scaled into cloud-first operations during 2020-2024 without revisiting authentication policy. For organisations already running conditional-access policies enforcing MFA across all users, the v3.3 transition is largely a documentation and evidence-gathering exercise.
The Five Cyber Essentials Controls in v3.3
The five-control structure of Cyber Essentials does not change in v3.3. What changes is the depth of MFA enforcement under the access-control pillar. The controls are:
- Firewalls. Boundary firewalls and personal firewalls configured to default-deny inbound, with documented exceptions for legitimate inbound services. No material change in v3.3.
- Secure configuration. Default passwords removed, unnecessary software and services disabled, only required ports open. No material change in v3.3.
- User access control. The control where v3.3 tightens. Standard user accounts on cloud services now require MFA enforcement, alongside the existing requirements for least-privilege administration, separation of administrator accounts from daily-driver accounts, and joiner/mover/leaver process documentation.
- Malware protection. Anti-malware on endpoints, application allowlisting where applicable, sandboxing for unknown applications. No material change in v3.3.
- Security update management. Critical and high-severity security updates applied within fourteen days. No material change in v3.3.
The v3.3 documentation also clarifies the device scope: bring-your-own-device endpoints used to access in-scope data are in scope for the user-access-control test, even when not centrally managed. SMEs running BYOD policies need to walk through how MFA is enforced for those devices specifically — typically via conditional-access policies that require compliant device + MFA + sign-in risk evaluation in combination.
What Counts as "in the Boundary"
The certification scope is whatever you draw on your network diagram. The temptation in v3.3 is to draw a narrow boundary that excludes some cloud services and avoid the MFA-everywhere lift. The IASME assessor is trained to test the scope statement against operational reality: if your contact-form data lands in HubSpot, HubSpot is in scope. If your finance team approves invoices in a third-party SaaS, that SaaS is in scope. Excluding services from the scope on paper but using them in practice is a self-assessment integrity issue, not a clever scoping move.
The practical scope inventory for a typical 30-200 person UK SME includes:
- Microsoft 365 or Google Workspace (always in scope)
- Slack, Microsoft Teams, or equivalent (always in scope when handling internal data)
- File storage: SharePoint, OneDrive, Google Drive, Dropbox Business, Box (in scope)
- Payroll SaaS (in scope — PAYE data)
- HR information system (in scope — employee personal data)
- Customer relationship management (in scope — customer data)
- Finance and accounting platforms: Xero, QuickBooks, Sage (in scope)
- Project management tools holding work product (typically in scope)
- Code repositories: GitHub, GitLab, Bitbucket (in scope for technology firms)
- Customer support platforms: Zendesk, Intercom, Freshdesk (in scope where used)
The single-sign-on dimension matters here. If users authenticate to most of those services via Microsoft Entra or Google Workspace, MFA enforced at the identity provider covers the downstream applications — provided the conditional-access policy actually requires MFA for the relevant user populations and the downstream applications cannot be reached via a separate authentication path. SaaS platforms that offer direct username/password fallback alongside SSO need that fallback disabled, otherwise the MFA-everywhere requirement is not satisfied.
The 14-Day Prep Sequence
The sequence below is a practical one — designed for an SME with a CE Basic renewal booked, an existing patchwork of MFA coverage, and a fortnight to close the gap.
- Days 1-2: Cloud-service inventory. List every cloud service that processes company data, including the long-tail SaaS adopted by individual departments. Procurement, finance, marketing, and engineering each contribute. The shadow-IT inventory is often longer than the IT-managed inventory.
- Days 3-4: MFA status audit. For each service, check whether MFA is enforced (not just available) for all user roles. Distinguish between optional MFA, conditional MFA, and enforced MFA. Enforced is the only state that satisfies v3.3.
- Days 5-7: Identity-provider conditional-access cleanup. Where SSO is used, validate the conditional-access policy covers every user group. Review break-glass / emergency-access accounts and document their MFA status separately — emergency accounts typically use FIDO2 keys rather than authenticator apps.
- Day 8: Recovery and exception procedures. Document the process for lost MFA device, account recovery, third-party contractor onboarding, and temporary access. Assessors look for the documented procedure, not improvisation under pressure.
- Days 9-10: BYOD and mobile-device scope. Confirm conditional-access policy treats personal devices appropriately. Mobile-only users (often field staff) need their authentication path tested.
- Days 11-12: Network diagram and scope statement update. The assessor reads the scope statement before testing. Make the scope statement match the operational reality discovered during the inventory phase.
- Day 13: IASME self-assessment portal walkthrough. Complete the self-assessment as if it were the live submission. Surfaces wording gaps and uncertain answers before they become assessor questions.
- Day 14: Sign-off and assessor booking. The director or designated executive signs off on the self-assessment. Book the assessment with a calendar buffer in case re-submission is needed.
The Failure Modes That Surface Most Often
Three patterns recur in initial CE v3.3 assessments based on practitioner write-ups since the v3.3 question set entered consultation.
Pattern 1: Conditional access excluding a service-account group. Organisations carve out service accounts from conditional-access policies to avoid breaking automation, then forget those carve-outs include accounts that humans also use. The assessor finds standard user activity from an account excluded from MFA enforcement, and the certification fails on that single instance.
Pattern 2: Legacy authentication enabled on Microsoft 365. POP, IMAP, and basic-authentication protocols can bypass conditional-access MFA enforcement. Microsoft has been disabling these by default in new tenants, but organisations with multi-year tenants often have the legacy protocols still enabled for one or two integrations. v3.3 treats legacy-protocol availability as a control failure regardless of whether the protocols are actively used.
Pattern 3: A SaaS in the boundary with no SSO integration. The SaaS supports MFA in its own native authentication flow, but enforcement is per-user not organisation-wide. The IT director assumes MFA is on; the assessor checks the admin panel and finds three users with MFA disabled. The certification fails until those three are remediated, which usually requires the user to log in, accept the MFA enrolment, and validate the second-factor delivery — adding days to the cycle.
Cyber Essentials Plus vs Basic in v3.3
The Plus variant adds on-site or remote technical testing by the assessor: vulnerability scanning of devices in scope, validation of malware protection on a sample of endpoints, and authenticated testing of access control. The v3.3 changes apply equally to Plus. The technical testing component will now include the assessor attempting to authenticate to in-scope cloud services without a second factor — if that authentication succeeds, the Plus certification fails on the access-control pillar.
For UK SMEs that supply NHS, central government, or the regulated financial sector, Cyber Essentials Plus is typically the procurement requirement, not Basic. Plus assessments have approximately a six-month preparation cycle for organisations starting from a low baseline; if your renewal is more than three months out, the v3.3 transition is manageable. If your renewal is in the next thirty days and your MFA coverage is not yet 100%, consult your assessor about pushing the assessment date rather than failing and re-paying for a re-test.
The IASME Transition Window
Assessments booked before 28 April 2026 are evaluated against v3.2; assessments booked on or after 28 April 2026 are evaluated against v3.3. The certificate validity period (twelve months) is unaffected by the version change. Organisations certified under v3.2 retain their certificate until expiry; the v3.3 criteria apply at the next renewal.
IASME has published transition guidance for assessor bodies and for organisations renewing. The guidance is the authoritative reference; this article is informational and does not substitute for the IASME requirements document version 3.3.
What Cyber Essentials v3.3 Does Not Cover
Cyber Essentials is a baseline scheme. It is intentionally narrow — five controls, focused on the most common attack vectors against SMEs — and is not a substitute for broader information-security frameworks. SMEs that hold Cyber Essentials Plus and have NIS2 supplier-questionnaire obligations under EU customer requirements still need to demonstrate the wider NIS2 Annex I controls (incident management with 24-hour and 72-hour notification windows, supply-chain risk assessment, business-continuity planning, encryption policy, and so on). Cyber Essentials Plus covers approximately the equivalent of NIS2 Annex I measures (a) firewalls, (b) basic access control, (c) malware protection, and (i) authentication policies — a useful subset but not the full ten measures.
Organisations seeking a single certification to satisfy both UK procurement and EU supplier questionnaires typically pair Cyber Essentials Plus with ISO/IEC 27001 or a documented NIS2-alignment evidence pack. The pairing is more cost-effective than treating each compliance regime as separate.
Where SummitBridge Horizon Fits
The Cyber Essentials Readiness Assessment is designed to surface every cloud service in your boundary, flag missing MFA enforcement, and produce a gap matrix mapped to v3.3 criteria — so the IASME assessor sees a remediated environment, not a work-in-progress. The assessment runs over roughly two working weeks with a designated IT contact at your organisation, and produces a written remediation roadmap with effort and cost estimates for each open item.
For organisations preparing for NIS2 supplier-questionnaire flows alongside Cyber Essentials Plus, the combined readiness assessment maps overlapping evidence between the two regimes, so the same documentation serves both purposes where appropriate.
Information disclaimer
This article is for information only and is not legal, regulatory or assessment advice. Cyber Essentials v3.3 requirements are defined in the IASME requirements document version 3.3, effective 28 April 2026. Verify specific obligations applicable to your organisation with your certifying body before acting. The information here reflects publicly available IASME and NCSC publications as of the article date and may be superseded by subsequent IASME guidance.
Need help with this?
Our team can help you assess where you stand and build a practical remediation plan. Free 30-minute consultation — no obligation.
Book a Free Consultation