PSIRT Guide: Product Security Incident Response

Every organisation that ships software, firmware or connected hardware will receive vulnerability reports about its products, and without a product security incident response team (PSIRT) those reports get lost, mishandled or answered too late. The pressure has risen sharply: since 11 September 2026, manufacturers of products with digital elements on the EU market must report actively exploited vulnerabilities and severe incidents under the Cyber Resilience Act (CRA) within 24 hours. This guide explains what a PSIRT does using the FIRST PSIRT Services Framework, how to choose an operating model, the vulnerability handling workflow from intake to advisory, how CRA reporting fits in, and how to measure the function. It is written for product security leads, engineering managers, CISOs at software and device vendors, and anyone setting up vulnerability handling for the first time. The maturity view is in the Vulnerability Disclosure Maturity Model; this page covers how to run the team.

Key takeaways

A PSIRT serves products, not a constituency. FIRST separates PSIRTs from CSIRTs: the PSIRT handles vulnerabilities in what you sell, the CSIRT handles incidents in what you run.
Six service areas define the job: stakeholder ecosystem management, vulnerability discovery, triage and analysis, remediation, disclosure, and training and education.
The operating model is a scaling decision. Distributed PSIRTs scale across large portfolios; centralised PSIRTs suit smaller or more uniform ones.
CRA reporting is a clock, not a disclosure. A 24-hour early warning, 72-hour notification and a final report go to the national CSIRT and ENISA through the single reporting platform, separately from your public advisory.
Fix quality matters as much as speed. Incomplete fixes and advisories without post-patch actions leave customers exposed after they have patched.

What a PSIRT is and how it differs from a CSIRT

FIRST publishes two companion frameworks. The FIRST CSIRT Services Framework Guide covers teams that serve a constituency. The PSIRT Services Framework (version 1.1, published spring 2020) covers teams that handle vulnerabilities in a vendor's products and services. The two work together: coordinating and national CSIRTs warn their constituents using information that vendor PSIRTs publish.

Aspect	PSIRT	Enterprise CSIRT
Focus	Vulnerabilities in products and online services the organisation ships	Incidents affecting the organisation's own systems
Main inputs	Reports from finders, partners, coordinators, component advisories, internal testing	Alerts, user reports, threat intelligence
Main outputs	Fixes, security advisories, CVE records, machine-readable advisories, regulatory reports	Containment, eradication, recovery, notifications
Key partners	Engineering, product management, legal, support, upstream suppliers, downstream OEMs	IT operations, legal, communications, retainer firms
Typical standards	ISO/IEC 29147, ISO/IEC 30111, CVSS, CSAF, RFC 9116	NIST SP 800-61 Rev. 3, ISO/IEC 27035

ISO/IEC 29147:2018 covers receiving vulnerability reports and publishing remediation information; ISO/IEC 30111 covers the handling activities between those two points. ISO's page lists 29147 as due for revision, so check for a new edition before citing it in contracts.

The FIRST PSIRT service areas

The framework groups PSIRT work into six service areas. The table lists every service.

Service area	Services	What it means in practice
1. Stakeholder ecosystem management	1.1 Internal stakeholder management; 1.2 Finder community engagement; 1.3 Community and organisational engagement; 1.4 Downstream stakeholder management; 1.5 Incident communications coordination within the organisation; 1.6 Reward finders with recognition and acknowledgement; 1.7 Stakeholder metrics	Executive support, researcher relations, OEM and partner notification, coordinated communications, hall of fame or bounty
2. Vulnerability discovery	2.1 Intake of vulnerability reporting; 2.2 Identify unreported vulnerabilities; 2.3 Monitoring for product component vulnerabilities; 2.4 Identifying new vulnerabilities; 2.5 Vulnerability discovery metrics	Report channels, monitoring the internet for unreported issues, tracking third-party component advisories against the SBOM, internal testing
3. Vulnerability triage and analysis	3.1 Vulnerability qualification; 3.2 Established finders; 3.3 Vulnerability reproduction	Applying the bug bar, scoring severity (the framework references CVSS), working with repeat finders, reproducing in a controlled environment
4. Remediation	4.1 Remedy release management plan; 4.2 Remediation; 4.3 Incident handling; 4.4 Vulnerability release metrics	Choosing patch, release or mitigation; fixing across supported versions; handling vulnerabilities exploited in the wild
5. Vulnerability disclosure	5.1 Notification; 5.2 Coordination; 5.3 Disclosure; 5.4 Vulnerability metrics	Notifying partners under embargo, coordinating with finders and coordinators, publishing advisories and CVE records
6. Training and education	6.1 Training the PSIRT; 6.2 Training the development team; 6.3 Training the validation team; 6.4 Continuing education for all stakeholders; 6.5 Provide feedback mechanisms	Feeding root causes back into the secure development lifecycle

