Cyber Resilience Act Response Center Request a demoDemo

Guide Last updated 13 min read

The first 24 hours after a vulnerability report: a runbook for manufacturers

A report arrives on a Saturday evening. Who picks it up, who assesses it, when does the 24-hour deadline start, and what has to be in place by then? This guide gives manufacturers without their own security team a process they can run with the people they already have.

The 24-hour deadline in the Cyber Resilience Act does not start when a report arrives, but when the manufacturer becomes aware (Article 14(2)(a)). According to the Commission guidance (paragraph 213), awareness is the point at which your initial assessment establishes with a reasonable degree of certainty that a vulnerability in your product is being actively exploited. That assessment has to start immediately and end in writing. From the moment of awareness, 24 hours for the early warning notification and 72 hours for the vulnerability notification run in parallel. A manufacturer without its own security team can meet these deadlines if four things are settled in advance: a reporting address that someone reads, a call chain, two people with access to the reporting platform and a record template. The runbook counts in hours from the moment a report arrives.

Key points

  • The deadline runs from awareness, not from receipt. Awareness is the written outcome of the initial assessment: "reasonable degree of certainty: yes" (Commission guidance, paragraph 213).
  • The initial assessment has to start immediately. Leaving it in a queue does not credibly postpone awareness.
  • The early warning contains little: product, version, affected Member States, a short description. It does not have to be complete (Article 14(2)(a)).
  • The 24 and 72 hours run at the same time from awareness, not one after the other.
  • Four timestamps in UTC (Coordinated Universal Time) belong in the record: first observation, awareness, alert, submission.

What has to be in place beforehand

The biggest gains come before anything happens. NIST SP 800-61 Revision 3 of April 2025 puts preparation at the start of every incident response. For a manufacturer with 20 to 200 employees, that means:

  • A reporting address with cover. A mailbox for vulnerability reports, published in a security.txt file, that is read at weekends too.
  • A call chain. Names, mobile numbers and deputies for product management, development and senior management, plus a lawyer and the data protection officer where needed.
  • Two accounts for the reporting platform. ENISA's single reporting platform, the web form under Article 16, requires a registered person, the Assigned Representative. Two people cover holidays and sickness.
  • A product list with versions and Member States, a checklist for "actively exploited?", a record template and standard wording in English.
  • Two tabletop exercises a year, one on a vulnerability and one on an incident, never using the real reporting channels.
Free toolsecurity.txt generatorThe reporting address is where the 24-hour clock begins. You can create a matching security.txt file in a few minutes, checked against RFC 9116 and TR-03183-3.Create the file

The hour-by-hour plan from receipt

The hours are a suggestion. For the initial assessment, the Commission guidance only says "immediately" and calls for "prompt action" (paragraphs 213 and 214). The plan spreads the 24 hours so that a buffer remains at the end.

  1. Hour 0: intake with a timestampThe report comes in through the mailbox, the reporting form, support, a customer, the CSIRT (Article 15(4)), a scanner or the media. It goes into a ticket with the timestamp "first observation" in UTC. The person reporting receives an acknowledgement; BSI TR-03183-3 requires a first reply within five working days that is not automated; straight away is better. Four-eyes principle: nobody closes the ticket alone.
  2. Hours 0 to 2: triage, the first classificationThree questions: does it concern one of your products, and which version and component? Can it be reproduced? Is it a test finding, a proof of concept (evidence that a flaw can be exploited in principle), a known vulnerability in a component, or are there signs of real exploitation, such as logs, unknown access to customer systems or an extortion attempt? There are three possible outcomes: no link to your product; a vulnerability with no sign of exploitation (coordinated disclosure, and passing it on to the component manufacturer under Article 13(6)); suspected active exploitation or a severe incident. Only the third triggers escalation.
  3. Hours 2 to 6: initial assessment with a written outcomeGather evidence: request customer logs, check your own telemetry, ask CERT-Bund for information. The outcome goes into the ticket in writing: "reasonable degree of certainty yes or no, since when, on what basis". If yes, the time of that entry is the moment of awareness, and from then on the 24 and 72 hours run in parallel. If no, record the reasons, keep watching and, if in doubt, report voluntarily under Article 15; this creates no additional obligations (Article 15(5)).
  4. In parallel from hour 2: call chainOne person leads the case and a second deputises. Senior management is informed because it decides on user information and communication. A lawyer or the data protection officer joins if personal data is involved or if your company may itself be affected under NIS2; further deadlines then run in parallel (72 hours under the GDPR, 24 hours under NIS2). No approval loop before the early warning.
  5. Hours 6 to 12: containment and targeted user informationDecide on immediate measures: a workaround, a configuration notice, switching off a function. Inform affected customers directly (Article 14(8)), without details that would make exploitation easier (Commission guidance, paragraph 220). If the vulnerability lies in a bought-in component, inform the component manufacturer.
  6. Hour 20 at the latest: submit the early warningIn the single reporting platform, with the mandatory fields: type, title, summary, manufacturer, Member States, product, version, time of detection. For an incident you also state whether it is suspected of being caused by unlawful or malicious acts (Article 14(4)(a)). File the confirmation e-mail. The four hours left before the deadline are a buffer for login problems or a platform outage. For an outage, the BSI exceptionally accepts an e-mail to CERT-Bund; it does not replace the report via the platform, which must be submitted once the platform is back (ENISA FAQ 25).
  7. Hours 20 to 24: record and planningThe record contains the four timestamps in UTC (first observation, awareness, alert, submission) and all decisions, people involved and evidence. Add the task list for the 72-hour notification (nature of the exploitation, measures taken, measures for users) and for the final report, whose 14 days only start once a corrective or mitigating measure is available (Article 14(2)).

