They should rapidly confirm product scope, assess reachability, document the decision, and determine whether the finding triggers the CRA notification duty to ENISA. The key is to contain uncertainty before it becomes a reporting and customer-communication problem.
How manufacturers should react when exploitation is confirmed
When a supported product is actively exploited, the first task is to narrow the problem fast enough to make the reporting decision reliable. Confirm exactly which product line, build range, deployment mode, and customer segments are in scope, then test whether the vulnerability is actually reachable in the field. That reachability check is what turns a vague issue into a defensible operational judgment.
A product team should treat this as both a technical and communications event. If the issue is reachable, or if reachability is still uncertain but plausible, the manufacturer should move into a structured incident workflow that preserves evidence, tracks decisions, and prepares customer-facing guidance in parallel with engineering triage. The goal is to avoid letting uncertainty linger until it becomes a disclosure failure.
This is where a current vulnerability management process matters. The NIST Cybersecurity Framework 2.0 and the CIS Controls v8 both support the basic discipline of identifying exposure, tracking vulnerable assets, and responding consistently once exploitation is credible.
What “reachability” and “scope” should mean in practice
Scope is not just the product name on the cover page. Manufacturers need to determine whether the vulnerable function is enabled, exposed to external traffic, reachable through a local network boundary, or only present in a bundled component that customers cannot invoke. A supported product can still be out of practical scope for some deployments if the vulnerable path is absent or effectively isolated.
That same check should also cover product variants, embedded distributions, cloud-managed versions, and OEM or partner-delivered builds. If the vulnerability sits in a shared component, the manufacturer should assume that multiple downstream products may be affected until proven otherwise. The fastest safe assumption is usually broader than the final confirmed scope.
For prioritisation, manufacturers should compare the issue against public exploitation signals rather than treating every report the same way. The CISA Known Exploited Vulnerabilities Catalog is the clearest external signal when CISA has already confirmed active exploitation, while the FIRST EPSS model can help teams judge whether rapid exploitation is likely even before operational confirmation is complete.
How to document the notification decision without slowing response
The notification question should be answered with a written record, not informal consensus. Manufacturers should log when they first learned of the exploit activity, what evidence they reviewed, what product scope they confirmed, whether the vulnerability was reachable, and why they concluded the matter did or did not trigger the CRA notification duty to ENISA. That record matters even if the answer is “not yet,” because the decision may need to be revisited as facts change.
Good documentation also separates what is known from what is assumed. If you have not verified exposure in all supported versions, say so. If remediation is not yet available, say whether a mitigation exists and whether it is operationally practical for customers. A clean record is often the difference between a defensible regulatory decision and a weak post-incident explanation.
Manufacturers should align their process with the broader CRA disclosure model. The EU Cyber Resilience Act is the key regulatory reference for products with digital elements, and the CRA guide on CRA vulnerability reporting is useful where the question is not just whether to fix, but whether the fix triggers a formal reporting obligation.
Risk and Threat Considerations
Actively exploited vulnerabilities create a dual problem: real compromise risk and a fast-moving disclosure obligation. If the manufacturer cannot prove scope quickly, customers may remain exposed while the reporting clock, customer notification expectations, and incident handling timeline are already moving.
Failure mechanism: Attackers exploit the vulnerable path before the manufacturer has validated where it exists, then use that ambiguity to prolong exposure across supported deployments, especially when product variants, managed services, or embedded builds are hard to inventory.
Impact: Delayed scope confirmation can lead to missed containment actions, inconsistent customer advice, and a late or incomplete CRA notification decision. In the worst case, the organisation learns too slowly that a supported product is already part of a broader compromise pattern.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 and EU Cyber Resilience Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Actively exploited flaws require fast asset scope and exposure validation. |
| Recommendation — Prioritise and track exposed vulnerable assets until risk is reduced. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset Vulnerabilities Are Identified and Prioritised | The answer centers on confirming scope and reachability before notification decisions. |
| RS.MA-01 — Response Plan Is Executed | Exploited vulnerabilities require coordinated containment and decision logging. | |
| Recommendation — Identify the vulnerable product scope and prioritise the affected assets. Execute the incident response plan and document response actions. | ||
| ISO/IEC 27001:2022 | A.5.25 — Assessment and Decision on Information Security Events | The question requires a documented judgment on whether the event triggers reporting. |
| Recommendation — Assess the event and record the decision basis before escalation. | ||
| EU Cyber Resilience Act | UNKNOWN — Vulnerability reporting obligation | The topic is whether an exploited product flaw triggers the CRA notification duty. |
| Recommendation — Determine whether the vulnerability meets the CRA reporting trigger and notify when required. | ||
Practitioner Guidance
What to prioritise: Confirm whether the vulnerable function is actually reachable in supported deployments before debating patch messaging. If you cannot prove non-reachability, treat the issue as operationally live and prepare customer guidance accordingly.
What to verify: Keep a decision record that shows product scope, evidence reviewed, mitigation status, and the exact reason the CRA notification threshold was or was not met. That record should be specific enough for legal, product security, and support teams to use without reinterpretation.
Decision rule: If the exploit is confirmed and the vulnerable path is reachable in a supported product, move from investigation to coordinated response immediately, even if the final notification analysis is still underway. Do not wait for perfect certainty before starting containment and customer communications.
Practitioner takeaway: The critical skill is not speed alone, but disciplined speed, prove scope fast, preserve the reasoning, and make the notification decision from evidence rather than from pressure.
Related resources from NHI Mgmt Group
- How should product teams prepare for Cyber Resilience Act reporting when a vulnerability is actively exploited in the wild?
- How should TPRM teams respond when a critical vulnerability is actively exploited in a supplier product?
- What is the difference between patching a vulnerability and reducing identity blast radius?
- Who is accountable when an actively exploited SharePoint vulnerability exposes regulated data or disrupts essential services?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 21, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org