How to Set Up a PSIRT for Connected Products

PSIRT meaning: a Product Security Incident Response Team is the function inside a company that identifies, assesses and resolves security vulnerabilities in the products it makes and sells ^[1]. It isn’t a separate island. FIRST, the global incident-response forum, describes it as part of the organization’s wider product development and security work ^[1].

If you sell connected products in the EU, a PSIRT is no longer optional in practice. Since 11 September 2026, the EU Cyber Resilience Act has required manufacturers to report actively exploited vulnerabilities within 24 hours ^[2][3]. This guide sets out how to stand one up: charter, roles, intake, triage, fixes and advisories, and the reporting clock. It’s part of our product security operations hub.

PSIRT vs CSIRT (and vs CVE)

• PSIRT handles vulnerabilities in your products ^[1].
• CSIRT usually means a team that responds to incidents in an organization’s own IT, or a national team. Under the CRA, manufacturers notify a national "CSIRT designated as coordinator" and ENISA simultaneously, via the single reporting platform ^[2][4].
• CVE is an identifier for a specific publicly disclosed vulnerability. FIRST’s PSIRT Services Framework describes a CVE entry as a widely used way to give a vulnerability a unique identification number, a description and a public reference, and PSIRTs commonly reference CVEs in advisories ^[1].

1. Write a charter

One page is enough to start. It should say:

• Scope: which products, versions and services, including end-of-support products and remote data processing (cloud back-ends) that are part of the product.
• Authority: who can declare a vulnerability, delay a release or publish an advisory.
• Commitments: response targets you can actually meet, and the support period for each product. Under the CRA, vulnerabilities must be handled for the support period, which is at least five years unless the product’s expected use is shorter ^[2].
• Interfaces: engineering, product management, legal, communications, customer support, suppliers.

FIRST’s PSIRT Services Framework organizes PSIRT work into service areas: stakeholder ecosystem management, vulnerability discovery, vulnerability triage and analysis, remediation, vulnerability disclosure, and training and education ^[1]. It’s a useful checklist for what your charter covers.

2. Roles: a starter RACI

Our original RACI for a mid-sized product company. R = responsible, A = accountable, C = consulted, I = informed.

Treat these assignments as a starting point. Who is accountable for releasing a security update varies by company; decide it explicitly.

3. Intake channels

• A public reporting contact. The CRA requires a contact address for reporting vulnerabilities and a coordinated vulnerability disclosure policy ^[2], and the user information must name the single point of contact for vulnerability reports ^[2].
• A published disclosure policy saying what reporters can expect. See our coordinated vulnerability disclosure guide.
• Internal sources: your own testing, SBOM-driven monitoring of components, customer support tickets, field telemetry.
• Supplier advisories from chip, BSP, RTOS and library vendors. The CRA requires manufacturers to report vulnerabilities they find in an integrated component to whoever manufactures or maintains it ^[2].

An SBOM per firmware release is what makes component monitoring work. See SBOM generation for embedded products.

4. Triage and severity

For each report: reproduce it, identify affected products and versions (from the SBOM), rate severity, and decide whether it’s actively exploited.

• Severity. CVSS, maintained by FIRST and currently at version 4.0, produces a numerical score that maps to qualitative ratings such as low, medium, high and critical ^[5]. CVSS also defines Environmental metrics that refine the score for a specific environment, for example the mitigations present and how critical the affected system is ^[6]. Product context matters too: is the vulnerable interface reachable in the field? Is the device safety-relevant?
• "Actively exploited." The CRA defines this as a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the owner’s permission ^[2]. Decide in advance who makes this call and what evidence counts, because it starts the 24-hour clock.

5. Fix, release and advise

• Fix without delay and ship security updates separately from feature updates where technically feasible ^[2].
• Distribute updates securely, and automatically where applicable ^[2]. See our secure firmware update architecture guide.
• Once an update is available, publish information on the fixed vulnerability: description, affected products, impact, severity and remediation guidance. Publication can be delayed in duly justified cases until users have had a chance to patch ^[2].
• Security updates must be free of charge (unless otherwise agreed for a tailor-made product with a business user) and come with advisory messages ^[2].

6. The Cyber Resilience Act reporting clock

Under Article 14 ^[2], for an actively exploited vulnerability:

For a severe incident affecting product security, the 24-hour and 72-hour steps are similar, and the final report is due within one month of the incident notification ^[2].

Practical points:

• Where to report. Notifications go simultaneously to the CSIRT designated as coordinator and to ENISA, via the single reporting platform, from 11 September 2026 ^[2][3][4]. ENISA publishes the list of CSIRTs designated as coordinators ^[4].
• US manufacturers without an EU main establishment report via the coordinator CSIRT of a Member State determined in order: where the authorised representative is, then the importer, then the distributor, then where most users are ^[2]. Work this out now.
• Tell users. After becoming aware, manufacturers must inform impacted users, and all users where appropriate, of the vulnerability or incident and any mitigations, where appropriate in a machine-readable format ^[2].
• Installed base. Reporting applies to in-scope products placed on the market before 11 December 2027 too ^[2].

See the step-by-step swimlanes in our Cyber Resilience Act reporting workflow, and the dates in our EU regulatory timeline.

Where to start

1. Name a PSIRT lead and an executive sponsor.
2. Publish a reporting contact and disclosure policy.
3. Adapt the RACI above, and decide who calls "actively exploited".
4. Set up access to ENISA’s Single Reporting Platform and confirm which CSIRT you’d report to.
5. Make sure every shipped firmware version has an SBOM.
6. Run a tabletop exercise against the 24-hour clock.
7. Measure yourself with our PSIRT maturity self-assessment, and adapt a PSIRT and reporting runbook template.

Spotted an error? Report it to our corrections log. Read our editorial methodology.