Does the Cyber Resilience Act Require Penetration Testing?
No. The Cyber Resilience Act does not require penetration testing. The phrase does not appear anywhere in Regulation (EU) 2024/2847. What the law requires is that manufacturers "apply effective and regular tests and reviews of the security of the product with digital elements" (Annex I, Part II, point 3). Penetration testing is one way to satisfy that obligation. It is not the only way, and for many products it is not the most efficient way.
What the CRA does require is that your testing is effective, regular, and evidenced. Those three words carry the full weight of the obligation.
This article provides general guidance on the Cyber Resilience Act, not legal advice. Confirm specifics against Regulation (EU) 2024/2847.
TL;DR
- Annex I, Part II, point 3 mandates effective and regular security tests - no method, no frequency, no template is specified.
- Annex I, Part I requires products to ship without known exploitable vulnerabilities - a hard edge that testing must address.
- Article 13 requires a documented risk assessment, and that assessment should drive what you test, how deeply, and how often.
- Annex VII requires test reports to sit in the technical file, available to market surveillance authorities on request.
- No CRA harmonised standard is yet cited in the Official Journal, so no standardised testing benchmark currently confers presumption of conformity.
- Penetration testing is high-signal and appropriate where the risk assessment says the blast radius is largest - but it is one tool in a broader programme.
What the CRA actually says about testing
Four provisions are directly relevant. Read them together, not in isolation.
Annex I, Part II, point 3 is the core testing obligation. Manufacturers must "apply effective and regular tests and reviews of the security of the product with digital elements."[1] That is the complete requirement. No method is named. No frequency is set. No report template is prescribed. As Equixly's August 2026 analysis of the CRA and security testing notes, the requirement is "one line. No method, no frequency, and no template" - yet it sits behind the technical documentation a market surveillance authority can ask to see.
Annex I, Part I creates a testing-adjacent obligation with a hard edge. Products must be placed on the market without known exploitable vulnerabilities.[2] This is not a best-efforts standard. If your testing reveals an exploitable vulnerability and you ship anyway, you are in breach - regardless of how thorough your test programme otherwise is.
Article 13 requires a documented cybersecurity risk assessment. That assessment must analyse risks based on the product's intended purpose, reasonably foreseeable use, and operational environment. Critically, it must indicate how the Annex I requirements are implemented as informed by the risk assessment. In other words, the risk assessment is not a separate compliance exercise - it is the document that tells you what to test, how deeply, and how often. Our Article 13 risk assessment guide covers the mechanics in detail.
Annex VII closes the loop on evidence. Technical documentation must include reports of the tests carried out to verify conformity with the essential cybersecurity requirements. Test output is not internal-only. It is a file the authorities can ask for, and it must be retained for ten years from the date the last product is placed on the market.
Why "effective" is the load-bearing word
"Effective" is not defined in the Regulation, which is deliberate. The CRA is technology-neutral: it defines outcomes, not methods. That flexibility is useful, but it also means you cannot hide behind a generic testing policy.
Effectiveness is judged against your own risk assessment. A penetration test that never touches your product's real attack surface - because the scope was drawn too narrowly, or the build tested was not the production build, or the cloud backend was excluded - is not effective, regardless of how polished the report looks. Equally, running SAST on a firmware image that has no network-facing interface, while ignoring the Bluetooth stack that does, is not effective.
The practical implication: your test programme must be traceable back to the threats and attack surfaces identified in your Article 13 risk assessment. If the risk assessment says the primary attack surface is the OTA update mechanism, your testing must cover that mechanism with appropriate depth. If it says the product handles sensitive personal data over a public API, that API needs to be tested accordingly.
Independent practitioner commentary through 2026 converges on the same reading. Wirtek's analysis of testing under the CRA concludes that "connected-product manufacturers cannot meet CRA requirements with point-in-time penetration testing or release-time security checks alone[4]" - the Act expects testing to be ongoing, risk-based, and evidenced across the full product lifecycle.
A testing toolkit, and what each method proves
No single method covers everything. A defensible programme uses a combination, weighted by the risk profile of the product.
| Method | What it evidences for the CRA |
|---|---|
| Threat modelling / design review | That attack surfaces were identified before code was written; informs scope of all downstream testing |
| SAST and secret scanning | That known insecure code patterns and hardcoded credentials were caught at commit time |
| SCA / SBOM-driven dependency analysis | That third-party components were inventoried and known-vulnerable versions were not shipped |
| DAST and fuzzing (including protocol and firmware fuzzing for embedded) | That the running product was tested against malformed input and unexpected state; especially relevant for network-facing interfaces and proprietary protocols |
| Hardware and interface testing (debug ports, secure boot, physical access) | That hardware attack surfaces - JTAG, UART, boot chain - were assessed; essential for embedded and IoT products |
| Penetration testing | That a skilled attacker attempting to exploit the product's real attack surface was simulated; high-signal, expensive, best deployed where the risk assessment says the blast radius is largest |
| Red-team exercises | That multi-stage, objective-based attack scenarios were tested; appropriate for high-risk or critical products |
| Regression testing of past fixes | That previously identified vulnerabilities were not reintroduced; a retest record is a compliance artefact |
| Third-party / independent assessment | That an external perspective was applied; may be required for Annex III/IV products via a notified body |
A word of honesty about penetration testing: it is the method most people ask about because it is the most legible to non-technical stakeholders. It is also expensive, point-in-time, and only as good as its scope. A penetration test that is scoped to exclude the update mechanism, the cloud backend, or the mobile companion app is not evidence that those surfaces are secure - it is evidence that they were not tested. Deploy it where the risk assessment says the consequences of compromise are most severe, and make sure the scope statement reflects the actual product, not a convenient subset of it.
How often is "regular"?
There is no number in the law. "Regular" is not defined, and no implementing act has set a frequency. That is not an oversight - the Regulation is deliberately proportionate. A low-risk default product and a Class II important product with safety implications should not be on the same testing cadence.
A defensible approach has two components: a risk-tiered baseline and event triggers.
Baseline cadence (illustrative, not a legal standard):
- Default products, low attack surface: Continuous automated scanning (SAST, SCA, DAST in CI/CD); targeted manual review or penetration test at major release.
- Important Class I products: Continuous automated scanning; penetration test at least annually and at major release; hardware interface review at design freeze.
- Important Class II / Critical products: All of the above; independent third-party assessment; consider red-team exercises for high-consequence scenarios.
Event triggers that should prompt an out-of-cycle test regardless of class:
- A substantial modification to the product (new interface, new protocol, new data type handled)
- A major version bump in a dependency that touches a security-relevant component
- New threat intelligence indicating a relevant attack technique or newly weaponised vulnerability class
- A security incident or near-miss affecting the product or a closely related product
- A significant change in the operational environment (new deployment context, new integration)
The most important compliance point here is not the cadence itself - it is the justification. Whatever frequency you choose, write down why you chose it, and tie that reasoning to your risk assessment. The written justification is the compliance artefact. An authority reviewing your technical file is not going to count your tests; they are going to ask whether your testing programme was proportionate to the risks you identified.
What evidence goes in the technical file
Annex VII is specific: the technical documentation must include reports of tests carried out to verify conformity. In practice, a complete testing evidence package for the technical file should contain:
- Test plan - tied explicitly to the risk assessment; scope statement that names what is in and what is out, and why
- Build identification - the exact version, build hash, or firmware image that was tested (testing the wrong build is a common and serious mistake)
- Dates and duration - when testing was conducted and over what period
- Tooling and versions - tools used, versions, configuration; sufficient for a third party to understand and reproduce the approach
- Findings log - all findings with severity ratings, affected component, and reproduction steps
- Remediation records - what was fixed, how, and when; linked to the findings log
- Retest evidence - confirmation that fixes were verified; a finding without a retest record is an open question in an audit
- Sign-off - who approved the test results and accepted any residual risk
- Residual risk decision log - for any finding accepted rather than remediated, a documented rationale explaining why the residual risk is acceptable given the product's risk profile
The ten-year retention expectation (from the date the last product is placed on the market) means this file needs to be structured for long-term retrieval, not just current-sprint convenience. See our Annex VII technical documentation guide for the full file structure.
Common mistakes
Running a single annual penetration test as the whole programme. One test per year, with no automated scanning in between, leaves the product untested for the eleven months in which most code changes happen. It is unlikely to satisfy "regular" for any product with an active development cycle.
Testing the wrong build. The build tested must be the build shipped. Testing a development build with debug features enabled, or a pre-release candidate that differs from the production image, produces evidence about a product that does not exist.
Scoping out the cloud backend or update mechanism. If your product's security depends on a cloud API or an OTA update channel - and for most connected products it does - those surfaces must be in scope. Excluding them because they are "not the device" is a scope error that will be visible to any competent reviewer.
No retest evidence. A penetration test report full of findings, with no record of what was fixed and retested, is not a compliance artefact - it is a list of known vulnerabilities. Retest records are mandatory.
Findings that never reach a ticket. Test output that sits in a PDF and never enters the engineering workflow does not improve security and does not demonstrate the "effective" part of the obligation. Findings must be triaged, tracked, and resolved through a documented process.
Treating a certificate as proof of conformity. A penetration test certificate, or any other third-party security certificate, is evidence of a point-in-time assessment against a defined scope. It is not a CRA conformity declaration. The CE marking and EU Declaration of Conformity remain the manufacturer's responsibility.
A note on harmonised standards
As of September 2026, no CRA harmonised standard has been cited in the Official Journal of the EU, so the Article 27 presumption of conformity is not available for any product category. That means there is currently no standardised testing benchmark that, if followed, automatically demonstrates conformity.
On 13 August 2026, ETSI opened the Public Enquiry on 17 vertical final draft standards for the CRA, covering product categories including password managers, anti-virus software, smart home assistants, connected toys, and wearables.[5] These are the documents that will eventually tell a manufacturer of a specific product type what the CRA's essential requirements mean in practice - including, in some cases, what testing is expected. The approval procedure runs until mid-September to mid-November 2026, depending on the vertical, with final versions expected around December 2026. Until a standard is ratified and cited in the Official Journal, it is guidance at best - useful for understanding the direction of travel, but not a substitute for demonstrating conformity directly against Annex I.
Our harmonised standards and presumption of conformity guide tracks the current status, and our ETSI 17 vertical standards post covers what the drafts say for each product category.
What to do next
Where to go next on CRA Facts
- Is your product in scope? -> CRA scope and class checker
- Full compliance roadmap -> CRA compliance checklist
- The risk assessment that drives your test programme -> Article 13 CRA risk assessment guide
- The security properties your product must have -> Annex I, Part I: security by design
- Vulnerability handling obligations -> Annex I, Part II: vulnerability handling
- What goes in the technical file -> Annex VII technical documentation guide
- Standards status and presumption of conformity -> Harmonised standards tracker
- The 17 ETSI vertical drafts -> ETSI public enquiry: what important product makers should do now
- Regulation (EU) 2024/2847 (Cyber Resilience Act) - Annex I, Annex VII | EUR-Lex
- The Cyber Resilience Act - Summary of the legislative text | European Commission
- The Cyber Resilience Act and the key role of security testing | Equixly (August 2026)
- Testing under the EU Cyber Resilience Act: what manufacturers of connected products need to prove | Wirtek
- ETSI launches approval process for 17 European Standards supporting the Cyber Resilience Act
Related reading
Three Weeks Into CRA Reporting: What Early Users Learned and What a "Disclosure Delay" Really Means
Article 14 reporting has been live for three weeks. Here is what early users of ENISA's Single Reporting Platform report, what a "disclosure delay" does and does not change, and the four things worth doing this week.
CRA SBOM Requirements: What Goes Inside, Which Format Versions to Use, and Where VEX Fits
The CRA says your SBOM must be machine-readable but not what fields it needs. Here is what goes inside, which CycloneDX and SPDX versions still count, and why VEX is optional.
The CRA Notified Body Capacity Crisis: What Class II and Critical Manufacturers Should Actually Do
Zero CRA notified bodies are listed in NANDO as manufacturers head into the final compliance stretch. If your product is Class II or Critical, here is why the bottleneck exists, who it actually affects, and the sequenced plan that turns waiting into progress.