CRA Reporting Obligation in Practice: 24 Hours, Reporting Platform and Internal Process

TL;DR

The reporting obligations under Article 14 of the Cyber Resilience Act have applied since September 11, 2026. The remaining obligations of the regulation follow on December 11, 2027.
Actively exploited vulnerabilities and severe security incidents that affect product security must be reported: early warning within 24 hours, notification within 72 hours, final report 14 days after a corrective measure is available (vulnerability) or one month after the 72-hour notification (incident).
You report once, through ENISA's Single Reporting Platform. It forwards the report to the coordinating CSIRT, which in Germany is CERT-Bund at the BSI.
The clock starts when you become aware, weekends included. Without on-call duty, triage rules and platform access set up in advance, 24 hours is hard to meet in a mid-sized company.
NIS2, GDPR and customer notification run in parallel and separately. For now you file each report individually, and a joint reporting channel is so far only a proposal by the European Commission.

The reporting obligations of the Cyber Resilience Act are no longer a future topic: since September 11, 2026, every manufacturer of products with digital elements must report an actively exploited vulnerability within 24 hours. The deadline runs through the weekend, and many mid-sized companies have neither on-call duty nor a rehearsed procedure for it. This article complements the introductory article with the practical side: what you report and when, where you report it, and how you build the process in your company.

What has applied since September 11, 2026?

The CRA is Regulation (EU) 2024/2847 and applies in stages. Three dates matter for reporting:

Date	What applies
June 11, 2026	Provisions on the notification of conformity assessment bodies
September 11, 2026	Manufacturers' reporting obligations under Article 14
December 11, 2027	All remaining obligations, including security requirements, conformity assessment and CE marking

This is where manufacturers often stumble: the reporting obligation is the first CRA obligation that actually applies to you, and it applies regardless of whether your product is already CRA-compliant. According to several consistent specialist sources, it also covers products that are already on the market. So you cannot wait until your product portfolio has been adapted by the end of 2027.

The manufacturer files the report. Importers and distributors inform the manufacturer when they learn of a vulnerability and do not report themselves. Open-source stewards are only covered on the platform from December 11, 2027.

What do you have to report? Actively exploited vulnerabilities and severe incidents

The CRA has two triggers. Not every vulnerability and not every incident belongs to them.

Actively exploited vulnerability

This means a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the system owner's permission. That is the definition in Article 3(42). According to its own account, the BSI expects credible indications of actual exploitation in real systems. A published exploit or a proof of concept alone is not enough.

Two consequences in practice:

A newly found vulnerability without exploitation is not a reportable case under Article 14. It continues through your normal vulnerability management: assessment, fix and coordinated disclosure.
The wording does not require that the attack targeted your own product. If a component in your product has a vulnerability that is being exploited somewhere, you should decide the case deliberately and document the decision. This is our reading of the wording, not an official position.

Severe security incident

An incident is severe if it affects the availability, authenticity, integrity or confidentiality of sensitive or important data or functions of the product, or if it enables the introduction or execution of malicious code. The incident must have an impact on the security of the product. The BSI gives an example: ransomware in the manufacturer's own network is not automatically reportable under the CRA as long as the product itself is not affected.

It looks different when an attacker takes over your build pipeline and ships manipulated firmware. Then the security of the product is at stake, and this is the typical case that supply chain attacks bring to manufacturers.

The timeline: 24 hours, 72 hours, final report

Reporting runs in three stages. The first two deadlines run from the moment you become aware. The third depends on the case.

Stage	Deadline	Start	Minimum content
Early warning	24 hours	Awareness of the exploitation or incident	Category, manufacturer, affected product, descriptive title, suspected unlawful act, affected Member States
Notification	72 hours	Awareness	Product details, nature of the exploitation or incident, first assessment, corrective or mitigating measures, what users can do
Final report, vulnerability	14 days	A corrective or mitigating measure becomes available	Description with severity and impact, the attacker if known, the security update provided
Final report, incident	1 month	After the 72-hour notification	Detailed description, type of threat and probable root cause, measures taken and ongoing

The early warning is deliberately thin. In 24 hours you give the signal, not the analysis. According to the BSI, a report on the platform can be updated until it is finalized, and information already entered is carried over to the next stage.

When does the clock start?

With awareness. This is the sentence everything hinges on in practice, because it is not the moment a ticket is assigned or someone has time. If you have reliable information in an inbox at 9 a.m. and only look at it on Monday, the time is used up anyway. Define internally from which information you assume awareness, and record the time in the ticket. A suggestion: the moment a member of the triage team has seen the evidence and rated it as reliable is documented as awareness. Until then, triage itself has to be fast, otherwise it looks as if you delayed the start of the clock.

And the users?

