Penetration Testing for Cyber Resilience Act Compliance: A Manufacturer's Checklist

If you make hardware, software, or connected devices that are placed on the EU market, the Cyber Resilience Act now sets the bar for what a cybersecurity testing programme should look like. This checklist is intended for manufacturers approaching CRA conformity for the first time — product security leads, engineering managers, compliance officers — and is structured to give you an actionable sense of what scope, deliverables, and budget look like in practice.

Start With Your Product Category

Everything downstream of classification depends on where your product sits in the CRA's three-tier structure. Default products (the bulk of the market) can self-assess against harmonised standards. Important Class I products (password managers, VPNs, network management) can self-assess but with more scrutiny. Important Class II products (firewalls, IDS/IPS, operating systems, HSMs, smart meters) require third-party conformity assessment. Critical products (smart meter gateways, secure cryptographic hardware) require EU certification schemes.

Your testing depth should scale with this classification.

For default products, internal penetration testing supported by external validation on a periodic basis is typically sufficient. The test scope needs to cover the product itself, its interfaces, and the essential cybersecurity requirements in Annex I. Expect testing to run 5 to 15 tester-days depending on complexity, with typical costs of €5,000 to €20,000.

For Class I products, a more substantial external pen test supporting the self-assessment is the minimum expectation. The tester needs to be independent, appropriately qualified, and able to produce a report that maps findings to Annex I requirements. Expect 15 to 30 tester-days and costs of €15,000 to €40,000.

For Class II products, a comprehensive pen test is required as part of the notified body's conformity assessment. This typically covers the product itself, its back-end services, its update mechanism, and often includes hardware analysis and firmware reverse engineering where applicable. Expect 30 to 60 tester-days and costs of €30,000 to €80,000 for the initial assessment, with recurring lighter-touch testing in subsequent cycles.

For critical products, testing is part of a broader certification exercise with significantly higher investment. Budgets start at €80,000 and can extend well beyond €200,000 for complex hardware security modules or smart metering systems.

Typical Test Scope for Class I Products

A Class I product pen test should cover the following at minimum.

Application-layer testing of all external interfaces — web UI, mobile apps, desktop clients, APIs — looking for the standard OWASP Top 10 vulnerability classes, plus application-specific issues like bypass of product-enforced access controls.

Authentication and identity management testing. Given that Annex I requires appropriate control of access including authentication, this is a first-class testing area. Weak authentication, credential reuse paths, and session management flaws get specific attention.

Data protection in transit and at rest. If the product processes sensitive data, testing should validate that encryption is correctly implemented and that data protection controls function as documented.

Secure default configuration review. The CRA requires products to ship in a secure-by-default state. Testers validate that default configurations actually meet this standard rather than relying on post-install hardening guides that customers rarely follow.

The update mechanism. Annex I requires secure distribution of updates. Testers should validate integrity checking, authenticity verification, rollback protection, and the inability of attackers to downgrade or block updates.

Privilege separation and attack surface minimisation. The CRA asks for limited attack surface. Testers check for unnecessary exposed services, overly permissive APIs, and dormant functionality that increases risk.

Logging and monitoring. Security-relevant events should be logged in a way that supports detection. Testers validate that logs capture the events an incident responder would need.

Typical Test Scope for Class II Products

Class II adds hardware testing, deeper back-end testing, and more rigorous vulnerability handling validation.

Firmware extraction and analysis. Testers typically extract the firmware via debug interfaces, flash chip reads, or update packages, then reverse engineer it to identify embedded secrets, weak cryptographic implementations, and vulnerabilities not visible from external interfaces.

Hardware interface testing. JTAG, UART, SPI, I2C and similar debug and diagnostic interfaces are tested to determine if they can be leveraged to gain privileged access to the device. The CRA's requirement to limit attack surfaces applies to physical interfaces as well as logical ones.

Back-end service testing. Any cloud or server-side component that the product connects to is in scope. This includes APIs, management consoles, telemetry endpoints, and update distribution servers. A vulnerability in the back-end is a vulnerability in the product from the regulation's point of view.

Cryptographic implementation review. Class II products often use cryptography for core security functions. Testers validate that algorithms are appropriate, key management is sound, and implementations do not have side-channel weaknesses.

Supply chain and third-party component testing. Class II products typically integrate many third-party components. Testers validate the SBOM, check for known vulnerable versions, and test the mechanisms that keep third-party components updated.

What Documentation Auditors Expect

For Class II products, notified bodies will want to see a specific set of documents alongside the pen test report.

Scope statement. A clear definition of what was tested, what was excluded, and why. Ambiguous scope is a common cause of findings being discounted.

Methodology statement. Reference to established frameworks — OWASP, PTES, OSSTMM, NIST SP 800-115, or CREST — with explanation of how the methodology was applied to this specific product.

Tester credentials. Named testers with individual certifications (OSCP, CREST CRT/CCT, GPEN, GXPN, and similar) documented. Anonymous reports from untraced testers do not satisfy notified bodies.

Findings mapped to Annex I requirements. Each finding should be tagged against the specific Annex I requirement it relates to. This makes it straightforward for the notified body to assess compliance.

Severity and CVSS scoring. Industry-standard scoring is expected. Bespoke severity scales raise questions.

Proof of concept evidence. For critical findings, demonstrable exploitation evidence is expected. Screenshot or log-based evidence is typical.

Remediation guidance. Specific, actionable guidance for each finding. Generic recommendations are a common complaint from notified bodies.

Retest evidence. For significant findings, evidence that the fix was tested and confirmed to resolve the issue. This is often delivered as a retest report addendum.

Testing the Product Itself vs Supporting Infrastructure

