What the DfE’s cyber security update means for multi-academy trusts

Before dawn on 10 July 2024, one ransomware attack took down ten schools inside the same multi-academy trust at once.

Every control that eventually stopped it was something the Department for Education’s own cyber security standard already asked for, well before the attack.

That’s a case DfE has published on its own Cyber Security Hub, and it’s the clearest illustration of why the department tightened that same standard again on 24 June 2026.

The update didn’t add anything new to what DfE expects schools and trusts to do. It closed the room to do it only most of the time.

What the DfE’s cyber standard actually changed on 24 June 2026

The DfE’s cyber security core standard has had several edits in 2026 alone.

In April, the department clarified that a vulnerability fix means more than installing a patch. It also covers configuration changes, registry changes and vendor scripts.

In June, it updated the standard again, this time, in the department’s own words, to reflect new technical requirements introduced by the National Cyber Security Centre as part of the Cyber Essentials 2026 standard.

Cyber Essentials 2026 is IASME and NCSC’s Requirements for IT Infrastructure v3.3, known by its question set name, Danzell, which replaces the previous Willow set. It takes effect for new assessment accounts from 27 April 2026. 

Two changes in it matter here.

Multi-factor authentication becomes a straight fail if it’s available on a cloud service and hasn’t been switched on, with no exception for cost. And the 14-day window for fixing high-risk or critical vulnerabilities becomes a straight fail too, with the old buffer of two allowable near-misses removed.

None of this is new to the DfE standard itself as it already required 14-day fixes for anything with a CVSS v3.1 score of 7.0 or above, and MFA on cloud and admin accounts, well before June.

What changed is what happens when a trust doesn’t quite manage it.

Why auto-fail rules change the maths for a shared estate

Under the previous Willow question set, an organisation could carry up to two major non-compliances and still pass a Cyber Essentials assessment. That cushion is gone for the controls that matter most.

A single school with one site has one chance to trip an auto-fail. A trust running 10 sites has 10 times the surface area for the same mistake, and the assessment doesn’t distinguish a trust’s best-run school from its worst.

The cost exemption removal matters here too.

Paying for MFA on one licence tier is a small decision for a single school. But doing it across every cloud service at every school a trust runs is a much bigger one, and now there’s no version of “we’ll get to it” that still passes.

None of this means the standard got harder to meet. It does mean the standard stopped grading on effort.

Why one trust rarely means one IT estate

86% of multi-academy trusts are now fully centralised, according to the Kreston UK Academies Benchmark Report 2026.

But centralisation doesn’t happen at the same speed across every function. Lift Schools (formerly Academies Enterprise Trust), for example, has described dividing HR into five regions and IT into four within the same organisation.

That unevenness isn’t a management failure. It’s what happens when schools join a trust bringing their own contracts, their own hardware and their own support arrangements with them, and nobody replaces all of it on day one.

This is where the DfE standard is unusually direct for a government document.  It names the risk explicitly, describing other schools on a broader organisational network, such as a multi-academy trust, as being impacted by the same cyber incident or attack.

That’s not a hypothetical clause, it’s the reason a 14-day SLA written into a trust-wide policy and a 14-day SLA actually held at every site are two different things.

And the certificate doesn’t care which one a trust has got. It belongs to the trust, not to whichever IT provider happens to be patching which school. If a provider misses the window at one site, that gets recorded against the trust’s assessment, not filed away as a supplier issue to chase up later.

The certificate stays with the trust even when the patching doesn’t. If your IT runs through a managed provider, it’s worth seeing how one MSP built a DfE-standards service around exactly that gap (with Heimdal).

What Active Learning Trust’s ransomware attack shows about shared risk

DfE’s own case study on Active Learning Trust is the clearest evidence of what a shared estate risks.

The trust runs 21 schools across Cambridge and Suffolk and serves almost 9,000 students across more than 2,000 devices.

At 6.30am on 10 July 2024, staff discovered they couldn’t open their files. Ransomware had encrypted data across 10 of those schools at once with several unable to access their school management system. The recovery took nine days and cost over £500,000, consuming 1,200 staff hours.

it got worse a week in when the global CrowdStrike outage landed on top of an already difficult recovery.

The trust’s response, once it was underway, reads like a checklist of what Cyber Essentials 2026 and the DfE standard now expect proactively. 

