The NCSC Annual Review 2026, published on 3 November 2026 under the title The State of the Cyber Nation, is the tenth edition and covers the year from 1 September 2025 to 31 August 2026. Most coverage of it will stop at the numbers. The useful question is narrower: given what the review says about how UK organisations are actually being compromised, what can you verify about your own internet-facing exposure this week?

Six checks follow, in the order an attacker works through them. All six use only what is publicly visible about your organisation, which means you can run them without touching a single internal system.

What the NCSC Annual Review 2026 Actually Changed in the Conversation

The review reports 1,831 reports of cyber incidents handled during the period and 337 incidents requiring support from the NCSC, a portion of which were classed as nationally significant. Those figures are worth quoting at a board meeting once. After that, they stop being useful, because volume alone does not tell you where your own gap sits.

The line that matters is the shift in emphasis from whether you have controls to whether you can demonstrate they work. That distinction is not a tooling problem. Most security teams can produce a patching policy, a scanner licence and a risk register inside ten minutes. Far fewer can take one named internet-facing host and show the version it ran before, the date the fix landed, the retest output that confirms it, and the name of the person who signed it off.

Three themes in the review are worth acting on rather than summarising: incident volume and severity, third party and supply chain routes in, and identity-led intrusion using valid credentials rather than exploits. Each one maps to something observable from outside your perimeter.

Read it that way and the review becomes a work plan. Read it as a slide and it changes nothing.

Check 1: Find the Internet-Facing Assets Nobody Has Told You About

Incident counts rise fastest against assets that never made it into the asset register. Marketing microsites built by an agency three years ago. Dev and staging subdomains that were meant to be temporary. Cloud tenants spun up on a departmental card. Entire estates inherited through acquisition, still resolving, still patched to whatever the previous owner's standard was.

Most organisations do not have a complete view of their external attack surface, and the reason is usually methodological. Discovery gets scoped to the domains the team already knows about, which validates the register instead of challenging it. That is circular by design and it guarantees you find nothing new.

A discovery route that actually challenges the register looks like this:

  • Certificate transparency logs, which record every publicly trusted certificate issued against your domains, including the ones issued for hosts you forgot
  • DNS records and historical DNS, which surface subdomains that still resolve and CNAMEs pointing at decommissioned cloud resources
  • IP range and ASN mapping, to catch hosts outside your primary ranges
  • Cloud provider fingerprints, which identify tenants and storage endpoints associated with your brand
  • Geographical asset mapping, which regularly surfaces infrastructure in regions the business did not realise it operated in

Then there is drift. An inventory that was accurate in March is routinely wrong by June, because deployment velocity does not pause for your audit cycle. Point-in-time discovery produces a document; continuous asset monitoring with change detection produces a signal when something new appears. For most mid-market estates, the practical answer is continuous discovery with alerting on new hosts, not a quarterly sweep.

Check 2: Prove Your Edge Services Are Patched, Not Just Listed as Patched

Internet-facing VPN and remote access appliances, managed file transfer platforms and business applications reachable from the public internet keep recurring in the incidents the NCSC categorises as most serious. The pattern is familiar: an advisory is published, the exploit follows within days, and the organisation that gets hit is usually the one that patched most of the fleet and missed the host nobody owned. ServiceNow instances exposed beyond their intended audience. PaperCut print servers answering on the public internet. The outlier is the problem.

Two scanning disciplines are needed, not one. Infrastructure scanning finds the unpatched appliance and the exposed service. Web application scanning finds the authentication flaw, the injection point and the misconfigured endpoint sitting on top of it. Run a single engine and you get a confident report about half the problem.

The side effect is volume. A few hundred external hosts can generate thousands of raw findings across both engines, much of it the same issue counted repeatedly. Deduplication across engines, plus automatic resolution of items that have already been fixed, is what turns that export into a short list of grouped remediation projects with an owner and a due date against each. If your team is still triaging line items individually, that is where the time is going, and it is worth reading up on the noise sources that quietly drain analyst capacity.

For each grouped project, keep four things: the version evidence before, the fix date, the retest result, and the sign-off. That short record is what proving a control works actually looks like.

Check 3: Look for Your Own Credentials and Stealer Logs Before Someone Else Buys Them

Identity-led intrusion is in the review's themes for a simple economic reason. A valid credential or a live session token is cheaper, quieter and more reliable than an exploit chain. No crash, no anomalous payload, just a successful login from somewhere plausible.

This material surfaces across criminal marketplaces, leak sites, closed forums and Telegram channels, with combolists recycled endlessly across old breaches. The reason teams monitor Telegram for leaked data is that it now functions as a distribution layer alongside traditional marketplaces, with channels reposting claimed breaches at speed. The nuance is validation. A large share of posted "breaches"are recycled, repackaged or simply fabricated, so the output you want is a verified match against your own domains and identities, not a raw alert count that looks alarming and means nothing.

Triage in this order:

  1. Corporate domain hits on current, active accounts
  2. Credentials reused on SSO and VPN entry points
  3. Privileged and administrative accounts
  4. Contractor and third party identities with access to your systems

The mistake that costs organisations the most is treating every hit the same. A combolist entry is an old password, probably already rotated. A stealer log is a different animal: it can carry session cookies, browser autofill data and host fingerprints taken from a currently infected machine. Reset the password and leave the session valid, and the intruder stays logged in. Reset the password and leave the device infected, and the next credential set leaks within the week. Make that distinction explicit in your process, because the response differs completely, and the coverage gaps in credential monitoring are usually where the live log hides. Where this ends up, if unanswered, is account takeover.

