PSIRT: What It Is and How to Build One (Complete Guide)

A Product Security Incident Response Team (PSIRT) is the organisational function responsible for receiving vulnerability reports about a manufacturer's own products, triaging and reproducing them, coordinating remediation with engineering, and managing public disclosure. It sits at the intersection of security research, software engineering, and communications — and is now effectively mandated for any manufacturer selling products in the EU under the Cyber Resilience Act.

---

PSIRT vs CSIRT vs SOC — What Each Team Actually Does

Confusion between these three functions is common, and conflating them produces governance gaps. The table below draws the boundary cleanly.

Team	Primary mission	Inbound signal	Outbound action
SOC (Security Operations Centre)	Detect and respond to active threats against the organisation's own environment	SIEM alerts, EDR telemetry, network anomalies	Contain, eradicate, recover internal incidents
CSIRT (Computer Security Incident Response Team)	Manage security incidents that affect the organisation's own systems, data, or people	Internal reports, SOC escalations, law enforcement	Incident closure, forensics, breach notification to regulators (e.g., GDPR Art. 33)
PSIRT (Product Security Incident Response Team)	Manage vulnerability reports about products the organisation ships to customers	External researchers, customers, bug bounty, automated scanners, CERT feeds	Patches, advisories, CVE assignment, coordinated public disclosure

A router manufacturer hit by a ransomware attack on its corporate network needs its SOC and CSIRT. A researcher who finds a stack overflow in that same router's management interface needs the PSIRT. Organisations that lack a PSIRT route both calls to the same team — which is how vulnerabilities get buried in help-desk queues for six months.

---

Why PSIRT Matters Now: The CRA Mandate

The EU Cyber Resilience Act (CRA) — Regulation (EU) 2024/2847, applicable from 11 December 2027 for most obligations — does not contain the word "PSIRT," but its requirements in Art. 13 and Art. 14 describe a PSIRT function in everything but name.

Art. 13(6) requires manufacturers to "identify and document vulnerabilities contained in the product with digital elements, including by drawing up a software bill of materials." Art. 13(7) requires that vulnerabilities "be addressed without undue delay and, where applicable, in accordance with the coordinated vulnerability disclosure policy referred to in Art. 13(8)." Art. 13(8) explicitly mandates a coordinated vulnerability disclosure (CVD) policy that includes contact details for third-party researchers.

Art. 14 escalates further: manufacturers must notify ENISA of an actively exploited vulnerability with an early warning within 24 hours and a full notification within 72 hours. Member-state CSIRTs receive a copy. This is not aspirational — non-compliant manufacturers face market surveillance authority investigations and fines up to €15 million or 2.5% of global annual turnover under Art. 64.

The CRA applies to any manufacturer, regardless of where they are incorporated, whose products are placed on the EU market. A California-based IoT startup with a single EU distributor is in scope. For those manufacturers, the PSIRT function is not optional infrastructure — it is compliance infrastructure.

---

The FIRST PSIRT Services Framework: What It Covers

The Forum of Incident Response and Security Teams (FIRST) publishes the PSIRT Services Framework, currently at v1.1. It is the closest thing the industry has to a universal PSIRT standard and is directly referenced in guidance from ENISA and BSI.

The framework organises PSIRT work into five service areas. The table below maps each area to what it covers and the CRA article it most directly satisfies.

Service area	What it covers	CRA article satisfied
Stakeholder Ecosystem Management	Identifying customers, researchers, suppliers, and CERTs; maintaining contact lists; operating a bug bounty or VDP	Art. 13(8) — CVD policy with contact details
Vulnerability Discovery	Internal fuzzing, penetration testing, dependency scanning, SBOM-driven CVE monitoring	Art. 13(6) — identify and document vulnerabilities
Vulnerability Triage	Reproducing reports, CVSS/EPSS scoring, root-cause analysis, SLA assignment	Art. 13(7) — "without undue delay" (requires knowing severity)
Vulnerability Remediation	Patch development, backport decisions, coordination with upstream open-source maintainers	Art. 13(7) — remediation; Annex I Part II — security updates
Vulnerability Disclosure	Advisory drafting, CVE assignment via CNA, coordinated release with reporters, ENISA notification	Art. 14 — 24h/72h reporting; Art. 13(8) — CVD policy

An organisation whose PSIRT function demonstrably covers all five service areas can point auditors and market surveillance authorities to concrete evidence for each CRA obligation.

---

PSIRT Intake: How to Receive Vulnerability Reports

A PSIRT that is hard to reach receives reports late — or never, which means researchers go straight to full disclosure. The intake layer is the cheapest investment with the highest return.

