Cyber Essentials for MSPs

Cyber Essentials has always been a straightforward scheme to describe and a difficult one to deliver at scale. For a managed service provider, the difficulty is rarely technical. It is operational.

Cyber Essentials for MSPs

Cyber Essentials has always been a straightforward scheme to describe and a difficult one to deliver at scale. For a managed service provider, the difficulty is rarely technical. It is operational. You are running the same five controls across twenty, fifty or two hundred client environments, each with its own tenancy, its own legacy exception and its own director who signs the declaration without reading it.

The April 2026 update made that operational problem harder. The Danzell question set replaced Willow, and with it came version 3.3 of the Requirements for IT Infrastructure. The five controls did not change. The marking did. For the first time in the history of the scheme there are questions where a single wrong answer fails the entire assessment regardless of how strong everything else is.

This guide is written for the people delivering the certification, not the businesses receiving it. It covers scoping, the five controls, the auto-fail conditions, evidence, submission and renewal, in the order you actually encounter them. It is the anchor for everything else we publish on the subject.

What actually changed in April 2026

The Danzell question set was published on 13 February 2026 and took effect for assessment accounts created from 27 April 2026, alongside Requirements for IT Infrastructure v3.3.

If a client had an active assessment account created before that date, they were given six months to complete certification under the old Willow question set and v3.2. That window closes at the end of October 2026. Every MSP with a client sitting on a pre-April account needs to know exactly where that account is right now, because after the deadline there is no route back to the old requirements.

The substantive changes fall into four buckets:

  1. Stricter marking. Three questions became automatic failures.
  2. Tighter scoping. Cloud services received a formal definition and cannot be excluded. Exclusions now require justification and evidence of segregation.
  3. Greater transparency. Scope descriptions are no longer length limited, out of scope areas must be described, and every legal entity in scope must be named.
  4. A tougher Cyber Essentials Plus process. Sampling on retest now includes a fresh random sample, and a second failure revokes the underlying self-assessment certificate.

Each of these lands squarely on the service provider rather than the client. Scoping is your job. Patch evidence comes out of your RMM. The declaration is signed by the client, but you are the one who told them it was safe to sign.

Scoping: the decision that determines everything else

Most Cyber Essentials failures are not caused by weak security. They are caused by a scope that was drawn badly at the start and defended poorly at the end. Get this right and the rest of the assessment is administration. Get it wrong and you will spend three weeks answering assessor clarifications.

Whole organisation or defined subset

The default and cleanest position is whole organisation. It is easier to evidence, easier to renew and it is what most procurement teams expect when they ask a supplier for the certificate. A subset scope is legitimate, but under v3.3 it carries a heavier burden of proof. You must describe what has been excluded and explain how the excluded network is segregated from everything in scope. Segregation means a demonstrable boundary, not a different VLAN name.

Practical rule for MSP delivery: if you cannot describe the segregation in two sentences that would survive an assessor reading them cold, scope the whole organisation instead.

Legal entities

Danzell requires organisations to identify every legal entity included in the scope, with name, address and company number. This matters enormously for the client base most MSPs actually serve, where a single trading operation sits under a holding company with three dormant subsidiaries and a property vehicle.

Ask for the group structure at kick off. Not later. The certificate now displays the entities covered, and clients bidding for public sector work will be asked why the entity on the tender is not the entity on the certificate. Individual certificates can be requested for each legal entity within a wider scope, for a small additional fee, and it will be clear on the certificate that it forms part of a larger scope.

Cloud services

This is the single biggest scoping change. Version 3.3 defines a cloud service as an on demand, scalable service, hosted on shared infrastructure and accessible via the internet, accessed through an account and storing or processing data for the organisation. If the client's data or services are hosted on a cloud service, that service is in scope. It cannot be excluded.

That definition is broader than most clients assume, and broader than most MSPs have historically scoped. It captures the obvious platforms, and it also captures the marketing automation tool the sales director signed up for on a company card, the design tool with three seats, and the file transfer service used once a quarter by finance.

Build a cloud service register per client and treat it as a living asset. You cannot certify what you have not enumerated, and as covered below, a cloud service without MFA is now a hard failure.

Devices, home working and BYOD

End user devices that access organisational data or services are in scope, including personally owned devices used for work beyond a very narrow exemption for accessing web based email or applications. Servers, desktops, laptops, tablets, thin clients and mobile phones all count. Firmware on routers and firewalls is in scope where those devices are owned or managed by the organisation.

Home routers supplied by an internet service provider to a remote worker are not in scope. The boundary for a home worker is the software firewall on the device itself. Note that this is genuinely out of scope, so do not include home router details in the submission. A short scope statement covering the position is usually enough.

Application development

The section previously titled web applications is now called application development and references the UK Government Software Security Code of Practice. Publicly available commercial web applications are in scope by default. Bespoke and custom components are out of scope. If your client is a software business, expect this to require a conversation rather than a checkbox.

The five controls, from a delivery perspective

The controls are unchanged. What follows is how they behave when you are delivering them across a managed estate rather than reading them in a requirements document.

1. Firewalls

Every device in scope must sit behind a correctly configured firewall, either at the boundary or on the device itself. Default administrative passwords must be changed. No unauthenticated access to the administrative interface from the internet. Any inbound rule must be documented, justified by a business need and removed when that need ends.

