Two engineers at a desk reviewing code together on a large monitor

PSIRT & disclosure

PSIRT response SLA examples: published deadlines from regulators, coordinators and vendors

Last updated: 2026-11-13

PSIRT response SLA examples worth copying come from published rules, not from benchmarks: since 11 September 2026 the EU Cyber Resilience Act requires an early warning within 24 hours of becoming aware of an actively exploited vulnerability, CERT/CC publishes reports 45 days after the initial report, and Google Project Zero gives vendors 90 days to ship a patch. The table below lists each published figure with its source and the date we checked it, then shows how a small device maker sets its own targets by severity.

By SoftWSP Firmware Security Desk11 min read

Key takeaways

A PSIRT response SLA is a set of internal time targets for four clocks that start when a vulnerability report arrives.
The examples that hold up are the ones written into a law, a directive or a published policy, so each row below quotes one and says who it binds.
Only the CRA clocks are legal duties for a manufacturer, and only for products on the EU market.
Set each target below the shortest outside clock that applies to the case, and grade cases by CVSS severity, KEV listing and EPSS rather than CVSS alone.

What does a PSIRT response SLA cover?

A PSIRT response SLA is a set of internal time targets for four clocks that start when a vulnerability report arrives. FIRST's PSIRT Services Framework v1.1 puts it plainly: "Response times to external finders should be defined in a SLA, internal to the company." The framework then names the metrics to track, such as the on-time response rate against the SLA (sub-function 2.5.2.1) and the time from intake to completed triage (2.5.2.3), but it gives no figures. Our guide to the framework covers its structure.

The four clocks most device makers write down:

Acknowledge: the reporter gets a human reply and a case number.
Triage: the report is reproduced, scored and marked as exploited or not.
Fix or mitigation: a corrected firmware image, or a workaround users can apply, is available.
Advisory: the public notice with affected versions, severity and remediation is published.

The rest of this page is about what number goes next to each clock. If you are still setting up the team itself, start with how to set up a PSIRT in a hardware company.

Which published deadlines can a PSIRT use as examples?

The examples that hold up are the ones written into a law, a directive or a published policy, so each row below quotes one and says who it binds. We read every source on 13 November 2026; the figures are as published on that date.

Source (date)	Binds or applies to	Clock	Published figure	Clock starts
CRA Article 14(2)(a) (applies from 11 Sep 2026)	Manufacturers selling in the EU	Early warning, actively exploited vulnerability	Within 24 hours	Manufacturer becomes aware
CRA Article 14(2)(b)	Same	Vulnerability notification	Within 72 hours	Manufacturer becomes aware
CRA Article 14(2)(c)	Same	Final report	No later than 14 days	A corrective or mitigating measure is available
CRA Article 14(4)(c)	Same	Final report, severe incident	Within one month	Submission of the 72-hour incident notification
CISA BOD 26-04 (issued 10 Jun 2026)	US federal civilian agencies	Remediation	3 days (plus forensic triage for some rows), 14 days, 60 days, or fix on system upgrade	Per CISA decision table
CISA KEV catalog 2026.11.10	Same, through BOD 26-04	Due date per KEV entry	126 of 162 entries added since 10 Jun 2026 are due in 3 days, 36 in 14 days	Date added to KEV
FDA postmarket guidance (28 Dec 2016)	Medical device manufacturers, non-binding	Communicate with customers; fix	No later than 30 days; no later than 60 days	Learning of the vulnerability
CERT/CC disclosure policy	Cases CERT/CC coordinates	Public disclosure	45 days	Initial report
Google Project Zero policy	Vendors Project Zero reports to	Patch available; details public	90 days; 30 days after the patch	Vendor notified
Google Project Zero, in the wild	Same	Patch available	7 days (3-day grace)	Vendor notified
ZDI disclosure policy	Vendors ZDI reports to	Vendor acknowledgement; fix	Second contact after 5 business days; 120 days to fix	Initial notification
Linux kernel security team	Kernel fixes for undisclosed bugs	Embargo on a fix	Up to 7 calendar days, 14 by exception	Start of the release process
Siemens ProductCERT	Reports to Siemens	First response	"Usually" within one business day	Report received
Cisco Security Vulnerability Policy	Cisco advisories	Advisory publication	Wednesdays at 16:00 GMT; scheduled bundles twice a year for some product families	Publication schedule

Notes on the rows. The CRA clocks are in Article 14 of Regulation (EU) 2024/2847, and Article 71(2) makes Article 14 apply from 11 September 2026. The BOD 26-04 tiers come from the 16-row decision table that CERT/CC publishes as the CISA BOD 26-04 response model: an internet-exposed, KEV-listed vulnerability that gives total control is "3 days & forensic investigation". The KEV split is our count of dueDate minus dateAdded in the cisagov/kev-data feed, catalog version 2026.11.10. The CERT/CC policy states the 45 days apply "regardless of the existence or availability of patches or workarounds". The Project Zero policy grants a grace period of 14 more days when a patch will follow within 104 days. The ZDI policy also allows a public advisory 15 business days after first contact if it has exhausted all reasonable means of reaching the vendor.