Dedicated security contact. Publish a security email address (e.g., security@yourdomain.com) linked from the product documentation and the company website footer. Provide a PGP public key. FIRST recommends listing the contact in a machine-readable security.txt file at /.well-known/security.txt per RFC 9116.

CVD policy page. A one-page policy stating: what products are in scope, what you commit to (acknowledge within 48 hours, provide a fix timeline, no legal action against good-faith reporters), and what you ask of reporters (give you reasonable time before public disclosure). Siemens ProductCERT, SAP Product Security Response, and Microsoft MSRC all publish public CVD pages — their language is a useful template.

Bug bounty or VDP. A Vulnerability Disclosure Programme (VDP) is free to operate; a bug bounty adds cash rewards for valid reports. For CRA compliance, a VDP is sufficient. Bug bounties accelerate researcher engagement but require PSIRT capacity to handle increased volume. Do not launch a bug bounty before your triage SLAs are in place — it creates a queue you cannot serve.

Automated feeds. Subscribe to CVE feeds (NVD, vendor advisories) filtered to your dependency graph. If you maintain an SBOM per CRA Art. 13(6), cross-referencing new CVEs against it is automatable with tools such as Grype or OSV-Scanner.

---

Triage and Severity Scoring: CVSS, EPSS, and SLA Tiers

Every report that arrives must be triaged before any other action. Triage answers two questions: is this real, and how bad is it?

Reproduce first. A report that cannot be reproduced is not yet confirmed. Assign it to an engineer familiar with the affected component and give them a reproduction deadline — five business days is standard practice.

Score with CVSSv3.1. The Common Vulnerability Scoring System version 3.1 produces a base score from 0.0 to 10.0 using six base metrics (attack vector, attack complexity, privileges required, user interaction, scope, confidentiality/integrity/availability impact). Base scores are computed without environmental context; supplement with environmental and temporal metrics for internal prioritisation.

Layer in EPSS. The Exploit Prediction Scoring System, maintained by FIRST, outputs a daily probability (0–1) that a CVE will be exploited in the wild within 30 days. A CVSSv3 High (7.5) flaw with an EPSS score of 0.87 is more urgent than a Critical (9.1) flaw with EPSS 0.03. Mature PSIRTs gate patch SLAs on both scores together.

A practical SLA structure (these are rule-of-thumb figures, not regulatory mandates):

Severity	CVSSv3 Base Score	Target patch release
Critical	9.0 – 10.0	30 days
High	7.0 – 8.9	60 days
Medium	4.0 – 6.9	90 days
Low	0.1 – 3.9	Next scheduled release
Informational	0.0	No patch required

When EPSS exceeds 0.5, escalate one tier regardless of CVSS base score.

---

Disclosure Timeline: The CRA Clock and CVD Convention

Once a vulnerability is confirmed, two clocks run simultaneously.

The CRA clock (Art. 14). If the vulnerability is being actively exploited in the wild, the 24-hour early warning to ENISA starts from the moment the manufacturer "becomes aware." The 72-hour full notification follows. "Becomes aware" has not yet been defined in a harmonised standard (this remains an open interpretive question as of mid-2026), but the conservative reading is: the moment the PSIRT confirms the report and can verify active exploitation evidence — not when a patch is ready.

The CVD clock. Under coordinated disclosure conventions established by CERT/CC and formalised by FIRST, the researcher is typically given a 90-day embargo from the date of the vendor's first acknowledgement. After 90 days, the researcher may publish regardless of whether the vendor has shipped a fix. Google Project Zero operates on this same 90-day timeline with a 14-day grace extension if a patch is imminent.

Both clocks demand that your PSIRT acknowledge reports promptly. An auto-reply is not acknowledgement; a human response confirming receipt and providing a case number is.

---

Worked Example: A Researcher Reports an RCE in Your Product

This walkthrough applies the framework to a concrete scenario.

Day 0 — Report arrives. A security researcher emails security@example.com describing a heap buffer overflow in the SNMP parser of your network switch firmware, version 3.4 and earlier. They include a proof-of-concept script.

Day 0, within 4 hours — Acknowledge. The PSIRT engineer on duty replies, assigns case PSIRT-2026-0041, thanks the reporter, and asks for permission to share the report internally with engineering.

Days 1–5 — Reproduce. The firmware engineer confirms the overflow is real, achievable remotely without authentication, and produces arbitrary code execution on the device. CVSSv3.1 base score: 9.8 (Critical). EPSS at first scan: 0.12 (no known public exploit yet). SLA: 30-day patch target.