Alongside the report to the authorities, you must inform affected users about the vulnerability or incident and about the measures they can take to protect themselves. If you do not do this in time, the CSIRTs can pass this information to users themselves. So plan customer information as its own strand in the process and not as a footnote.

What happens if you fail to comply?

The CRA provides fines for violations of the obligations, in the familiar range of up to 15 million euros or 2.5 percent of global annual turnover. Micro and small enterprises are not fined for a missed 24-hour early warning, but the duty to report remains. A company with 100 employees counts as a medium-sized enterprise and does not have this relief.

Where do you report? The Single Reporting Platform

There is only one reporting channel: the Single Reporting Platform (CRA-SRP) of ENISA, the EU Agency for Cybersecurity. It has been available since September 11, 2026 at portal.cra-srp.enisa.europa.eu. You report once, and the platform distributes the report to the coordinating CSIRT and to ENISA.

Which CSIRT is responsible?

For manufacturers with their main establishment in the EU, it is the CSIRT of the Member State in which the essential cybersecurity decisions are made. For manufacturers without an EU establishment, a sequence applies that runs via the authorized representative, the importer and the distributor, down to the Member State with the most users. In Germany the coordinating CSIRT is CERT-Bund at the BSI. The BSI also runs market surveillance for the CRA.

Registration and access

According to the BSI, you do not have to register in advance, and registration and submission of a report should be possible within minutes. The first time it works like this: you select the Assigned Representative role, select the country and the coordinating CSIRT, sign in with an EU Login, accept the terms of use, check the pre-filled details and enter the manufacturer data. You invite further representatives. According to the BSI, the forms are in English.

Do not count on this taking care of itself in an emergency. If the early warning falls due at 3 a.m., that is a bad moment to apply for an EU Login for the first time. Set up access now, with a primary and a secondary representative, and test it once with everyone involved.

What if the platform is unavailable?

The BSI names an e-mail directly to CERT-Bund as the fallback. Keep the contact details from the BSI publication available offline and check them regularly. The platform has also only started in a first operating stage and, according to ENISA, will be extended in the coming months. We do not know whether and when there will be a machine-readable interface for automated reports. Plan for manual entry.

How do you build the internal process?

A template alone does not help if nobody knows who fills it in. The process has five building blocks: intake, triage, decision, report and documentation. It can run in a company with 100 employees without its own security team. You need roles, not a department.

Intake: where does the information come from?

Indications of exploitation come from more sources than most people assume:

the public contact address for vulnerability reports (security@ and a security.txt on the website)
customer support, when several customers report the same failure pattern
your own telemetry and monitoring of cloud components
security researchers, authorities and CSIRTs approaching you directly
distributors and importers informing you as the manufacturer
suppliers whose components are inside your product

All channels must end up in the same inbox or ticket system and trigger an alert. A security@ mailbox that nobody reads on Friday evening is the most common gap.

Roles: who does what?

The roles can be filled even with few people. What matters is that every role has a deputy.

Role	Task	Typical staffing at 100 employees
PSIRT coordination	Takes in reports, steers the process, prepares the decision	Head of product security or head of development
Triage engineer	Checks technically whether there is exploitation and which products and versions are affected	Experienced developer with access to the bill of materials and logs
Reporting officer	Submits the report on the platform, registered there as Assigned Representative, plus a deputy	PSIRT coordination and information security officer
Decision maker	Approves the report, at night as well	Managing director, or PSIRT coordination by written authorization
Communication	Informs customers, distributors and, if necessary, the press	Head of support, sales
Legal and data protection	Checks the separation from GDPR and contracts, wording	Data protection officer, law firm

PSIRT stands for Product Security Incident Response Team and is what is a dedicated team in large corporations. For you it is a function with fixed names. The difference from an internal IT security incident lies in the perspective: your incident response plan takes care of your own IT, the PSIRT of the product at the customer's site.

Decision authority is crucial. If the managing director is on vacation and the approval depends on them, the deadline is gone before they call back. Define in writing in advance who may approve the early warning on behalf of the company.

24/7 availability without shift work

The deadline knows no weekend, but you do not need shift work for that. What has proven itself in mid-sized companies:

An on-call rota of three people from PSIRT coordination, triage and reporting officer, rotating weekly.
An alert triggered by the security@ mailbox and the support ticket system, not just an e-mail.
Platform access for at least two people, both with a tested EU Login.
A deputy rule for vacation and illness that is also visible in the duty roster.

If you have a works council, clarify the compensation for on-call duty with it before introducing it. This is one of those things that cost time later if you do not raise them early.

Triage: actively exploited, yes or no?

Triage is the real bottleneck. It has to lead to a decision within a few hours so that the 24 hours are enough for approval and reporting. As a working guideline: plan a maximum of four to six hours for triage from intake, and the rest for approval and platform. That is our suggestion, not a CRA requirement.

