CRA: Your Pentester's Findings Aren't Reportable. An Attacker's Are.

Quick Answer: Since 11 September 2026, CRA Article 14 requires manufacturers of products with digital elements sold in the EU to report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform: an early warning within 24 hours, a notification within 72 hours and a final report later. The obligation covers only flaws with reliable evidence of malicious exploitation. A vulnerability your own testers find in a controlled engagement isn't reportable: you fix it. The same flaw found by an attacker first becomes a regulatory event, which makes the timing of security testing a CRA question, not only a security one.

In June we wrote about the Cyber Resilience Act's first deadline. That deadline has now passed. Since 11 September 2026, the CRA reporting obligations are live, ENISA's Single Reporting Platform is operational, and the obligations cover products already on the EU market, not only new launches.

Most of what's been written since is about how to file a report inside 24 hours. This article is about the other side of the same rule: how to have fewer things to file.

Two kinds of events: actively exploited vulnerabilities and severe incidents affecting product security. Everything else stays inside your normal vulnerability process.

Actively exploited vulnerabilities. An actively exploited vulnerability is one where there's reliable evidence that a malicious actor has used the flaw in a system without the owner's permission. Theoretical severity doesn't decide it. A critical flaw nobody has exploited isn't reportable. A modest one that's being exploited is.

Severe incidents. A severe incident is one that negatively affects, or could affect, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or one that has led or could lead to malicious code being introduced or executed in the product or in users' systems. The second part is easy to miss: a compromised build pipeline or update server can meet that definition even when the product itself has no known flaw.

What's excluded matters just as much. A vulnerability found by your own engineers, by a penetration tester you hired, or in a code review isn't reportable on its own. You still have to handle it properly, but it goes through your vulnerability process, not to a national CSIRT.

The obligation also isn't retroactive. Exploitation you already knew about before 11 September 2026 doesn't need to be reported now.

When the manufacturer becomes aware of the exploitation or incident. The Commission's CRA guidance of 27 July 2026 describes that moment as the point where a prompt initial assessment gives you a reasonable degree of certainty that it has happened. A raw alert or an unverified claim doesn't start the clock. A completed forensic investigation isn't required either.

That cuts both ways. A prompt first look at an odd alert doesn't eat into your 24 hours. But the guidance expects that first look to happen quickly, so leaving an alert unexamined isn't a way to delay becoming aware. The practical answer is a triage process fast enough that awareness and assessment happen on the same day, weekends included.

Three reports at 24 hours, 72 hours and a final stage, each with a different job:

Affected users have to be informed as well, and in some cases all users. Non-compliance with the reporting obligation can bring fines of up to €15 million or 2.5% of worldwide annual turnover, whichever is higher.

Then there's the cost that doesn't show up in the regulation. NIS2 requires the organisations it covers to manage supply-chain security, so an enterprise customer that learns about a CRA report on your product is likely to follow up with questions of its own.

None of that applies to the flaw your tester found in May and you patched in June.

The CSIRT designated as coordinator in the member state of your main EU establishment. All reports go through the Single Reporting Platform, which delivers them to that CSIRT and to ENISA at the same time.

For manufacturers outside the EU, the regulation works down a list: the member state of your authorised representative, then of your importer, then of your distributor, and finally the member state where the product has the most users. If that's you, settle the answer before an incident, not during one.

Not by name. The CRA never uses the words "penetration test". What it requires, for products placed on the market from 11 December 2027, is that they ship without known exploitable vulnerabilities and that manufacturers run effective, regular security tests and reviews. The same requirements add a coordinated vulnerability disclosure policy and a contact address for reporting vulnerabilities.

Here's the detail that matters for older products. The full Annex I requirements generally don't apply retroactively to products already on the market, unless they're substantially modified later. But the reporting obligation does apply to them, starting now. So for legacy products there's no formal testing requirement, while the reporting exposure is already live. Testing them is voluntary, and it's also the only real way to shrink that exposure.

If you want the test to double as compliance evidence, the report needs more than a list of findings. Look for a written scope and rules of engagement, a named methodology such as OWASP WSTG, PTES or NIST SP 800-115, findings scored with CVSS and classified by CWE, and a retest that shows the fixes worked. That's what a market surveillance authority or an enterprise customer can actually read and rely on.

The one where exploitation is most likely and most costly. If you have more than one product in scope, you don't need to test everything at once. Rank them by:

Then match the depth of testing to the risk. A vulnerability assessment, automated discovery with manual validation of serious findings, typically works as a baseline across a wider portfolio. A manual penetration test, where someone actively tries to exploit each finding and the business logic, belongs on the products at the top of that list.

Published European prices for a web application pentest in 2026 run from about €1,700 to €12,750, with most single-application startups landing between €3,400 and €5,100. Price is driven mostly by scope: the size of the application, the number of user roles, the API and SSO surface, and whether a retest is included.

Watch the retest line when comparing quotes. Lower-priced assessments often exclude it or charge for it separately, and an excluded retest can add 10 to 20% to the effective cost. Confirm it before putting two quotes side by side.

Timing matters as much as price. A full engagement plus remediation and a retest takes weeks, not days. Booking in 2026 leaves room to fix what's found before the December 2027 requirements apply. Our Focused Web App Pentest starts at €1,800 and includes a remediation retest, so the quote you sign is the number you actually pay.

A short list, in order:

If you're still unsure which of your products are in scope or how they're classified, a CRA Readiness Assessment answers that before you spend on testing.

The reporting obligation will catch some incidents no matter what you do. The ones it doesn't have to catch are the flaws you found first.