Who does what

A manufacturer without a PSIRT, that is without its own product security team, fills the roles with people it already has. The FIRST PSIRT Services Framework calls this the "distributed" model. What matters is that every role has a name and a deputy.

RoleWho in the companyTask in the first 24 hours
On callWhoever reads the mailbox and form outside working hours, with a deputyIntake, timestamp, acknowledgement, first classification, triggering the call chain
Case leadProduct management or technical lead, with a deputySteering the initial assessment, recording the outcome, setting the time of awareness, deciding on containment
DevelopmentA developer with security experience or an external contractorReproducing the issue, identifying affected versions, analysing logs, proposing a workaround
Senior managementManaging director or head of salesApproving user information and customer communication, bringing in legal and data protection
Assigned RepresentativeTwo registered people with access to the single reporting platformSubmitting the early warning, filing the confirmation, preparing the 72-hour notification
Legal and data protectionOn call, can be externalParallel notifications under the GDPR and NIS2, wording of the customer information

External help is possible, but responsibility stays with the manufacturer. What can and cannot be outsourced is covered in the guide Outsourcing the CRA reporting obligation.

A weekend, played through

A manufacturer of packaging machines with 120 employees ships its lines with a remote maintenance module. It has no security team, but it does have a call chain and two people registered on the reporting platform. The example is fictitious.

  1. Saturday, 23:14A customer in France writes to the vulnerability mailbox: for two days, logins from an unknown account have been appearing on the operator PC of one line, each time via the remote maintenance module. The person on call reads the e-mail at 23:20, opens a ticket with the timestamp "first observation" 21:14 UTC, and acknowledges receipt to the customer.
  2. Saturday, 23:30Triage: own product, module version known, the customer describes unknown access rather than a test finding. Classification: suspected active exploitation. The person on call phones the case lead, who wakes a developer. Timestamp "alert" 21:35 UTC.
  3. Sunday, 00:10 to 03:40The developer requests the log files from the operator PC. At 03:40 they show logins from unknown addresses through a vulnerability in the module's login function, which has been listed in a public database for four weeks.
  4. Sunday, 04:10The case lead writes in the ticket: "Reasonable degree of certainty: yes. Active exploitation of the login vulnerability in the remote maintenance module, evidenced by customer logs from Thursday to Saturday." Timestamp "awareness" 02:10 UTC. The early warning is due by Monday, 04:10, the vulnerability notification by Wednesday, 04:10.
  5. Sunday, 09:00Conference call with senior management. Decision: all customers with this module are told that same day to disconnect remote maintenance until the update arrives, without any details of the type of vulnerability. The lawyer is informed because the logs could contain personal data.
  6. Sunday, 14:00The customer information goes out to 38 operators in six Member States. Sales phones the three largest customers.
  7. Sunday, 21:30The Assigned Representative submits the early warning: product, module version, six Member States, short description, time of detection. Timestamp "submission" 19:30 UTC, a good six hours before the deadline. The confirmation is filed in the ticket.
  8. Monday, 08:00The record is complete. Development starts work on the update; the day it becomes available starts the 14 days for the final report.

What makes the difference this weekend is nothing technical. Someone read the e-mail at 23:20. The call chain had numbers that answered. Two people were able to report. Every step has a timestamp.

