The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, is not merely a documentation requirement. It connects product security requirements, vulnerability handling, support, updates, and incident reporting with access to the European market.
Scope note: this article summarizes general technical implications for software companies. It does not replace a legal assessment of scope, exceptions, or contractual obligations for a specific product.
What changes in practice
The CRA's central principle is to treat cybersecurity as a product property throughout its lifecycle. The European Commission states that devices and software must be designed, updated, and maintained securely. This shifts the conversation from a point-in-time check before release to a continuous engineering and response process.
For a software company, four areas tend to converge:
- secure development: requirements and controls embedded in the engineering process;
- component visibility: the ability to identify components and dependencies included in the product;
- vulnerability handling: receiving, assessing, fixing, and communicating flaws during the support period;
- compliance evidence: records demonstrating decisions, tests, fixes, and change control.
The milestones that require attention now
| Date | Milestone |
|---|---|
| June 11, 2026 | Provisions on notifying conformity assessment bodies became applicable. |
| September 11, 2026 | Reporting obligations for actively exploited vulnerabilities and severe incidents become applicable. |
| December 11, 2027 | The regulation becomes fully applicable. |
According to the European Commission, reporting from September 2026 includes an early warning within 24 hours of awareness and a complete notification within 72 hours. The process uses the Single Reporting Platform and cannot be treated as work that begins only after an incident occurs.
Meeting a short reporting window depends on an operational inventory, clear ownership, classification, and a tested response process.
Where engineering feels the impact
Inventory is not a spreadsheet produced at the end
The organization must connect products, versions, components, dependencies, and owners. An SBOM can support that visibility, but its value depends on freshness, consistent identifiers, and integration with vulnerability processes. The inventory must follow the artifact that was actually delivered, not only a manifest from an earlier build stage.
Vulnerability handling needs clear inputs and outputs
Receiving a report is only the beginning. The process must define triage, severity, impact confirmation, remediation, update distribution, communications, and evidence preservation. Without a connection among PSIRT, engineering, product, support, and legal teams, the regulatory clock advances while the organization is still looking for the owner.
The pipeline becomes an evidence producer
Test results, approval policies, provenance, signatures, and promotion history help answer two questions: “what was delivered?” and “which controls were executed?”. This does not mean retaining every log indefinitely. It means defining evidence proportionate to risk and protecting it from modification or loss.
How to assess readiness
- Which products and versions may be in scope, and who owns each one?
- What support period was communicated, and how are security updates distributed?
- Can the team generate a reproducible inventory from the delivered artifact?
- Is there a vulnerability intake channel and a process to confirm active exploitation?
- Who starts the report, and what data can they gather in the first 24 hours?
- Do repositories and pipelines preserve sufficient logs, approvals, and provenance?
- Can a fix be built, tested, signed, and distributed without improvisation?
- 01Productdefined scope, version, and owner
- 02Inventorycomponents tied to the delivered artifact
- 03Monitoringcontinuous tracking of vulnerabilities and incidents
- 04Triage and remediationconfirmed, contained, and treated impact
- 05Communicationreporting and updates for affected parties
- 06Evidencerecords preserved to improve the process
What an isolated tool cannot solve
SCA helps identify components and known vulnerabilities. SAST, DAST, and other controls broaden technical coverage. None of them alone defines regulatory scope, ownership, support periods, reporting processes, or risk acceptance criteria. The CRA requires a connection among product governance, engineering, AppSec, and incident response.
Official guidance and implementing acts also need continuous monitoring. The European Commission continues to publish supporting material, so controls and interpretations should be reviewed throughout the preparation process.
Sources and references
- European Commission — Cyber Resilience Act: implementation
- European Commission — CRA reporting obligations
- European Commission — summary of the legislation
- EUR-Lex — Regulation (EU) 2024/2847
How does this apply to your software lifecycle?
Xmart helps teams assess AppSec and Software Supply Chain controls, evidence, and architecture — from inventory to operations.
