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

A minimum viable PSIRT has six parts: intake with a security.txt file, a triage rule, a route to a CVE ID, a fix-and-release path, a CSAF advisory, and VEX statements on which products are affected. Each part is small, and one to three people can run all of them if the templates exist before the first report.

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. Article 69(3) of the Regulation makes the reporting duty reach back: Article 14 applies to products placed on the market before 11 December 2027 as well, so cameras sold in 2023 are covered. Buyers' security questionnaires ask for the same thing: a working process, not a shared mailbox.

• 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 with a contact, an expiry date and a link to the policy. RFC 9116 makes Contact and Expires mandatory, allows Expires only once and recommends a date less than a year ahead. Our security.txt guide for product makers walks through every field.
• 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. Put the Expires date in a shared calendar: a stale file tells researchers your contact may no longer work.

With two people, one leads and one deputises, and both can act alone on any step; with three, the third person owns regulatory reports and the advisory. A single person cannot cover a 24-hour clock through holidays, so a one-person PSIRT needs an outsourced intake or a named back-up outside the team.

A confirmed vulnerability that will be disclosed should get a CVE ID, so customers' scanners can match it. Only a CVE Numbering Authority (CNA) assigns one, and the CNA Operational Rules 4.2.1 list "Software and hardware Suppliers, including product security incident response teams (PSIRTs)" among the organisations that become CNAs. Rule 4.2.1.1 gives the first opportunity to assign to the CNA with the most appropriate scope, often the supplier of the product. A small maker that is not a CNA asks a CNA whose published scope covers it; when the flaw sits in a chip vendor's SDK, that vendor may own the assignment. CNA rules explained covers the process.

• 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)).
• Publish it in CSAF too. The CSAF 2.0 standard defines a "Security Advisory" profile and a "VEX" profile; VEX gives each product one of four states, fixed, known_affected, known_not_affected or under_investigation, and requires an impact statement for every product marked not affected. 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.

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.

Under Article 14(7), a manufacturer with no EU establishment notifies the CSIRT of the Member State of its authorised representative, then importer, then distributor, and otherwise of the Member State with the most users. Article 14(8) adds a second audience: once aware, inform the impacted users about the vulnerability or incident and the mitigations they can apply, where appropriate in a machine-readable format. ENISA's Single Reporting Platform page links the platform, its user guides and the list of CSIRTs designated as coordinators; on 2026-11-13 it noted that the platform was upgraded to version 1.3 on 4 November 2026.

Log when you became aware, what you knew, what you decided and what you sent; authorities and customers will look at the timeline. After every significant case, check what was slow: intake, reproduction, the supplier, the release. Feed the result into the next release and into supplier contracts, for example agreed fix times for your ODM.

Each step above answers a specific provision of the Cyber Resilience Act. The table is our mapping of the Regulation text, read on 2026-11-13; the last column is the evidence an authority or a customer audit can ask to see. CRA Annex I explained covers the whole annex.

Article 13(7) also asks manufacturers to document the vulnerabilities they become aware of; Step 7 produces that record.

AI helps with reading and writing around a case; the decisions stay with named people. Matching components to known CVEs and ranking them by KEV, EPSS and CVSS is work that code does reproducibly. A language model is useful for turning that ranked list into readable notes, summarising a long researcher report, and drafting advisories or VEX justifications from evidence an engineer collected.

It should not decide that a product is not affected, set a severity or judge active exploitation, because each of those is a statement the manufacturer signs. SoftWSP works this way: code extracts the SBOM from a firmware image, matches it against NVD, CISA KEV, FIRST EPSS and CSAF advisories and scores it with a fixed ruleset, and AI drafts a report in which every claim sentence must cite a matched record, for an engineer to review. AI-assisted SBOM and vulnerability triage shows the full path.

• Policy and security.txt published, the file signed, and its Expires date in a shared calendar.
• security@ inbox checked every day by a named person, with an auto-reply that says what reporters can expect.
• Rota covering weekends and holidays.
• SBOM for every firmware version in support, so "which models?" takes minutes.
• Written decision rules: the CVSS version you use, how KEV and EPSS feed priority, and who decides that a case shows active exploitation.
• A CNA contact for CVE IDs, or your own CNA scope.
• Reporting platform access tested by two people, and the coordinating CSIRT identified under Article 14(7).
• Templates for acknowledgment, early warning, notification, final report, user notice and CSAF advisory.
• Supplier contacts at the chip vendor and the ODM, with agreed response times and a sharing rule such as TLP.
• Support period declared for each product and stated in the user information.

Once these basics run reliably, FIRST's PSIRT Services Framework describes the full catalogue of PSIRT services, and the PSIRT Maturity Document helps you decide what to add next.

• Starting the clock at confirmation. Article 14 counts from when the manufacturer becomes aware of active exploitation. Write down who decides, then log the time.
• Forgetting the users. Informing impacted users under Article 14(8) is a separate duty from notifying the CSIRT.
• Forgetting old products. Article 69(3) puts products sold before December 2027 under the reporting duty too.
• No SBOM per version. Without one you cannot say which models are affected within 24 hours.
• Fixing only your own copy. Article 13(6) asks you to report a component vulnerability to its maintainer and share your fix.
• A one-person PSIRT. A 24-hour deadline needs a deputy who can act when the lead is away.

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: we triage reports, check which products contain the component, and draft CRA reports for the manufacturer to sign and submit.