Since 11 September 2026, a manufacturer in scope of the EU Cyber Resilience Act must send an early warning within 24 hours of becoming aware of an actively exploited vulnerability, a fuller notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available (Article 14(2)). The clock runs from awareness. For a company with a VDP, awareness usually begins in the security inbox.
So the first report you receive is not only a customer-relations moment. It is the start of a process that either finds the facts quickly or leaves you guessing about when you knew.
What's affected
Anyone who publishes a VDP, and especially teams where the security mailbox is watched by one engineer between other duties. The CRA's notification duty covers actively exploited vulnerabilities and severe incidents, not every report. Most reports will be ordinary findings that fall under your own policy. Triage is where you tell the two apart.
Be exact about what binds and what advises:
- The CRA deadlines above are binding for in-scope manufacturers.
- CISA's BOD 20-01 is binding on US federal agencies only. It requires a stated expectation of when the reporter hears back and, for agencies, tracking of median time to validate, to respond and to remediate.
- The OpenSSF guide for open source projects suggests acknowledging a report within 1 to 2 days. That is guidance.
- Your own VDP is a promise. Whatever you write becomes the standard people hold you to.
How to check if you're exposed
Run a dry run. Send a realistic fake report to your security address from a personal account, with a short description, steps and an impact claim. Record these timestamps:
received : mailbox delivery time
first human read : who, when
acknowledged : reply sent to the reporter
validated : reproduced or rejected
severity assigned : with the rubric used
fix owner assigned : name and ticket link
If the gap between received and first human read is longer than a working day, your published SLA is fiction. If nobody can say who decides severity, you cannot make the 24 hour call either.
What to do now
- Pick SLAs you can meet with the people you have. Suggested starting points for a small team, written in business days:
| Stage | Target |
|---|---|
| Acknowledge receipt | 2 business days |
| Initial assessment: valid, invalid or need more info | 7 business days |
| Status update to reporter | Every 14 days until closed |
| Fix for critical or exploited issues | As fast as the fix can safely ship |
| Fix for other confirmed issues | Within 90 days, or agree an extension |
- Make the first reply short and human. For example: "Thanks for the report. We received it today and have assigned it to a named owner. We will tell you within seven business days whether we can reproduce it. Please do not publish details before we have talked."
- Triage in this order: Is it in scope? Can we reproduce it? Does it expose customer data, allow code execution or bypass authentication? Is there any sign it is already being exploited?
- Write down the moment you establish evidence of exploitation. That timestamp is when the 24 hour question starts if the CRA applies to your product.
- Use a ticket for every report, with a private label, and keep the reporter's emails attached.
- Score severity with CVSS, then adjust for your context. A medium score on an unauthenticated data endpoint may deserve a critical response. 7. Close the loop. Tell the reporter when the fix ships, ask whether they plan to publish, and offer credit.
A simple adjustment rubric helps two people reach the same answer:
| Question | If yes |
|---|---|
| Is customer data readable or writable without authentication? | Raise one level |
| Does it need an unusual setup that few customers use? | Lower one level |
| Is there public proof of concept code? | Raise one level |
| Is a compensating control already in place and verified? | Lower one level |
Record the answers in the ticket so a later reviewer can see why a level was chosen. Re-score when new facts arrive, such as a public proof of concept or a customer who reports odd traffic. The point is a consistent, explainable decision, not a perfect number.
How to avoid this trap
The failure pattern is a policy that says "within 24 hours" and an inbox that nobody opens until Monday.
- Set an auto-reply that is honest about hours and promises a human acknowledgment time, not a fix time.
- Assign a primary and a backup for the mailbox, with a rota that follows holidays.
- Keep a one-page runbook that says who may declare an incident and who files any regulatory notice.
- Track median time to acknowledge and to validate each quarter. If either grows, adjust the promise before a researcher notices.
- Treat out-of-scope and low-quality reports with a template reply, so they do not consume the same attention as real ones.
Why it matters
Researchers judge a program by its first response. A fast, specific acknowledgment tells them the report went to a person. Silence is how disagreements turn into public posts, usually with a date attached.
There is a legal edge too. Under the CRA, the question "when did you become aware" can matter. A mailbox that is read sporadically does not help your answer, and neither does a process that never records the time. You do not need a big team to fix that. You need a timestamped record and a named owner.
If you do only one thing this month, run the dry run and publish the SLA you measured, not the one you hoped for.
Try it yourself
Take the timestamp template above and replay your last three real security reports through it, even if they came through support or social media. Note where information waited. Then walk through the incident and postmortem flow below and see which of your stages map to it.
Click through it at your own pace, or open it full screen.
Quick check
When does the CRA's 24 hour early warning clock start for an actively exploited vulnerability?
When the manufacturer becomes aware of it. Article 14(2)(a) says without undue delay and in any event within 24 hours of becoming aware.
Is the 90 day fix target in a VDP a legal requirement?
No. It is a common convention. The CRA's hard deadlines concern notifying authorities of actively exploited vulnerabilities and severe incidents, not fixing ordinary reports.
