PSIRT for SMEs: receiving, assessing and answering vulnerability reports

A PSIRT (Product Security Incident Response Team) is the function within a manufacturer that receives and checks vulnerability reports about its products, organises the fix and informs customers. Regulation (EU) 2024/2847 does not use the term. But in Annex I, Part II it requires a contact address, a coordinated vulnerability disclosure policy and remediation procedures, and in Article 14 an early warning notification within 24 hours of becoming aware. That only works if someone reads, assesses and decides on reports. BSI TR-03183-3, a technical guideline from the German Federal Office for Information Security, defines two roles for this, PSIRT and CSIRT, and response times of 5 and 10 working days. For mid-sized manufacturers, the right fit is the model that the FIRST PSIRT Services Framework calls "Distributed": a small core coordinates, and existing staff from the product teams take on the tasks alongside their regular work, with clear responsibilities and named deputies.

What is a PSIRT, and how does it differ from a CSIRT?

The Forum of Incident Response and Security Teams (FIRST) is the global association of security teams. Its PSIRT Services Framework version 1.1 describes six service areas: stakeholder ecosystem management; vulnerability discovery (receiving reports, monitoring); triage and analysis (qualification, reproduction, identifying affected products); remediation (fix, quality assurance, release); disclosure (informing partners, coordinators and reporters, security advisory); training. The "Distributed" organisational model provides for a small core that sets the rules and procedures and spreads the work across representatives of the product teams, instead of building a large central team. For a mid-sized manufacturer, this is the right form.

A CSIRT (Computer Security Incident Response Team), by contrast, deals with incidents in the company's own infrastructure: office IT, servers, production. In section 4.3.1, TR-03183-3 requires both roles with separate mailboxes, because the consequences differ. A vulnerability in a product can trigger the reporting obligation under Article 14; an incident in the office IT can fall under NIS2 or the GDPR. The same word "CSIRT" also refers to the government bodies to which manufacturers report, in Germany CERT-Bund at the BSI.

Why does the CRA in practice require a PSIRT?

The Regulation does not prescribe an organisational form, but it does set tasks that someone has to carry out. Annex I, Part II, point (6) requires a contact address, point (5) a coordinated vulnerability disclosure policy, point (4) the publication of information on fixed vulnerabilities. Article 13(8) requires appropriate policies and procedures to handle and remediate vulnerabilities reported from internal or external sources, and Article 13(6) requires vulnerabilities in bought-in components to be reported to whoever manufactures or maintains them. Article 14 requires an early warning within 24 hours and a notification within 72 hours, each from the moment of awareness, and a final report no later than 14 days after a corrective or mitigating measure is available.

In paragraph 213, the Commission guidance C(2026) 5252 states that the manufacturer should assess such information immediately; it is regarded as having become aware once it has a reasonable degree of certainty that active exploitation is taking place. A manufacturer that has not organised this assessment starts the clock too late, or cannot show afterwards when it started. That is why TR-03183-3 requires roles with defined tasks and authority, deputies and the four-eyes principle: under section 4.4.7, no analyst may close a report alone.

Which roles does TR-03183-3 require?

• PSIRT: responsible for vulnerabilities in products and services, mailbox psirt@, its own OpenPGP key, handling at least in English.
• CSIRT: responsible for the company's own infrastructure, mailbox csirt@, its own key.
• Separation: except in microenterprises, the two roles must not be held by one and the same person (section 4.3.1). For this, the TR refers to Article 3, point (19) of the Regulation and thus to Recommendation 2003/361/EC: microenterprises have fewer than ten employees and an annual turnover or balance sheet total of no more than EUR 2 million; a manufacturer with 50 employees does not qualify.
• Authority: tasks and decision rights are clearly defined; the PSIRT acts without asking senior management for approval at every step.
• Four-eyes principle: no report is closed by one person alone.

How does the process run, from report to security advisory?

The five steps follow the FIRST framework, reduced to what is feasible and supplemented with the TR's response times.

1. ReceiptEvery report, whether it arrives via psirt@, the form, support, CERT-Bund or a customer, goes into a case with a timestamp. The reporter receives a reply written by a person, within 5 working days under the TR, preferably the same day.
2. QualificationDoes the report concern one of your products, and which version? A genuine vulnerability or scanner output without evidence? Any signs of active exploitation, such as logs, affected customer systems, extortion? The result is one of three classifications: no product relevance, vulnerability without signs of exploitation, suspected active exploitation. In the third case, escalate immediately under Article 14; see The first 24 hours.
3. ReproductionReproduce the vulnerability in a test environment, determine the affected products and versions, rate the severity (usually with CVSS). This leads to the detailed response to the reporter within 10 working days: confirmed, rejected, follow-up questions, or an explanation of the delay with a commitment to an update within a further 10 working days.
4. RemediationFind the cause, develop the fix, test it, release it, distribute it. If the vulnerability lies in a bought-in component, the report goes to that component's manufacturer under Article 13(6). In reportable cases, the date on which the fix becomes available starts the 14-day deadline for the final report.
5. Security advisoryPublish after the update (Annex I, Part II, point (4)): description, affected products, impact, severity, guidance. The TR requires a confirmed vulnerability to be published within 90 days and recommends the machine-readable CSAF format. The case is then closed under the four-eyes principle, with the reporter credited if they wish.

