EU cyber resilience act reporting now forces faster vulnerability disclosure

At a glance

What this is: FOSSA explains that the CRA’s first live obligation is a mandatory reporting regime for exploited vulnerabilities and severe incidents, with filing now required through ENISA’s Single Reporting Platform.

Why it matters: This matters because product security, release governance, and identity-controlled filing workflows now need to support regulator-facing evidence collection and user notification on compressed timelines.

👉 Read FOSSA’s full guide to the EU Cyber Resilience Act reporting requirements

Context

The EU Cyber Resilience Act turns vulnerability reporting into an operational control, not just a legal note. For product teams, the immediate challenge is not whether a flaw exists, but whether evidence of exploitation, incident scope, and user impact can be captured fast enough to meet the 24-hour and 72-hour clocks. In an environment where filing depends on who owns the product, who can submit, and what the evidence chain looks like, identity and access controls become part of the compliance path.

This is especially relevant for manufacturers with distributed development, outsourced support, and cross-border filing responsibilities. The reporting duty reaches products already on the market, so mature teams cannot treat it as a new-product-only issue. The governance burden is to align security monitoring, legal triage, and authorised reporting roles before the first event is discovered, which is a familiar pattern for mature programmes but atypical for organisations still separating security operations from regulatory response.

Key questions

Q: What should teams do first when a CRA reportable vulnerability is discovered?

A: Teams should immediately preserve evidence, timestamp awareness, and decide whether the issue is an actively exploited vulnerability, a severe incident, or both. Then they should route the case to the authorised filing path, because the first 24 hours determine whether the organisation can meet the early-warning obligation and maintain a defensible record.

Q: Why do product security issues create regulatory risk under the CRA?

A: Because the CRA turns technical findings into timed obligations. Once a vulnerability is actively exploited or an incident is severe, manufacturers must disclose it through ENISA’s platform and inform users. The risk is not only the flaw itself, but whether the organisation can classify it, file it, and document the response correctly.

Q: What breaks when filing authority is not pre-assigned for CRA reporting?

A: Reporting becomes slow, ambiguous, and vulnerable to internal bottlenecks. Without named authority, teams waste time deciding who can file, which entity owns the event, and whether the right Member State coordinator is involved. That delay can cause missed deadlines and produce an incomplete regulatory trail.

Q: Who is accountable for CRA reporting in a multi-entity organisation?

A: Accountability sits with the manufacturer of the product as placed on the EU market, but the operational filing path may involve assigned representatives, importers, distributors, or open source stewards in limited cases. Organisations need a documented internal owner so the legal obligation and the filing action line up before an incident occurs.

Technical breakdown

How CRA Article 14 reporting works in practice

Article 14 creates a three-stage disclosure workflow: early warning, 72-hour notification, and final report. The trigger is either an actively exploited vulnerability or a severe security incident, and those are assessed separately. That matters because not every exploited flaw produces the same reporting path, and not every severe incident depends on a confirmed vulnerability. The clock starts when the manufacturer becomes aware of the event, not when investigation ends. Practical implication: teams need a triage model that preserves timestamps, evidence, and decision ownership from first detection.

Practical implication: Map detection, legal review, and filing ownership to a single incident workflow before an event begins.

Why the Single Reporting Platform changes governance

ENISA’s Single Reporting Platform centralises reporting, but it does not remove internal coordination complexity. Manufacturers still need the right entity to file, the correct Assigned Representative to act, and the appropriate CSIRT coordinator for their Member State of main establishment. The platform also uses a phased information model, so data quality must evolve from a minimal alert into a structured incident package. Practical implication: the reporting path should be pre-authorised, identity-controlled, and tested like any other regulated disclosure process.

Practical implication: Pre-register filing roles and validate who can submit before a real incident creates time pressure.

Why product security and identity control are now linked

The CRA does not just ask whether a vulnerability exists. It asks whether the organisation can identify who is allowed to submit, prove that an issue was discovered in time, notify users, and preserve accountability across entities and Member States. That makes access control, delegated authority, and evidence integrity part of the compliance mechanism. For teams already managing non-human identities in build, release, and monitoring systems, the lesson is straightforward: the reporting chain depends on controlled identities as much as on technical remediation. Practical implication: treat filing authority as a privileged workflow.

Practical implication: Restrict filing privileges to named roles and align them with PAM-style approval and audit controls.

Threat narrative

Attacker objective: The objective is to exploit product weakness or incident ambiguity long enough to disrupt users, force disclosure, and expand downstream regulatory and operational damage.

