CRA Reporting: How Art. 14 Differs from Section 32 BSIG

Written by the NIS2Compass editorial team | As of: October 2026

The CRA reporting obligation under Art. 14 has applied since 11 September 2026: manufacturers must report actively exploited vulnerabilities and severe incidents in their products within 24 hours via the ENISA platform. § 32 BSIG, by contrast, covers significant security incidents in your own operations. If both apply, you currently report twice. For the NIS2 side, NIS2Compass provides reporting templates for all three stages.

Which Two Reporting Tracks Does Art. 14 CRA Set Out?

Art. 14 CRA has two triggers, each with its own cascade. For an actively exploited vulnerability, the deadlines are 24 hours (early warning notification), 72 hours (vulnerability notification) and a final report no later than 14 days after a corrective measure becomes available. For a severe incident, 24 and 72 hours also apply, with the final report one month after the 72-hour notification.

This assumes you are a manufacturer of a product with digital elements under Regulation (EU) 2024/2847. Whether you are affected at all is covered separately.

Track A: actively exploited vulnerability (Art. 14(1) and (2))

• Trigger: Under Art. 3 of the Regulation, reliable evidence shows that an attacker has exploited the vulnerability without authorisation. Theoretical exploitability does not suffice.
• 24 hours: Early warning notification, naming the Member States where, to the manufacturer's knowledge, the product has been made available.
• 72 hours: Vulnerability notification with details on product, exploit, measures taken and steps for users.
• Final report: no later than 14 days after a corrective measure is available, with severity and security update details.

Track B: severe incident (Art. 14(3) to (5))

• Trigger: The incident impairs the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions. It is also severe if it has led to malicious code being introduced into the product or a user's network. Possibility alone suffices.
• 24 hours: Early warning notification, including whether malicious acts are suspected.
• 72 hours: Incident notification with an initial assessment.
• Final report: one month after the incident notification, as the Commission's page on CRA reporting obligations also states.

You know the 24- and 72-hour deadlines from the NIS2 cascade under § 32 BSIG, which NIS2Compass details in its article on NIS2 reporting obligations. Under the CRA, however, triggers and final deadlines follow their own logic.

In both tracks, the coordinating CSIRT can request an intermediate report (para. 6), and the manufacturer must inform affected users (para. 8).

When Does the 24-Hour Deadline Start, and Why Is It Different from NIS2?

Under the CRA, the clock starts once the manufacturer, after an initial assessment, is reasonably certain that a vulnerability is being exploited or that a severe incident has occurred. Under NIS2, according to the BSI, it starts when any employee becomes aware of a significant security incident during working hours. In practice, the NIS2 clock often starts earlier.

When Does a Manufacturer Become Aware Under the CRA?

Deadlines run from the manufacturer's awareness. The European Commission's guidance on applying the CRA (C(2026) 5252, Annex, paras. 213-214) is clear: suspicious events must be assessed immediately, and awareness exists once there is a "reasonable degree of certainty" after this initial assessment. The Commission expects a prompt initial assessment. A slow assessment does not push back the deadline indefinitely.

As a benchmark, the Commission cites Recital 31 of Implementing Regulation (EU) 2024/2690 and the GDPR Guidelines 9/2022 (para. 212).

When Does the Clock Start Under NIS2?

The BSI information package on the NIS-2 reporting obligation starts earlier: "'Becoming aware' refers to the point in time at which an employee of the entity (during working hours) becomes aware of a significant security incident" (translated from German). What significant means under NIS2 is defined in § 2 No. 11 BSIG.

The same event can therefore start two clocks with different start times. Your incident logbook needs separate timestamps for both deadlines.

Does the CRA Reporting Obligation Also Apply to Older Products?

Yes. Under Art. 69(3) CRA, Art. 14 covers all products placed on the market before 11 December 2027, even, according to the Commission, after the support period ends. The obligation does not apply retroactively, however (Commission guidance, paras. 210 and 217): if the manufacturer already knew of an exploitation before 11 September 2026, it does not have to report it.

Who Receives the CRA Report, and How Does the Single Reporting Platform Work?

Manufacturers report via ENISA's single reporting platform (SRP), operational since 11 September 2026. The report goes simultaneously to ENISA and to the coordinating CSIRT of the Member State of the main establishment. If the main establishment is in Germany, CERT-Bund at the BSI is the coordinating CSIRT; the BSI portal does not accept CRA reports.

Which CSIRT Is Responsible for Your Report?

