The CRA Never Says "PSIRT" - But From 11 September 2026 You Need One

Search the text of Regulation (EU) 2024/2847 for the word "PSIRT" and you will not find it. Search it for the capabilities a product security incident response team provides - taking in vulnerability reports, judging them, fixing them, and notifying authorities on a fixed clock - and they are all there, in Articles 13 and 14 and in Annex I, Part II. Since 11 September 2026 those obligations are legally binding, which means the question is no longer whether your company needs the function. It is who owns it, and whether that is written down.

This article provides general guidance, not legal advice. If you need advice specific to your product or situation, consult a qualified legal or compliance professional.

Key points

• The CRA never uses the term PSIRT (product security incident response team). It does require intake, triage, coordination and notification capabilities that amount to the same thing.
• Reporting obligations under Article 14 became applicable on 11 September 2026. ENISA switched on the Single Reporting Platform (SRP) the same day, at what it calls "initial operating capability"^[1].
• The clock is 24 hours for an early warning, 72 hours for a notification, and 14 days for a final report on an actively exploited vulnerability (one month for a severe incident). It starts when you become aware - so define "aware" in writing, now.
• A PSIRT is not your SOC. A CSIRT or SOC defends your own infrastructure. A PSIRT handles flaws in what you ship to other people.
• For a small company this is not a department. It is a named owner, a named deputy, a monitored inbox, one page of triage rules, and SRP access provisioned before you need it.
• Open-source software stewards are not caught by reporting yet. Under Article 24(3) that applies from 11 December 2027.

The CRA never says "PSIRT"

The regulation describes obligations, not org charts. That is deliberate - EU product legislation sets outcomes and leaves companies to organise themselves. But read the obligations in sequence and a shape emerges.

Article 13 requires manufacturers to handle vulnerabilities across the support period, to have a coordinated vulnerability disclosure policy, and to publish a contact point where vulnerabilities can be reported. Annex I, Part II sets out the ongoing vulnerability-handling requirements that run for the product's whole life. Article 14 then sets hard deadlines for telling the authorities when something is actively exploited or an incident is severe.

Put together, the regulation requires you to be able to:

1. Receive a vulnerability report from outside the company, reliably, at any time.
2. Assess it quickly enough to know whether a 24-hour clock has started.
3. Fix or mitigate it, and tell affected users what to do.
4. Notify the authorities through the correct channel, three times, on schedule.

That is the working definition of a product security incident response team. The industry has a name for it; the legislator did not use it. The gap between the two is where companies get caught out, because "nobody is against vulnerability handling" is not the same as "Priya owns it and Marek covers when she is on leave".

A PSIRT is not your SOC

This is the most common and most expensive confusion, so it is worth being blunt about it.

A CSIRT or SOC protects the organisation's own infrastructure: your corporate network, your laptops, your production environment. Its instinct when something goes wrong is to contain and defend.

A PSIRT deals with vulnerabilities in the products, components and services you sell to other people. Its instinct has to be different: coordinate with an external reporter, build and ship a fix through a release process, tell thousands of customers, and file with a regulator.

The skills overlap. The muscle memory does not. A security engineer who is excellent at isolating a compromised host may never have coordinated a disclosure timeline with a researcher, written customer-facing mitigation guidance, or filed a regulatory notification.

If your instinct is to hand CRA reporting to the team that already "does security", stop and check that they have the second set of capabilities, not just the first. FIRST, the global incident response community, publishes a PSIRT Services Framework precisely because these teams face distinct challenges. It is a voluntary community framework, not EU law - nothing in the CRA requires you to follow it - but it remains the most useful existing map of the capabilities the regulation implicitly assumes you have.

The four capabilities, mapped

Intake

You need a route by which a vulnerability reaches you. Article 13 and Annex I, Part II require a contact point and a coordinated disclosure policy. In practice reports arrive from several directions at once: independent researchers, customers' security teams, national CERTs, upstream maintainers of components you ship, and your own scanning of your own SBOM.

The failure mode is boring and common: a security@ address that forwards to a shared mailbox nobody reads at weekends.

Triage

Someone has to decide, quickly, whether what just arrived is an actively exploited vulnerability or a severe incident within the meaning of Article 14 - or neither. This is a judgement call with a legal deadline attached, which is why it cannot sit with whoever happens to pick up the email.

We cover the qualifying tests in detail in Does This Trigger a CRA Report?. What matters here is that a named person is authorised to make that call and to start the clock.

Coordination

Fixing the thing. Getting the patch through your release process, deciding whether to ship a mitigation first, agreeing a disclosure timeline with the reporter, and writing the guidance your users will actually act on. Article 14 also expects you to inform affected users about the issue and, where appropriate, corrective or mitigating measures.

Notification

Submitting the early warning, the notification and the final report through ENISA's Single Reporting Platform. The platform is now the channel: once you submit, the coordinator CSIRT that receives your report disseminates it to other relevant CSIRTs in Member States where your product is available, and ENISA receives it simultaneously. We walk through the mechanics in Inside the ENISA Single Reporting Platform.

