PentrCRA reporting is live. Know your exposure before the clock starts
CRA Article 14 reporting has applied since 11 September. What it asks, what it does not, and why the work starts before the 24-hour clock does.
On 11 September 2026 the first operational part of the Cyber Resilience Act started to apply. Manufacturers of products with digital elements now have to report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform. Most of what has been written since is about the reporting itself: who files, through which form, by when.
That matters, and if you have not sorted it out yet, it should be first on your list. This post is about the step before it. The reporting clock starts when you become aware of a problem. How much you already know about your own products decides whether that moment is a surprise.
What applies now¶
Article 14 covers two kinds of event: a vulnerability in your product that is being actively exploited, and a severe incident affecting the security of your product. For an actively exploited vulnerability, the sequence is:
- an early warning within 24 hours of becoming aware;
- a vulnerability notification within 72 hours, with general information and any mitigations;
- a final report within 14 days of a corrective measure being available.
Severe incidents follow the same 24 and 72-hour steps, with a final report within a month. Reports go through the SRP, which forwards them to the CSIRT acting as coordinator for your main establishment and to ENISA. You also have to inform affected users, and in some cases all users.
Two details are easy to miss. First, the obligation covers products already on the EU market, not only new ones. Second, the Commission's guidance says you do not have to report, retroactively, exploitation you already knew about before 11 September.
The rest of the regulation, including the essential requirements and the vulnerability handling processes in Annex I, applies from 11 December 2027.
What Article 14 does not ask¶
The reporting duty is narrower than it sounds. It is not about every vulnerability you have. It is about vulnerabilities someone is actually exploiting, and incidents that actually affected security.
This means a weakness found in your own test is not, by itself, an actively exploited vulnerability. If your pen test finds an SSRF in an API, you fix it. You do not file it with ENISA, unless you also find evidence that someone else got there first. Where that line falls for a specific case is a question for your counsel, not for a vendor's blog. But it is worth being clear that testing does not create reporting obligations on its own.
The uncomfortable part is legacy¶
New products can be designed for the CRA. The harder problem is what is already out there: a device line sold five years ago, firmware whose original team has moved on, a cloud backend that three product generations still talk to. The CRA counts a product's remote data processing as part of the product, so that backend is in scope too.
For these products, the first sign of trouble is often external: a CSIRT, a researcher, a customer's security team, a threat report that names your product. At that point the clock is already running, and the first question is what you knew about that part of the system before today.
If the answer is "nothing recent", the 24 hours go into finding out what the system even exposes. If the answer is a dated record of what was tested, what was found and what was fixed, the 24 hours go into the question that matters: is this new, or is it something we already understood?
A record cuts both ways¶
We should be honest about one thing. A dated record of your tests shows what you knew and when. If a test found a problem in March and it was still open in September, the record shows that too.
We do not think that is an argument for not looking. It is an argument for fixing what you find, and for keeping the retest in the same record as the original finding. A finding, a fix and a confirmed retest is about the best evidence of diligence a manufacturer can show. An unexamined system is not a defence.
December 2027 is closer than it looks¶
From 11 December 2027, Annex I Part II requires manufacturers to apply effective and regular tests and reviews of their products' security, along with an SBOM, a coordinated disclosure policy and a working update process. Conformity assessment will look for evidence of all of this in your technical documentation, and the CRA expects that documentation to be kept for at least ten years or the support period, whichever is longer.
Two words in that requirement are worth reading slowly. "Regular" suggests a single annual test will be hard to defend for a product that ships updates every month. "Effective" suggests the tests have to reach the parts of the product that matter, not only its marketing site.
Where Pentr fits, and where it does not¶
Pentr tests what is reachable over a network: hosts, ranges, web applications and authenticated APIs. For many manufacturers, that is the cloud backend and the device-facing APIs, which is often where legacy risk sits. Each run produces a sealed record of what was tested, found and retested, which you can keep as part of your technical documentation.
Pentr does not test firmware or hardware, file reports on the SRP, generate SBOMs or perform conformity assessment. If you need those, you need other tools and, for some product classes, a notified body. Also note that our standard retention is one year, so export the locker if you need to keep it for the CRA's ten years.
Before December 2027¶
A short list we would work through, in this order:
- List every product on the EU market, including legacy lines and the backends they depend on.
- Decide who declares "aware". Name the person and the escalation path that can meet 24 hours on a weekend.
- Register on the SRP and confirm which CSIRT coordinates for your main establishment.
- Publish a disclosure policy and a contact point, so researchers report to you rather than about you.
- Set a testing cadence per product, tied to its release rhythm, and keep each run's evidence with the release it covers.
- Plan retention for ten years. Whatever produces your test evidence, make sure it can be exported and still verified later.
The ENISA Single Reporting Platform page has the registration guidance and FAQs. If you want to see what a sealed test record looks like, the locker page walks through one.