1. Entry occurs when an actively exploited vulnerability, compromised build pipeline, or malicious update path creates a reportable security event in a product with digital elements.
2. Escalation happens when the manufacturer must determine scope, decide whether the event meets Article 14 thresholds, and coordinate filing through the correct legal and operational entities.
3. Impact is regulatory and operational. Delayed or incomplete reporting can weaken the organisation’s record, frustrate user mitigation, and create enforcement exposure once full CRA penalties apply.

NHI Mgmt Group analysis

Reporting deadlines expose the weakness of traditional split ownership. Many product organisations still separate engineering, security operations, and regulatory response into different chains of command. CRA Article 14 collapses those separations by making awareness, assessment, and filing time-bound obligations that depend on one coordinated workflow. That makes governance design, not just vulnerability detection, the real control question for product teams.

Privileged filing is now part of the security programme. The person who can submit a report on behalf of the manufacturer holds a compliance-sensitive authority that should be governed like a privileged account. Identity proofing, strong authentication, delegated approval, and auditability all matter here because the regulatory record starts with the filing identity. Teams that ignore this will struggle when regulators review who knew what, when, and who was authorised to act.

Article 14 makes disclosure a lifecycle control, not a one-off legal event. The obligation applies to products already on the market and persists even after support ends, which means governance cannot stop at release. The named concept here is compliance-aware product lifecycle control: the ability to preserve evidence, ownership, and reporting readiness across product age, support state, and market exposure. That is the standard manufacturers must now operationalise.

The CRA rewards organisations that can convert technical signals into regulatory decisions. The real differentiator is not whether scanners find issues, but whether teams can decide quickly whether a finding is actively exploited, severe, or neither. That requires playbooks, escalation paths, and evidence standards that bridge engineering and legal functions. The practitioners who succeed will be the ones who treat incident classification as a governed operational discipline.

Identity governance now reaches beyond workforce access into regulated disclosure paths. Where a report can only be filed by an authorised representative, the access model itself becomes part of the compliance posture. That intersection matters for IAM and PAM teams because it extends least-privilege thinking into external-facing reporting duties. Practitioners should expect more controls around who can speak for the organisation in a security event.

What this signals

Compliance reporting now depends on identity discipline as much as vulnerability detection. Organisations that already control non-human and privileged workflows will adapt faster because they have a cleaner model for delegated authority, audit trails, and time-bounded action. That same control logic is relevant to filing roles, especially where one authorised representative must speak for multiple entities or jurisdictions.

Compliance-aware product lifecycle control will become a durable operating concept for manufacturers that sell into regulated markets. The practical shift is from ad hoc incident response to pre-built disclosure pathways that connect scanners, case management, legal review, and submission authority. Teams should align that workflow with established control sets such as NIST SP 800-53 Rev 5 Security and Privacy Controls and formal access governance.

The broader signal is that disclosure itself is becoming a governed asset. The organisations that treat reporting as a privileged workflow will be better positioned when other regimes begin to demand similar evidence, timelines, and user notice standards. That is where product security, IAM, and legal operations converge into one control surface.

For practitioners

• Create a CRA reporting decision tree Define who decides whether an event is an actively exploited vulnerability or a severe incident, and record the evidence required at each stage.
• Pre-authorise filing identities and approvals Map Primary AR and Secondary AR responsibilities, enforce multi-factor authentication, and keep a tested backup path for submission if the primary filer is unavailable.
• Align detection outputs to reportable fields Ensure scanners, incident tooling, and case management capture product name, version, awareness time, corrective measures, and user mitigations in a form usable for the SRP.
• Treat user notification as part of the incident workflow Prepare a process for informing impacted users in structured, machine-readable form where appropriate, so mitigation advice can move quickly after filing.
• Test cross-entity filing ownership Verify which legal entity files, which Member State coordinator applies, and how the organisation avoids duplicate or missed notifications across subsidiaries.

Key takeaways

• The CRA’s September 2026 obligation makes vulnerability disclosure an active operational duty, not a later compliance cleanup exercise.
• The reporting path depends on who is authorised to act, which means identity and privileged access controls are now part of the compliance design.
• Teams that pre-build evidence, ownership, and filing workflows will be better positioned when regulators review the record of discovery and response.

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.

What's in the full article

FOSSA's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step interpretation of Article 14 triggers for actively exploited vulnerabilities and severe incidents
• Submission workflow details for ENISA’s Single Reporting Platform, including the role of Assigned Representatives
• Field-by-field breakdown of the 24-hour, 72-hour, and final reporting stages
• Practical notes on how to inform impacted users and when machine-readable notices are appropriate

👉 FOSSA’s full article covers the reporting workflow, deadlines, and filing details in operational depth

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management in operational terms. It helps practitioners connect privileged workflows, auditability, and controlled access across security and compliance programmes.