EU cyber resilience act reporting now forces faster vulnerability disclosure

At a glance

What this is: NHI Mgmt Group's analysis, drawing on FOSSA's blog post: The EU Cyber Resilience Act's reporting duty is now live for actively exploited vulnerabilities and severe incidents affecting products on the EU market.

Why it matters: This matters because product security, vulnerability management and customer communications now have a hard reporting clock that affects software, hardware and the remote services they depend on.

Context

The core governance problem is no longer whether product vulnerabilities will be disclosed eventually, but when the disclosure clock starts and which evidence is enough to trigger it. The Cyber Resilience Act creates an operational reporting duty for products with digital elements, including products already on the market, so security, legal and product teams have to treat vulnerability awareness as a regulated event rather than an internal triage outcome.

That changes the way organisations manage product security evidence, incident classification and customer notification. The article also reaches into identity governance because reporting, authentication and filing responsibilities now depend on controlled access to a single reporting channel, role assignment and documented accountability across the manufacturer organisation.

Key questions

Q: What breaks when CRA reporting depends on manual coordination?

A: Manual coordination breaks the CRA model because the regulation compresses discovery, escalation, and notification into a 24-hour window. If teams need spreadsheets, email chains, or ad hoc ownership decisions to identify the affected product, they will miss the clock before they can even classify the issue.

Q: Why does a vulnerability become reportable under the Cyber Resilience Act?

A: A vulnerability becomes reportable when there is reliable evidence that it has been actively exploited, or when a severe incident affects the product’s ability to protect confidentiality, integrity, authenticity or availability. The trigger is evidence and impact, not the existence of a CVE or a theoretical weakness.

Q: What do product teams get wrong about CRA notification deadlines?

A: They often treat the reporting timeline as a documentation task instead of an incident workflow. The clock starts when the organisation becomes aware of the event, not when investigation is complete, so teams need a fast triage path that can produce an early warning, a fuller notification and a final report.

Q: Who is accountable for CRA reporting when multiple entities sell the same product?

A: Accountability should sit with the manufacturer of record or the entity treated as the manufacturer under the CRA, but internal responsibility still has to be assigned explicitly. Organisations with importers, distributors or open-source stewards in the chain need a clear decision model so one submission is made through the correct establishment and authority path.

Technical breakdown

What counts as an actively exploited vulnerability under the CRA?

The CRA uses a narrow threshold: there must be reliable evidence that a malicious actor exploited a vulnerability without the system owner’s permission. That is not the same as a CVE being published, a scanner flagging a weakness, or a lab proof-of-concept existing. Teams therefore need a production-context judgment, not just a code-level finding. The important distinction is between theoretical exposure and evidence of real-world exploitation in the affected product context. Practical implication: build a validation process that distinguishes exploitable in production from merely known in the abstract.

Practical implication: validate exploitability in the deployed product before starting the reporting clock.

Why the CRA reporting duty is separate from SBOM and coordinated disclosure

The September 2026 duty is only the reporting obligation. SBOM production, coordinated vulnerability disclosure programmes and broader conformity obligations arrive later, which means teams cannot wait for the 2027 regime to organise their response workflow. This is a common regulatory pattern: reporting obligations often arrive before the full compliance stack, forcing organisations to separate notification readiness from longer-term product security maturity. Practical implication: treat reporting intake, triage and filing as a standalone control layer that can operate before the rest of the CRA programme matures.

Practical implication: separate reporting readiness from longer-term CRA implementation workstreams.

How ENISA’s Single Reporting Platform changes submission control

The reporting path is centralised through ENISA’s Single Reporting Platform, with the coordinating CSIRT and ENISA receiving the notification simultaneously. That matters because the obligation is not satisfied by email, a national portal, or informal regulator contact. It also introduces a governance requirement around who can file, which manufacturer entity is responsible, and how access is validated. In identity terms, this is a role-controlled filing process with regulated access and auditable submission ownership. Practical implication: assign filing authority explicitly and test the reporting workflow before an actual event occurs.

Practical implication: pre-assign filing authority and verify the controlled submission path end to end.

NHI Mgmt Group analysis

CRA reporting turns vulnerability disclosure into a governed operational control. The article shows that reporting is now time-bound, event-driven and mandatory for products already in market. That means disclosure readiness sits alongside detection, triage and customer notification as a core security process. For product organisations, the real governance question is whether evidence, decision rights and filing paths are already mapped before the first reportable event.

