Search the Cyber Resilience Act for the word "PSIRT." It isn't there. Neither is "CSIRT," "security.txt," "CVSS," nor ISO/IEC 29147. The vocabulary that every vendor briefing now treats as the CRA's vulnerability-handling requirement appears nowhere in Regulation (EU) 2024/2847. What the statute names is a function and a set of outcomes, written into Annex I Part II. The gap between the industry shorthand and the legal text is not pedantry. It is exactly where compliance programmes drift.
The current round of "stand up a PSIRT before 2026" briefings is directionally right and technically loose. Right, because you cannot meet the law without a team doing this work. Loose, because the CRA never tells you to buy a product, run a portal, or adopt a numeric score. It tells the manufacturer to achieve specific results, and to keep achieving them for the whole declared support period. Build to the acronym and you get an org chart. Build to Annex I Part II and you get something you can defend.
What the statute actually requires
Annex I Part II is a short list of standing duties, not a project with an end date. A manufacturer must identify and document the vulnerabilities and components in a product, including a machine-readable software bill of materials. It must address and remediate vulnerabilities without delay, and ship security fixes separately from feature updates where that is technically feasible. It must run a coordinated vulnerability disclosure policy, publish a contact address so anyone can report a flaw in the product or its third-party components, and distribute updates through a secure mechanism. Once a fix ships, it has to disclose enough about the vulnerability for users to identify affected products and act.
None of those clauses says "CSIRT." None mandates CVSS v4, SSVC, a PGP key, or a security.txt file. Those are sound engineering practice, and most mature teams will use some of them. They are the means people choose, not the outcome the law requires. Writing "CRA requires CVSS 7.0" into a policy asserts something the Regulation does not.
One provision does name a concrete obligation. Article 13(17) requires a single point of contact that lets users reach you directly and rapidly: easy to find, listed in the user information, and not restricted to an automated form. If your product's only reporting channel today is a generic support inbox, that clause alone is already unmet.
Why the clock is already running
CE marking under the CRA applies from 11 December 2027, which is where most planning attention goes. The date that should worry a product-security lead sits earlier. The Article 14 reporting duties for actively exploited vulnerabilities and severe incidents begin on 11 September 2026. Reporting presumes the machinery behind it already exists: something is watching shipped products, triaging what comes in, and able to move within hours. You cannot bolt a reporting reflex onto a company that has no handling function underneath it.
That is what makes the "before 2026" urgency real, even where the framing is imprecise. The task is not buying a PSIRT. It is standing up the Annex I Part II function so the September reporting obligation has something to report from.
The minimum function, stated plainly
If you are starting from a support inbox, this is the smallest thing that meets the outcomes rather than the acronym:
- A monitored intake channel behind the single point of contact, acknowledged and never lost.
- A queryable index of what shipped — which products contain which components and versions — so a new upstream CVE becomes a five-minute lookup instead of a two-week audit.
- A tracked path from report to fix to disclosure, timestamped, because the timeline is your proof you acted without delay.
- A reliable way to publish advisories to the affected users.
- Named ownership for each of those, with the authority to hold a release when an unresolved issue crosses a severity line you set in advance.
That is a function, not a font of acronyms. How you staff and charter it, and how the roles map to each Annex I Part II duty, is the build problem, worked through in the PSIRT roles playbook. The disclosure policy that faces external researchers is its own discipline, in the coordinated vulnerability disclosure post.
Read the requirement off the statute, not off the vendor slide. The CRA does not care whether you call it a PSIRT, a CSIRT, or a product-security cell. It cares whether the eight things in Annex I Part II happen, on time, for as long as the product is supported. Name the function whatever you like; build it so those outcomes are somebody's job.