Cyber Essentials+ 2026 Update: What Changed and What It Means for Meraki Networks

What Is Changing?

On 27 April 2026, IASME is rolling out version 3.3 of the Cyber Essentials Requirements for IT Infrastructure. The verified self-assessment process is also being renamed to Danzell. Assessment accounts created after 26 April will use the new requirements. Accounts created before that date have a six-month grace period to certify under the previous version.

The five core technical controls — firewalls, secure configuration, access control, patch management, and malware protection — remain the same. But the rules within several of those controls have been tightened, and the consequences for non-compliance are now harsher.

Here is a summary of the key changes and what they mean for organisations running Cisco Meraki networks.

1. MFA Is Now Mandatory for All Cloud Services

This is the biggest change in the 2026 update. Previously, the MFA requirement under the Access Control pillar focused primarily on administrator and privileged accounts. The new rules expand the scope significantly.

Multi-factor authentication must now be enforced on every cloud service that stores or processes organisational data, wherever MFA is available. The scheme defines a cloud service broadly: if it is accessed via business credentials and hosted on shared infrastructure, it is in scope.

This includes:

• Cloud email — Microsoft 365, Google Workspace
• Identity providers — Entra ID, Okta, Google Identity
• SaaS platforms — CRM, HR, accounting, project management tools
• Cloud storage — OneDrive, Google Drive, Dropbox
• Remote access services — VPN portals, remote desktop gateways
• Administrative tools — including the Meraki Dashboard itself

Any service where MFA is available but not enforced is an automatic failure.

What this means for Meraki networks

Meraki Dashboard MFA enforcement is still critical — that has not changed. But now you also need to demonstrate that MFA is enforced across every other cloud service in the organisation. For MSPs, this means the conversation with clients needs to go beyond "is your Meraki dashboard MFA enabled?" to "show me MFA is enforced on every SaaS tool your staff use."

MerakiGuard already checks the Meraki organisation-wide MFA enforcement setting via GET /organizations/{id}/loginSecurity. The expanded cloud services scope is outside Meraki's API, but your CE+ evidence pack now needs to cover both.

2. Patching Non-Compliance Is Now an Automatic Failure

The 14-day patching window for critical and high-risk security updates is not new. What has changed is the consequence: failing to apply patches within 14 days is now an automatic failure, not a non-compliance note.

This applies to:

• Operating systems
• Applications
• Router and firewall firmware — including Meraki MX, MS, and MR devices

For Meraki networks, firmware management is centralised through the dashboard, which makes it relatively easy to stay current. But "relatively easy" and "actually done" are different things. If a firmware upgrade has been available for more than 14 days and your MX is still running the old version, that is now an automatic fail.

MerakiGuard checks firmware currency by comparing running versions against available upgrades via GET /organizations/{id}/firmware/upgrades and GET /organizations/{id}/devices/statuses. With the stakes raised to automatic failure, running this check regularly — not just before your annual assessment — is more important than ever.

3. CE+ Assessments Use Double Sampling

Under the previous rules, if an assessor found a patching issue on a specific device, the organisation could fix that one device and continue the assessment. The new rules introduce double sampling.

If a device in the assessor's initial random sample fails the update check, they must test a second random sample. If the second sample also contains failures, the entire certification fails. You cannot fix your way through the assessment one device at a time.

This is a fundamental shift. It means patching has to be consistently applied across your entire estate, not just the devices that happen to get sampled. For MSPs managing dozens of Meraki organisations, portfolio-wide firmware visibility is no longer a nice-to-have — it is essential.

4. VSA Responses Are Locked During Assessment

The Verified Self-Assessment (now called Danzell) responses are locked once CE+ testing begins. Organisations can no longer modify their self-assessment answers mid-assessment to align with what the assessor is finding.

This means your self-assessment answers need to be accurate from the start. If you claim your firewalls are configured with default-deny and the assessor finds otherwise, you cannot go back and change the answer. The discrepancy between your self-assessment and the assessor's findings will be flagged.

5. Scope Documentation Changes

There are also changes to how organisations document what is in scope for their CE+ assessment:

• No word limits on scope descriptions (previously restricted)
• Legal entities within scope must be explicitly listed
• Exclusions must be documented with explanations (though not published publicly)

For MSPs certifying multiple client organisations, this means each client's scope documentation needs to be more thorough. The days of a one-paragraph scope statement are over.

What Has Not Changed

The five core technical controls remain the same:

1. Firewalls — default-deny inbound, least-privilege rules, minimal port forwarding
2. Secure configuration — no defaults, unnecessary services disabled, attack surface minimised
3. Access control — MFA, least privilege, no shared accounts (scope expanded, see above)
4. Patch management — 14-day window for critical updates (consequences raised, see above)
5. Malware protection — AMP and IDS/IPS active on boundary devices

The Meraki API endpoints you use to audit these controls are unchanged. The mapping between API data and compliance checks that we covered in our original CE+ automation guide remains accurate. What has changed is the pass/fail threshold and the consequences of getting it wrong.

Summary of Changes

What You Should Do Now

If your CE+ renewal falls after 27 April 2026, you will be assessed against the new requirements. Here is how to prepare:

1. Audit MFA across all cloud services. Go beyond Meraki Dashboard. Document every SaaS, IaaS, and PaaS tool in use and confirm MFA is enforced on each one.
2. Check firmware across your entire Meraki estate. Not just the MX — switches and access points too. Any device more than 14 days behind a critical update is now a hard fail.
3. Run scans regularly, not just before assessment. With double sampling, you cannot rely on fixing issues during the assessment. Continuous monitoring catches drift before the assessor arrives.
4. Review your scope documentation. Ensure all legal entities are listed and any exclusions are documented with justification.
5. Ensure your self-assessment answers are accurate. They will be locked once testing begins. Discrepancies between your answers and the assessor's findings will be flagged.

MerakiGuard automates the Meraki-specific checks — firewall rules, MFA enforcement, firmware currency, AMP/IDS status, SSID configuration, and more. Run a scan now and find out where you stand before the new rules take effect.