What counts is the Member State where you mainly take decisions on your products' cybersecurity (Art. 14(7) Regulation (EU) 2024/2847). For manufacturers without an EU establishment, an order of precedence applies, starting with the authorised representative. In Germany, CERT-Bund at the BSI is the coordinating CSIRT. The BSI is also the CRA market surveillance authority, a separate role.

Within the CRA, you report once; the coordinating CSIRT forwards it to other Member States via the platform. This does not replace the NIS2 report. According to the BSI press release of 11 September 2026, the receiving CSIRT forwards it via the SRP to the CSIRTs of the Member States where the product is available.

On 11 September 2026, ENISA launched the SRP in its first stage ("initial operating capability") (ENISA announcement on the launch of the SRP). In the German version of the Regulation, it is called "einheitliche Meldeplattform" (Art. 16).

What Applies in Practice When Reporting via the SRP?

According to the BSI page on the CRA Single Reporting Platform:

• Registration: No advance registration is required; when needed, registration and reporting take a few minutes.
• Access: Login is via EU Login with multi-factor authentication (ENISA FAQ).
• Language: Reports are submitted in English.
• No BSI portal: CRA reports do not go through the BSI portal you use for NIS2 reports.
• SRP outage: Only then, as an exception, does the report go to CERT-Bund by email; per the ENISA FAQ, it must later be resubmitted via the SRP.

How Does the CRA Cascade Differ from NIS2 Reporting Under § 32 BSIG?

The 24- and 72-hour deadlines match; the rest differs. The CRA is tied to the product and reports via the ENISA platform to CERT-Bund and ENISA; § 32 BSIG is tied to operations and reports via the BSI portal. Trigger, start of deadline, final deadline and language differ too.

• Scope: CRA: manufacturers of a product with digital elements. NIS2: essential and important entities under § 32(1) BSIG.
• Trigger: CRA: actively exploited vulnerability or severe incident affecting product security. NIS2: significant security incident under § 2 No. 11 BSIG.
• Start of deadline: CRA: reasonable certainty after initial assessment (Commission guidance). NIS2: awareness of an employee (BSI information package on reporting).
• 24 hours: CRA: early warning notification. NIS2: initial early report, process described in detail under NIS2 reporting obligations.
• 72 hours: CRA: vulnerability notification or incident notification. NIS2: incident report with an initial assessment (sample texts).
• Interim status: CRA: intermediate report at the CSIRT's request (Art. 14(6)). NIS2: interim report at the BSI's request.
• Completion: CRA: final report 14 days after a fix is available (vulnerability) or one month after the incident notification. NIS2: final report after one month, with a progress report first if the incident is ongoing.
• Channel and recipient: CRA: SRP to CERT-Bund and ENISA. NIS2: BSI portal, the joint reporting office of the BSI and BBK.
• Language: CRA: English according to the BSI FAQ. NIS2: German.
• Informing third parties: CRA: inform users of the product (Art. 14(8)). NIS2: notify service recipients only on BSI order or, in certain sectors, for significant cyber threats (§ 35 BSIG).
• Fines: CRA: up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher (Art. 64(2)), applicable only from 11 December 2027. NIS2: for reporting violations up to EUR 10 million (essential entities) or EUR 7 million (important entities), since 6 December 2025 (§ 65 BSIG). The 2% and 1.4% thresholds only apply above EUR 500 million worldwide total turnover (fine tiers).

Does a CRA Report Replace the NIS2 Report?

No. On its SRP page, the BSI says of double reporting: "Yes, this can happen. In this case, the incident must be reported both under NIS-2 (via the BSI portal) and under the CRA (via the CRA SRP)" (translated from German).

The BSI recommends that each report reference the other. With the Digital Omnibus, the European Commission has proposed a single entry point for several reporting obligations (Commission FAQ). According to the BSI, a CRA report on a severe incident would then, under certain conditions, also count as a NIS2 report (new Art. 23(12) NIS2 Directive). This is a proposal in the legislative process, not applicable law.

What Happens When a Vulnerability in Your Own Product Hits Your Own Operations?

In a constructed example, one attack triggers two reporting obligations with two clocks, because the company is both a manufacturer and a NIS2 entity. The CRA report describes the vulnerability in the product and goes via the ENISA platform; the NIS2 report describes the impact on its own operations and goes via the BSI portal. Both reports need a single person in charge.

A mechanical engineering company with around 180 employees is subject to NIS2 as an important entity. It makes a remote maintenance gateway, sold to customers in several EU countries and used in its own production.

