EU Cyber Resilience Act Puts 24-Hour Clock On Software Supply Chains
The European Commission lists 11 September 2026 as the start of Cyber Resilience Act reporting duties and 11 December 2027 for its main product-security obligations. Manufacturers face distinct reporting and engineering deadlines.
The EU Cyber Resilience Act creates two distinct deadlines for software and hardware manufacturers.
The European Commission’s implementation summary lists the start of reporting obligations on 11 September 2026 and the main product-security obligations on 11 December 2027.
DeveloperTech’s coverage examines the supply-chain preparations behind those requirements.
The support period is not a five-year maximum.
Under Regulation (EU) 2024/2847, manufacturers must reflect the expected time of use and provide a support period of at least five years; if the product is expected to be used for less than five years, that expected time may determine the period.
Vulnerability handling therefore needs to be planned alongside design, documentation and release processes.
The requirements apply to products with digital elements within the Act’s scope.
Developers of software libraries and embedded components need to determine whether their products fall within it, including relevant exclusions and the treatment of free and open-source software.
Secure design, vulnerability handling and Software Bills of Materials are central engineering preparations, rather than evidence that every sector or software project faces identical duties.
That requirement creates a problem for component suppliers whose code is built before the final device or deployment environment is known.
Andrew Longhurst, managing director at Wittenstein High Integrity Systems, framed the supplier role as providing secure-by-design architecture and compliance evidence without locking customers into rigid designs or closed ecosystems.
The reporting process starts with an early warning, not a complete incident report.
According to the Commission’s guidance, manufacturers must notify the coordinating CSIRT and ENISA within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident affecting product security, followed by a fuller notification within 72 hours.
The Commission’s reporting guidance explains the subsequent reporting stages.
Manufacturers outside the EU also need to assess obligations when placing covered products on the EU market.
Machine identities add another layer to that control map.
Autonomous software agents and other non-human identities can move through production systems at machine speed and often hold broad permissions.
Gregg Hardie, public sector regional vice president at SailPoint, warned that organisations first need a clear picture of how many agents exist and what each can access, because ignorance is not a defence under the Act.
Dependency visibility may decide whether the deadline is realistic.
Sonatype data puts the average software supply chain at more than 180 external components.
In 2025, the firm tracked nearly 1.8 billion component downloads that carried known security risks where fixes were available but not applied.
Those figures make software inventory a reporting control, not just an engineering convenience.
If teams cannot quickly identify which products contain an exposed component and which versions are affected, the notification window becomes hard to meet.
Boards therefore have a governance task before any attack begins.
Incident teams need authority lines for who approves initial notifications during irregular hours, which territorial rules apply to affected assets and how reporting work stays separate from recovery.
James Blake, Cohesity’s vice president of global cyber resiliency strategy, response and consulting services, cautioned that the disclosure clock should not consume the hours needed to restore the business.
The UK is moving in a similar direction through proposed expansions to the Cyber Security and Resilience Bill, including powers for government intervention when technology suppliers create national security risks.
Across both jurisdictions, the compliance burden points to tested offline backups, network segmentation, third-party risk monitoring and rehearsed response workflows as operating requirements rather than optional security maturity markers.
