Notifications
Clear all
Topic starter
18/08/2026 2:18 pm
TL;DR: Europe’s Cyber Resilience Act shifts the real compliance burden to September 11, 2026, when mandatory vulnerability and incident reporting begins for products with digital elements, according to ArmorCode. The practical challenge is not policy drafting but building continuous visibility, exploit awareness, and an auditable disclosure workflow before the first clock starts.
NHIMG editorial — based on content published by ArmorCode: EU Cyber Resilience Act News Today, Your 2026 Compliance Summary Blog
By the numbers:
- The European Cyber Resilience Act enters full application on December 11, 2027, but mandatory vulnerability reporting starts on September 11, 2026.
- Manufacturers have 24 hours to submit an early warning after learning a product vulnerability is actively exploited, followed by a 72-hour notification and a 14-day final report after remediation.
Questions worth separating out
Q: What breaks when organisations treat CRA compliance as a 2027 problem?
A: They miss the 2026 reporting deadline, which is the first enforceable checkpoint.
A: Because the CRA is not a single compliance switch.
Q: How do organisations know whether CRA readiness is actually working?
A: They should look for complete product inventories, named control owners, evidence of secure defaults, tracked vulnerability remediation, and repeatable reporting to leadership.
Practitioner guidance
- Build exploit-state classification into vulnerability triage Separate theoretical exposure from actively exploited vulnerabilities and route only the latter into the CRA reporting workflow.
- Map product lineage to component inventories Maintain product-level traceability from shipped release to dependent libraries, containers, and embedded components.
- Instrument disclosure workflows with immutable timestamps Record when the organisation first knew exploitation was active, who approved each notification step, and what remediation evidence supported the final report.
What's in the full article
ArmorCode's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step breakdown of the CRA Notification Status workflow from early warning to final report
- How ArmorCode models PDE classes and exploit status across product lifecycles
- The specific evidence fields used to support remediation and reporting timelines
- Operational examples of how the platform calculates due dates from confirmed exploitation
👉 Read ArmorCode's summary of Cyber Resilience Act reporting deadlines and workflows →
EU Cyber Resilience Act reporting in 2026: are teams ready?
Explore further
18/08/2026 3:11 pm
CRA readiness is now a runtime governance problem, not a compliance calendar problem. The September 2026 reporting date forces teams to prove they can detect and classify active exploitation before the broader 2027 obligations arrive. That shifts the discipline from document preparation to continuous operational evidence. For practitioners, the question is no longer whether the policy exists, but whether the reporting chain can survive a live incident.
A question worth separating out:
Q: Who is accountable when a vulnerability report misses an exploitable issue?
A: Accountability sits with the programme owner who accepted the testing model and closure criteria, not only with the tester. If the organisation chose snapshots over continuous validation, the control gap is governance-led. Security leaders, application owners, and risk owners all need clear closure standards and evidence requirements.
👉 Read our full editorial: EU Cyber Resilience Act reporting is a 2026 readiness problem