The FDA row is narrower than it looks. The 2016 postmarket guidance says FDA does not intend to enforce 21 CFR part 806 reporting for a vulnerability with uncontrolled risk when, among other conditions, the manufacturer communicates with customers no later than 30 days and fixes and distributes a validated fix no later than 60 days after learning of it.

What the table does not give you

None of these sources sets an acknowledgement time a device maker must meet for an ordinary report. The CRA clocks start only with active exploitation or a severe incident; the coordinator deadlines describe when the outside world will publish, not when you must reply. Vendor figures such as the Siemens ProductCERT one-business-day response are self-set commitments by large teams. Treat them as published examples, not as an average or a norm.

Which of these clocks bind a device maker?

Only the CRA clocks are legal duties for a manufacturer, and only for products on the EU market. The other rows matter because they set deadlines around you: your customers' remediation dates and the date a researcher or coordinator will publish.

Type of clock	Rows in the table	What it means for the PSIRT
Your legal duty	CRA Article 14	Fixed. Build the 24-hour route before you need it; see CRA 24-hour reporting for the filing steps
Regulator expectation	FDA 2016 guidance (medical devices)	Meet 30 and 60 days if you want the part 806 enforcement policy to cover you
Your customers' clock	BOD 26-04 and KEV due dates	A federal customer must remediate in 3 or 14 days; your advisory and mitigation must exist before their date
Outside publication clock	CERT/CC, Project Zero, ZDI	Details go public on that date whether or not your firmware fix has shipped
Peer practice	Siemens, Cisco, Linux kernel	Examples of written commitments; copy the structure, set your own numbers

The customer clock is easy to miss. When a vulnerability in your product enters KEV, a federal agency running it is told to remediate by the KEV due date; for an internet-exposed device with an automatable exploit that is 3 days. If the only remedy is a firmware release you have not built, the agency's fallback is your published mitigation. Your advisory timing has to work back from their date.

The outside clock works the same way. A report that arrives through CERT/CC carries a 45-day publication date from day one. Your disclosure policy can ask for more time, and coordinators do extend for hard cases, but plan as if the published date holds.

How does a small maker set its own SLA by severity?

Set each target below the shortest outside clock that applies to the case, and grade cases by CVSS severity, KEV listing and EPSS rather than CVSS alone. Here is a method that uses only the published figures above and your own measured times.

Write down the fixed clocks firstThe 24-hour and 72-hour CRA reports are not negotiable once you are aware of active exploitation, so the decision "is this exploited?" belongs in triage, with a named person who makes it.
Score severity the same way every timeThe CVSS v4.0 specification maps scores to ratings in Table 22: Low 0.1 to 3.9, Medium 4.0 to 6.9, High 7.0 to 8.9, Critical 9.0 to 10.0. Our CVSS calculator computes the v4.0 vector and rating in the browser. Record which version you use.
Raise the tier on exploitation signalsA KEV listing is evidence of exploitation in the wild; EPSS is a probability of exploitation in the next 30 days. FIRST's Using EPSS page says "how to set a threshold (or multiple thresholds) is a very localized effort and may be best achieved through trial and updating over time", so pick your threshold, write it down and review it. Our KEV and EPSS guide shows how to combine the two.
Find the ceiling for each tierTake the shortest published clock that would apply to a case in that tier.
Measure, then set the numberTime your last few cases from report to reproduction and from fix to signed release. Your SLA is the measured time plus margin, as long as it stays under the ceiling. If it does not, the gap is the work item, not the SLA.

The ceilings per tier, taken from the table:

Tier	Trigger	Ceiling that applies	Source of the ceiling
Exploited	KEV-listed, or reliable evidence of exploitation of your product	24 h early warning, 72 h notification with user mitigations; 7 days to a patch if Project Zero reported it	CRA Article 14(2); Project Zero in-the-wild policy
Critical or High, coordinated	CVSS 7.0 or above, reported through CERT/CC	Fix and advisory before day 45	CERT/CC policy
Critical or High, direct researcher	CVSS 7.0 or above, reported directly	The researcher's stated deadline, for example 90 days	Project Zero policy; ZDI 120 days
Medium or Low	CVSS below 7.0, no exploitation signal	Your next scheduled firmware release, inside any researcher deadline	Your release cadence
Medical device, uncontrolled risk	Patient-harm risk not controlled	Customers told within 30 days, validated fix within 60 days	FDA 2016 guidance

Acknowledgement is the one clock you set from scratch. Publish it in the policy: for connectable products sold in the UK, Schedule 1 of SI 2023/1007 requires the manufacturer to publish when a reporter will receive "an acknowledgment of the receipt of a security issues report" and status updates until the issue is resolved. ZDI's policy shows what happens at the outer bound: after five business days without an acknowledgement it makes a second formal contact attempt.