The platform is live - and still maturing

ENISA deployed the SRP on 11 September 2026, the same day the obligations became applicable. Two details from the launch are worth holding on to.

First, ENISA described this as the initial operating capability and said it will "continue to improve and expand its functionalities over the coming months based on operational experience and user needs^[1]". The channel you are legally required to use is itself still being built out. Expect changes; do not build a process that assumes today's screens are permanent.

Second, ENISA has published real supporting material: an FAQ, user manuals, tutorial videos, a glossary, a factsheet in several EU languages, and a dedicated help desk. If your reporting owner has not read the manuals, that is a half-day of work that will pay for itself the first time you need the platform under pressure.

Common misconception, worth correcting: the reporting obligations do not apply to open-source software stewards yet. Under Article 24(3) they apply from 11 December 2027. If you steward an open-source project, you have time - and stewards cannot be fined under the CRA in any case.

The clock starts when you become aware

This is the operational heart of the whole thing, and the part most teams have not settled.

The 24-hour early warning is tied to the point at which you become aware. That single word decides whether you filed on time. And in any later dispute, the question will not be "when did you become aware?" - it will be "show me how you determined that, and show me the record".

So write it down. A workable internal definition covers four things:

• Who can declare awareness. A named role, with a named deputy. Not "the security team".
• What counts. A credible report with enough detail to assess, evidence of exploitation, or your own confirmed finding - versus a vague rumour, an unverified scanner hit, or a social media post you have not corroborated. Draw the line explicitly and give examples.
• When the timestamp is taken. The moment of the declaration, recorded in a system with an audit trail - your ticketing system is fine - not reconstructed afterwards from memory or an email thread.
• What happens next. Who is paged, what the first hour looks like, and who submits.

Your clock-start record is evidence. Treat it that way. A dated, versioned internal definition written before an incident is worth considerably more than a well-argued explanation written afterwards.

A minimum viable PSIRT

If you are a ten-person company shipping one connected product, you are not going to staff a team. You do not need to. You need six things:

1. A named owner with the authority to declare awareness and start the clock.
2. A named deputy who covers leave, illness and holidays.
3. A monitored intake channel - a published security contact, per your CVD policy, that someone actually watches. See How to Build a CRA-Compliant Coordinated Vulnerability Disclosure Policy.
4. A one-page triage rule that tells the owner how to decide whether Article 14 is engaged.
5. SRP access provisioned in advance, for at least two people.
6. A one-page runbook: who to call, what to write, where the SBOM lives, how to reach the reporter.

Point 5 deserves emphasis. Nobody should be creating an account on a regulatory reporting platform for the first time at 23:00 on a Saturday with a researcher waiting and twenty of the twenty-four hours already gone. Provision access now, while it is a calm administrative task. Then have both people log in once a quarter so the credentials still work.

Out of hours

The 24-hour clock does not pause for weekends, public holidays or your release freeze. Whatever rota you run should be proportionate to your size - for most small manufacturers that means a phone number that reaches the owner or deputy, not a staffed night shift.

Two points of relief, and one caution.

Under Article 33, the CRA includes support measures for microenterprises and SMEs - we cover what that actually gives you in CRA for Small Companies. And micro and small enterprises are not subject to fines specifically for missing the 24-hour early warning deadline.

The caution: that relief is narrow. It does not exempt a small company from reporting, from the 72-hour and 14-day deadlines, or from the vulnerability-handling requirements in Annex I, Part II. And the top penalty tier under Article 64 - up to €15 million or 2.5% of worldwide annual turnover, whichever is higher - attaches to breaches of Articles 13 and 14. Having no process at all is not a strategy.

What to do this month

1. Name the owner and the deputy. Write both names in a document with a date on it.
2. Write your definition of "aware", with examples of what does and does not count.
3. Provision SRP access for both people and log in once to confirm it works.
4. Read ENISA's SRP manuals and FAQ. Half a day, once.
5. Check your intake channel actually reaches a human within hours, including at weekends. Send a test report from an external address.
6. Write the one-page runbook and put it somewhere findable without VPN access.
7. Run a tabletop. Ninety minutes, one invented report, walk it to a filed early warning. You will find the gap in step three or five, which is the point.

None of this requires budget. It requires somebody to be given the job and the time to do it.

Where to go next

• Check whether your product is caught at all with the scope checker.
• Work backwards from the dates on the CRA deadlines page.
• Sequence the wider programme with the CRA compliance checklist.
• Get your component inventory in order with the SBOM guide - your PSIRT cannot triage what it cannot see.

{{component:callout|level=tip}} One update a week, no noise. The CRA is still moving - the SRP is expanding, harmonised standards are not yet cited in the Official Journal, and guidance keeps arriving. Subscribe to The CRA Brief and we will send you what changed and what it means. {{/component}}