• Multi-factor authentication enforced across the estate.
• Network segmentation with VLANs at every site.
• Internal firewalls installed where there hadn’t been any. All of it happened after the attack, not before.

Chris Everard, the trust’s Chief Operating Officer, was direct about the lesson. 

“Understanding and documenting how systems connect to each other and work together would have saved us a lot of time.”

His advice to other trusts is practical rather than dramatic. MFA for every user, and no one logged into an account with admin rights for day-to-day work.

DfE has already published what this risk looks like in practice. One attack on Active Learning Trust encrypted files across 10 of its schools at once.

What a multi-academy trust actually needs to prove, not just do

Start with the triggers because they’re more specific than most guidance admits.

A 14-day fix window applies when a vendor rates a vulnerability as critical or high risk. And when it scores 7.0 or above on the CVSS v3.1 scale or when the vendor gives no severity rating at all, the 14-day clock applies by default.

And since April, a “fix” covers more than a downloaded patch. Configuration changes, registry changes and vendor scripts all count. They all start the same clock.

Map MFA the same way.

It’s required on staff accounts with access to cloud services or remote access to on-site systems and on every IT administrative account. Passkeys can stand in where staff use a dedicated device.

There’s no carve-out for a school still running a legacy system with no MFA option, only a requirement to use the strongest control available. And that status lives inside Microsoft Entra ID, not a spreadsheet, which is exactly where the evidence needs to come from.

Then build the evidence, not just the control. An assessor samples across the estate, not just the site a trust chooses to show them. So a policy that’s true at the flagship school and untested everywhere else won’t hold up. Keep the audit trail at site level and log the date each fix went in, not just the date the policy was signed off centrally.

Where Heimdal fits, and where it doesn’t

None of the above requires a particular vendor but it does require proof that’s held consistently where a trust operates. That’s the specific problem parts of the Heimdal platform were built to address, and it’s worth being precise about where that helps rather than listing everything we sell.

Patch & Asset Management handles the 14-day problem directly

We patch Windows and third-party software automatically across every device in an estate and track CVE and CVSS data against each fix. Compliance tracking is mapped to frameworks including Cyber Essentials.

A trust can show an assessor exactly when a vulnerability was identified and when it was closed, not just that a policy exists saying it should have been. 

Privilege Elevation and Delegation Management and Application Control handle the account side.

Elevated access gets granted for a set period and revoked automatically, rather than left open indefinitely. This is close to what the DfE standard asks for when it talks about dedicated administrative accounts and SLT sign-off on privilege changes. 

In February 2026 we published what we believe is the first IASME Cyber Essentials aligned control mapping for PEDM, setting out what evidence removing standing admin rights produces for an assessment.

And on the MFA problem from the last section, the dashboard reads that status straight from Microsoft Entra ID, so a trust can see what’s actually switched on, not what a policy assumes.

Threat-hunting & Action Center gives a lean central IT team one place to watch every site

Rather than logging into separate systems at each one to work out what’s happening where.

For a trust the size of Active Learning Trust, that’s the difference between spotting an intrusion at one school and discovering it’s already reached nine more.

We don’t have a published case study with a named multi-academy trust to point to here, and we’re not going to pretend otherwise. But, we do have quotes from our MAT customers.

Dave Leonard, Strategic IT Director at Watergrove Trust, said reporting to trustees “has been made simpler and more informed” since consolidating onto one platform.

Charles Greig, Director of IT at Oxlip Learning Partnership, put the multi-site angle directly. “Knowing that the right experts are watching the signals from a large Multi Academy Trust and taking the right action gives me real confidence.”

If any of that’s relevant to what your trust needs to prove, it’s worth a conversation. If it isn’t, the rest of this piece still stands on its own.

The real shift

Most trusts already have the right controls somewhere in their estate, though the shift isn’t from insecure to secure. You move from “we’re doing this” to “we can prove it, at every site, today”, and that’s the same question the Academy Trust Handbook 2025 and RPA conditions of cover are starting to ask.

Treat it as an operating habit rather than a one-off project, and the next update, whenever it lands, stops being a scramble.

Danny Mitchell

Head of Content at Heimdal. A journalist by trade who cares about helping MSPs and security teams make better decisions, enjoy their work, and see real results.