Penetration testing is most valuable when its scope follows the product's attack surface, trust boundaries and cybersecurity risk assessment. It should complement secure design, automated security testing, code review and vulnerability management rather than become the only evidence of product security.
The CRA Requires Security Testing, Not a Universal Penetration Test
Annex I Part II point 3 requires manufacturers to apply effective and regular tests and reviews of the security of products with digital elements. The Regulation does not prescribe penetration testing by name as a universal standalone requirement for every product. A manufacturer can therefore choose testing methods appropriate to the product and its cybersecurity risks. For products with exposed interfaces, privileged functionality or significant remote attack paths, penetration testing can provide useful adversarial evidence that complements automated and functional security testing.
- Security testing is explicitly required.
- Penetration testing is one possible testing method.
- Use the cybersecurity risk assessment to determine appropriate depth.
- Do not claim that every CRA product legally requires the same penetration-test programme.
Penetration Testing Simulates Realistic Attack Paths
A penetration test attempts to determine whether identified weaknesses can be combined or exploited to compromise meaningful product security objectives. The tester may move across authentication, authorisation, exposed interfaces, data flows and privilege boundaries rather than examining each technical issue in isolation. This makes penetration testing useful for discovering attack chains that simple automated checks may not reveal. The test should still have a defined scope, safety constraints and expected evidence rather than being treated as unrestricted hacking.
- Define the product and version under test.
- Define permitted attack surfaces.
- Define testing constraints.
- Identify important security objectives.
- Preserve reproducible evidence for confirmed findings.
Penetration Testing Is Different From Vulnerability Scanning
Vulnerability scanning generally identifies known weaknesses, insecure configurations or suspicious patterns using automated or semi-automated checks. Penetration testing goes further by attempting to validate exploitability and demonstrate realistic security impact. A scanner may identify an outdated service version, while a penetration test may determine whether that weakness can actually be used to reach a privileged function in the product. Both techniques can be useful, but one should not automatically be presented as a substitute for the other.
- Scanning provides broad automated coverage.
- Penetration testing provides deeper adversarial validation.
- Scanner findings still require triage.
- Penetration findings should describe demonstrated impact.
- Use both where the product risk justifies them.
Scope the Test From the Cybersecurity Risk Assessment
A penetration-test scope should reflect the product's cybersecurity risk assessment rather than simply repeat the same checklist for every product. High-value targets can include administrative interfaces, remote-management services, authentication boundaries, update mechanisms, externally exposed APIs, parsers, wireless interfaces and privileged local functions. Where important risks depend on cloud services or companion applications, those components may also need inclusion where they form part of the relevant product security architecture.
- Use the risk assessment to identify high-value attack paths.
- Include important external interfaces.
- Include privileged functions.
- Include update mechanisms where relevant.
- Include connected services where they affect product security.
Authentication and Authorisation Deserve Adversarial Testing
Authentication and authorisation controls often contain state, workflow and privilege assumptions that basic functional tests do not expose. A penetration test can attempt credential bypass, session abuse, privilege escalation, direct calls to protected functions and cross-account access. Testing should verify not only that valid users can perform intended actions but that untrusted or lower-privileged actors cannot reach protected functionality through alternative paths.
- Test authentication bypass attempts.
- Test privilege escalation.
- Test direct access to protected functions.
- Test session handling.
- Test separation between user roles.
Test External Interfaces and Parsers
External interfaces are natural penetration-testing targets because they form part of the product's attack surface. APIs, network services, file parsers, protocol handlers, administrative endpoints and wireless interfaces can be tested for malformed input, unauthorised operations and unexpected state transitions. The objective is not simply to generate errors but to determine whether an attacker can violate confidentiality, integrity, availability or access-control objectives.
- Test exposed APIs.
- Test network services.
- Test parsers and protocol handlers.
- Test administrative endpoints.
- Test malformed and unexpected input.
Test the Security Update Path Where It Is in Scope
Update mechanisms are particularly sensitive because compromise of the update path can undermine the entire product. Where appropriate to the penetration-test scope, testers can examine update authenticity, package integrity, rollback protections, version validation and the exposure of update infrastructure. An attempt to install a tampered or unauthorised package can provide useful evidence that update controls reject malicious modification as intended.
- Test unauthorised update packages.
- Test integrity checks.
- Test signature verification.
- Test rollback behaviour where relevant.
- Review privileged update interfaces.
Findings Need Risk-Based Remediation
A penetration-test report is not the end of the process. Confirmed findings should be mapped to affected versions, security requirements and relevant risks. Teams should determine whether remediation is required before release, whether a compensating control exists or whether residual risk can be accepted through a controlled process. High-impact findings should remain visible until their disposition is complete rather than disappearing into a general development backlog.
- Validate confirmed findings.
- Identify affected product versions.
- Assign remediation ownership.
- Document risk decisions.
- Retest important fixes.
Retesting Confirms the Fix Rather Than the Ticket Status
Closing an engineering ticket does not demonstrate that the original attack path has been removed. Significant penetration-test findings should be retested after remediation where practical. Retesting can also reveal whether a fix created a new bypass or only addressed one visible symptom. Important attack scenarios can then become regression tests so later product changes are less likely to reintroduce the weakness.
- Retest significant findings.
- Confirm the original attack path no longer works.
- Check for obvious bypasses.
- Convert important fixes into regression coverage.
- Retain retest results.
Penetration-Test Reports Can Support Annex VII Evidence
Annex VII requires reports of tests carried out to verify conformity with applicable essential cybersecurity requirements. A penetration-test report can form part of that evidence where the test is relevant to those requirements. Useful records include the product version, scope, methodology, environment, findings, severity, remediation status and retest results. The report should be one part of the wider security-test record rather than the sole basis for claiming CRA conformity.
- Identify product version and test scope.
- Record confirmed findings.
- Record security impact.
- Record remediation status.
- Retain retest evidence.
- Connect findings to relevant requirements.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.