Cyber Resilience Act: penetration testing and the evidence it leaves
The CRA makes the manufacturer responsible for the security of a product with digital elements for its whole support period, and since 11 September 2026 it has had reporting duties with a clock: 24 hours from learning that a vulnerability in your product is being exploited. You cannot report what you have not found. Testing that proves what is exploitable, and a record of how each finding was handled, is how a manufacturer stays on the right side of both.
When it applies.
- 01Entered into forcemilestone
- 02Reporting obligations apply (Article 14)The date that matters
- 03Full application of the Regulationdeadline
JurisdictionEuropean Union. Applies to products with digital elements placed on the EU market, wherever the manufacturer is based.
In scope, and out.
- Manufacturers of products with digital elements made available on the EU market in the course of a commercial activity, hardware and software alike, wherever the manufacturer is based.
- Importers and distributors carry lighter duties of their own and must pass vulnerability information to the manufacturer.
- Outside it, broadly, are products already covered by sector rules (medical devices, motor vehicles, civil aviation) and free and open-source software supplied outside a commercial activity, for which a separate steward regime applies.
What it asks of you
The CRA is written for the manufacturer, and it is written as a process. Before a product reaches the market it must be free of known exploitable vulnerabilities and come with a documented risk assessment. Once it is on the market, the manufacturer must identify and document vulnerabilities, remediate them without delay, test and review the product’s security regularly, disclose what was fixed, and keep doing so for a support period of at least five years. From 11 September 2026 it must also report: an early warning within 24 hours of becoming aware that a vulnerability in the product is being actively exploited, a fuller notification within 72 hours, and a final report within 14 days, with affected users informed along the way.
Three of those duties are testing by another name: deliver without known exploitable vulnerabilities, test and review regularly, identify and document. Two more depend on testing having happened: remediate (you can only remediate what you have found) and report (you can only report what you know). The 24-hour clock is the one that concentrates minds, and it is unforgiving of a manufacturer whose first knowledge of a vulnerability arrives from the attacker.
What the evidence looks like
A CRA record is not a scan export. For each vulnerability it should show that it was found, how it was proven, which component it lives in, what was done about it, that the fix was re-tested and held, and who did the work. Where a finding was deliberately not fixed, the record should say why. That is the shape of every OSec report, and it is why the report and not a dashboard is what we hand over.
The obligations testing can answer.
- Annex I, Part I, point 2(a)
Products are made available on the market without known exploitable vulnerabilities.
We find the exploitable ones before release and prove each by exploiting it, so that "known" means found by you and not by an attacker.
Penetration testing of the product; application and API testing - Annex I, Part II, point 1
Identify and document the vulnerabilities and components the product contains, including a software bill of materials.
Every finding names the component and version it sits in, with proof. We test the components you depend on, not only the code you wrote.
Penetration testing; Incenter - Annex I, Part II, point 2
Address and remediate vulnerabilities without delay, including by providing security updates.
The closure sprint fixes the critical findings with your team and re-tests every one. The re-test is the evidence that the remediation worked.
Closure sprint - Annex I, Part II, point 3
Apply effective and regular tests and reviews of the security of the product.
Incenter tests the product's exposed surface continuously with a senior reviewing anything ambiguous or high-impact, and a penetration test accompanies each major release.
Incenter; penetration testing - Article 13(2) and 13(3)
Carry out and document a cybersecurity risk assessment, keep it updated, and take it into account from design through maintenance.
Our findings arrive ranked by what would breach you, with the reasons, together with the list of what we recommend leaving alone. Those are the inputs a risk assessment has to be able to show.
Every engagement - Article 14
Report an actively exploited vulnerability through the single reporting platform with an early warning within 24 hours, a notification within 72 hours and a final report within 14 days, and inform affected users.
We do not make your reports. We make sure you have something to say before an attacker shows you, and the re-test record describes the corrective measures the notification has to name.
Incenter; penetration testing - Article 13(8)
Handle vulnerabilities for a support period of at least five years, unless the product's expected use time is shorter.
Testing for the life of the product rather than a test at launch, which is what Incenter's continuous model is for.
Incenter
The record you can hand over.
- A report per test with each finding, its proof of exploitation, the affected component and version, the fix agreed, the re-test result and the named testers.
- The list of what we recommended not fixing, with the reasons.
- Reproduction steps your own engineers can run to confirm the finding and the fix.
- A machine-readable export for your vulnerability-handling records, alongside the PDF.
CRA, answered plainly.
Does a penetration test make a product CRA-compliant?
No single test does. The Regulation asks for a process, to identify, remediate, test regularly, disclose and report, and for evidence of it. Testing supports three of those duties directly and produces the evidence the others rest on.
What counts as an "actively exploited vulnerability"?
One for which there is reliable evidence that malicious code was executed on a system by a malicious actor without the owner's permission (Article 3). A finding in our report is not that. It is exploitable, proven by us under your authorisation, and the point of finding it is that it never becomes one.
Do the reporting duties apply before December 2027?
Yes. Article 14 has applied since 11 September 2026. The rest of the Regulation applies from 11 December 2027.
We are not in the EU. Does the CRA reach us?
It applies to products placed on the EU market, wherever the manufacturer is based.
Does the report go to the regulator?
No. The report is yours. If a vulnerability we found is later exploited in the field, its evidence is what your 72-hour notification and 14-day final report draw on.