Penetration Testing

Penetration testing (pen testing) is a controlled security exercise in which a qualified tester — internal or external — attempts to compromise a target system using the same techniques and tools a real attacker would use. The scope, rules of engagement, and target environment are agreed in advance. Pen testing goes beyond automated vulnerability scanning: it involves manual analysis, exploit chaining, and attacker-perspective reasoning to uncover vulnerabilities that automated tools miss. Outputs include a report of confirmed vulnerabilities, exploitation paths, and remediation recommendations. Common methodologies include OWASP, PTES, and OSSTMM.

The CRA's essential cybersecurity requirements in Annex I require manufacturers to ensure their products are designed, developed, and produced to achieve an appropriate level of cybersecurity. Conducting penetration testing before market placement is the most credible demonstration that a manufacturer has proactively searched for exploitable weaknesses — not merely assumed their product is secure. For Important Class I and Class II products, conformity assessment bodies and notified bodies will expect evidence of pre-release security testing as part of the technical documentation. Pen test reports form a core part of the technical file maintained under Article 23.

Manufacturers should embed penetration testing into their secure development lifecycle (SDLC), not treat it as a one-time pre-release activity. Best practice includes: (1) threat modelling early in design to focus testing on the highest-risk attack surfaces; (2) automated vulnerability scanning during CI/CD pipelines; (3) manual penetration testing of release candidates against defined scope before market placement; (4) re-testing after significant architectural changes or when critical third-party components are updated. Test reports, including findings, risk ratings (CVSS), and remediation evidence, should be retained as part of technical documentation for the duration of the product's support period.

A frequent error is treating a single pre-launch pen test as a permanent proof of security. Threat landscapes evolve and new attack techniques emerge, so periodic re-testing is essential. Manufacturers also commonly scope tests too narrowly — for example, testing only the web interface while leaving firmware, update mechanisms, and cloud APIs untested. Another mistake is failing to remediate and retest: a pen test report that documents critical findings not fixed before market placement provides evidence of non-compliance rather than compliance. Finally, using unqualified internal staff for complex embedded system assessments often yields incomplete coverage.