The EU’s Cyber Resilience Act (CRA) stopped being a distant 2027 problem on 11 September 2026. From that date, manufacturers must alert a national CSIRT and ENISA within 24 hours of discovering that a flaw in a product they sell is being actively exploited.
ENISA’s Single Reporting Platform launched the same day. Design, documentation and CE marking rules don’t arrive until 11 December 2027, but the reporting duty already covers products on the market today.
According to GRC platform Copla, this turns readiness into a long-term governance programme rather than a one-off compliance sprint.
The CRA regulates products, not companies. It applies to software and hardware with a direct or indirect connection to a device or network, along with any remote data processing they rely on.
For FinTech and SaaS teams, the cloud boundary is critical. A pure SaaS platform generally falls outside the CRA, since NIS2 already covers it, but an app, SDK or device falls inside, as does any back end it cannot function without. The Commission’s non-binding guidance of 27 July 2026, which includes 67 practical examples, should be read before anyone declares a product out of scope.
Article 14 creates two reportable events: actively exploited vulnerabilities and severe incidents. Both require an early warning within 24 hours and a notification within 72 hours. Final reports differ, with 14 days after a fix is available for vulnerabilities and one month for incidents. The platform currently has no API, operates only in English, and submitting the wrong coordinator CSIRT can invalidate a notice.
Copla argues the real test is organisational. Someone must be able to answer four questions on a weekend: who reads an incoming report, who judges whether exploitation is active, who authorises the warning, and which products and versions contain the affected component.
Consider a DORA-regulated payments firm whose mobile SDK is exploited on a Friday evening. If nobody owns the decision, the report waits until Monday, and the firm is left debating when it became aware.
Most readiness advice, Copla notes, captures a single moment. Yet the CRA demands vulnerability handling for a support period of at least five years, with documentation retained for ten years or the support period, whichever is longer. Every release can change a product’s components, so a static SBOM quickly becomes outdated.
The good news is that firms running NIS2, DORA or ISO 27001 already own much of the machinery. Incident handling processes, asset inventories and supplier oversight can be extended to product level, provided each regulator’s trigger, clock and recipient is modelled separately. Third-party conformity assessment for Class II and critical products, and firmware testing, will still require outside expertise.
Read the full Copla post here.
Copyright © 2026 RegTech Analyst
Copyright © 2026 RegTech Analyst
