Can You Answer “Are We Exposed to Anything on the KEV List?” From Your Azure Architecture — in Minutes?

In a single week, CISA added six vulnerabilities to its Known Exploited Vulnerabilities catalogue across two separate updates — products including PTC Windchill, Cisco Unified Communications Manager, Lantronix and Ubiquiti devices, each added on the same evidentiary basis: confirmed active exploitation in the wild. The KEV catalogue is not a list of theoretical risks. It is the subset that attackers are using now. And the operational question it puts to every regulated Azure environment is uncomfortably simple: when two new entries land mid-week, how long does it take you to answer whether you are exposed to either?

For most organisations the honest answer is “a few days, if someone drops what they are doing.” That gap — between a vulnerability becoming known-exploited and your ability to determine your own exposure — is exactly what NIS2 Article 21 means by vulnerability handling. The directive does not ask whether you patch eventually. It asks whether you have a functioning capability to know, quickly, what you are running and where it is exposed.

Key takeaways

• The CISA KEV catalogue lists vulnerabilities with confirmed active exploitation. Two updates in one week is normal cadence, not an anomaly — exposure assessment cannot be a quarterly exercise.
• NIS2 Article 21 requires vulnerability handling as an ongoing capability: knowing what you run, knowing where it is exposed, and being able to act — not a periodic patch cycle.
• The binding constraint is rarely patching. It is visibility: can you map a newly-listed CVE to your actual Azure footprint and its exposure in minutes, or does it take a manual hunt across subscriptions?
• Exposure is an architecture property, not just a resource property. The same CVE on an internet-facing component behind no segmentation is a different incident from the same CVE on an internal component behind a firewall — and your architecture documentation is what tells you which you have.
• The defensible position is an environment whose architecture you can query against a moving threat list — and the evidence trail that proves you did.

Why the KEV catalogue is the right list to measure yourself against

There are more vulnerability feeds than any team can act on, and treating all of them as equally urgent is how vulnerability handling collapses into noise. The KEV catalogue solves the prioritisation problem by inclusion criteria: a CVE only lands on it when there is reliable evidence of active exploitation. That makes it the shortlist that matters — not what could be attacked, but what is being attacked.

The cadence is the point most teams underweight. Entries are added as exploitation is confirmed, which means the list moves continuously — twice in the week these examples are drawn from, and that is unremarkable. A vulnerability-handling process tuned to a monthly or quarterly review is structurally behind a list that updates weekly. By the time your scheduled review comes around, an actively-exploited CVE may have been on the list, and in your environment, for three weeks.

This is why “are we exposed to anything on the KEV list” has to be a question you can answer on demand, not on a calendar. The threat list does not wait for your review cycle.

What NIS2 Article 21 means by vulnerability handling

NIS2 Article 21(2) requires measures for “vulnerability handling and disclosure” among its ten control categories. The phrasing is deliberately outcome-based rather than prescriptive — it does not mandate a specific tool or patch SLA. What it requires is a capability: that your organisation can identify vulnerabilities affecting its systems, assess its exposure, and act, as an ongoing function.

The trap is reading “vulnerability handling” as “we run a scanner and patch on Patch Tuesday.” Scanning is part of it. But a supervisor evaluating the capability under the Cyberbeveiligingswet is asking something broader: when a vulnerability with known exploitation appears, can you determine whether it affects you, how exposed you are, and what you did about it — and can you evidence that the process functioned? That is a question about visibility and decision-making, not just about a patch pipeline. (For the full Article 21 control set this sits within, see the NIS2 Article 21 Azure controls.)

The organisations that struggle with this finding in an audit are rarely the ones that patch slowly. They are the ones that cannot quickly say what they run and where it is exposed — because the exposure answer is scattered across subscriptions, resource groups, and the memories of whoever built each workload. Vulnerability handling sits directly alongside supply-chain security in Article 21, and a large share of your exposure arrives through dependencies you did not write — the Entra ID app, service-principal, and SBOM dimension is covered separately.

Exposure is an architecture question, not just a resource question

