Does the Cyber Resilience Act require penetration testing? What it says

Does the Cyber Resilience Act require penetration testing?

The Cyber Resilience Act does not name penetration testing and does not set a fixed annual test. What it requires is in Annex I Part II point (3): manufacturers must apply effective and regular tests and reviews of the security of their product with digital elements. Penetration testing is one of the test types the Commission lists as possible security tests, alongside fuzz testing, firmware analysis, side-channel analysis, red-team exercises and network traffic analysis. A manufacturer facing a customer or contract demand for CRA evidence should therefore not ask for a pentest certificate. The question to answer is whether the testing program is effective, regular and documented for the product in question.

The Commission's guidance (section 9.2.3 of C(2026) 5252) makes clear that regularity does not mean repeating an unchanged test campaign at fixed intervals. The manufacturer must review whether new threats or newly discovered vulnerabilities require the tests to change, and then run them. The depth and frequency of that review should follow the product's risk profile, how the product has changed, and the threat landscape, and may include regression testing after modifications. A connected device with frequent firmware releases and a remote management interface will need a different program from a stable, offline industrial component. Manufacturers should document the risk basis for their chosen test types and intervals, because that reasoning is what an assessor or market surveillance authority will read first.

The manufacturer owns this obligation. Annex VII point 6 requires the technical documentation to include reports of the tests carried out to verify conformity with Annex I Parts I and II, so the evidence sits with the manufacturer, not with the tester. External testers can plan, execute and report on the testing, and a notified body under Annex VIII module B examines the technical design and vulnerability handling processes, but neither issues a generic compliance statement. Before engaging a provider, confirm what the report must contain for the technical file, which product versions it covers, and how retest results will be recorded. The Commission's FAQs explain how these tests fit the broader conformity route.

Why the testing cadence is risk-based rather than a fixed annual test

Annex I Part II point (3) requires effective and regular testing, and the Commission's guidance reads "regular" as a review cycle tied to the product, not a calendar. Four factors feed that review, and each one changes the test plan in a way an assessor can trace.

Product risk profile

The manufacturer's cybersecurity risk assessment decides which functions, interfaces and data flows carry the most exposure. A product that handles authentication, remote management or sensitive data usually needs deeper test coverage on those components than a function with little attack surface. Review the risk assessment first, then check that the test scope still matches the highest-ranked risks. The evidence is a dated mapping from each risk to the tests that address it.

Product evolution over time

Architecture changes, new features, new dependencies and new deployment models all alter what an attacker can reach. The test plan should be revisited whenever the design baseline moves, not only when a release date arrives. Ask engineering to flag changes to interfaces, libraries and network exposure at each review. The evidence is a change log linked to test scope decisions, showing which changes triggered new tests and which did not.

Threat landscape and new vulnerabilities

Newly published vulnerabilities in a component, or new attack techniques against a product class, can make an earlier test insufficient. The guidance asks manufacturers to consider whether such developments require tests to be updated. Track advisories for the components in the bill of materials and record how each relevant one was assessed. Evidence includes triage notes that show whether a new threat led to an updated test case or a documented reason it did not.

Regression testing after modifications

Each security fix, configuration change or component update can break a control that previously passed. Regression testing re-runs the affected tests against the modified product, so the result of the last review still holds. Confirm with the engineering team which changes count as modifications for this purpose and keep the criteria written down. The evidence is a regression run record tied to the specific build or version it covers.

Review frequency and depth

The guidance says the frequency, depth and content of reviews should be proportionate to the factors above, so the cadence is a decision the manufacturer must justify. Document who approves the review schedule, what triggers an unscheduled review, and how the depth of each test type was chosen. Assessors will look for reasoning, not a fixed interval. Ask your notified body or assessor which records they expect to see before the first assessment.

Which test types the Commission lists and when each fits

This table sets out the six test types listed in the Commission's CRA FAQ 4.4.2 as possible additional tests when integrating components. Each row names the question the test answers and the product types where it usually matters, so you can scope testing against your risk profile rather than running every type by default.

