Article 14 of the Cyber Resilience Act (Regulation (EU) 2024/2847) is the first part of the law that applies in practice. It has applied since 11 September 2026, more than a year before the rest of the regulation, and there is no grace period.
It also reaches further back than most people expect. Article 69(3) says the reporting obligations apply to every product in scope that was placed on the market before 11 December 2027. If you sell installable software in the EU today, including versions you released years ago, the clock already applies to you.
What has to be reported
Two things trigger a report:
- An actively exploited vulnerability in your product. That means there is reliable evidence that someone has exploited it in a system without the owner's permission. A vulnerability you found in code review, or one with a public CVE but no known exploitation, does not trigger Article 14 on its own.
- A severe incident that affects the security of your product. Broadly, an incident that harms your ability to protect the availability, integrity or confidentiality of data or functions, or that led to malicious code being introduced or run. A compromised build pipeline or update server is the classic example.
The three deadlines
The clock starts when you become aware of the exploitation or the incident, not when it happened.
| Stage | Actively exploited vulnerability | Severe incident |
|---|---|---|
| Early warning | Within 24 hours | Within 24 hours, including whether you suspect unlawful or malicious acts |
| Notification | Within 72 hours, with what you know about the vulnerability, the exploitation and any mitigations | Within 72 hours, with an initial assessment and any mitigations |
| Final report | Within 14 days of a fix or mitigation being available | Within one month of the 72-hour notification |
Each stage builds on the previous one. You are not expected to know everything at hour 24. You are expected to say what you know and keep going.
Where reports go
Reports are submitted through the single reporting platform run by ENISA. It forwards them to the CSIRT designated as coordinator in the Member State where you have your main establishment, and to ENISA. You file once, not with every country where you have customers.
Work out who on your team will have access to the platform before you need it. Hour 23 is a bad time to discover that nobody has an account.
Telling your users
Article 14(8) adds a second audience. After you become aware of an actively exploited vulnerability or a severe incident, you must also inform the users affected, and where appropriate all users, about what happened and what they can do to reduce the impact. This is where most small vendors have nothing ready: no mailing list of customers by product version, no template, no page to point people to.
A runbook for a small team
Before anything happens
- Publish a way to receive reports: a security.txt file and a short vulnerability disclosure policy. Annex I, Part II of the CRA requires a contact address and a coordinated disclosure policy.
- Name one person who owns the clock and one backup. Write down their phone numbers.
- Keep an up-to-date list of supported versions and the customers on each one.
- Prepare drafts for the early warning, the notification, the final report and the customer notice, so that on the day you only fill in facts.
Hours 0 to 24
- Record the exact time you became aware. Every deadline counts from it.
- Confirm the basics: affected product and versions, how you know it is being exploited, whether it looks malicious.
- Send the early warning. Short and factual is fine.
Hours 24 to 72
- Assess severity and impact, and decide on a mitigation, even a temporary one.
- Send the notification with what you now know.
- Start the customer notice, so it can go out as soon as there is something useful to tell them.
Up to 14 days after the fix
- Ship the fix and tell users how to apply it.
- Send the final report: what the vulnerability was, its impact, the root cause where known and what you changed.
What this means for PHP and Laravel products
Most security problems in PHP products come from dependencies. If a vulnerable Composer or npm package inside your product is actively exploited through your product, that is a vulnerability in your product for reporting purposes. Separately, Article 13(6) asks you to report vulnerabilities you find in components to whoever maintains them.
That makes two habits worth having now: know exactly which dependency versions each release ships (an SBOM, generated from composer.lock and package-lock.json), and get told quickly when one of them gets a known exploited vulnerability.
This guide explains the regulation in plain terms. It is not legal advice. For decisions about your obligations, speak to a qualified adviser.