A common early mistake is to scope a CRA pen test narrowly to the product as shipped, excluding the manufacturer's own supporting infrastructure. This misses what the regulation considers in scope.

Included in scope: the product itself, its firmware, its update mechanism, any cloud or back-end service the product uses as part of its intended function, the vulnerability disclosure process, and the security-relevant customer-facing interfaces (documentation portals, support channels).

Excluded from CRA scope (but still worth testing): the manufacturer's corporate IT environment, internal development tooling not used in production, and services unrelated to the product's function.

Where this gets subtle is with shared back-end infrastructure. If a single back-end supports both product functionality and unrelated services, the CRA scope includes the product-related surfaces. Testers should be explicit about which back-end components were tested under CRA scope and which were excluded.

Vulnerability Handling Testing — How to Test Your VDP

Annex I Part 2 requires manufacturers to enforce a coordinated vulnerability disclosure policy and to facilitate the sharing of information about vulnerabilities. This is testable, and testing it is a meaningful part of CRA conformity work.

Submission path testing: attempt to submit a vulnerability report through every advertised channel — security.txt contact, dedicated email, bug bounty platform, portal form. Document which paths worked and which failed.

Triage process testing: submit a realistic vulnerability report and track how long it takes to reach a triage decision. Annex I does not set specific SLAs but regulatory expectations are that reports receive attention in days, not months.

Notification testing: validate that, when a vulnerability is confirmed, the organisation has the internal process to meet the 24-hour, 72-hour, and 14-day ENISA reporting deadlines that apply from September 2026.

Update distribution testing: once a fix is deployed, confirm that the update is securely distributed and that customers actually receive it through the documented mechanism.

Disclosure testing: check that once a fix is available, the vulnerability is publicly disclosed in line with the coordinated disclosure policy. Silent patches without disclosure do not satisfy Annex I Part 2.

SBOM Validation

The SBOM is a specific deliverable under the CRA. Testing should validate that the SBOM is accurate, complete for at least top-level dependencies, in a machine-readable format (CycloneDX and SPDX are the two common standards), and available to notified bodies and market surveillance authorities on request.

Practical SBOM testing includes: comparing the SBOM against the actual components shipped in the product, checking that vulnerable component versions are flagged, validating that SBOM updates are generated whenever the product is updated, and confirming that the SBOM format parses correctly in standard tooling.

For firmware-based products, SBOM generation can be more involved than for pure software products. Testers with firmware analysis experience are well placed to validate that SBOMs actually reflect what is in the firmware rather than what the build manifest says should be in the firmware.

Retesting After Updates

The CRA's vulnerability handling obligations make retesting a continuous rather than a one-off activity. Three situations trigger retesting.

Material product updates. Any update that changes core product functionality or security-relevant components should be retested at least at the level of changed surfaces.

Response to reported vulnerabilities. When a vulnerability has been reported and fixed, the fix should be validated through retesting, with the retest evidence available to auditors.

Annual or biennial comprehensive retests. For Class II products, notified bodies typically expect recurring comprehensive testing on a defined cadence, usually aligned with the conformity assessment renewal cycle.

Budget expectations: retest engagements typically run 20 to 40 percent of the cost of the initial full test, depending on scope. For a Class II product initially tested at €60,000, budget €15,000 to €25,000 for each significant retest cycle.

How to Choose a Provider with CRA-Relevant Experience

For CRA work, look for providers with demonstrable strength in the following areas.

Product security testing specifically, not just appsec or network testing. Firms that have a track record of IoT and embedded device penetration testing are best placed.

Hardware analysis capability for Class II work. Firmware extraction, reverse engineering, JTAG and hardware interface testing are specific skills that not all providers have in house.

Cryptographic review capability. Class II products often live or die on their cryptographic implementations, and providers need people who can genuinely review them.

Notified body engagement experience. For Class II and critical products, the pen test needs to satisfy a specific notified body. Providers who have done this before navigate the documentation and evidence expectations more smoothly.

EU-geography coverage. Providers with staff based in the EU or UK who can engage with EU notified bodies directly simplify coordination. Language capability (German, French, Italian) matters for some national markets.

Credentialed testers. OSCP, OSWE, CREST CRT/CCT, GPEN, GXPN, and hardware-specific certifications. The notified body will ask.

Independence. The tester must be independent of the development team. Internal testing does not satisfy Class II conformity.

Our directory at /compliance/cyber-resilience-act lists providers with product security and CRA-relevant expertise. Filtering by IoT Penetration Testing, Source Code Review, and manufacturing industry experience will surface the strongest candidates for Class II work.

Budget Expectations Summary

To budget for CRA compliance testing from scratch, the following rough ranges apply for initial full assessment.

Default products: €5,000 to €20,000.

Class I products: €15,000 to €40,000.

Class II products: €30,000 to €80,000, with hardware-heavy products running higher.

Critical products: €80,000 and up, often substantially more within broader certification exercises.

Budget approximately 30 to 50 percent of the initial test cost annually for ongoing retesting and vulnerability response work.

These numbers are meaningful but should be weighed against the potential €15 million or 2.5 percent of global turnover fines the regulation enables. For most manufacturers, the testing cost is a rounding error compared to the penalty exposure of non-compliance.

The Calendar

The regulation's first hard deadline is 11 September 2026 — reporting obligations. This is less than five months away as of this article. The full application date is 11 December 2027.

A realistic preparation sequence is: classify your products and assess Annex I gaps through Q2 2026, build vulnerability handling programme by August 2026, commission initial pen tests through H2 2026 and H1 2027, engage notified bodies for Class II products in 2026 to avoid the 2027 rush, and complete conformity assessment and CE marking activity by Q3 2027.

The CRA is a substantial build for most manufacturers. Starting now is materially easier than starting in 2027.