Here is the distinction that turns vulnerability handling from a patching task into an architecture one. The same CVE is not the same incident depending on where it sits in your design.

A known-exploited remote code execution vulnerability in a component that is internet-facing, behind no segmentation, with a broad identity attached, is an emergency. The identical vulnerability in a component that is internal-only, behind a firewall, on a segmented network, with a least-privilege managed identity, is a managed risk you can schedule. The CVE is the same. The exposure — the thing that actually determines urgency — is a property of your architecture: the segmentation, the network reachability, the blast radius if it is compromised.

A resource-level vulnerability scanner tells you the CVE is present. It does not, on its own, tell you which of those two situations you are in, because that answer lives in the relationships between components — the architecture — not in the resource itself. Which means answering “how exposed are we” quickly depends on having your architecture documented and queryable, not just your resources scanned. If your segmentation model and reachability are only in someone’s head, every KEV update triggers a manual reconstruction of facts that should have been written down.

The minutes-versus-days gap, and how to close it

Run the exercise honestly. The next time CISA adds an actively-exploited CVE in a product you might run, time how long it takes to answer three questions: Do we run this anywhere in Azure? Where, and how is it exposed? What is the blast radius if it is compromised before we remediate? For most teams the first question takes hours of cross-subscription hunting, the second requires tracking down whoever built the workload, and the third is a guess.

Closing that gap is an architecture-visibility problem. It requires that your Azure footprint and its design are captured as structured, current evidence — what runs where, how it is segmented, what each component’s exposure and blast radius are — so that a new entry on a moving threat list can be checked against a known map rather than reconstructed from scratch each time. The environments that answer in minutes are not the ones with faster engineers. They are the ones whose architecture was documented and kept current, so the exposure answer already exists and only needs to be queried.

This is where the assessment layer earns its place. Platform Architecture Authority (PAA) reads your Azure environment through Resource Graph and produces a structured, current map of your architecture — components, segmentation, exposure, and blast radius — mapped to the Well-Architected Framework and to NIS2, DORA, and ISO 27001 Annex A. When a KEV entry lands, that map is what turns “are we exposed” from a days-long hunt into a query against documentation you already have, and it generates the evidence trail that demonstrates your vulnerability-handling capability functioned. PAA does not patch the vulnerability or replace your scanner or your SecOps judgment — it makes sure the architectural exposure picture those people need exists before the threat list moves, not after. PAA is read-only.

FAQ

What is the CISA KEV catalogue and why does it matter for NIS2? It is CISA’s list of vulnerabilities with confirmed active exploitation — the subset attackers are actually using. It matters for NIS2 because Article 21 requires vulnerability handling as an ongoing capability, and the KEV list is the highest-priority, continuously-updated input to that capability. A process that cannot keep pace with it is structurally behind the threat.

Doesn’t a vulnerability scanner already cover this? Partly. A scanner tells you a CVE is present on a resource. It does not, on its own, tell you your architectural exposure — whether the affected component is internet-facing or segmented, what its blast radius is — which is what actually determines urgency. Exposure is a property of the architecture, so answering “how exposed are we” quickly needs the design documented and queryable, not just the resources scanned.

How fast does NIS2 expect us to respond to a known-exploited vulnerability? Article 21 is outcome-based and does not set a fixed patch SLA. What a supervisor evaluates is whether the capability functions: can you identify exposure, decide, and act as an ongoing process, and can you evidence it. The practical bar is being able to determine exposure quickly enough to act before exploitation, which the weekly cadence of the KEV list makes a matter of minutes-to-hours, not weeks.

Why is exposure an architecture question? Because the same CVE is a different incident depending on where it sits in your design. Internet-facing with no segmentation versus internal behind a firewall with least privilege — same vulnerability, completely different urgency. That difference lives in the relationships between components, which is architecture, not in the resource the scanner flags.

The test is concrete and worth running before an examiner runs it for you: pick the most recent actively-exploited CVE in a product you might be running, and time how long it takes to prove whether you are exposed. If the answer is “longer than a coffee break,” the gap is not in your patching. It is in whether your architecture can be queried at all.