Disclosure timing is now a compliance boundary, not just a communication choice. The 24-hour, 72-hour and final report stages create a measurable escalation path that teams must be able to execute under pressure. The practical failure mode is not only poor security telemetry, but also unclear ownership over when an event becomes reportable. Practitioners should treat reportability assessment as part of incident classification, with legal, product and security aligned on triggers.

Identity and access control now shape regulatory execution. Filing through a single reporting platform is not only a process issue, it is an access-governance issue. If only a few people can authenticate, validate and submit under deadline, the organisation’s reporting resilience depends on role design, backup coverage and auditable delegation. Teams should make reporting access part of operational identity governance, not an informal duty assignment.

Regulated vulnerability disclosure is becoming a lifecycle expectation for product security programmes. The CRA’s early reporting duty pushes manufacturers to think beyond release security and into post-market security operations. That is a stronger model for the market, because it forces continuous awareness of in-use products, not just pre-release controls. Practitioners should assume that product security now includes downstream reporting, user notice and evidence retention as standard obligations.

Reporting programmes will separate mature product security teams from reactive ones. The organisations that perform well will be the ones that can correlate exploit evidence, product inventory, customer exposure and filing readiness quickly. That requires an operational governance model, not just a compliance checklist. Teams should use the CRA to stress-test whether security, legal and product functions can act as one reporting unit when a severe event appears.

From our research library:

• The 2026 Verizon DBIR found that exploitation of software vulnerabilities became the leading initial access vector in confirmed breaches, accounting for 31% of incidents.
• Read next: Identity Security Regulatory Map

What this signals

Product security teams now need a reportability operating model. The CRA makes vulnerability disclosure time-bound, which means incident classification, evidence capture and filing authority have to be designed together. Organisations that still treat disclosure as an after-the-fact legal review will struggle to meet the 24-hour and 72-hour thresholds when the clock starts.

Regulatory readiness depends on identity governance as much as security telemetry. The Single Reporting Platform introduces a controlled submission path, so access assignment, backup authority and auditable delegation become part of the compliance surface. Teams should test who can file, who can validate and who can step in if the primary filer is unavailable.

Reportability triage is becoming a named control gap. The new pressure is not just vulnerability discovery, but deciding quickly whether evidence reaches the threshold for a reportable exploit or severe incident. Practitioners should build a decision tree that ties product inventory, exploit evidence and customer notification into one workflow.

For practitioners

• Define the reportability decision tree Map what qualifies as an actively exploited vulnerability versus a severe security incident, and document who makes the call when evidence is incomplete.
• Pre-register filing roles and backups Assign Primary AR and Secondary AR coverage, and verify the EU Login and multi-factor authentication path before an incident forces submission.
• Inventory in-scope products already on market Maintain a live list of products with digital elements that are already available in the EU, including older releases and support-end products.
• Test the 24-hour and 72-hour evidence workflow Run a tabletop that exercises early warning, notification and final report drafting so teams can assemble the required facts inside the deadline.
• Prepare user-notification language in advance Draft plain-language and machine-readable mitigation notices so customers can act quickly when a reportable vulnerability or severe incident occurs.

Key takeaways

• The CRA’s early reporting duty changes product security from a release-time concern into a live operational obligation.
• The main challenge is not only discovering vulnerabilities, but proving whether they are actively exploited in the product context.
• Teams that can align evidence, submission authority and customer notice will handle the new reporting regime more reliably.

Key terms

• Known Exploited Vulnerability: A Known Exploited Vulnerability is a flaw that has confirmed active exploitation in the wild and is tracked for urgent remediation. In governance terms, KEV status turns patching from a general hygiene task into a time-bound operational obligation.
• Severe Security Incident: An incident that can negatively affect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions, or that can introduce malicious code into a product or user environment. Under the CRA, it is a distinct reporting trigger from an exploited vulnerability.
• Single Reporting Platform: ENISA’s central portal for mandatory CRA notifications. It channels manufacturer submissions to the coordinating CSIRT and ENISA at the same time, which makes the reporting process a governed workflow rather than a local or informal notification path.
• Assigned Representative: A person authorised to file a CRA notification on behalf of a manufacturer. The role combines identity, delegation, and accountability, so it should be governed like privileged access with strong authentication, clear scope, and an auditable submission trail.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is suited to practitioners who need to connect access governance, lifecycle control and operational accountability across security programmes.