Test type	Question it answers	Product types where it usually matters
Fuzz testing	Does malformed or unexpected input crash, hang or expose memory in a parser, interface or protocol handler?	Products with network interfaces, file parsers or custom protocol stacks, such as IoT gateways and industrial controllers
Penetration testing	Can an attacker with a defined access level bypass controls and reach assets they should not reach?	Connected products, SaaS backends and cloud-hosted services exposing APIs, web consoles or remote management
Firmware analysis	Does the firmware image contain hard-coded secrets, unsafe components, unsigned update paths or known vulnerable libraries?	Embedded devices and hardware products with firmware updates, including consumer IoT and networking equipment
Side-channel analysis	Can timing, power or electromagnetic leakage reveal cryptographic keys or protected data?	Hardware security modules, smart cards, secure elements and devices handling keys in physically accessible environments
Red-team exercises	Can a realistic adversary chain weaknesses across people, processes and technology to reach a goal?	Security software and enterprise products in important or critical categories, where the impact of compromise is high
Network traffic analysis	Does the product send unexpected data, use weak protocols or behave differently from its documented design on the wire?	Products with telemetry, cloud connections or machine-to-machine communication, such as connected vehicles and industrial systems

How test results end up in the technical documentation

This sequence turns a security test campaign into dated evidence that the manufacturer can show in the technical documentation, linking each finding to the Annex I requirement it checks and to the fix that closed it. Each step produces a named artifact that an assessor or market surveillance authority can trace.

Scope tests against Annex I Parts I and II
The manufacturer, with its security lead and the testing provider, maps each planned test to the Annex I Part I essential requirements it checks and to the Part II vulnerability handling requirements, including point (3) on regular and effective testing. The output is a written test scope register listing the product version, components in scope, test types and the requirement each test supports. The step is done when every in-scope requirement has at least one named test or a documented reason why no test applies, and the manufacturer has signed off the register.
Run tests against the defined scope
The testing provider executes the agreed tests, which may include penetration testing, fuzz testing, firmware analysis or network traffic analysis as the scope requires. The provider records the tool versions, test accounts, environments and dates used, so the campaign can be repeated and explained later. The output is a set of raw tool outputs, notes and a list of candidate findings, and the step is done when each planned test has a recorded result or a recorded reason it was not completed.
Produce the test report
The provider writes a test report that states the scope, method, environment, findings with severity and reproduction steps, and a clear pass or fail statement against each mapped requirement. The manufacturer's security team reviews the draft for accuracy and for any finding that affects the product's risk assessment. The output is a dated, versioned test report, and the step is done when the manufacturer has accepted it and the report identifies the product version it covers.
Link findings to fixes and handling records
Each finding is entered in the manufacturer's vulnerability tracking system with an owner, a remediation decision and a link to the code change, configuration change or documented risk acceptance that resolved it. Findings that concern third-party components are also routed into the vulnerability handling process so that upstream reporting and advisories can follow where needed. The output is a traceability record connecting finding, fix and retest, and the step is done when every finding is either closed with retest evidence or formally accepted by an accountable person.
Retest and record regression results
After fixes are applied, the affected tests are rerun to confirm the issue is closed and to check that the change has not reopened other weaknesses. This is where regression testing after modifications, as the Commission guidance describes, is recorded. The output is a retest report or an addendum to the original report showing the date, version and result of each rerun, and the step is done when no open finding lacks a documented decision.
File the reports in the technical documentation
The manufacturer places the final test reports, the scope register and the traceability records into the technical documentation under the Annex VII point 6 heading for tests verifying conformity with Annex I Parts I and II. The file is indexed so an assessor or market surveillance authority can move from a requirement to its test and its result. The output is a versioned technical documentation file with a test evidence section, and the step is done when a person who did not run the tests can follow one requirement to its evidence without help.
Keep the evidence current after each change
When the product changes, or when new threats or vulnerabilities emerge, the manufacturer reviews whether the test set still fits the risk and updates the register and reports accordingly, as the Commission guidance on regular testing describes. Notified body assessments under Annex VIII module B also examine the vulnerability handling processes, so the evidence should match what the process actually does. The output is an updated technical documentation version with a dated change note, and the step is done when the file reflects the current product version.

