Engineering takeaways
- Mandatory reporting for actively exploited vulnerabilities and severe security incidents starts on 11 September 2026; the main CRA provisions apply from 11 December 2027.
- The manufacturer role follows whose name or trademark places the product on the EU market, so contracts do not automatically transfer the legal responsibility.
- Start with a product and component inventory, risk assessment, support-period decision, vulnerability workflow, and evidence ownership.
Two dates should already be on the engineering calendar
The CRA entered into force in December 2024. Its Article 14 reporting obligations apply from 11 September 2026, while the main product obligations apply from 11 December 2027. Reporting is not limited to new 2027 products: the Commission's summary states that the reporting duties cover products with digital elements already made available on the Union market.[1][2][3]
| Date | What changes | OEM action now |
|---|---|---|
| 11 June 2026 | Conformity-assessment body provisions apply | Confirm likely product class and assessment route |
| 11 September 2026 | Article 14 reporting applies | Staff and rehearse the 24 h / 72 h workflow |
| 11 December 2027 | Main CRA provisions apply | Place compliant products with complete evidence on the EU market |
Define the product, the manufacturer, and the class
A connected machine, its controller software, management service, and separately marketed software may create more than one scope decision. Start from the product placed on the market and its intended purpose, including remote data-processing solutions on which the product depends. Then record whether your company is manufacturer, importer, distributor, authorised representative, or a supplier to someone else's product.[1][2]
Do not infer the conformity route from a marketing category. Review Annexes III and IV together with Implementing Regulation (EU) 2025/2392, which gives technical descriptions for important and critical product categories. Document the reasoning even when the conclusion is the default class.[5][1]
Build one product-security baseline per supported release
- Identify the product, variants, hardware revisions, software releases, cloud dependencies, and intended security environment.
- Perform and maintain the cybersecurity risk assessment across design, development, production, delivery, and maintenance.
- Map Annex I requirements to design controls, tests, operating instructions, and evidence owners.
- Create a machine-readable software bill of materials covering at least top-level dependencies and link it to the release digest.
- Set and communicate the support-period end date, including month and year.
- Preserve the technical documentation and EU declaration of conformity for the required period.
An SBOM is an index, not a vulnerability programme. It becomes useful when each released product can be matched to deployed components, vulnerability intelligence, affected configurations, customer contacts, remediation decisions, and update evidence.[1][2]
Turn Annex I into engineering acceptance criteria
The essential requirements cover risk-appropriate security, secure-by-default configuration, protection from unauthorised access, confidentiality and integrity where relevant, data minimisation, availability, limited attack surface, logging, and secure updates. A useful compliance matrix names the threat, design control, verification method, result, release, and residual risk. A policy sentence without a test result is weak evidence.[1]
- Make default credentials impossible or unique and require secure initialisation.
- Separate machine control from remote management and minimise exposed services.
- Authenticate releases, prevent rollback to vulnerable versions, and test power-loss recovery.
- Define security logging that supports incidents without collecting unnecessary process or personal data.
- Re-run relevant security tests when hardware, dependencies, or operating assumptions change.
Practise the reporting clock before it starts
From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting product security through the ENISA Single Reporting Platform. The Commission summarises an early warning within 24 hours and a main notification within 72 hours, followed by final-report deadlines. A product team cannot build reliable facts, approvals, customer communication, and legal review from scratch inside that window.[3][4]
- Name a monitored intake channel and a 24/7 escalation owner.
- Define who decides whether exploitation is active and whether an incident is severe.
- Map installed products, versions, customers, and Member States from release records.
- Prepare the 24-hour minimum facts and the 72-hour investigation workflow.
- Coordinate remediation, disclosure, customer instructions, and update delivery.
- Run a timed exercise with engineering, security, management, legal, support, and communications.
A practical 90-day starting plan
| Weeks | Deliverable | Exit test |
|---|---|---|
| 1–2 | Named products, roles, owners, provisional classes | Management accepts the scope record |
| 3–5 | Release inventory, SBOM pipeline, support-period proposal | One shipped unit resolves to its components |
| 6–8 | Risk and Annex I evidence matrix | Top risks have controls and tests |
| 9–10 | Vulnerability intake, triage, update and disclosure workflow | A sample CVE reaches affected products |
| 11–12 | Timed CRA reporting exercise and remediation review | 24 h and 72 h packages are produced on time |
| 13 | Gap register, budget, roadmap and executive decision | Every gap has an owner and date |
The best commercial response to the CRA is not to hide compliance work. A clear support period, documented update process, vulnerability contact, and honest security instructions reduce buyer uncertainty. For a young industrial brand, that operational clarity is also sales evidence.
Frequently asked questions
Does the CRA apply to industrial machines?
It can. The analysis depends on the product with digital elements placed on the EU market, its intended purpose, dependencies, exclusions, and the economic operator's role. Perform and document a product-specific scope assessment.
When do CRA incident and vulnerability reports become mandatory?
Article 14 reporting obligations apply from 11 September 2026. The Commission states that the duty includes relevant products already made available on the EU market.
Is an SBOM sufficient for CRA compliance?
No. The SBOM supports component and vulnerability management, but the CRA also requires risk-based product properties, vulnerability handling, security updates, documentation, instructions, conformity assessment, and reporting.
Sources and standards
- Regulation (EU) 2024/2847: Cyber Resilience ActEUR-Lex
- The Cyber Resilience Act: summary of the legislative textEuropean Commission
- Cyber Resilience Act: reporting obligationsEuropean Commission, Updated June 2026
- Cyber Resilience Act Single Reporting PlatformEuropean Union Agency for Cybersecurity, Updated 17 July 2026
- Implementing Regulation (EU) 2025/2392 on important and critical product categoriesEUR-Lex
BootCtrl Engineering last reviewed the technical claims and source links on 26 July 2026. Product statements are checked against the current implementation repositories; roadmap work is not presented as released capability.
