You need a PSIRT. The CRA just does not call it that
The regulation asks for eight vulnerability-handling duties, a contact address printed in the product documentation, and a clock measured in hours. Nothing part-time survives five years of that.
Practical guidance, not legal advice. The article and annex references below are drawn from Regulation (EU) 2024/2847; check them against the official text before you rely on them.
The Cyber Resilience Act does not ask you for a PSIRT. It talks about CSIRTs, which are the national teams you report to, and it says almost nothing about what you are supposed to have on your own side of that exchange.
Then read what it asks you to do. Eight vulnerability-handling duties in Annex I Part II. A contact address that ships inside the product documentation under Annex II. Reporting deadlines in Article 14 measured in hours. All of it for a support period that Article 13(8) puts at a minimum of five years. Those duties describe a product security incident response team whether or not anyone calls it one. You either have the function or you are relying on somebody happening to be free that week.
What a PSIRT actually handles
The distinction that matters is direction. A security operations centre defends the network you own: your servers, your laptops. The input is telemetry you collect and the output is containment. A PSIRT handles flaws in the product you sold to somebody else. The input is usually a stranger's email and the output is an advisory plus an update that other people have to choose to install.
They fail differently too. A SOC that misses something loses your data. A PSIRT that misses something means a customer runs a vulnerable version of your product for another eighteen months, and after 11 September 2026 it can also mean a filing you did not make.
The reference material for this predates the CRA by years. FIRST, the Forum of Incident Response and Security Teams, publishes the PSIRT Services Framework. ISO/IEC 30111 covers vulnerability handling processes and ISO/IEC 29147 covers disclosure. None of them are mandatory under the CRA. They are worth reading because they describe, in far more detail than the regulation does, the function the regulation assumes you already run.
The duties, and what each one costs you in practice
Annex I Part II lists eight things a manufacturer shall do. Read as documents to produce, they look like a fortnight of work. Read as a job with a rota, they look different.
| What the CRA requires | What somebody actually has to do |
|---|---|
| Annex I Part II (5) and (6): a coordinated vulnerability disclosure policy, and a contact address for reports | Read an inbox every working day, for years, mostly finding nothing |
| Annex II (2): the single point of contact goes in the information accompanying the product | The address is printed in documentation the customer keeps. It has to outlive whoever created it |
| Annex I Part II (1): identify and document vulnerabilities and components, including an SBOM | Rebuild the SBOM when the product changes, and check it against new advisories |
| Annex I Part II (2) and (3): remediate without delay, and apply effective and regular tests and reviews | Continuous work, not a release gate |
| Annex I Part II (4) and (8): publicly disclose information about fixed vulnerabilities, and disseminate updates without delay, free of charge, with advisory messages | Write the advisory, and own the channel it goes out on |
| Article 14: early warning within 24 hours, notification within 72, final report within 14 days or a month | Be able to file at 2am on a Sunday, or have a deputy who can |
| Article 13(8): all of the above for the support period, at least five years | Five years of the above, minimum |
| Article 13(19): display a notification to users when the support period ends | Still be tracking this long after the product stopped being interesting |
No single row on that list needs a team. The list does, because the rows do not arrive one at a time and they do not stop.
Continuity is what breaks
The failure mode has nothing to do with skill. It goes like this. A capable engineer sets up the security address, writes the disclosure policy, publishes security.txt, and does a good job of all of it. Two years later they take a job somewhere else. The mailbox still exists. The Expires date in security.txt lapsed eight months ago and scanners have quietly begun treating the file as stale. Nobody notices, because no reports are arriving.
That last part is what makes it hard to catch. From the outside, a PSIRT that is working and a PSIRT that died with its founder produce the same signal, which is silence. The only difference is whether the silence is real.
The fix is unglamorous and it is a calendar entry. Send a test report to your own security address from an outside account and confirm it reaches a human. Renew the security.txt Expires date. Check that the named deputy still works here.
What this looks like at nine people
Most companies reading this have no security team, and the CRA does not require one. It requires that the function exists and that you can evidence it. At small scale that means six things you can set up in an afternoon.
- A named owner and a named deputy, written down, with the deputy genuinely reachable when the owner is away. Two people, because the Article 14 clock runs through weekends.
- A shared mailbox rather than one person's inbox, so the published address survives a resignation.
- A written triage step answering two questions: is this real, and is it being exploited. The second question is the one that starts the legal clock.
- A log with one line per report: date in, who handled it, what was decided, date closed.
- A recurring calendar entry to test the reporting path end to end and renew the security.txt expiry.
- An after-hours number for counsel, agreed before you need it.
That is a couple of days of setup and something like an hour a month afterwards, until the month when it is not.
If you have not built the front door yet, start with the VDP starter kit, which has the disclosure policy and security.txt templates. The reporting playbook covers what happens once triage decides a flaw is being exploited. This article is the part in between: who owns both of those, for the next five years.
What an assessor will ask for
A market surveillance authority and an enterprise customer's procurement team ask the same question in different words. Neither of them asks whether you have a policy, because everyone has a policy and a PDF costs nothing to write.
They ask for the log. How many reports did you receive last year, what did you do with each, and how long did each take. A log with four entries and honest timestamps is better evidence than a twelve-page process document with none. If you genuinely received nothing, say that, and show that you tested the path anyway. This is why the calendar entry matters more than it looks.
Article 13(13) requires the technical documentation and the EU declaration of conformity to be kept at the disposal of market surveillance authorities for at least ten years after the product is placed on the market, or for the support period, whichever is longer. That is the horizon this function operates on.
The arithmetic
Take a product placed on the EU market on 11 December 2027, the day the CRA fully applies, with the minimum five-year support period. Vulnerability handling under Annex I Part II runs to December 2032. The documentation stays available to authorities until at least December 2037.
Whoever you name as owner this month is unlikely to be the person who closes that file.