Topic starter
24/10/2026 8:47 pm
TL;DR: Shipped products drive Cyber Resilience Act exposure because reporting duties begin on 11 September 2026, according to Finite State. Inventory and evidence tracking have to be ready before the reporting clock starts, or compliance falls behind the installed base.
Editorial analysis by NHI Mgmt Group, based on content published by Finite State: “Cyber Resilience Act Fines and Penalties: What Non-Compliance Actually Costs”.
By the numbers:
- Non-compliance can cost up to €15 million or 2.5% of worldwide annual turnover, whichever is higher.
- Article 64 sets three penalty tiers at €15 million or 2.5%, €10 million or 2%, and €5 million or 1%.
Key questions
Q: Why do legacy products create CRA risk before the main deadline?
A: Legacy products remain in scope for reporting obligations even when older market placements are grandfathered from some essential requirements.
Q: What do security teams get wrong about CRA fines and recalls?
A: They focus on the euro amount and miss the operational impact of withdrawal or recall.
Q: What breaks when CRA reporting is not operational before 2026?
A: Teams lose the ability to produce a defensible report inside the first deadline window, because they still need to identify affected products, confirm exploitation, gather evidence, and route approvals.
Practitioner guidance
- Map every shipped product to its CRA scope and tier Build a product register that ties each model and firmware line to Annex I exposure, reporting obligations, and responsible owners.
- Stand up a reporting workflow before 11 September 2026 Create an incident-to-report path that can produce early warning, vulnerability notification, and final report outputs without waiting for full forensic closure.
- Reconcile SBOMs to shipped binaries Verify that the SBOM reflects the actual image deployed in the product, then tie that record to provenance, support status, and customer impact analysis.
Bottom line: The article shows that CRA exposure is driven by shipped product reality, not just future development plans.
Glossary terms: Article 14 Reporting Clock, Installed Base Exposure, Software Bill of Materials, Market Surveillance
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 6 days ago by NHI Mgmt Group
25/10/2026 11:12 am
CRA compliance is really a product identity problem disguised as a legal one: the regulation punishes manufacturers who cannot reliably identify what they shipped, when they shipped it, and whether the installed base is still reportable. That makes product inventory, component provenance, and updateability part of governance evidence, not merely engineering hygiene. Practitioners should treat asset truth as the control surface.
A question worth separating out:
Q: How should manufacturers separate product security evidence from compliance evidence?
A: They should treat them as linked but distinct. Product security evidence shows the product can be updated, supported, and triaged; compliance evidence shows who owns the obligation, when reporting starts, and which customers or jurisdictions are affected. Both are necessary, but they answer different governance questions.
👉 Read our full editorial: CRA fines and reporting deadlines expose shipped products first
This post was modified 6 days ago by NHI Mgmt Group