Worked example: what does a written SLA look like?

This is a hypothetical example, not a customer case, and the numbers are the example maker's own choices. A 25-person maker of industrial gateways sells in the EU and the US, has one PSIRT lead and a deputy, and ships a signed firmware release every six weeks. Its measured times on the last four reports: reproduction within two working days, emergency signed build within five working days.

Its published policy says reporters get a human acknowledgement within two business days and a status update at least every 14 days. Its internal SLA reads:

Exploited (KEV-listed or evidence of exploitation): CRA early warning inside 24 hours of the lead's awareness decision, notification with user mitigations inside 72 hours, emergency build in five working days, advisory with the build.
Critical or High: reproduced and scored in two working days, fix in the next release or an emergency build if the release is more than 30 days out, so that the advisory lands before day 45 for CERT/CC cases.
Medium or Low: fix in the next scheduled release; advisory with the release.
Advisory: published in CSAF and HTML the day the fix ships; CRA final report inside 14 days of the fix for exploited cases.

Each figure stays under the ceiling in the tier table, and each comes from the maker's own measured cycle. The PSIRT lead reviews the SLA after every case that missed a target, which is the review FIRST's metrics functions describe.

Where do the SBOM and AI-assisted triage fit?

Triage time is the clock an SBOM shortens most, because "which models and firmware versions contain this component?" is the first question in every case. With an SBOM per firmware version, that answer is a lookup instead of a rebuild.

SoftWSP's firmware analysis extracts the SBOM from the binary image, matches components and versions against CVE records, the CISA KEV catalog and FIRST EPSS, and scores the result with fixed rules. An AI model then drafts the report text, and the platform refuses to store a draft whose claims do not cite the record behind them; an engineer reviews it before anyone acts on it. The code scores, the AI narrates. It does not decide whether a case is exploited, and it does not file CRA reports. Our PSIRT service runs intake and coordination for makers who cannot watch the inbox every day, and drafts the CRA reports for the manufacturer to submit.

What are the common mistakes with PSIRT SLAs?

Copying a big vendor's number. One business day is a published Siemens figure for a large team; a two-person PSIRT that promises the same will miss it.
One fix target for all severities. A single "90 days" misses the 45-day CERT/CC clock for coordinated cases and the 24-hour CRA clock for exploited ones.
Starting the clock at confirmation. CRA clocks start at awareness, and coordinator clocks start at the initial report, not when you reproduce the bug.
Ignoring the customer's clock. A KEV due date of 3 days for your federal customers needs a published mitigation, even if the firmware fix takes longer.
No measurement. An SLA nobody times is a wish; log the timestamps for each of the four clocks. Our CVD process guide shows where each step sits in ISO/IEC 30111.
Treating a peer's release day as an SLA. Cisco's Wednesday publication schedule in its Security Vulnerability Policy is a release calendar, not a response time; it shows that a fixed advisory day helps customers plan.
Forgetting embargo limits upstream. If the fix is in the Linux kernel, the kernel security team's process document allows a fix to be held for up to 7 calendar days, 14 by exception, so your release plan has to fit that window.

Put this guide to work

ServicePSIRT as a ServiceReceive, assess and report vulnerabilities.See the service

Disclosuresecurity.txt and VDP generatorGenerate an RFC 9116 security.txt file from your contact, policy and expiry details. Runs in your browser; nothing is uploaded.Free

Frequently asked questions

Is there an industry-standard PSIRT response SLA?

No single figure is standard. FIRST's PSIRT Services Framework v1.1 says response times to external finders should be defined in an SLA internal to the company, and gives no numbers. The published clocks that exist come from law (the EU Cyber Resilience Act), from coordinators such as CERT/CC (45 days) and Google Project Zero (90 days), and from individual vendor policies.

How fast must a manufacturer acknowledge a vulnerability report under the CRA?

The CRA sets no acknowledgement time for ordinary reports. Its fixed clocks start when the manufacturer becomes aware of an actively exploited vulnerability: an early warning within 24 hours, a vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available (Article 14(2), applying since 11 September 2026).

Does the CISA KEV due date apply to device makers?

No. KEV due dates come from CISA Binding Operational Directive 26-04, which binds US federal civilian agencies. They matter to a device maker because federal customers must remediate KEV-listed vulnerabilities by those dates, as short as 3 days, so a fix or mitigation has to exist first.

What happens if a vendor misses a coordinator's deadline?

The coordinator publishes anyway. CERT/CC discloses 45 days after the initial report regardless of patch availability, Project Zero publishes after 90 days if no patch exists, and the Zero Day Initiative (ZDI) may publish a limited advisory with mitigations at the end of its 120-day deadline.

Should a PSIRT publish its SLA?

Publish the reporter-facing part: how soon you acknowledge and how often you send status updates. The UK PSTI regime requires manufacturers to publish when a reporter will receive an acknowledgement and status updates. Internal fix targets per severity can stay internal, as FIRST suggests.