TL;DR: The EU Cyber Resilience Act’s September 2026 reporting obligation turns vulnerability disclosure into a 24-hour operational workflow, with early warning to ENISA and CSIRTs, full notification in 72 hours, and final reporting within 14 days, according to Cycode. The real problem is not paperwork but the detection, ownership, and evidence chain needed to file on time.
At a glance
What this is: Cycode’s analysis says the EU Cyber Resilience Act turns vulnerability disclosure into a 24-hour operational workflow with strict follow-on reporting deadlines.
Why it matters: This matters because IAM, product security, and GRC teams will need a named reporter, fast decision rights, and traceable evidence paths before the first real notification is due.
By the numbers:
- Manufacturers must submit an early warning within 24 hours of becoming aware of an actively exploited vulnerability or severe incident.
- Manufacturers must submit a full notification within 72 hours.
- Manufacturers must submit a final report within 14 days of a corrective measure becoming available.
- The article says serious breaches can carry fines up to €15 million or 2.5% of global turnover, whichever is higher.
Context
The EU Cyber Resilience Act adds a disclosure clock to product security, which is a different problem from general vulnerability management. Instead of only finding and fixing issues, manufacturers must prove they can detect, qualify, and report active exploitation quickly enough to meet legal deadlines. That shifts the question from technical hygiene to governed operational readiness, especially where product ownership, incident authority, and evidence collection are split across teams.
For IAM and security governance teams, the identity issue is who is authorised to make the reporting call and sign the submission, not just which system found the issue. The workflow has to work across products, suppliers, customer impact analysis, and weekend coverage, which is why many organisations underestimate the operational burden. Cycode’s framing is typical of teams that have strong tooling but have not yet rehearsed the disclosure path end to end.
Key questions
Q: What fails first when EU CRA reporting is not operationalised?
A: The first failure is usually ownership, not detection. Teams may spot a credible vulnerability signal, but without a named reporter, a backup, and a fast approval path, the 24-hour obligation becomes a coordination problem. The answer is to pre-assign decision rights and rehearse the path from signal to filing before September 2026.
Q: Why does the EU CRA create risk even when a product team has good security tooling?
A: Good tooling does not guarantee timely disclosure. The CRA ties legal compliance to how quickly teams can correlate a signal to products, versions, customers, and evidence, which means fragmented inventories and slow sign-off create risk even if detection is strong. The operational bottleneck is the workflow between tools, not the tools themselves.
Q: What are the signs that a vulnerability disclosure workflow is not ready for the EU CRA?
A: Common signs include no named filing owner, no timed tabletop, no measured path from detection to notification, and no clean inventory of EU-sold products and shared components. If teams have to ask around to identify scope or approvers, they are already outside the control boundary the CRA expects.
Q: Who should own CRA reporting and sign-off when a vulnerability is actively exploited?
A: Ownership should sit with a clearly designated security or product security lead, supported by a backup and an executive approver who can act under time pressure. Legal should advise, but the reporting decision itself needs a named operational owner so the filing can happen within the deadline.
Technical breakdown
How the EU CRA disclosure clock starts
The reporting clock starts when the manufacturer becomes aware of an actively exploited vulnerability or severe incident, not when triage is complete. That matters because “awareness” is intentionally earlier than certainty, so organisations cannot wait for full root-cause confirmation before starting the workflow. In practice, the first 24 hours are about qualification, scope, and evidence collection, while the 72-hour window expects a fuller technical picture and the final report closes the loop after corrective measures. The operational challenge is coordinating detection, product ownership, and legal sign-off under one timeline.
Practical implication: define the decision threshold for “awareness” before an incident does.
Why detection-to-disclosure is a workflow problem, not a filing problem
A compliant filing depends on upstream capabilities that most teams treat separately: threat intelligence ingestion, product inventory, vulnerability correlation, customer impact mapping, and approval routing. If those data points live in disconnected tools, the filing window shrinks before anyone starts writing the report. The article’s key insight is that the legal obligation exposes the maturity of the whole chain from signal to submission. That means the quality of the inventory, ownership metadata, and evidence trail is as important as the vulnerability scanner itself, because the report cannot be credible without it.
Practical implication: connect product inventory, ownership, and detection data into one operational chain.
How supply-chain context changes CRA reporting
The article makes clear that the trigger may come from first-party code, third-party dependencies, leaked secrets, CI/CD compromise, or AI-generated code. That broadens the reporting problem beyond classic CVE handling because teams must correlate multiple trust sources quickly enough to determine which products and versions are affected. In other words, the CRA turns software supply-chain visibility into a reporting control. Organisations that cannot trace findings from component to product to customer will struggle to produce a defensible notification, even if the technical fix is straightforward.
Practical implication: maintain product-to-component traceability that can survive a weekend incident.
Threat narrative
Attacker objective: The immediate objective is to exploit a product flaw before the manufacturer can complete a compliant 24-hour disclosure workflow.
- Entry occurs when an actively exploited vulnerability, leaked secret, third-party dependency issue, or CI/CD compromise is detected in a product sold into the EU.
- Escalation happens when the organisation must rapidly decide whether the signal qualifies as reportable, while product ownership and impact data are still being assembled.
- Impact is a missed or late early warning, followed by incomplete technical notification and weak evidence for regulator review.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- United Nations breach 2021: Sakura Samurai used exposed Git credentials to reach 100,000+ UNEP staff records, then reported the flaw through the UN disclosure programme.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
CRA readiness is now a governance test, not just a security test: the reporting obligation only looks simple until organisations have to name the reporter, define the approver, and prove the evidence path. The article shows that the real failure mode is ownership ambiguity under time pressure, which turns a legal deadline into an operating-model question. Practitioners should treat disclosure authority as part of security governance, not a side task.
Detection-to-disclosure is the new control surface for product security: many teams still measure detection and remediation separately, but the CRA ties them together with hard reporting deadlines. That creates a new named concept, detection-to-disclosure gap, where tooling may exist but the handoff from signal to submission is not measurable. The practical implication is that organisations need one audited workflow from first signal to filed notice.
The article exposes a product-inventory problem hidden inside a compliance problem: you cannot report quickly if you do not know which products, versions, dependencies, and customers are in scope. That is especially relevant where product lines share components or where AI features and third-party services blur the boundary of what is shipped. Practitioners should treat scope mapping as a prerequisite to reporting, not as a separate documentation exercise.
Supply-chain visibility now determines regulatory survivability: the CRA broadens the trigger surface to secrets, dependencies, CI/CD compromise, and AI-generated code, which means the disclosure workflow depends on how well software assets are connected to ownership and exposure context. This is where identity governance intersects with software governance, because the people and systems authorised to attest, sign, and submit must be traceable. The lesson for practitioners is to build a notification path that can survive fragmented tooling and fragmented accountability.
What this signals
detection-to-disclosure gap: the real control gap is the time between first credible signal and a defensible filing, not the vulnerability itself. Teams that cannot measure that interval will not know whether the 24-hour clock is achievable until the first real incident forces the test.
The broader signal for practitioners is that product security, supply-chain visibility, and disclosure governance are now one operating model. If product ownership, dependency traceability, and sign-off authority are fragmented, the organisation will likely miss the reporting window even when the underlying issue is understood quickly.
For practitioners
- Define the 24-hour reporting authority Name the primary reporter, backup reporter, and decision-maker for determining when an issue becomes an actively exploited vulnerability or severe incident.
- Measure the full detection-to-disclosure timeline Time the workflow from first credible signal to filed early warning, including customer impact mapping, evidence gathering, and sign-off.
- Map every EU-sold product to an owner Maintain a current inventory of products with digital elements, supported versions, shared components, and customer geography so notifications can be scoped quickly.
- Rehearse the reporting workflow under pressure Run a tabletop that starts with a Friday-evening exploitation signal and ends with a drafted 24-hour notification, then fix the delays it exposes.
- Correlate supply-chain signals to product impact Connect findings from dependencies, secrets, CI/CD, containers, and AI components to the affected product and version before the disclosure clock expires.
Key takeaways
- The EU CRA makes rapid reporting part of product security operations, which means disclosure readiness now matters as much as remediation speed.
- The hardest part is usually not writing the notification, but proving who owns the decision, what product is affected, and what evidence supports the filing.
- Organisations that rehearse the workflow, map product scope, and pre-authorise sign-off are better positioned to meet the 24-hour and 72-hour deadlines.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, NIST CSF 2.0 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The article links reporting urgency to exploited vulnerabilities and supply-chain compromise. |
| Recommendation — Map exploited-access scenarios to TA0006 and TA0008 when designing disclosure and containment workflows. | ||
| NIST CSF 2.0 | RS.CO-01 — Response Communications | CRA reporting is a regulated communications workflow under incident response. |
| ID.AM-01 — Physical devices and systems are inventoried | The article stresses accurate product and version inventory for scoping reports. | |
| GV.RR-01 — Roles, responsibilities, and authorities are established | The article makes clear that reporting depends on named decision-makers and backups. | |
| Recommendation — Build a documented response communications path that can support mandatory external notification. Maintain an authoritative inventory of products, versions, and ownership so notifications can be scoped quickly. Assign explicit reporting authority and escalation backups before the disclosure clock starts. | ||
| CIS Controls v8 | CIS-5 — Account Management | The workflow depends on accountable, designated people who can approve filings on time. |
| Recommendation — Tie CRA reporting responsibilities to named accounts and backups so on-call handoffs remain unambiguous. | ||
| ISO/IEC 27001:2022 | A.5.24 — Information security incident management planning and preparation | The article is fundamentally about preparing incident reporting processes before a deadline. |
| Recommendation — Document and test incident reporting procedures that can satisfy the CRA's mandatory timelines. | ||
Key terms
- Detection-to-Disclosure Gap: The interval between first credible awareness of an exploitable security issue and a compliant external notification. In regulated environments, this gap measures whether detection, triage, ownership, and evidence collection are integrated tightly enough to meet legal deadlines.
- 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.
- Reporting Authority: The person or role empowered to decide that a security signal qualifies for formal notification and to sign the submission. Good governance makes this authority explicit, because ambiguity at this point is one of the most common causes of late or incomplete filings.
- Control-to-Asset Mapping: Control-to-asset mapping is the practice of linking a rule or requirement to the specific dataset, report, model, or use case it governs. Without that connection, teams can observe activity but cannot prove that the control applied to the right thing at the right time.
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 designed for practitioners who need to connect identity governance to wider security operations and control decisions.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org