Who runs the tests and who checks them

The manufacturer carries the obligation under Annex I Part II point (3) to apply effective and regular tests and reviews of the product's security. That duty cannot be handed to a vendor. The internal team decides which tests run, how often the review happens, and whether new threats or vulnerabilities require the test plan to change. It also decides what counts as a pass, which findings are fixed, and what is accepted as residual risk. The resulting test reports become part of the technical documentation under Annex VII point 6, so the team must keep them complete, dated and traceable to the product version tested.

Test plan ownership: The team sets the scope of fuzzing, penetration testing, firmware analysis or other tests based on its own cybersecurity risk assessment.
Review triggers: It records what prompts a test update, such as a new vulnerability class, a major component change or a regression after a modification.
Findings decisions: It decides remediation priorities and documents the reasoning for any finding left open.
Documentation: It stores reports in the technical documentation with the product version, date, tester identity and scope.
Conclusion: It signs off that the product meets Annex I, since the conclusion stays with the manufacturer even when a third party performed the work.

Before relying on the internal process, confirm with your team who holds each of these decisions and where the records will be kept.

What to put in a penetration test scope for CRA evidence

A penetration test only becomes CRA evidence if its scope matches the product an assessor will examine. The decisions below determine what the report covers, which components it can vouch for, and whether it can be placed in the technical documentation. Confirm each choice with your testing provider before work starts, and ask for cost and duration in a written quote that follows from that scope.

Product versions and components in scope

Name the exact product versions, builds and configurations the test covers, and list the components that ship with them. Annex VII point 6 expects reports tied to the product the manufacturer places on the market, so a test of a development branch or an older release will not support the current technical file. Ask the tester to record the version hashes tested and to state which features were disabled or excluded. Confirm that the tested build is the one you ship.

Third-party and open-source components

Decide whether bundled libraries, frameworks and open-source dependencies are in scope as integrated code, or only as attack surface reached through your own interfaces. The Commission FAQ lists fuzz testing, firmware analysis and network traffic analysis as possible additional tests when components are integrated, so the scope should say which of these apply. Ask for a record of which components were examined directly and which were covered only through the product.

Update and delivery mechanisms

Include the path that delivers software and firmware to the product: update servers, signing and verification, package repositories, and any remote management channel. A product that accepts unsigned or weakly verified updates can undermine every other control, so testers should attempt to modify, replay and downgrade updates. Ask whether the test covers the update process end to end, including rollback behavior and the keys used to sign releases.

Cloud and backend services the product depends on

Decide whether hosted accounts, APIs, telemetry endpoints and vendor-operated services that the product relies on fall inside the test boundary. The guidance notes that penetration testing and red teaming of systems are not themselves part of the product's remote data processing, so these tests are a separate question from the product's own design. Write the boundary down, including who owns each service, and get written permission from the service owner before testing begins.

Report content for the technical file

Specify what the report must contain for the technical documentation: the test objectives, the methods, tools and versions, the findings with severity and status, the retest results, and the link between each finding and the Annex I requirement it concerns. Also ask whether the report covers the vulnerability handling processes under Annex I Part II, not only the product. A report without these elements may be accurate but still hard for an assessor or notified body to use.

Buyer questions about CRA security testing

Does the Cyber Resilience Act require a penetration test every year?

No. The CRA does not set a fixed annual penetration test. Annex I Part II point (3) requires manufacturers to apply effective and regular tests and reviews of product security. The Commission's guidance (section 9.2.3 of C(2026) 5252) says regular testing does not mean repeating an unchanged test campaign at fixed intervals. It means reviewing whether new threats or newly discovered vulnerabilities require updated tests, then running them. The depth and frequency should be proportionate to the product's risk profile, how it evolves, and the threat landscape. Ask your assessor to document that review logic, because that record is what you will show.

Will a notified body run the penetration test for us?

