How to set up a PSIRT and vulnerability disclosure process for a hardware product company

To set up a PSIRT (product security incident response team) in a hardware company, publish a way to receive vulnerability reports, name the people who triage them, agree how fixes and advisories are released, and, for products sold in the EU, prepare the Cyber Resilience Act reporting route before the first exploited vulnerability arrives. Seven steps below cover all of it for a small or mid-size device maker.

Why a hardware company needs a PSIRT now

Firmware stays in the field for years, and a vulnerability found in a product you shipped is still your problem. The EU Cyber Resilience Act (Regulation (EU) 2024/2847) turned that into law: since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents in their products under Article 14, and from 11 December 2027 the vulnerability handling duties in Annex I Part II apply to every product placed on the EU market. The UK product security regime and buyers' security questionnaires ask for the same thing: a working process, not a shared mailbox.

Step 1: Publish how researchers can reach you

• A vulnerability disclosure policy that says what is in scope, how to report, what reporters can expect and what you will not do (no legal action against good-faith research). Our VDP template is a starting point.
• A security.txt file at /.well-known/security.txt (RFC 9116) with a contact, an expiry date and a link to the policy. The security.txt generator builds one in your browser.
• One security@ address that is monitored every day, with an encryption key if you accept sensitive details.

This covers Annex I Part II points (5) and (6): a coordinated vulnerability disclosure policy and a contact address for reporting vulnerabilities, including in third-party components.

Step 2: Name owners and an on-call rota

Role	Who in a small company	Does what
PSIRT lead	Product owner or head of firmware	Accepts or rejects reports, sets severity, signs off advisories
Deputy	Senior firmware engineer	Covers absences, reproduces issues
Engineering contact per product line	Firmware or platform lead	Builds and tests the fix
Legal / regulatory contact	Compliance or management	Signs CRA reports, handles disclosure disputes

A 24-hour deadline does not pause for weekends, so the rota must cover holidays.

Step 3: Triage every report the same way

1. Acknowledge the reporter quickly and give a reference number.
2. Reproduce on the affected firmware versions; use the SBOM of each version to see which models share the vulnerable component. See firmware SBOM.
3. Score severity with CVSS and prioritise with exploitation data such as CISA KEV and EPSS. See KEV and EPSS.
4. Decide whether there is reliable evidence of active exploitation. If there is, the CRA clock in Step 5 has started.

ISO/IEC 30111 describes this internal handling process; ISO/IEC 29147 describes the reporter-facing side. Our CVD process guide explains both.

Step 4: Fix, release and disclose

• Fix without delay and ship the security update free of charge, with an advisory that states the impact and what users should do (Annex I Part II points (2) and (8)).
• Distribute updates securely: signed images, integrity checks, rollback protection (point (7)).
• After the fix is out, publish the advisory: affected products and versions, impact, severity and remediation (point (4)). Machine-readable advisories in CSAF with VEX statements help customers' scanners. See CSAF and VEX.
• Credit the reporter if they agree.

When the vulnerable code sits in a chip vendor's SDK or an ODM's build, coordinate with them; ISO/IEC TR 5895 covers multi-party disclosure.

Step 5: Prepare the CRA reporting route

Report	Deadline under Article 14
Early warning, actively exploited vulnerability or severe incident	Within 24 hours of becoming aware
Vulnerability or incident notification	Within 72 hours of becoming aware
Final report, exploited vulnerability	At most 14 days after a corrective or mitigating measure is available
Final report, severe incident	Within one month after the 72-hour notification

Reports go through the ENISA Single Reporting Platform to the coordinating CSIRT of your main EU establishment. Test access with at least two people before you need it, and keep templates ready. Details: CRA 24h/72h reporting.

Step 6: Record everything

Log when you became aware, what you knew, what you decided and what you sent. Authorities and customers will look at the timeline, and the log is your evidence that the process works.

Step 7: Review after each case

After every significant case, check what was slow: intake, reproduction, the supplier, the release. Feed the result into the next firmware release and into supplier contracts, for example a clause that requires your ODM to deliver fixes and build access within agreed times.

Run it yourself or outsource it

A small device maker can run this process with two named people and good templates. If nobody can watch the security inbox every day, intake and coordination can be outsourced while you keep the decisions. SoftWSP's PSIRT service does exactly that, and drafts CRA reports for the manufacturer to submit.