The NCSC patch wave is not a single vulnerability, a named product or a dated event. It is a forecast about volume: that UK organisations should expect to absorb a sustained run of significant security updates rather than the occasional emergency. If your patch process already works for the kit you know about, the wave will not break on the act of applying updates. It will break on the hosts nobody listed.
What the NCSC’s patch wave warning actually says
The framing comes from the NCSC’s chief technology officer, Ollie Whitehouse, in a blog published on 1 May 2026 that builds on remarks he made at CYBERUK 2026. The argument, in short: AI-assisted code analysis is now good enough to surface long-standing flaws in software that has carried technical debt for decades, and those flaws will reach vendors, researchers and attackers faster than they used to. Read the original rather than the commentary, and read it alongside the NCSC’s vulnerability management guidance, which the blog points readers towards.
Note what the warning does not contain. No start date. No named vendors or products. No single novel threat to defend against. It is a capacity prediction, not an advisory, which means “wait for the announcement and then react”is not a plan; there is nothing to wait for.
The squeeze, then, falls in two places. Remediation capacity, meaning how many changes your teams can actually land per week without breaking production. And decision-making, meaning how quickly you can answer a simple question when an advisory drops: does this affect us, and where. Most organisations are better at the first than the second.
Why a patch surge breaks on inventory, not on patching
A patch programme only reaches what the asset register lists. Everything else is invisible to it by definition, and the things outside the register are rarely exotic: a campaign microsite a marketing agency stood up three years ago, a UAT host from a migration that finished, the infrastructure that arrived with an acquisition and was never fully absorbed, a supplier widget embedded on a subdomain you delegated and forgot.
December 2021 is the closest recent analogue. For most teams, Log4Shell was not hard to fix; it was hard to locate. The genuinely painful weeks went on working out which applications bundled the component, which vendors had shipped it inside an appliance, and which hosts were running something built by a team that had since moved on. The update itself took minutes. The search took a fortnight.
Some of your exposure you cannot patch at all. A supplier-hosted subdomain, a SaaS tenant on your DNS, a payment or booking page rendered by somebody else’s stack: for each of those the only meaningful preparation is a named human contact and an out-of-hours escalation route, recorded before you need it. Chasing a procurement portal for the name of an engineer, on the day a CVE lands, is a poor use of a Tuesday.
The asymmetry is the whole problem. An attacker mass-scanning for a fresh CVE does not consult your CMDB. They see hosts, ports, banners and certificates, and they see them all equally. Coverage gaps that are administratively invisible to you are operationally invisible to nobody.
Map the internet-facing estate before the wave arrives
Mapping the external estate means starting from what you definitely own, usually a handful of registered domains, and expanding outwards the way an attacker does: from the outside. Three sources do most of the practical work.
- Certificate transparency logs. Every publicly trusted TLS certificate is logged, so a single seed domain search will usually surface hostnames no internal register lists. A uat. or staging. name still answering on the public internet, running an older software stack, is a routine finding rather than a rare one.
- DNS records. A and AAAA records, CNAMEs, MX, plus the mail authentication records (SPF, DKIM, DMARC) that reveal which third parties send on your behalf.
- Domain registration and WHOIS data. Useful for finding the sibling domains bought for a campaign, a product launch or a defensive registration, and then never monitored.
What comes back is a candidate list, not an inventory. That distinction matters more than anything else in this section. Each candidate needs an ownership decision: ours, a supplier’s, or genuinely not ours, and the third answer is common because shared hosting and partner IP ranges create false neighbours. Making those calls calmly in advance is the difference between a two-hour triage and a two-week argument about whether a host on a partner’s range is in scope. Our guide on how discovery surfaces the assets you forgot walks through the expansion process in more detail.
Record the fields that make surge triage fast rather than the fields that look tidy in a spreadsheet: hostname, resolved IP, hosting location or provider, owning team, business function, and whether the thing is still needed at all. That last field retires more risk than any patch will. We set out the full set in the seven fields worth recording for an internet-facing inventory.
Do this now, while nothing is on fire, for one more reason: change detection needs a baseline. Once emergency rebuilds start, you want to be able to see what appeared this week and what vanished. Without a before, the after tells you very little. That is also the case for monitoring continuously rather than scanning once a year.
Likely versus definitely: triaging an advisory across the estate
Passive external observation infers exposure. It reads banners, response headers, TLS certificate details, favicon hashes and behavioural fingerprints, and from those it says: this host looks like it is running the affected product at the affected version. Within a few hours of an advisory, that gives you a shortlist. Hours matter.
But the error rate runs in both directions, and this is the part teams underestimate. Debian and Red Hat backport security fixes without bumping the upstream version string, so a fully patched host can present a version that a fingerprint reads as vulnerable. In the other direction, a patched CDN, WAF or reverse proxy can present clean headers while the origin behind it sits unpatched and reachable by another route. One produces wasted effort. The other produces false confidence, which is worse.
Across five hosts you absorb that error rate. Across four hundred, during a wave, it multiplies into a queue of tickets nobody trusts. So plan validation capacity alongside detection: authenticated checks, agent data, active vulnerability scanning against the specific flaw, or a maintenance-window test that actually exercises the code path. Detection tells you where to look; proof comes from the inside. The distinction is set out at length in likely versus definitely.
Use the shortlist to sequence work, not to declare a verdict. And when you report upwards, keep the two categories visibly separate. “Fourteen hosts confirmed vulnerable, sixty-one flagged as likely and awaiting validation, nine owned by suppliers and chased”is a sentence a board can act on. “Seventy-five vulnerable systems”is an inference dressed up as a fact, and somebody will eventually ask.
Decommission debris: the exposure the wave creates
Here is the failure mode almost no patch-wave article mentions. Emergency remediation does not only apply updates; it triggers rebuilds, migrations and rip-and-replace decisions, at speed, often by people working outside their normal change process. Cloud resources get retired in minutes. The DNS record pointing at them almost always survives.
A CNAME pointing at a deleted storage bucket or a released app service name is a dangling record: a pointer to nothing. Whoever registers that name next controls the content served on your subdomain, on your certificate, inside your cookie scope. Take promo.example.co.uk, created for a six-week campaign, still pointing at a bucket that was deleted when the project closed. The project team moved on. The record did not. Weeks later somebody else owns that page. The mechanics, including how to test for it, are covered in our piece on subdomain takeover and dangling DNS.
Two fixes, both dull, both effective. Put an explicit “remove or repoint the DNS record”step in your rebuild and rollback runbooks, with a named approver who signs the change off rather than a generic team mailbox. And re-run external discovery in the week after each significant patch push, treating the aftermath as its own exposure window rather than as the end of the incident.
Keeping prioritisation honest when everything is labelled critical
Prioritisation logic, not detection volume, decides whether a team survives a months-long wave. Score alone will not carry you: a CVSS 9.8 on an internal build server behind an authenticated VPN is a worse use of Thursday than a 7.5 on an unauthenticated internet-facing login page with public exploit code. Filter on three things together: internet-facing, presence of an authentication or data-handling surface, and evidence of active exploitation.
Then do the arithmetic on your own commitments. Cyber Essentials requires high and critical vulnerabilities, broadly CVSS v3 base scores of 7.0 and above, to be patched or mitigated within 14 days of the fix being released. That is a workable clock for a normal month. Suppose thirty qualifying advisories land in a fortnight across an estate where a tenth of the internet-facing hosts are not in any register. The 14 days do not stretch. You are simply out of compliance on the hosts you never found, and you will not know which ones those are.
Manage fatigue on a scale of months, not days. Tune what raises a page, agree in advance what “stop everything”actually means and who is allowed to call it, and accept that once every finding is labelled critical the label has stopped doing any work. Several of the related traps are covered in the costly errors teams make with external attack surface management.
A readiness checklist to work through now
- Run discovery from your seed domains and close out every candidate. Each one gets an owner, or gets formally disowned in writing. No “unknown”rows left open.
- Record a named contact and an out-of-hours escalation path for every supplier-hosted asset on your DNS, including agencies and marketing platforms.
- Rehearse. Pick a real advisory from the last three months and time how long it takes to answer: which of our external hosts could be affected. The number you get is your actual triage capability, whatever the process document says.
- Add the DNS removal step to rebuild and rollback runbooks, with a named approver, then re-run discovery a week after each push.
- Agree the prioritisation filter and the “stop everything”threshold before you need them, and write down who decides.
- If you are buying tooling, interrogate data freshness first. A weekly snapshot is close to useless when an advisory lands on a Tuesday morning. Ask how often assets are re-fingerprinted, whether checks re-run automatically when a new CVE is published, and how a finding reaches your ticket queue without somebody copying it across by hand. The wider evaluation criteria are in our practical checklist for choosing an EASM product.
The Short Version
The NCSC patch wave warning is about volume and pace, not a specific flaw, and it carries no start date, so preparation has to begin without a trigger. Your constraint will be knowing where affected software runs, not deploying the update, exactly as it was with Log4Shell in December 2021. Map the external estate from your seed domains now and settle the ownership questions while it is calm. Expect passive detection to give you a fast “likely affected”list and nothing more; keep validation capacity in reserve and never report an inference as a confirmation. Watch the debris the wave leaves behind, because a dangling DNS record is a gift to whoever claims the name next. And fix your prioritisation filter in advance, because the 14-day Cyber Essentials clock does not care how many hosts you failed to find.
Frequently Asked Questions
What is the NCSC patch wave?
It is the NCSC’s expectation that organisations will face a sustained increase in significant security updates, set out by chief technology officer Ollie Whitehouse in a blog of 1 May 2026 that developed his CYBERUK 2026 remarks. The stated driver is AI-assisted code analysis surfacing long-standing flaws in software carrying decades of technical debt. It describes volume and pace rather than one new threat, and it names no specific products.
When will the patch wave start, and what should organisations do in the meantime?
No start date has been given, which is precisely why waiting is not a strategy. The useful work is capacity work: map the internet-facing estate, assign an owner to every host, record supplier contacts and escalation routes, and rehearse triage against a recent advisory to find out how long an answer actually takes. None of that depends on knowing which product is hit first.
How does external attack surface management help with patch wave preparation?
External attack surface management builds the view an attacker has: hosts, subdomains, certificates and services reachable from the internet, discovered from your domains rather than read from your asset register. That gives you a candidate list that includes the staging server and the forgotten microsite, and a baseline against which to spot what changes during emergency rebuilds. For a fuller definition, see what external attack surface management actually is.
Can external scanning confirm whether a system is definitely vulnerable?
Usually not on its own. Passive fingerprinting infers exposure from banners, headers and response behaviour, and both false positives and false negatives are routine: distribution backporting leaves version strings unchanged on fixed systems, while a patched CDN can hide an unpatched origin. Treat the output as a prioritised shortlist and confirm with authenticated or active checks before you call anything proven.
How quickly do internet-facing systems need patching under Cyber Essentials?
Cyber Essentials requires vulnerabilities rated high or critical, broadly CVSS v3 base score 7.0 and above, to be patched or otherwise mitigated within 14 days of the fix being released. Check the current requirements document on the NCSC’s Cyber Essentials pages, as the scheme is periodically updated. During a sustained wave the clock does not move, so unmapped hosts become a compliance problem as well as a security one.