What manufacturers must report now, which deadlines apply and which obligations follow in December 2027.
Whether banking software, customer apps, card readers or tokens: the Cyber Resilience Act (CRA) is relevant to anyone who develops products with digital elements, markets them under their own brand or supplies them to customers. Since 11 September 2026, manufacturers have had to issue an early warning within 24 hours to Germany's Federal Office for Information Security (BSI) and the European Union Agency for Cybersecurity (ENISA). For financial firms, this reporting route is additional to the established one under the Digital Operational Resilience Act (DORA); it does not replace it.
Article 14 of the CRA (Regulation (EU) 2024/2847) has applied since 11 September 2026. It is the first CRA obligation affecting companies, and applies exclusively to manufacturers. Distributors and importers have no obligations of their own under the CRA until 11 December 2027. The product requirements, conformity assessment, CE marking and penalties follow under Article 71 on 11 December 2027.
Reports are submitted through ENISA's CRA Single Reporting Platform.
The CRA determines a company's role by the product and how the company handles it, not by its industry.
Software developed by a company and delivered to customers is a product with digital elements. It makes no difference whether it is installed in the customer's data centre, runs as a desktop client or is an app on a smartphone. The same applies to components incorporated into another company's products, such as a payment module or library, even if the end customer never sees them. The company is a manufacturer and has been subject to the reporting obligation since 11 September. This also includes the backend if it was developed by or under the responsibility of the manufacturer and the software could not perform one of its functions without it.
The answer depends on how the product came into the company. If a service provider built it to the company's specifications and the company markets it under its own name, the company is a manufacturer and has been subject to the reporting obligation since 11 September. If, instead, the company takes an existing product from another manufacturer's catalogue and merely puts its own brand on it, such as a standard card reader, the manufacturer obligations under Article 21 apply from 11 December 2027. Until then, there is no reporting obligation for that product. A simplified rule of thumb, which the Regulation does not expressly draw as a boundary: if the company specified requirements and the supplier built to them, it is the manufacturer. If an existing product was simply given the company's logo, Article 21 applies.
A company that supplies card readers, tokens or software unchanged and under the manufacturer's name is a distributor. If it obtains the product directly from a manufacturer outside the EU and is the first to place it on the EU market, it is an importer. Whether customers pay for it is irrelevant: the CRA also covers free supply in the course of business. Distributor and importer obligations apply from 11 December 2027 and are set out below.
Software that a company uses only internally and does not provide to third parties is outside the CRA. The same applies to online banking or customer portals that run exclusively in a browser. The customer receives a service, not a product, as the CRA excludes pure software-as-a-service offerings. The company is responsible for the security of this software as an operator: financial firms under DORA, and other companies depending on their sector and size under NIS 2. A company offering only a browser service and no app should record this in writing so that the question does not recur in every audit. If an app is added later, its backend is part of the product; see case 01.
Buying hardware or software and using it internally without passing it on makes a company neither manufacturer nor distributor. Here the CRA operates through the supplier: from December 2027 the supplier may place only products with CRA-compliant CE marking on the market. The requirement for a financial firm to demand and document this when purchasing comes not from the CRA but from due diligence under DORA. Procurement requirements should be adjusted by then.
The five cases show a company's position. The following overview shows the consequences. The CRA recognises three supply-chain roles, each with its own obligations and starting date. A company can have several roles at once, one for each product. A company with its own app in an app store that also supplies another manufacturer's card readers is a manufacturer for one product and a distributor for the other.
Two events trigger the obligation: an actively exploited vulnerability in a product with digital elements and a severe security incident affecting the security of the product. Under the CRA, active exploitation means that reliable evidence exists that someone has actually used the vulnerability without the system owner's consent.
The 24 hours are the outer limit; the early warning must be issued without undue delay. There is no working-day rule: a manufacturer that becomes aware of an issue on Friday evening must report by Saturday evening at the latest. According to the European Commission's guidance of 27 July 2026, awareness does not mean the first indication, but the point at which the manufacturer, after an initial assessment, has sufficient certainty that active exploitation is taking place. The initial assessment therefore precedes the deadline. It must not be delayed to postpone the start of the clock. A company that leaves an indication unattended cannot later claim that the 24 hours had not yet started.
Separately, affected users must be informed without undue delay about the vulnerability or incident and available corrective measures. The CRA does not specify an hourly deadline for this.
Under Article 69(3), Article 14 also applies to products placed on the market before 11 December 2027, including products already on the market today. For an individual report, what matters is when the manufacturer obtained reliable knowledge of the active exploitation or incident. An exploitation known and concluded before 11 September 2026 does not require a retrospective report. Continued or newly discovered exploitation requires an assessment of the reporting obligation against current knowledge; if in doubt, the case belongs in an early legal and technical assessment, not in the filing cabinet.
The same event, two clocks. For a financial firm with its own software on the market, a single event may trigger two reports. Under DORA, a major ICT-related incident must be reported to BaFin within four hours of classification. Under the CRA, the company is a manufacturer and reports an actively exploited vulnerability to the BSI and ENISA within 24 hours of awareness. The triggers differ, and the deadlines do not run in the same way: DORA permits a report by noon on the next working day if the deadline falls on a weekend or public holiday. For credit institutions, central counterparties, trading venues and NIS 2 entities, this does not apply to initial and intermediate reports. The CRA has no such rule for anyone. DORA asks whether critical services are affected and whether there has been malicious access to the company's own systems or thresholds relating to customers, duration or damage have been met. The CRA asks whether a vulnerability in the company's own product is being exploited. Three examples illustrate the difference:
An attacker exploits a vulnerability in the company's own banking app and gains access to customer data in its systems.
Why: CRA because of active exploitation in the product. DORA because a successful malicious intrusion into systems supporting critical services is classified as major under Article 8 of Delegated Regulation 2024/1772.
A vulnerability in the company's own information app is exploited. The app does not support a critical or important function.
Why: CRA because of exploitation. Not DORA as long as no critical service is affected. The app's function, not its name, determines this.
The core banking system is unavailable for four hours, and the company's own software is not the cause.
Why: DORA if the classification thresholds for duration and affected services are met. Not CRA because no product of the company is involved.
A company combining both reporting routes in one incident-response organisation needs a decision rule that asks both questions for every event.
The platform is centralised, uniform across the EU and in English. One report reaches both the coordinating CSIRT and ENISA. The responsible CSIRT is that of the Member State where the main decisions about product cybersecurity are made. In Germany, this is CERT-Bund at the BSI. The German government has designated the BSI to the European Commission as both the notifying authority and the market surveillance authority for the CRA. The BSI takes on market surveillance from 11 December 2027.
Access requires an EU Login with multi-factor authentication. Advance registration is not necessary; according to the BSI, registration and reporting take only a few minutes if needed. After selecting the CSIRT and entering manufacturer details, a report can be submitted immediately. The CSIRT checks afterwards, in parallel with the report, whether the reporting person is authorised to report for the manufacturer. ENISA explicitly advises registering only when a report is due. For cover arrangements this means that a second person can be invited as backup only once the first person has been confirmed. Anyone wishing to remain operational at weekends should therefore have at least two people ready with EU Login and multi-factor authentication, CSIRT assignment and manufacturer details. ENISA's step-by-step guide and a BSI video tutorial explain the process; the BSI Technical Guideline TR-03183 addresses the remaining manufacturer obligations.
Five tasks can be completed without a specific incident and should be addressed before the first report.
From 11 December 2027, Article 64 provides for fines of up to EUR 15 million or 2.5 per cent of worldwide annual turnover for breaches of the security requirements and obligations under Articles 13 and 14, whichever is higher. Until then the reporting obligation applies without a breach giving rise to a fine under Article 64. Other legal consequences, including supervisory measures under DORA or liability issues, remain unaffected.
In the 15 months until then, the reporting process can be practised under real conditions without an error attracting a CRA fine. Reports go to the BSI, and from December 2027 the BSI will also check whether products meet the requirements. Those who report properly now will have developed a routine by then.
The reporting obligation is only the beginning. By December 2027, manufacturers will also face the Annex I security requirements, vulnerability management throughout the support period, technical documentation including a software bill of materials, conformity assessment and CE marking. Importers and distributors will face inspection and information obligations, while all companies will need to adapt procurement.
We support companies throughout this process: determining the role for each product, setting up the reporting route and DORA decision rule, identifying gaps against Annex I, preparing conformity assessment and documentation, and adapting procurement requirements. Anyone who wants to know where their company stands is welcome to contact us.