Operational foundations

Before the services, the framework lists foundations at three levels:

Strategic: executive sponsorship, stakeholder identification, a PSIRT charter with mission and purpose, the organisational model, and management and stakeholder support.
Tactical: budget, staffing, and resources and tools.
Operational: policies and procedures, and evaluation and improvement.

The framework also defines working terms worth adopting verbatim in your policy: a bug bar (criteria that decide whether a bug is a security vulnerability), an embargo (holding details until fixes or mitigations are available), a finder (anyone who identifies a potential vulnerability) and a coordinator (an optional party helping vendors and finders).

Choosing an operating model

Model	How it works	Fits	Watch out for
Distributed	A small core PSIRT operations team works with security representatives in each product team	Large, diverse portfolios; spreads cost and scales well	People doing triage and fixes do not report to the PSIRT, so service levels need executive backing
Centralised	A larger PSIRT staff, drawn from several departments, reports to a senior executive	Smaller or more homogeneous portfolios	Scales less well as products are added or acquired
Hybrid	Central intake, triage and disclosure; distributed remediation	Most mid-size and large vendors, shaped by structure and development strategy	Unclear hand-offs between central and product teams

Decision guidance

Whatever the model, the PSIRT needs an escalation path above product management, because the framework places budget, staffing and executive sponsorship among its foundations: a team that can only ask product teams to fix will lose to feature deadlines.

Small vendor or start-up: one named owner, a published security.txt and disclosure policy, a shared mailbox with an encryption key, and an agreement with engineering on fix targets. That meets the basics and the CRA requirement to have a contact point.
Growing vendor: centralise intake and triage, appoint product security champions, and integrate the SBOM so component advisories are matched automatically.
Large or acquisitive vendor: distributed or hybrid model with a central disclosure and regulatory reporting function, because CRA reports must be consistent across product lines.
Bug bounty or not: a bounty adds volume and cost; start with a disclosure programme and add a bounty once triage capacity is proven. See the Bug Bounty and Vulnerability Disclosure Guide.

The vulnerability handling workflow

Intake: publish /.well-known/security.txt as defined in RFC 9116 (the Contact and Expires fields are required; Policy and Encryption are optional and recommended) and a disclosure policy. Acknowledge every report within [2] working days. See the Vulnerability Disclosure Policy Template.
Qualify: apply the bug bar, confirm affected products and versions, and score severity. See the CVSS v4 Guide.
Check exploitation: decide early whether there is evidence of active exploitation, because that starts the CRA clock (next section) and changes remediation urgency.
Reproduce and analyse root cause: in an isolated environment; record the vulnerable code path so the fix addresses the class, not just the reported input.
Plan the remedy: decide fix, configuration mitigation or end-of-support guidance for each supported version; agree release dates with engineering and an embargo with the finder and partners.
Fix and validate: the validation team tests the fix, including variant analysis for bypasses of the same root cause.
Notify and coordinate: give downstream OEMs and partners advance notice under embargo; coordinate timing with the finder and any coordinator.
Disclose: publish a human-readable advisory, a CVE record (directly if you are a CVE Numbering Authority, otherwise through one), and a machine-readable CSAF advisory. See the CSAF Security Advisories Guide and the VEX Guide for stating which products are not affected.
Close the loop: credit the finder if they wish, feed the root cause into secure development training, and update the bug bar if needed. See the Secure Software Development Lifecycle (SSDLC) Guide.

What a good advisory contains

Identification: CVE IDs, advisory ID, affected and fixed versions per product, severity vector.
Exploitation status: whether exploitation is known, stated plainly.
Remediation: the fix, any workaround, and what customers must do after patching, such as terminating sessions, rotating keys or credentials the product stores, or checking for indicators.
Detection guidance: indicators or log patterns customers can search, where the PSIRT has them.
Revision history: every update dated, because advisories change as facts emerge.

EU Cyber Resilience Act reporting and vulnerability handling

The CRA (Regulation (EU) 2024/2847) entered into force on 10 December 2024. According to the European Commission, its reporting obligations apply from 11 September 2026; the main product obligations apply later (from 11 December 2027). The full legal picture is in the EU Cyber Resilience Act Guide; the operational impact on a PSIRT is summarised here.

Report	Actively exploited vulnerability	Severe incident affecting product security
Early warning	Within 24 hours of becoming aware	Within 24 hours of becoming aware
Notification	Within 72 hours	Within 72 hours
Final report	No later than 14 days after a corrective or mitigating measure is available	Within one month
Route	Single reporting platform; goes to the CSIRT of the member state of main establishment and to ENISA simultaneously