Free templatesCRA Reporting KitThe runbook as a playbook you can adapt, plus a call chain, an awareness record and a deadline calculator in Excel. Word, Excel and PDF.Request the kit

Common mistakes

  • Waiting for the root cause analysis or for sign-off. Awareness requires a reasonable degree of certainty, not a complete picture. The early warning may go out with little information; the Regulation does not require a signature from senior management.
  • Counting 24 and 72 hours one after the other. Both deadlines run from awareness. The final reports also differ: for a vulnerability, 14 days after a corrective or mitigating measure is available; for a severe incident, one month after the 72-hour notification (Article 14(2) and (4)).
  • Reporting a scanner finding. A database entry, a severity score or a finding from your own testing is not active exploitation (Article 3, point (42), recital 68). Conversely, a customer mentioning "strange logins" is not a support case but a suspicious event that has to be assessed straight away.
  • Only one person can report. A single Assigned Representative, an unread mailbox or a report sent by e-mail instead of through the platform will cost you the deadline when it matters.
  • Sending tests to live channels. Exercise reports never go to CERT-Bund or into the single reporting platform.
  • Not setting a timestamp for awareness. Without it, you can neither prove nor defend that you met the 24 hours. So far the platform only asks for the time of detection; ENISA has announced a field for the time of awareness in the next release but does not yet use it to calculate deadlines. The manufacturer records the time itself.

Where the building blocks come from

There is no official checklist from the BSI or ENISA for the first 24 hours. The process above draws on three sources, each of which asks for more than a mid-sized company needs:

  • FIRST PSIRT Services Framework, version 1.1. Six service areas of a product security team. Realistic for a mid-sized company: one intake channel, one qualification rule, reproduction in a test environment, a fix process with approval, a security advisory to customers.
  • NIST SP 800-61 Revision 3. Preparation, detection and analysis, containment, post-incident activity. Detection and analysis correspond to the initial assessment under paragraph 213 of the Commission guidance.
  • BSI TR-03183-3. Receiving vulnerability reports: a first response within five working days, the four-eyes principle, informing the CSIRT without undue delay, at least the roles PSIRT and CSIRT, held by one person in a microenterprise. More in the guide PSIRT for SMEs.

If you do not want to build this readiness yourself, you can hand it to a service. CRA Response Center monitors the vulnerability address, recognises important reports, alerts the responsible people by SMS and e-mail, shows the deadlines from confirmed awareness and keeps a record of everything that happens. Assessment, decisions and submission remain with the manufacturer.

Frequently asked questions

Do I need to know everything within 24 hours?

No. According to the Commission guidance, the early warning deliberately contains limited information (paragraph 215); on the platform that means the product, version, affected Member States, a short description and the time of detection. The details follow in the 72-hour notification and the final report.

When does the clock start?

When the initial assessment concludes with a reasonable degree of certainty that the vulnerability in your product is being actively exploited (paragraph 213), not when the report arrives. The assessment does, however, have to start immediately. More in the guide When does the 24-hour deadline start?

What if I am not sure?

Document the assessment with your reasons and keep investigating. If in doubt, you can report voluntarily under Article 15; a voluntary report creates no additional obligations (Article 15(5)).

Does senior management have to approve the early warning?

Not legally. In practice, the Assigned Representative should have advance approval for early warnings so that the deadline is not missed for want of a signature. Senior management decides on user information and communication.

Whom do I inform first, the authorities or customers?

Both, promptly. The deadline for the early warning is fixed; informing users under Article 14(8) has to happen "in a timely manner", with no deadline in hours, and depends on the risk. A workaround goes to those affected first.

What if the platform is unavailable?

E-mail CERT-Bund, put a screenshot of the outage in the record, and submit via the single reporting platform as soon as it is available again.

Do I need a PSIRT?

No. The Regulation does not require a team, it requires results: intake, assessment, notification, user information, evidence. Named roles with deputies and a rehearsed process are enough.

How do I practise this?

Two tabletop scenarios a year, one with a vulnerability and one with an incident, ideally at a weekend. Never with real reports to CERT-Bund or the platform.

Further reading

Sources

The reporting obligation already applies. Who answers at night at your company?

CRA Response Center monitors your security mailbox, recognises important reports using AI hosted in Germany (your e-mails never go to OpenAI, Anthropic or Google) and alerts your people by SMS and e-mail. EUR 190 per month including VAT. Try it free for 30 days.

Try it free for 30 days