What does a manufacturer with 50 to 500 employees need as a minimum?

Five roles, each with a deputy. With 60 employees, that might be four people holding several roles; with 400, ten. What matters is that every role has two names against it.

In addition, there is the CSIRT role for the company's own IT, in practice the head of IT with a deputy. CERT-Bund mediates if a case with a reporter stalls.

Checklist: what must be in place before the first report

• Mailboxes psirt@ and csirt@ with keys, read by at least two people.
• security.txt and a reporting form with an anonymous option, both online.
• A coordinated vulnerability disclosure policy published, with a date and a review date.
• Five roles with names, mobile numbers and deputies in a call chain that works outside working hours.
• Two people with tested access to ENISA's single reporting platform.
• A product list with versions and the Member States in which the products are in use.
• A decision rule for "actively exploited?", written as a checklist.
• Template wording in English for the personal first reply (no auto-responder; TR: 5 working days), the detailed response and informing users.
• A record template with four timestamps: first observation, awareness, escalation, submission.
• Two tabletop exercises a year, one of them with a weekend scenario, never with reports to the real channels.

Free toolsecurity.txt generatorMakes your PSIRT visible to the outside world: a security.txt with PSIRT and CSIRT addresses under TR-03183-3 is created in a few minutes.Create the file

Who is responsible outside working hours?

The TR's response times of 5 and 10 working days apply to the reply to the reporter. The deadline under Article 14 applies to the notification to the authorities and is counted in hours: 24 hours from awareness, weekends included. That does not mean someone has to sit at a desk around the clock. It means that a report reaches someone even on a Saturday, who reads it, makes a rough classification and, if there is a suspicion, wakes the lead. Three things make this workable: the mailboxes forward to a phone or are monitored by a service; the call chain has a fixed order with a time limit for each step; and the person who submits notifications has advance approval to send an early warning with limited information. Under paragraph 215 of the guidance, the early warning contains only limited information; for this, the platform asks for the product, version, Member States, a short description and the time of detection. Anyone who waits for a signature on Monday has missed the deadline.

What belongs in the record?

From 11 December 2027, Article 13(7) requires manufacturers to systematically document relevant cybersecurity aspects, including vulnerabilities of which they become aware. For the reporting obligation, the record is already the evidence that the deadline was met. At a minimum it should contain:

• Time and channel of the first observation.
• Who read the report, and when.
• The outcome of the initial assessment with reasons: actively exploited or not, since when, on what basis.
• The moment of awareness.
• Who was alerted, and when.
• Time and confirmation of every submission.
• Time of informing users and of the fix becoming available.
• Who closed the case.

The record is written as things happen, not reconstructed afterwards.

Free templatesCRA Reporting KitRoles, call chain, procedure and record as templates to adapt, plus a CVD policy under TR-03183-3. Word, Excel and PDF.Request the kit

What this means in practice

Most mid-sized manufacturers do not fail at the fix, but at receiving the report. The psirt@ mailbox exists, but nobody reads it. The report arrives at 19:00 on a Friday and is seen at 09:00 on Monday. Or only one person can submit a notification, and they are on holiday. This part, readiness, can be settled with a few decisions. CRA Response Center monitors the mailbox, classifies every report, alerts the manufacturer's on-call team by SMS and e-mail when a report is important, and records in the history who took the case on, when awareness was confirmed and how the deadlines stand. Assessment, remediation and submission stay with the manufacturer's PSIRT.

Frequently asked questions

Further reading

• The first 24 hoursThe plan from the moment a report comes in, hour by hour.
• security.txt under RFC 9116 and TR-03183-3The reporting address that makes the PSIRT visible to the outside world.
• Coordinated vulnerability disclosure policyThe commitments the PSIRT keeps towards reporters.
• Spam in the security mailboxClassifying beg bounties, scanner reports and bulk mail without losing a genuine report.

Sources

• Regulation (EU) 2024/2847, Article 13(6), (7) and (8), Article 14, Annex I, Part II, Publications Office of the EU, 20 November 2024.
• Commission guidance C(2026) 5252, Annex, paragraphs 213 to 218, European Commission, 27 July 2026.
• BSI TR-03183-3 Vulnerability Reports and Notifications, Version 1.0.0, sections 4.3 and 4.4, German Federal Office for Information Security, 20 August 2025.
• BSI-CS 019: Handling vulnerabilities, recommendations for manufacturers, version 2.0 (in German), German Federal Office for Information Security, 11 July 2018.
• PSIRT Services Framework Version 1.1, FIRST.