What counts: the recitals describe an actively exploited vulnerability as one where the manufacturer establishes that a malicious actor has exploited it; good-faith testing and disclosure do not trigger notification. A severe incident includes compromise of the manufacturer's development, production or update processes, for example malicious code in an update channel.
Who triggers the clock: define in your procedure who decides "aware", because the 24-hour window is short. A practical rule is to make the PSIRT duty officer responsible for opening a regulatory record as soon as exploitation evidence is plausible, with legal review running in parallel rather than first.
Support periods: the recitals say the support period for vulnerability handling should be no less than five years unless the product is expected to be used for less. That drives how many versions the PSIRT must fix.
Vulnerability handling requirements: the regulation's Annex I Part II expects, among other things, an SBOM for the product, remediation without delay, public information about fixed vulnerabilities, a coordinated vulnerability disclosure policy, a contact address for reports and secure distribution of updates. Confirm the exact obligations against the text with legal counsel.
Small enterprises: recital 120 says administrative fines do not apply to micro and small enterprises for missing the 24-hour early warning deadline. The other obligations still apply.

Where identity fits

Many product vulnerabilities expose credentials rather than data: hard-coded keys, default passwords, session tokens or signing keys. Fixing the code does not revoke what attackers already took. After CitrixBleed, Citrix's advice to kill active sessions came after the fixed builds, and some organisations were accessed after patching. A PSIRT advisory should say which secrets the product stores and how customers rotate them. The Gladinet hard-coded keys case shows why static keys in shipped products need a design fix, not only a patch: every installation of CentreStack and Triofox shared the same AES key and IV, so attackers could forge access tickets, read web.config and steal ASP.NET machine keys (CVE-2025-14611). The same product family had already shipped a hard-coded machineKey earlier in 2025 (CVE-2025-30406), a pattern a PSIRT root cause review should catch and feed into the bug bar.

Framework mapping

Framework	Reference	PSIRT relevance
NIST CSF 2.0	ID.RA-08, PR.PS-06, GV.SC-07	Processes to receive and respond to disclosures; secure development; understanding supplier and component risk
NIST SP 800-53 Rev. 5	RA-5(11), SA-11, SA-15, SR-4, SR-8, IR-6(3)	Public disclosure programme; developer testing; development process; provenance; notification agreements; supply chain coordination
NIST SP 800-218 (SSDF)	RV.1, RV.2, RV.3	Identify and confirm vulnerabilities; assess, prioritise and remediate; analyse root causes. See the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide
ISO/IEC 29147 and 30111	Disclosure; handling processes	The international reference for intake, handling and advisory publication
EU CRA	Article 14, Annex I Part II	Reporting of exploited vulnerabilities and severe incidents; vulnerability handling requirements

Measuring the PSIRT

The framework includes metrics services in four areas (1.7, 2.5, 4.4, 5.4). Useful starting measures:

Time to acknowledge: median working days from report to acknowledgement, target within the published policy.
Time to remediate by severity: median days from qualification to fix availability, split by critical, high, medium and low.
Regulatory timeliness: percentage of CRA early warnings, notifications and final reports filed within deadline; the target is 100 percent.
Fix quality: number of advisories later revised because the fix was incomplete or bypassed.
Component exposure time: days from an upstream component advisory to your own advisory or VEX statement.
Finder satisfaction: repeat finders and complaints about handling, a leading indicator of public zero-day disclosure.

Common failure patterns

Incomplete fixes: patching the reported input rather than the root cause invites a bypass. In ToolShell, the exploited CVE-2025-53770 and CVE-2025-53771 bypassed earlier fixes for related SharePoint flaws.
Advisories without post-patch actions: customers patch and assume they are safe while stolen sessions or keys remain valid.
No owner for component advisories: the PSIRT waits for external reports while a vulnerable library sits in every release. Track components through the SBOM Guide approach.
Regulatory clock started late: nobody is empowered to decide that exploitation is "established", so the 24-hour CRA early warning is missed.
Hostile handling of finders: slow replies or legal threats push researchers to publish without coordination.
Distributed model without authority: product teams deprioritise fixes because the PSIRT has no agreed service levels or executive escalation.

Practitioner checklist

Write a PSIRT charter with mission, scope of products, executive sponsor and organisational model.
Publish security.txt with Contact, Expires, Policy and Encryption fields, and a disclosure policy.
Define a bug bar and severity scoring method, and agree remediation targets with engineering.
Map every product to its supported versions and support period end date.
Match component advisories against product SBOMs automatically.
Name who decides exploitation is established and who files CRA reports, with 24x7 cover.
Use an advisory template that includes post-patch actions, detection guidance and revision history.
Publish machine-readable CSAF advisories and VEX statements alongside human-readable ones.
Run variant analysis on every critical fix before release.
Report 4 to 6 PSIRT metrics quarterly to the sponsor.

PSIRT Guide: build product vulnerability handling that meets CRA reporting