The Cyber Resilience Act (Annex I, Part I) requires that the essential cybersecurity requirements are effectively implemented in the product, and Article 13(6) obliges manufacturers to undertake effective and regular testing and review of the security of the product. Requirements testing is the verification mechanism that closes the loop between what was specified and what was actually built; without it, security requirements remain untested assumptions rather than confirmed product properties.
Verify that every security requirement defined for the product is explicitly tested before release. Testing must confirm the correct implementation of authentication, access control, input validation, encoding and escaping of data, and encryption controls to protect data and system integrity. Security testing must be executed not only prior to initial release but whenever the product changes its implementation or use of these security controls, ensuring that modifications do not silently degrade the product's security posture.
Document test results and link them to the corresponding security requirements, establishing clear traceability from requirement to test case to outcome. Ideally, security requirements testing should be automated as part of the development pipeline through a combination of unit, integration, and acceptance tests that verify security controls with every build. Static and dynamic application security testing tools (SAST and DAST) can complement this effort by identifying certain categories of weaknesses, but relying solely on scanning tools is not sufficient to verify that security requirements have been correctly implemented.