The CRA Turns Product Security Into a Legal Duty
With the Cyber Resilience Act (Regulation (EU) 2024/2847), the EU has created binding cybersecurity requirements for almost every product with digital elements. The regulation entered into force on 10 December 2024. The reporting obligations for actively exploited vulnerabilities apply from 11 September 2026, and the main obligations from 11 December 2027. Anyone placing software or connected devices on the European market must then demonstrate that the product was developed securely and stays secure throughout its support period.
One point often gets lost in the debate about reporting deadlines and CE marking: the CRA requires manufacturers to actively and regularly test the security of their products. This is where security testing comes in, and in practice there is barely a way around a penetration test. This article sets out what the CRA actually requires and why a structured pentest is the most defensible way to meet that requirement.
What the CRA Says About Security Testing
The substantive requirements sit in Annex I of the regulation. Part I describes the essential security properties a product must have, including the central rule that a product must ship without known exploitable vulnerabilities. Part II governs vulnerability handling across the lifecycle and explicitly requires manufacturers to apply effective and regular tests and reviews of the security of the product.
An honest caveat matters here: the CRA is written to be technology-neutral. It does not prescribe a particular method and does not use the term penetration test. The legislator defines an outcome, namely products that are demonstrably tested and hardened, and leaves the choice of means to the manufacturer. That openness is not a free pass. If you have to show that your product contains no known exploitable vulnerabilities, you must have actively looked for them. A configuration check or an automated scan alone is usually not enough.
Why a Penetration Test Is the Practical Proof
The difference between an automated vulnerability scan and a penetration test decides whether the CRA requirement is really met. A scanner finds known signatures and obvious misconfigurations. It detects neither chained attacks nor logic flaws in the application, broken authorization, or weaknesses in individual business logic. In practice, exactly these flaws lead to exploitable vulnerabilities.
A penetration test simulates a real attacker and delivers the proof the CRA is fundamentally asking for: a deliberate attempt was made to compromise the product, and the vulnerabilities found were documented and fixed. For regulated products, repeatability is decisive on top of that. The CRA requires regular testing, not a single check before market launch. Every significant change to the product, every new exposed interface, and every major release should trigger another test. A clean pentest report with findings, severity ratings, and traceable remediation is therefore the practical evidence for the testing activity the CRA demands.
Security Testing, SBOM, and Vulnerability Handling Belong Together
The CRA does not treat testing in isolation but as part of a continuous vulnerability process. Annex I Part II obliges manufacturers to identify and document the components of their product, including in the form of a software bill of materials in a commonly used, machine-readable format. They must remediate vulnerabilities without undue delay, provide security updates, and disclose information about fixed vulnerabilities.
These requirements interlock. An SBOM analysis shows which third-party components and libraries a product contains and which of them carry known vulnerabilities. The penetration test then checks whether these and other weaknesses are actually exploitable in the concrete product context. What the test finds feeds a structured vulnerability management process that governs remediation, deadlines, and evidence across the support period. Only this interplay of bill of materials, testing, and documented remediation satisfies the CRA's demand for effective vulnerability handling.
Test Evidence in the Conformity Assessment
Under Article 13, the manufacturer must ensure that a product was developed in line with the essential requirements of Annex I and carry out a cybersecurity risk assessment whose outcome feeds into planning, development, and maintenance. The technical documentation and the EU declaration of conformity must be kept available for the market surveillance authorities for at least ten years.
For most products, conformity can be declared through self-assessment. For the important and critical products listed in Annexes III and IV, such as operating systems, password managers, firewalls, or routers, the involvement of a notified body may become necessary, especially where no harmonized standards are applied. In both cases the same holds: the authority or the notified body wants to see documented testing activity. A traceable pentest report that records scope, methodology, findings, and remediation is exactly the evidence that makes the risk assessment and the technical documentation credible. Anyone who only assembles this evidence shortly before the audit ends up under pressure they can no longer resolve within the ongoing development cycle.
Timeline: What Manufacturers Should Do Now
Less time remains until full application on 11 December 2027 than the date suggests, because testing and remediation take several cycles. An early start makes sense:
- Determine product scope: Clarify whether your product counts as a default, important, or critical product, because that determines the rigor of the conformity assessment.
- Build an SBOM: Create a machine-readable software bill of materials and keep it current.
- Define a testing regime: Set the triggers for a penetration test, at minimum before market launch and on every significant change.
- Establish a vulnerability process: Make sure findings are remediated on time, documented, and tracked across the support period.
- Prepare the reporting process: Set up the workflow for the reporting obligation that applies from September 2026, including the early warning within 24 hours through the single reporting platform to the responsible CSIRT and ENISA.
For a structured overview of the regulatory context, see our page on the Cyber Resilience Act.
Conclusion
The Cyber Resilience Act does not require a penetration test by that name, but it does require the proof that only a real security test can provide: that a product was deliberately checked for exploitable vulnerabilities and hardened, repeatedly across its lifecycle. Manufacturers who bring testing, SBOM, and robust vulnerability handling together now do more than meet a coming legal duty. They ship more secure products and can prove it when it matters. The full regulation is available at EUR-Lex, and the current reporting obligations are explained by the European Commission.