For the assessment you need quick answers to:

What evidence exists (logs, telemetry, customer incident, report from an authority, entry in a catalog of known exploited vulnerabilities)?
Is it genuine exploitation by an attacker, or a test, a pentest result or a proof of concept?
Which products and versions contain the affected component? Here your SBOM decides whether the answer takes ten minutes or two days.
In which Member States is the product on the market?
Is there already a fix or a mitigation?

Decision tree in text form

Pin this flow next to the on-call roster:

INTAKE: Indication of exploitation or incident (customer, researcher, monitoring, authority, supplier)

1. Does it concern a product with digital elements that you placed on the market?
   No  -> not a CRA case. Check NIS2, GDPR and customer contract (step 6). End.
   Yes -> continue with step 2.

2. Is it a vulnerability or an incident?
   Vulnerability -> step 3.
   Incident      -> step 4.

3. Is there reliable evidence that an attacker exploited the vulnerability without
   the system owner's permission?
   No  -> normal vulnerability process, monitoring, reassess on new evidence.
          Document the reasons and the time of the decision. End.
   Yes -> REPORTING OBLIGATION. Record the time of awareness. Continue with step 5.

4. Does the incident affect availability, authenticity, integrity or confidentiality
   of sensitive data or functions of the product, or enable the introduction or
   execution of malicious code?
   No  -> document internally, check NIS2 and GDPR separately. End.
   Yes -> REPORTING OBLIGATION (severe incident). Record awareness. Step 5.

5. Start the clock and prepare the report:
   - Inform the decision maker, obtain approval.
   - Early warning within 24 hours via the Single Reporting Platform.
   - Prepare the 72-hour notification, plan the fix.
   - Inform customers as soon as protective measures exist.

6. Check in parallel:
   - Is personal data affected? -> check the 72-hour GDPR deadline.
   - Are you yourself subject to NIS2 and is it a significant incident? -> BSI report.
   - Do customer contracts require faster or additional notifications?

If the evidence is thin: report and update later. A documented second assessment
is better than a missed deadline.

This is not legal advice. Clarify doubtful cases with your legal department or law firm.

The early warning: template

The platform asks for the details in forms. But you can prepare a text with the answers in advance and only fill in the blanks in an emergency. Since the forms are in English, the template is also best kept in English:

EARLY WARNING (Art. 14 CRA), within 24 hours

Report category:     Actively exploited vulnerability / Severe incident
Manufacturer:        [Company name, address, contact for PSIRT]
Affected product:    [Product name, versions, component if known]
Title:               [Short descriptive title, no exploit details]
Awareness:           [Date and time (UTC) you became aware]
Suspected unlawful or malicious act:  Yes / No / Unknown
Member States where the product is made available:  [List, e.g. DE, AT, FR]
Current status:      Under investigation. Detailed notification will follow within 72 hours.
Contact:             [Name, phone (24/7), e-mail]

Avoid technical details about the exploit in the early warning. The coordinating CSIRT passes the report on to the CSIRTs and market surveillance authorities of the affected Member States. So write only what is needed for classification. In exceptional cases the CSIRT can temporarily withhold distribution for security reasons, for example during ongoing coordinated disclosure.

In the 72-hour notification you add details on the exploitation, the affected versions, fixes or mitigations, and what users can do. The final report describes the vulnerability with severity and impact, the attacker as far as known, and the security update provided.

Documentation: what you record

Treat every report like an audit object. If you cannot show at the end when you became aware and when you reported, you are in a weak position even if you were on time. Record:

Time of receipt, source and evidence
Time of awareness and who determined it
Triage result with reasoning, including for cases without a report
Time, channel and reference number of each stage of the report
Approval by the decision-maker role, with name and time
Customer notification with date and recipient group
Corrections to a report, without overwriting the original state

In ISMS Lite you create the case as an incident and record the notification time, channel, reference and evidence of the report. You capture a correction as a correction and do not overwrite the first piece of evidence. That fits what auditors and supervisory authorities will want to see later.

How do you separate the CRA report from NIS2, GDPR and customers?

A security incident at a manufacturer can trigger up to four reports, each with its own addressee, its own deadline and its own trigger. This is where teams get mixed up.

	CRA (Art. 14)	NIS2	GDPR (Art. 33)	Customers and contracts
Who reports	Manufacturer of the product	The affected entity	Controller	Contractor, as per contract
Trigger	Actively exploited vulnerability or severe incident affecting product security	Significant incident at the entity	Personal data breach with risk	Contractual clause, often without a threshold
Deadlines	24 hours, 72 hours, final report	24 hours, 72 hours, one month	72 hours	As agreed in the contract
Recipient	ENISA and CERT-Bund via the Single Reporting Platform	BSI via the reporting portal	Data protection authority	The respective customer

