Does the Cyber Resilience Act Make Penetration Testing Mandatory?

No — and yet hardly any manufacturer will get by without structured security testing. Why both are true at the same time, and what question really matters.

“Does the Cyber Resilience Act now require penetration testing?” — we’ve been getting this question for months. The honest answer is: No. And yet, for most manufacturers, there is no way around structured security testing. Both are true at the same time — and it’s precisely in this apparent contradiction that the point lies, one that many companies are still underestimating in 2026.

What the CRA Actually Requires

Four anchor points in the regulatory text are decisive here:

Taken together, this does not amount to a named obligation to conduct penetration tests, but it does amount to a clear testing obligation with evidentiary character. Art. 64 backs this with a substantial penalty regime: up to €15 million or 2.5% of worldwide annual turnover.

“De Facto Obligation”: Why Proof Is Hardly Achievable Without Testing

The CRA does not say “penetration test = proof of conformity.” It requires appropriate testing and its documentation — and what testing depth and methods are appropriate is determined on a risk-based basis, taking into account the product, its architecture, the threat landscape, product class, and the technical specifications applied.

For many products, credible proof without technical security testing — including risk-appropriate penetration testing — is hardly convincing.

This is the de facto obligation: not literally in the law, but practically unavoidable once you take the required proof seriously. A penetration test is a key means of providing that proof — not the only one, and not the one prescribed by law, but one of the most meaningful.

To determine the appropriate testing depth, offensive threat modelling is indispensable. This involves systematically identifying and assessing product-specific threat vectors, attack paths, and potential vulnerabilities from an attacker’s perspective. Unlike a purely defensive risk analysis, offensive threat modelling does not just ask “What could happen?” but “How would an attacker actually compromise this product?” — and thus provides the foundation for a risk-based, targeted testing approach that stands up to scrutiny by market surveillance authorities and in liability cases.

Does Your Product Even Fall Under the CRA?

The CRA applies to products with digital elements — hardware and software that can be connected directly or indirectly to a network. This is deliberately broad in scope. Key distinctions:

Pure SaaS/cloud services do not automatically fall under the CRA — they may fall under NIS2. They become CRA-relevant primarily when they form an integral part of a product as a “remote data processing solution” (e.g., the cloud connectivity of a smart home device).

Open-source software is treated differently: non-commercial development is excluded; “open-source steward” obligations apply to foundations/projects with a commercial dimension.

Already regulated products (medical devices, motor vehicles, aviation) are exempt from the CRA to the extent that sectoral rules impose equivalent requirements.

The conformity assessment procedure also has gradations: most standard products can be demonstrated through internal self-assessment. For important and critical product classes, stricter procedures apply — up to and including third-party assessment. The category a product falls into helps determine the necessary testing depth.

CRA Implementation: NSIDE ATTACK LOGIC & RSM EbnerStolz – From Analysis to Declaration of Conformity

The CRA demands far more than just a security test – it requires a complete, documented conformity process: from the scoping analysis and risk assessment through technical security testing to CE marking. This is precisely where the partnership between RSM EbnerStolz and NSIDE ATTACK LOGIC comes in.

RSM EbnerStolz – one of Germany’s leading audit and advisory firms – provides the methodological lead for the entire CRA project: scoping analysis, regulatory classification (in cooperation with legal advisors where required), adaptation of processes and documentation, establishment of the required reporting and vulnerability management processes, and support through the conformity assessment procedure to CE marking. A compact overview of the EbnerStolz CRA offering can be found on the EbnerStolz website.

NSIDE ATTACK LOGIC provides support across all technical areas of CRA implementation: conducting the product-related cybersecurity risk assessment, security-by-design consulting, technical security testing (risk-based penetration tests, code reviews, architecture analyses), preparation of technical documentation (test results, SBOM, vulnerability management), and offensive threat modelling to identify product-specific attack vectors.

Deadlines and Sanctions

The timeline is tighter than many assume:

As for fines: up to €15 million or 2.5% of worldwide annual turnover for violations of Annex I requirements; lower tiers apply to other infringements (€10 million/2%; €5 million/1%). Additionally, market withdrawals and sales bans may be imposed by market surveillance authorities.

The Right Question Isn’t “Pen Test — Yes or No?”

The “Do we need a pen test?” debate leads nowhere because it suggests a yes/no answer that the CRA deliberately does not provide. The actually relevant question — and one that is significantly harder for manufacturers to answer themselves — is:

What tests, at what depth, does your specific product need to provide credible CRA proof?

That depends on the architecture, attack surface, product class, components used, and your existing maturity level. Companies that already practice DevSecOps and regular security testing have most of the journey behind them. Those that have only tested on an ad hoc basis should set up the process now — embedded in development and quality assurance, not as rework shortly before market launch.

Frequently Asked Questions