Cyber Essentials, the UK government-backed baseline certification run by the NCSC and IASME, has been assessed against version 3.3 of its requirements since 27 April 2026. Assessments started under the previous version, and the previous "Willow" question set, have six months from when the account was opened, so the last of them run out in late October. From then on, every applicant is on v3.3 and the "Danzell" question set. The change that will fail the most organisations isn't a new requirement. It's a marking change: no MFA on a cloud service that offers it is now an automatic fail.
This post is for IT and security leads at companies certifying or renewing Cyber Essentials, and for software vendors whose UK customers need it. It covers what changed in v3.3, the three rules that fail the most assessments, what the scheme asks of software you sell, and a script that checks a software inventory against the "supported software" rule.
The short answer
Cyber Essentials v3.3 and the Danzell question set apply to assessment accounts created after 27 April 2026, and older accounts expire six months after they were opened. The requirements changed little: a definition of "cloud service", a statement that cloud services can't be left out of scope, FIDO2 added to passwordless authentication, and a pointer to the UK Software Security Code of Practice. The marking changed more. IASME says failing to turn on MFA for any cloud service where it's available, free or paid, is now an automatic fail. The 14-day patch rule for critical and high-risk fixes and the ban on unsupported software haven't changed, and they remain where most organisations fall short.
What changed in v3.3
The NCSC's Requirements for IT Infrastructure v3.3 lists its changes on page 3:
- a definition of "cloud services";
- an updated definition of passwordless authentication that includes FIDO2;
- a definitive statement that cloud services can't be excluded from scope;
- the Software Security Code of Practice, referenced in the software development section;
- scope criteria that no longer mention "untrusted connections";
- more emphasis on backing up data.
IASME's announcement, published in November 2025, calls the requirement changes "minor". It singles out one marking change as "a notable shift that could have a substantial impact on compliance for many organisations". Organisations that don't turn on MFA for cloud services where it's available, "whether it is free, included, or a paid option", will "automatically fail the assessment".
The cloud definition closes a scoping gap
v3.3 defines a cloud service as "an on-demand, scalable service, hosted on shared infrastructure, and accessible via the internet". For Cyber Essentials, it's one accessed through an account, either credentials your organisation issues or a business email address, that stores or processes your organisation's data.
That covers more than the obvious platforms. A design tool someone signed up for with a work email, a file-sharing service a team uses for one client, a project tracker on a free plan: if it holds company data and someone logs in with business credentials, it's in scope. v3.3 states "Cloud services cannot be excluded from scope", and with the new marking, each one needs MFA if it offers it.
The practical job is an inventory of SaaS accounts, which most organisations don't have. Single sign-on logs, expense reports and finance records of software subscriptions are good places to start.
The three rules that fail assessments
MFA on every cloud service that offers it. The requirement text, "authentication to cloud services must always use MFA", is the same as in v3.2. What changed is the marking. Any extra factor counts, including SMS, though the NCSC recommends stronger options where they work. The password part of MFA must be at least 8 characters, with no maximum length.
Critical and high fixes within 14 days. All in-scope software must be updated within 14 days of a fix's release when the vendor calls it critical or high-risk, when it fixes a vulnerability with a CVSS v3 base score of 7 or above, or when the vendor doesn't say how severe it is. If a single update fixes several issues and any one of them is critical or high, the whole update falls under the 14-day rule. Automatic updates must be on where possible.
Only licensed and supported software. Supported means a vendor is committed to providing regular vulnerability fixes "and must provide the future date when they will stop providing these". Software must be removed when it loses support, or moved into a sub-set that blocks all traffic to and from the internet.
What it asks of software vendors
Two parts of v3.3 apply to companies that sell software to UK organisations.
First, the "licensed and supported" definition means customers need your end-of-support dates. If you don't publish a date when security fixes stop for each version, a customer's assessor can't confirm your product meets the requirement. A published support policy with dates per release line is the simplest answer.
Second, the software development section now points to the Software Security Code of Practice. In Cyber Essentials, publicly available commercial web applications are in scope by default, while bespoke and custom components of web applications are out of scope. The requirements say the best mitigation for application vulnerabilities is "robust development and testing in line with commercial best practice", and refer readers to the Code of Practice. It isn't a new pass or fail control. It does tell vendors which document UK buyers will measure them against.
Check your software against the support rule
This script takes a CSV of products and release lines and looks each up on endoflife.date, a community-maintained database of vendor end-of-support dates. It flags anything past its end date, anything ending within 90 days, and anything with no published date. It uses only the Python standard library and sends product names to endoflife.date. Check any date it reports against the vendor's own lifecycle page before relying on it in an assessment.
#!/usr/bin/env python3
"""Check a software inventory against Cyber Essentials' "licensed and supported" rule.
python3 ce_supported_check.py inventory.csv
inventory.csv has two columns, product and release line, using endoflife.date
product names, for example: windows,10-22h2-e / ubuntu,22.04 / python,3.10
Cyber Essentials v3.3 says in-scope software must be supported, with a vendor-
published date when fixes stop, and must be removed (or isolated from the
internet) once it's unsupported. This looks each line up on endoflife.date and
flags anything past its end date, due within 90 days, or with no published date.
Standard library only; sends product names to endoflife.date.
"""
import csv, datetime as dt, json, sys, urllib.request
API = "https://endoflife.date/api/v1/products/{}/"
SOON = 90
def releases(product, cache={}):
if product not in cache:
req = urllib.request.Request(API.format(product), headers={"User-Agent": "ce-check/1.0"})
try:
cache[product] = json.load(urllib.request.urlopen(req, timeout=20))["result"]["releases"]
except Exception as e:
cache[product] = e
return cache[product]
def main(path):
today = dt.date.today()
problems = 0
for row in csv.reader(open(path)):
if not row or row[0].startswith("#"):
continue
product, line = row[0].strip(), row[1].strip()
rel = releases(product)
if isinstance(rel, Exception):
print(f"[?] {product} {line}: lookup failed ({rel})")
problems += 1
continue
match = next((r for r in rel if r["name"] == line), None)
if not match:
print(f"[?] {product} {line}: not a known release line")
problems += 1
continue
# Security support ends at eolFrom; eoasFrom is only the end of bug fixes
end = match.get("eolFrom")
if not end:
print(f"[CHECK] {product} {line}: vendor publishes no end date; ask your assessor how it's treated")
continue
days = (dt.date.fromisoformat(end) - today).days
if days < 0:
print(f"[FAIL] {product} {line}: unsupported since {end}; remove it or cut it off from the internet")
problems += 1
elif days <= SOON:
print(f"[SOON] {product} {line}: support ends {end} ({days} days)")
else:
print(f"[ok] {product} {line}: supported until {end}")
print(f"\n{problems} item(s) that would fail the 'licensed and supported' requirement")
sys.exit(1 if problems else 0)
if __name__ == "__main__":
if len(sys.argv) != 2:
sys.exit(__doc__)
main(sys.argv[1])
We ran it on 16 October against a sample inventory:
$ python3 ce_supported_check.py inventory.csv
[ok] windows 11-25h2-e: supported until 2028-10-10
[CHECK] macos 15: vendor publishes no end date; ask your assessor how it's treated
[ok] ubuntu 24.04: supported until 2029-05-31
[ok] ubuntu 22.04: supported until 2027-06-01
[FAIL] office 2021: unsupported since 2026-10-13; remove it or cut it off from the internet
[FAIL] python 3.10: unsupported since 2026-10-01; remove it or cut it off from the internet
[ok] nodejs 22: supported until 2027-04-30
2 item(s) that would fail the 'licensed and supported' requirement
exit 1
Office 2021 and Python 3.10 both lost support in the past three weeks, which is easy to miss in a renewal cycle. macOS shows the other common problem: Apple doesn't publish end-of-support dates, so the script marks it for a conversation with your certification body rather than a fail.
What to do before your next assessment
- Check your assessment account date. If it was opened before 27 April 2026 under Willow, it expires six months after it was opened. Plan to finish or start again under Danzell.
- Build the SaaS inventory and turn on MFA everywhere it's offered, including paid add-ons.
- Measure your patch time for critical and high fixes against 14 days, per product, not on average.
- Remove unsupported software, or isolate it from the internet, and track end dates ahead of time.
- If you sell software, publish support end dates for each version, and map your development practice to the Code of Practice.
The fair view
Cyber Essentials is a baseline. It's a self-assessment for the basic level, it doesn't test applications in depth, and passing it says little about a mature security programme. Some of its rules are blunt: 14 days applies to every critical fix, whatever your exposure, and the MFA change will fail organisations over a forgotten free account.
But a baseline is the point. The controls it checks, MFA, patching and supported software, are the ones behind a large share of real incidents. It's also a condition of some UK government contracts, so the v3.3 changes reach suppliers as well as the organisations certifying. For vendors, the useful signal is the reference to the Code of Practice. Our PSTI review shows the same pattern in consumer IoT: UK rules that ask suppliers for published support periods and vulnerability handling, not just secure products.