Day 5 — ENISA check. No active exploitation is confirmed in threat intelligence feeds. The Art. 14 clock is not running yet. This assessment is logged and revisited weekly.

Day 6 — CVE request. The PSIRT requests a CVE ID from MITRE (or self-assigns if the organisation is a CVE Numbering Authority). CVE-2026-XXXXX is reserved.

Days 6–28 — Patch development. Engineering develops a fix for firmware 3.4.1. The PSIRT coordinates to ensure the fix is complete and does not introduce regressions. A backport to 3.2 (the oldest supported branch) is also prepared.

Day 28 — Advisory drafted. The PSIRT drafts a security advisory: CVE ID, affected versions, fixed versions, CVSSv3 score, a summary of the vulnerability class, and credit to the reporter. No exploit details that would help attackers are included.

Day 29 — Reporter review. The draft advisory is shared with the researcher for factual review. They confirm accuracy and agree to a Day 30 coordinated release.

Day 30 — Coordinated public disclosure. Firmware 3.4.1 is published. The advisory goes live on the product security page. CVE-2026-XXXXX is published on the NVD. The researcher publishes their own write-up simultaneously. No surprises for either side.

Post-disclosure. Threat intelligence monitoring begins in earnest. If exploit code appears in the wild and active attacks are confirmed, the Art. 14 clock starts from that moment — ENISA notification within 24 hours.

---

What an Immature PSIRT Looks Like

Failure modes are well-documented across public post-mortems. Recognising them is the first step to avoiding them.

No dedicated intake. Security reports arrive in a support@ alias managed by a help desk whose SLA measures first-response time, not security impact. Reports are closed as "cannot reproduce" without engaging an engineer. Researchers escalate to full disclosure.

No CVD policy. Researchers do not know whether the organisation will respond, retaliate, or ignore them. Security Twitter becomes the de-facto disclosure channel.

Legal as first responder. The first call a PSIRT engineer makes is to the legal team, which issues a cease-and-desist to the reporter. The CVD community learns about this and stops reporting. New vulnerabilities are sold to brokers instead.

CVSS-only prioritisation. Every Critical-scored issue jumps the queue, regardless of whether there is any exploit activity. Engineering is perpetually firefighting CVSS 9s that have zero real-world exploit likelihood while medium-scored issues with active exploitation sit in the backlog.

No SLA enforcement. Patch timelines exist in a document but are not tracked. Post-mortems reveal that a 30-day SLA became a 200-day reality because nobody owned the escalation path.

---

Standing Up a PSIRT from Scratch: The 30-60-90 Day Checklist

Days 1–30 — Foundation

• Designate a PSIRT owner (can be a single engineer in a small organisation; does not need to be a dedicated role initially)
• Publish a security contact email and PGP key
• Create a /.well-known/security.txt per RFC 9116
• Write a one-page CVD policy and publish it on the company website
• Set up an internal case-tracking queue (a separate project in your issue tracker is sufficient)
• Define the product scope: which products does the PSIRT cover?
• Draft an acknowledgement email template

Days 31–60 — Process

• Define severity tiers and SLA targets using CVSSv3.1 and EPSS
• Map internal escalation paths: who is the engineering owner for each product?
• Write an advisory template (CVE ID, affected versions, fixed versions, CVSS score, description, credit, references)
• Apply to become a CVE Numbering Authority (CNA) with MITRE, or identify which existing CNA covers your products
• Subscribe to NVD and relevant vendor advisory feeds; filter by your dependency SBOM
• Train engineering leads on the PSIRT workflow and their responsibilities

Days 61–90 — Compliance and maturity

• Conduct a tabletop exercise using the RCE scenario above or an equivalent
• Map your process against the FIRST PSIRT Services Framework v1.1 service areas and identify gaps
• Document the Art. 14 notification procedure: who calls ENISA, using which form, with what information?
• Establish a threat intelligence feed to detect active exploitation of your CVEs
• Review and update the CVD policy based on lessons learned from any real reports received
• Brief legal, communications, and executive leadership on the PSIRT process and their roles in a high-severity incident

This 90-day path produces a PSIRT that can demonstrate compliance with CRA Art. 13 and Art. 14. It will not be mature — maturity takes years and case volume — but it will be defensible to a market surveillance authority.

---

Links and Further Reading

• CVD Policy: How to Write a Coordinated Vulnerability Disclosure Policy
• CRA Hub: EU Cyber Resilience Act Compliance Overview
• SBOM Guide: Software Bill of Materials Under the CRA