The recurring finding here is the forgotten rule. An RDP port opened for a supplier in 2021 that nobody closed. Run an external port scan across your client base before you scope anything, not after the client has paid for the assessment.

2. Secure configuration

Remove or disable software and accounts that are not needed. Change default passwords. Disable auto run for removable media. Lock devices with a password, PIN or biometric, and ensure the device is protected against brute force attempts against that lock.

For an MSP, this control is a build standard question. If your gold image and Intune baseline are right, secure configuration answers itself for every new client device. If they are not, you are remediating device by device forever.

3. User access control

Accounts must be created through an approved process, tied to a named individual, and removed promptly when someone leaves. Administrative privileges must be granted only where justified, reviewed regularly, and separated from day to day accounts. Administrative accounts must not be used for browsing the web or reading email.

Password policy remains as before, offering the choice between multi factor authentication with a minimum eight character password, a minimum twelve character password, or a minimum eight character password backed by an automatic deny list of common passwords. Version 3.3 places significantly more emphasis on passwordless authentication, and passkeys are called out specifically as a stronger alternative. Expect that emphasis to become a requirement in a future release, and start moving clients now.

Leaver process is where MSPs fail this control. An offboarding automation that runs consistently and logs its actions is worth more at assessment time than any amount of policy documentation.

4. Malware protection

Devices must be protected by one of the approved approaches. Anti malware software that is kept up to date, or application allow listing where only approved applications can execute. Whichever route the client takes, the approach must be applied consistently across the in scope estate.

Defender for Endpoint managed through Intune covers this comfortably for most Microsoft estates. The problem is never the primary fleet. It is the three machines that never enrolled and are therefore invisible in your compliance report.

5. Security update management

All software in scope must be licensed and supported, removed from devices when it is no longer supported, and updated within fourteen days for anything rated high risk or critical. Automatic updates should be enabled where possible.

This control now carries two of the three auto fail conditions, so it deserves its own section.

The auto-fail conditions

Three answers now fail the entire assessment on their own. There is no discretion, no partial credit and no compensating control. An assessor cannot mark around them.

Multi factor authentication on cloud services

MFA is mandatory on every cloud service in scope where MFA is available. If MFA is available and it is not enabled, the assessment fails automatically. This applies whether MFA is free, bundled in the existing licence, dependent on another service or only available as a paid upgrade. Cost is not an accepted justification.

Two practical consequences for MSPs. First, your cloud service register must record MFA availability and MFA status for every entry, not just for the identity provider. Second, if a client uses a service that offers no MFA capability at all, you have a decision to make before the assessment rather than during it. Either replace the service, or establish and document that it holds no organisational data and is therefore genuinely outside the definition.

A6.4: operating system and firmware updates within fourteen days

All high risk or critical security updates and vulnerability fixes for operating systems and for router and firewall firmware must be installed within fourteen days of release. Failure is automatic.

Firmware is the part that catches people. Operating system patching is usually well handled by the RMM. Firewall and router firmware is often on a manual quarterly cycle, or on no cycle at all. Under Danzell, a firewall running firmware with a critical fix released two months ago will fail the assessment on its own.

A6.5: application updates within fourteen days

The same fourteen day rule applies to applications, including associated files and extensions. Browsers, browser extensions, productivity suites, PDF readers, line of business applications and anything else installed on an in scope device.

Third party application patching is where most MSPs discover their real coverage. If your patching solution covers operating systems well and applications selectively, you have an exposure across every client you certify. Fix that before August, not in the week the assessment is due.

Making this a repeatable service line

Most MSPs deliver Cyber Essentials as a favour that turned into a service. It sits with one person who knows the scheme, in a spreadsheet, next to a folder of screenshots. That works at five clients. It does not work at fifty, and it certainly does not work in a year where the marking criteria changed and every renewal has to be re-examined.

The components of a service line that holds up are consistent across every provider that has built one successfully:

  • A standard scoping questionnaire issued at kick off, covering entities, sites, cloud services, device types and exclusions.
  • A single evidence model so that every client's pack looks the same and can be reviewed by anyone on the team.
  • Automated evidence collection from the tools you already run, rather than manual screenshots that are out of date the moment they are taken.
  • A gap assessment step that runs before the client pays for the assessment, so that failure is discovered by you rather than by an assessor.
  • A renewal calendar across the whole client base, driven by expiry date rather than by memory.
  • Version awareness built into the process, so that the question set in use is confirmed at the start of every engagement.

None of that is glamorous. All of it is the difference between Cyber Essentials being a margin positive recurring service and being an annual scramble that consumes a senior engineer for three weeks.

Where Certiflow fits

Certiflow is a multi tenant platform built for service providers delivering Cyber Essentials across a client base. It exists because we were running exactly the process described above, by hand, and it did not scale.

The platform covers assessment workflow across multiple tenants, evidence collection and storage per client, gap assessment against the current question set, and renewal tracking across the whole base. Assessments completed in Certiflow can be pushed directly to IASME through our live Pervade Software integration, which removes the manual re-keying step at the end of the process. Microsoft and Google single sign on are live.

We are honest about what is not finished. Halo PSA, Autotask and ConnectWise integrations are in build. They are not available yet, and we will say so every time we are asked.

Early access is open now. If you deliver Cyber Essentials across more than a handful of clients and the Danzell transition has made that harder, we would like to talk to you.

Subscribe to receive articles right in your inbox