Guide · updated 17 October 2026

PSIRT for small device makers: a minimum viable setup

Large vendors have product security incident response teams (PSIRTs) with full-time staff. A 40-person maker of smart thermostats doesn't. But the Cyber Resilience Act expects every manufacturer to receive, triage, fix and report vulnerabilities. Here's the smallest setup that works.

What a PSIRT actually does

Strip away the org charts and a PSIRT does five things:

1. Receives vulnerability reports from researchers, customers, partners and its own monitoring.
2. Triages: is it real, which products and versions, how severe, is it being exploited?
3. Coordinates the fix with engineering and agrees disclosure timing with the reporter.
4. Communicates: security advisories, user notices and, under the CRA, regulator reports.
5. Learns: tracks components, watches for new CVEs, and improves the process.

None of that needs a dedicated team. It needs named owners, a few documents, and cover for evenings and weekends.

The minimum viable PSIRT

Service levels you can actually keep

Publish targets your team can meet. A common baseline for small makers:

• Acknowledge a report within 1–3 business days (much faster if it mentions exploitation).
• Initial assessment within 10 business days.
• Status updates to the reporter at least every 14 days.
• Coordinated disclosure normally within 90 days.

The CRA adds one hard deadline on top: when there's reliable evidence a vulnerability in your product is actively exploited, the early warning to ENISA's platform is due within 24 hours of you becoming aware, weekends included. That's the part small teams struggle with, because it needs someone watching and able to act at any hour. See the reporting requirements.

Triage questions, in order

1. Is the report about our product, and can we reproduce it?
2. Which models and firmware or software versions are affected? Which are still in their support period?
3. How severe is it? What can an attacker do, and what access do they need?
4. Is there evidence of active exploitation? From whom, and how reliable?
5. Does this appear reportable under CRA Article 14? If so, the 24-hour clock is running: escalate to the decision-maker and counsel now.
6. What can users do before a fix ships?

Build, buy or share?

You have three realistic options:

• Run it in-house with the roles above. Cheapest in cash, but someone must carry the pager, and the knowledge sits with one or two people.
• Use a tool for intake and tracking (several CRA platforms offer this). It organises the work but doesn't do it: your team still triages and files.
• Outsource the on-call part: keep engineering ownership of fixes, and let an outside team watch the inbox, triage and file regulator reports as your assigned representative. That's what CRA On Call does.

Start this week

1. Run the free scanner on your domain to see what researchers see today.
2. Generate and publish a security.txt and disclosure policy (the scanner page builds both).
3. Name your PSIRT lead and deputy, and agree who decides on CRA reports.
4. Start the product and version register with your top three product lines.
5. Get the 24h/72h/14-day runbook and walk through it once with the team.

Not legal advice. Where we say something appears reportable, confirm with your counsel.