Notifications
Clear all
Topic starter
19/08/2026 3:26 pm
TL;DR: EU Cyber Resilience Act compliance is already a 2026 operational problem because the 24-hour exploited-vulnerability reporting window starts in September 2026, while full obligations arrive in 2027, according to ArmorCode. The post says fragmented triage, SBOM snapshots, and manual escalation will not satisfy continuous, auditable response; the pressure is on governance, not just scanning speed.
NHIMG editorial — based on content published by ArmorCode: Cyber Resilience Act Compliance: From Regulatory Pressure to Operational Excellence
Questions worth separating out
Q: What breaks when CRA compliance is managed with separate security tools and teams?
A: Fragmented tooling breaks the compliance chain because no single team can prove what was found, who owned it, what was decided, and whether remediation was completed.
Q: Why do software teams need continuous vulnerability handling for CRA readiness?
A: Continuous handling is needed because vulnerability risk changes faster than periodic review cycles can keep up with.
Q: How do security teams know if a safe SBOM workflow is actually helping?
A: They should measure whether the team can identify exposure without running package lifecycle scripts, and whether that inventory is fast enough to guide containment decisions.
Practitioner guidance
- Build a 24-hour exploitation notification runbook Define the internal escalation path, evidence sources, decision owners, and approval checkpoints needed to notify ENISA within 24 hours when active exploitation is confirmed.
- Connect SBOMs to live remediation workflows Ensure machine-readable SBOM output feeds product version mapping, affected-customer identification, and issue routing so inventory changes drive immediate action rather than archive storage.
- Replace CVSS-only prioritisation with exposure-based triage Combine reachability, asset criticality, business impact, and customer exposure so vulnerability decisions can be defended as risk-based rather than score-based.
What's in the full article
ArmorCode's full blog covers the operational detail this post intentionally leaves for the source:
- A full breakdown of the CRA reporting cascade and how the 24-hour, 72-hour, and 14-day deadlines differ in practice.
- Detailed guidance on turning SBOM output into product-level impact analysis and remediation routing.
- A deeper explanation of why CVSS-based prioritisation fails the CRA test and how exposure-based decisioning changes the workflow.
- The article's view on how Unified Exposure Management maps across cloud, containers, code, and third-party dependencies.
👉 Read ArmorCode's analysis of CRA compliance and operational resilience →
Cyber Resilience Act compliance: what changes for security teams now?
Explore further
19/08/2026 4:10 pm
CRA compliance exposes the weakness of fragmented security governance. The regulation is less about introducing new technical risk than about proving that risk handling is continuous, documented, and attributable. Organisations that split vulnerability work across separate tools and teams will find that they cannot produce a coherent compliance story. The practical conclusion is that CRA readiness is now an operating model question, not a checklist exercise.
A question worth separating out:
Q: Who is accountable when a CRA reporting deadline is missed?
A: Accountability usually falls across product security, engineering leadership, and the manufacturer that places the product on the EU market. The regulation shifts responsibility away from the end user and onto the party shipping the software or device. That means governance must define who detects, who validates, who approves, and who signs the notification.
👉 Read our full editorial: Cyber Resilience Act compliance turns vulnerability handling into governance
