EU Publishes Practical Cyber Resilience Act Guidance for Software Makers
On 27 July 2026, the European Commission published practical guidance to help manufacturers, developers and businesses apply the Cyber Resilience Act (CRA). The guidance focuses on questions that routinely block product teams: which products are in scope, how to think about remote data processing and free or open-source software, what counts as a substantial modification, how support periods work, and how to approach reporting and risk assessment.
This is useful because product security is often treated as a late compliance task. The CRA instead asks organisations to manage cybersecurity across a digital product's lifecycle. The Commission describes the new guidance as non-binding, but it is an important practical reference for preparing implementation decisions consistently.
The dates that product teams should put on their roadmap
The Commission says the CRA's main obligations apply from 11 December 2027. Its reporting obligations apply earlier, from 11 September 2026. That does not mean every software company should wait for 2027 to start: vulnerability intake, coordinated disclosure, release ownership, support decisions and incident reporting cannot be assembled credibly in a few weeks.
Turn the guidance into engineering work
- Make a product-and-component inventory. Map the product, connected services, dependencies, maintainers, supported versions and expected support period. You cannot assess lifecycle risk without knowing what you ship.
- Assign vulnerability ownership. Define an intake channel, triage criteria, security-update authority, customer communication path and escalation route. A security contact that cannot trigger a fix is not a response process.
- Document security-relevant changes. Put a review gate around changes to authentication, cryptography, network exposure, permissions, update mechanisms and third-party components. This makes later "substantial modification" decisions evidence-based rather than retrospective guesswork.
- Design reporting evidence now. Preserve timestamps, affected versions, impact analysis, remediation decisions and customer notices. Good records support incident handling first and compliance second.
- Keep open source precise. Do not assume a project is automatically outside scope because its code is public. Evaluate the product's distribution, commercial context, maintenance and role in the supplied solution against the official guidance and applicable legal advice.
What the guidance does not do
It does not replace the Regulation, harmonised standards, a product-specific risk assessment or legal interpretation where the facts are difficult. It also does not turn a checklist into security. A secure release process still needs threat modelling, code review, dependency management, secure defaults, update testing and a plan for when a vulnerability is found after release.
A pragmatic next step
Start with one representative product and run a short readiness exercise: identify its owner, supported versions, external components, security-reporting path, vulnerability-to-release workflow and evidence gaps. The output is more valuable than a generic policy because it exposes the engineering and operational work that needs funding before the deadlines arrive.