Check 4: Map Supplier Exposure the Way an Attacker Maps It

Third party routes keep appearing in the most serious incidents because they sidestep your controls entirely. The attacker does not need to beat your edge if a supplier already has trusted access through it.

A questionnaire reports intent. The external view reports state. You can check a supplier's public-facing posture without asking them anything: certificate hygiene and expiry, exposed admin panels and management interfaces, the technologies answering on their edge, accreditation status against Cyber Essentials, and their historical incident record. An expired certificate on a payment-adjacent service or a lapsed accreditation is evidence you can hold before contract renewal, and it reframes the discussion from paperwork to observable exposure.

Push one layer further to fourth party risk. Several of your vendors are frequently sitting on the same shared platform, the same remote management tool, the same hosting provider. One compromise there touches all of them at once, which is the mechanism behind incidents like the ConnectWise supply chain compromise and the vendor access it exposed.

Package what you find as a short validation summary per supplier: what is exposed, when it was observed, what you asked for, and whether it changed. Procurement can use that at renewal. They cannot use a scan export.

Check 5: Audit Executive, VIP and People Exposure

Senior staff exposure is an organisational risk wearing a personal disguise. The value is not the individual; it is the approval authority, the payment route and the credibility their name carries in an email.

Separate two things when you assess it. Internal identities belong in credential monitoring. External personal accounts, reused personal email addresses and public profile data belong in people exposure monitoring, handled discreetly and with the individual's awareness, because the sensitivities differ.

Then check impersonation. Lookalike domains and typosquats registered against your brand. Cloned social profiles using a stolen headshot, which reverse image search finds quickly. If you want a registrar or platform takedown to succeed first time, assemble the evidence pack properly: registration records, screenshots with timestamps, the trademark or brand evidence, and proof of the impersonated individual's genuine identity.

The common failure is scoping by job title. Teams monitor the C-suite and miss the finance approver who signs payments, the executive assistant with calendar and inbox access, and the HR lead who handles payroll changes. Attackers target function, not seniority.

Check 6: Test Whether Your Reporting Would Survive the Review's Own Standard

Apply the proof standard to your own reporting. A board-ready exposure report needs trend over time, risks grouped into projects rather than listed as findings, a named owner, a due date and closure evidence. If any of those five are missing, you have a status update, not evidence.

Give the evidence a home by mapping it to frameworks you already answer to: the Cyber Assessment Framework for essential services, Cyber Essentials and Cyber Essentials Plus for baseline controls, and existing UK GDPR breach reporting duties to the ICO's 72 hour notification requirement. The Cyber Security and Resilience Bill was still progressing through Parliament at the time of writing, so treat its requirements as direction of travel rather than settled obligation, and check the current position before building process around it. Full detail on the review itself sits with the National Cyber Security Centre.

Cadence decides whether any of this holds. An annual snapshot ages the moment a developer publishes a new subdomain. Continuous monitoring with change detection catches the drift between reviews, which is where the exposure accumulates.

Automation handles breadth. Human analysis handles the three questions automation struggles with: is this finding actually reachable, do you genuinely own the asset, and is it worth the remediation spend this quarter. Ownership verification matters especially when a national advisory sends you hunting, because discovery regularly turns up hosts belonging to a partner, an acquired entity or a shared hosting neighbour. Verify ownership before you monitor or scan, keep boundaries customer-controlled, and keep the assessment proportionate. Our approach to responsible external assessment sets out how those boundaries are drawn.

If you want to act on the NCSC Annual Review 2026 rather than file it, start with the first check and work outward. See what attackers can already see about your organisation, then decide what to fix first.

Frequently Asked Questions

What period does the NCSC Annual Review 2026 cover?

The tenth Annual Review, The State of the Cyber Nation, was published on 3 November 2026 and covers 1 September 2025 to 31 August 2026. Within that period the NCSC reports handling 1,831 reports of cyber incidents and providing support on 337 incidents, a portion of which were classed as nationally significant.

What does the NCSC Annual Review 2026 say about supply chain and third party risk?

Third party and supply chain routes remain one of the review's recurring themes, continuing to feature in the incidents treated as most serious. The practical implication for you is that supplier posture needs checking from the outside, not just through questionnaires, because public signals such as exposed management interfaces and certificate hygiene report actual state rather than stated intent.

How do I prove my security controls work rather than just listing them?

Produce evidence per asset, not per policy. For a given internet-facing host, keep the version or configuration evidence before the fix, the remediation date, the retest output confirming the issue is closed, and the sign-off. Group those records into remediation projects so the trail is readable, and map them to the Cyber Assessment Framework or Cyber Essentials controls you already report against.

Which checks should a mid-sized UK business run first after reading the review?

Start with discovery, because every other check depends on knowing what exists. Follow it with edge service verification on VPN, remote access and file transfer platforms, then credential and stealer log monitoring. Supplier, executive and reporting checks build on those three and are harder to do well without them.

How often should external exposure checks be repeated?

Discovery and change detection should be continuous, because new subdomains, cloud resources and certificates appear between review cycles. Vulnerability scanning on known external hosts benefits from a regular scheduled cadence with ad hoc rescans whenever a relevant advisory lands. Credential and Telegram monitoring only works as an always-on feed, since the window between a stealer log appearing and being used is short.