• Monday, 08:10: A shift supervisor reports that two production lines can no longer be maintained remotely and the gateway is opening unknown connections. IT classifies this as a significant security incident; the NIS2 clock starts.
• Monday, 11:30: After its initial assessment, the product security team confirms that a vulnerability in the gateway firmware is being exploited. A customer reports the same pattern. The CRA clock is now running too.
• By Tuesday, 08:10: initial early report via the BSI portal, noting the suspicion of a malicious act.
• By Tuesday, 11:30: early warning notification via the SRP to CERT-Bund and ENISA, in English, listing the Member States in which the gateway has been sold.
• By Thursday, 08:10 and 11:30 respectively: incident report under § 32 BSIG and vulnerability notification under the CRA, the latter with measures customers can take themselves. In parallel, the manufacturer informs the gateway's users (Art. 14(8) CRA). If personal data is affected, a notification to the data protection authority under Art. 33 GDPR is also due.
• Afterwards, separately: The CRA final report follows no later than 14 days after the firmware update is available. The NIS2 final report is due one month after the 72-hour report, or a progress report first if the incident is ongoing.

Same attacker, same vulnerability, but two reporting subjects, two channels, two languages and two start times. Both reports reach the BSI, once at CERT-Bund and once at the reporting office. They are currently not merged. The BSI recommends cross-referencing, but it is not a legal requirement.

If you only watch the NIS2 clock, you will miss the CRA early warning. The SRP is a separate channel with separate access. According to the BSI, registration and reporting take just a few minutes; internal roles and approvals do not. One person in charge therefore tracks both clocks in the incident logbook, with two timestamps for two deadlines.

What Should You Define for CRA Reporting Now?

Before the next incident, decide who determines that a vulnerability is actively exploited, who holds the EU Login for the platform and who writes the English report. Also check that your incident response plan covers double reporting under NIS2 and the CRA.

1. Responsibility for awareness: Decide who in the product security team (PSIRT) assesses vulnerability reports and classifies exploitation as sufficiently established. The 24-hour deadline runs from that point of awareness.
2. Access: Set up EU Login accounts with multi-factor authentication for everyone who reports on the SRP. The ENISA FAQ calls them "Assigned Representatives"; arrange deputies as well.
3. Mailboxes: Set up dedicated shared mailboxes for product security reports (PSIRT) and reporting communication. That way, no deadline depends on one individual being reachable.
4. English text modules: Prepare drafts for the early warning notification, the vulnerability or incident notification and the final report.
5. Double reporting check: Add a fixed check question to your NIS2 reporting process. For every significant security incident, check whether one of your products is affected, and vice versa.

The SRP is new: by 11 September 2028, the Commission must report on its effectiveness (Art. 70(2) CRA). Align your processes regularly with ENISA and BSI guidance.

For the NIS2 side, the NIS2Compass Template Library contains reporting forms for the initial early report, the incident report and the final report, plus a reporting process policy. These templates do not cover the CRA reporting channel.

Frequently Asked Questions

Do I Have to Report an Incident Twice if Both the CRA and NIS2 Apply?

Yes, currently. On its page on the CRA Single Reporting Platform, the BSI makes clear that such an incident must be reported both under NIS-2 via the BSI portal and under the CRA via the CRA SRP. Neither report counts towards the other. The Commission's Digital Omnibus would change this for severe incidents, but is only a proposal.

Can I Submit the CRA Report via the BSI Portal?

No. According to the BSI, only ENISA's EU-wide single reporting platform is currently used for the CRA reporting obligation. The BSI portal remains the NIS2 channel under § 32 BSIG. Only if the SRP is down does the report go to CERT-Bund by email, as an exception.

Does the CRA Report Have to Be in English?

Yes. According to the BSI, the platform is in English so reports can be processed EU-wide and shared with other CSIRTs. SRP access requires an EU Login account with multi-factor authentication. Keep English text modules ready for the early warning notification, the vulnerability or incident notification and the final report.

Can Late CRA Reports Already Be Fined Today?

No. The reporting obligation has applied since 11 September 2026, but the CRA's penalty provisions only apply from 11 December 2027. Fines can then reach EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher. NIS2 fines under § 65 BSIG have applied since December 2025.

Do I Have to Report Vulnerabilities That Were Exploited Before 11 September 2026?

Not if you knew about them before 11 September 2026: according to the European Commission's guidance, the CRA does not require retroactive reporting. What matters is when you became aware. If you learn of them later, the obligation under Art. 69(3) CRA also applies to products placed on the market before 11 December 2027.