Not necessarily. Most products follow self-assessment under module A, so the manufacturer decides how testing is done and documents it. A notified body is involved for class II and critical products, and for certain class I important products, under Article 32 and Annex VIII module B. Under module B the notified body examines the technical design and vulnerability handling processes and carries out periodic audits of those processes. That is an examination of your process and documentation, not a substitute for your own testing program. Confirm with any notified body which tests it will review and whether it runs any itself.

What does a penetration test need from our internal staff?

Expect the engagement to depend on your staff for access and context. Typical inputs include architecture diagrams, the product's update and signing mechanisms, a list of third-party and open-source components, test environments that match production builds, and named contacts for questions during testing. Engineers also need to agree on rules of engagement and how findings enter your vulnerability handling process. The more complete these inputs are at kickoff, the less time the engagement spends rediscovering the design. Ask the provider to list every input in the written scope so you can plan internal time before work starts.

Can our in-house team perform the CRA security testing?

Yes, if the team has the skills, independence and tooling to cover the test types you need and to document results. The CRA does not require an outside firm, and Annex VII point 6 asks for test reports in the technical documentation regardless of who ran the tests. Internal teams often struggle with independence (testing code they wrote), coverage of firmware or hardware-level attacks, and keeping reports consistent across releases. A mixed model is common: internal teams run regular regression and review, while an external firm tests on a planned basis. Compare the cost of skills and tooling you would need to build against a fixed-scope engagement, and ask any provider which parts it would leave for your team.

How does security testing relate to the Article 14 reporting duty?

They are separate obligations that often share information. Article 14 requires manufacturers to notify actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform, which began applying on 11 September 2026. Testing is a source of findings, and a finding that turns out to be actively exploited may trigger a notification. The Commission guidance also notes that penetration testing, threat hunting and red teaming are not themselves part of a product's remote data processing. Build a path from test findings into your vulnerability handling and reporting workflow so that triage decisions are recorded.

How should open-source components be covered in CRA testing?

Open-source components are part of the product's security, so they belong in scope when you integrate them. The CRA's Commission FAQ 4.4.2 lists fuzz testing, penetration testing, firmware analysis, side-channel analysis, red-team exercises and network traffic analysis as possible additional tests when integrating components. Decide which components you test directly, which you test only through their integration points, and how you track upstream fixes. Document that decision, because an assessor will ask how you reviewed components that you did not write. Confirm with your provider how it treats third-party code in the written scope.

What must a CRA test report contain?

A test report must show what was tested and whether the product meets Annex I. Annex VII point 6 requires the technical documentation to include reports of the tests that verify conformity with Annex I Parts I and II, including the vulnerability handling processes. In practice a useful report states the product version and build tested, the scope and test types, the methods and tools, the test environment, findings with severity and status, retests, and the reviewer's conclusion. Ask the provider to show a sample report and to confirm that findings link to your tracking system, so that each report can be filed in your technical documentation for the support period.

How DeployOpen scopes testing and prepares the evidence

DeployOpen approaches CRA security testing as an implementation and evidence exercise. We scope the testing against the product's architecture and risk profile, then prepare the test reports and vulnerability handling records that feed the technical documentation. Final conformity decisions stay with the manufacturer and, where needed, an independent notified body.

How we scope

Agreed in writing before work starts, with the test types, targets and boundaries defined up front.
Scope starts from the manufacturer's cybersecurity risk assessment and the product's components, interfaces and update paths.
The written scope states how regression testing will run after later modifications to the product.

How we build

Security tests run against the product inside the client's own environment, using agreed tooling and test accounts.
Findings are triaged with the client's engineering team so fixes can be tracked against each Annex I requirement tested.
Test campaigns are set up so they can be rerun when new threats or vulnerabilities change the risk picture.

How we hand over

Test reports are written to fit the technical documentation, with scope, method, results and remediation status recorded.
Evidence of testing is linked to the vulnerability handling processes the manufacturer must keep for the support period.
Handover includes a review session so the manufacturer's staff can explain each report to an assessor or notified body.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement ends.
A retainer can cover periodic review of whether test coverage still matches new threats and product changes.
Ask us to confirm in writing which parts of the test evidence we prepare and which the manufacturer must sign off.

Does the Cyber Resilience Act require penetration testing?