The EU Cyber Resilience Act is often discussed as a compliance problem. Read with an engineer's eyes, it reads more like a description of how a well-run product team already works, with a deadline attached.
Where things stand
The regulation entered into force in December 2024 and phases in over three years. Since 11 September 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe security incidents, starting with an early warning within 24 hours. Most of the remaining obligations, including the essential cybersecurity requirements and conformity assessment, apply from December 2027.
That gap matters. The reporting duty is already live, and teams that cannot answer "which of our products contain this component?" within a day will feel it first.
Translate requirements into engineering work
Strip away the legal phrasing and the core asks are familiar:
- Secure by default. Ship products without known exploitable vulnerabilities and with a secure default configuration.
- Know what you ship. Maintain a software bill of materials covering at least top-level dependencies.
- Handle vulnerabilities as a process. Accept reports, fix issues without delay, and provide security updates for the support period.
- Design for limited blast radius. Minimise attack surface and protect the confidentiality and integrity of data.
- Prove it. Keep technical documentation that shows how these requirements are met.
Each of these maps to work a team can plan: an SBOM step in the pipeline, a disclosure policy and intake channel, a defined support period, hardening baselines, and evidence collected as builds run.
Evidence as a by-product
The documentation requirement is where teams lose the most time when they treat it as a separate exercise. The cheaper path is to make evidence fall out of delivery: requirements traced to controls, controls traced to tests, test results stored with the release. When the question comes, the answer already exists.
Start with the reporting path
If you do one thing this quarter, rehearse the reporting flow. Pick a recent vulnerability in a common dependency and time how long it takes to identify affected products and versions, decide on exposure, and draft a notification. The bottlenecks you find are your roadmap.