The reports do not exclude each other. An example: a manufacturer of building gateways discovers that attackers are exploiting a vulnerability in its firmware and are also harvesting credentials on customer devices. That triggers the CRA report, because an actively exploited vulnerability exists. If the manufacturer is itself subject to NIS2 and its own systems are affected, the NIS2 initial report to the BSI is added. If personal data is compromised, the notification of a data breach to the supervisory authority follows. And customers expect their own information, depending on the contract.

The fallacy is that one report replaces the others. It does not. For now you must file each report through its own channel, and the BSI points out that the European Commission's proposal on the Digital Omnibus provides for a joint reporting channel but only takes effect once it is adopted. Until then: a CRA report satisfies neither NIS2 nor GDPR.

In practice this means for the process: the reporting officer for the CRA report always clarifies the other obligations in step 6 of the decision tree. Same facts, same time of awareness, separate texts. If the texts diverge in substance, that becomes apparent at the latest when the authorities compare notes.

A case walked through

Take a manufacturer with 100 employees that supplies gateways for building technology, including firmware and a cloud portal.

Friday, 5:40 p.m. Support reports that three customers independently see unknown configuration changes on their gateways. On-call is alerted, and the triage engineer finds accesses in the logs that point to exploitation of a vulnerability in a library. At 7:10 p.m. he rates the evidence as reliable. That is the documented time of awareness.

Friday, 8:30 p.m. The PSIRT coordination informs the management, and approval comes by phone. The reporting officer enters the early warning on the platform and submits it at 9:15 p.m. The deadline would have expired on Saturday at 7:10 p.m. In parallel the team checks whether personal data is affected (no, only configuration data) and whether the company reports as a NIS2 entity (no).

Monday, 7:10 p.m. is the deadline for the 72-hour notification. It goes out on Monday morning with version details, a mitigation (restricting access to the management interface) and instructions for customers.

Wednesday the patch is ready and is shipped. From then on the 14-day deadline for the final report runs. You create the report in ISMS Lite as a measure with a due date and an owner, and it then shows up under deadlines and to-dos in the dashboard instead of getting lost in day-to-day business.

The case shows where the time goes: not in the report itself, but in the time between the first indication and the decision.

Checklist: CRA reporting process

Organization

PSIRT roles filled with names and deputies
Decision authority for the early warning regulated in writing
On-call duty for weekends and public holidays set up
Deputy for vacation and illness visible in the duty roster
Works council or staff representation consulted about on-call duty

Intake and triage

Public contact address for vulnerabilities set up (security@, security.txt)
All intake channels trigger an alert
Criteria for "reliable evidence" defined in writing
Definition of the time of awareness fixed in the process
Current SBOM available per product and version
Decision tree distributed to the on-call team

Reporting

Access to the Single Reporting Platform with EU Login set up and tested
Primary and secondary representative registered on the platform
Template for early warning, notification and final report agreed
Fallback by e-mail to CERT-Bund known, contact details available offline
List of Member States in which each product is offered is current

Separation and communication

Check step for NIS2, GDPR and customer contracts anchored in the process
Contractual notification deadlines towards customers recorded
Template for customer information with protective measures prepared
Contacts for law firm and data protection named

Documentation and exercise

Every case documented with timestamps, reference and evidence
Triage decisions without a report also documented
Exercise with a fictional case at the start of a weekend carried out
Lessons learned and improvements recorded as measures

Common mistakes with the CRA reporting obligation

Setting up the platform only in an emergency. Anyone who creates an EU Login at 3 a.m. for the first time and sorts out the roles loses hours. Set up access in advance and test it.

Confusing the 24 hours with working hours. The deadline runs from awareness, Saturday and Sunday included. A mailbox that nobody reads on Friday evening is not availability.

Treating every vulnerability as a reportable case. The CRA does not require a report for every vulnerability. Only reliably exploited vulnerabilities and severe incidents trigger Article 14. Anyone who reports everything overloads their own team and dilutes the reports.

Assuming one report replaces the others. The CRA report satisfies neither NIS2 nor GDPR nor customer contracts. Each obligation has its own channel. Without a joint check step, one of them gets forgotten.

Moving the clock back. If "awareness" internally only applies once the boss calls back, the documentation loses credibility. Define the time by traceable criteria and record it immediately.

Conclusion: The process decides the first 24 hours

According to the BSI, the report itself can be submitted within minutes. The hard part is the hours before it: recognizing the indication, assessing the evidence, getting approval. This week, set up platform access, name the on-call team and walk through a Friday-evening case with your team. For the fundamentals of the regulation and the obligations from December 2027, see the article on the Cyber Resilience Act.