EU Cyber Resilience Act — Guide for Quality Assurance & Test Engineer
What the CRA means for your role, your team, and your day-to-day responsibilities.
Quality assurance teams are instrumental in demonstrating CRA conformity. The technical file that underpins a product's Declaration of Conformity must contain evidence that the product has been tested against the Annex I security requirements. QA engineers design, execute, and document that testing. They also own regression test coverage for security vulnerabilities, ensuring that patched issues do not recur in subsequent releases. This guide explains how QA practices must adapt to the CRA's evidential requirements.
Your CRA responsibilities:
- ›Design and execute security test cases covering each Annex I Part I security property
- ›Maintain regression test suites for patched vulnerabilities, ensuring confirmed defects do not recur
- ›Produce test reports in a format suitable for inclusion in the product technical file
- ›Integrate security testing into the CI/CD pipeline as automated quality gates
- ›Collaborate with the security team on dynamic analysis, fuzz testing, and penetration test scope
- ›Track defect discovery rates for security issues and report trends to product and engineering leadership
- ›Verify that software update mechanisms deliver integrity-protected patches correctly in all supported configurations
QA's role in CRA conformity
CRA conformity is not self-asserted — it must be demonstrated through documented evidence. The technical file required under Annex VII must include test reports that show the product meets the Annex I security requirements. QA engineers are responsible for producing this evidence. This requires a shift from defect-focused testing to conformity-focused testing: each Annex I requirement becomes a test objective, and each test execution produces a traceable record that maps test outcomes to specific regulatory obligations. For Default-class products undergoing self-assessment, well-documented QA test evidence is the primary conformity record. For Class I Important Products relying on harmonised standards, test evidence must demonstrate compliance with the relevant standard's security test requirements.
Security test coverage requirements
Annex I Part I identifies the security properties that products must satisfy. QA must design test coverage for each one: authentication control testing (verifying default credential policies, brute-force resistance, and session management), data protection testing (verifying encryption of data at rest and in transit), update integrity testing (verifying that only signed updates can be applied), attack surface testing (verifying that unnecessary services and ports are disabled in default configuration), and resilience testing (verifying that the product degrades gracefully under denial-of-service conditions). Static application security testing, dynamic application security testing, and software composition analysis should all contribute to security test evidence. Fuzz testing is increasingly expected for network-facing interfaces and file parsing components. All test findings — including those that passed — must be documented.
Regression testing for vulnerabilities
When a vulnerability is discovered and remediated, QA must create a regression test that verifies the fix is effective and that the vulnerability cannot be reproduced. This regression test must be retained in the test suite permanently — a recurrence of a previously patched vulnerability is a serious CRA non-conformity because it indicates that the vulnerability management process failed. QA should maintain a dedicated security regression suite, labelled with the CVE or internal vulnerability identifier and the release in which the fix was first applied. When a security patch is shipped, the regression test should be executed automatically in the CI/CD pipeline before the release is approved. The test pass record forms part of the technical file evidence for that release.
Contributing to the technical file
Annex VII specifies that the technical file must contain a general description of the product, design and development documentation, and — critically — test reports. QA is responsible for producing these reports in a structured format that a market surveillance authority can interpret without additional context. Each test report should include: the test objective mapped to a specific Annex I requirement or harmonised standard clause, the test environment configuration, the test methodology, the pass/fail outcome, and the tester's identity and sign-off date. Reports should be version-controlled and linked to the specific product release they cover. When the product is updated, new test reports covering any changed functionality must be added to the technical file and the Declaration of Conformity reviewed to confirm it remains accurate.
Getting started checklist
Begin by mapping the existing QA test plan to Annex I Part I requirements and identifying gaps in security coverage. For each gap, design and document a test case with a clear pass criterion linked to the regulatory requirement. Integrate SAST and SCA tools into the CI/CD pipeline as automated quality gates that block release on critical findings. Create a security regression test suite covering all vulnerabilities patched in the past 24 months. Establish a test report template that includes the mandatory fields for technical file inclusion. Confirm with the product manager and compliance team what standard the product will self-assess against, so test coverage can be calibrated to that standard's requirements. Review the CRA readiness score on CVD Portal to benchmark current test coverage completeness.
CVD Portal handles your CRA Article 13 obligations automatically.
Public CVD submission portal, 48-hour acknowledgment tracking, Article 14 deadline alerts, and CSAF advisory generation — built for QA Engs and their teams.
Start your free portalFrequently asked by QA Engs
Is penetration testing required under the CRA?+
The CRA does not explicitly mandate penetration testing, but Annex I requires that products be free of known exploitable vulnerabilities at the time of placing on the market. Penetration testing is one of the most effective methods for identifying exploitable vulnerabilities that static analysis and functional testing miss. For Class II Important Products requiring notified body assessment, the notified body is likely to expect evidence of vulnerability discovery activities including penetration testing. For Default and Class I products, penetration testing is a best practice that significantly strengthens the technical file and reduces regulatory risk.
How often must security testing be repeated?+
The technical file must be updated to reflect the current state of the product throughout its market life. This means security testing should be repeated when: a new product version is released with functional changes; a new vulnerability class is discovered that requires testing the product's exposure; a third-party component is updated; or the product is extended to a new deployment environment. QA teams should also conduct periodic full security test cycles — at minimum annually — regardless of release activity, to detect vulnerabilities introduced by changes in the threat landscape rather than in the product itself.
What qualifications do QA engineers need to conduct CRA-relevant security testing?+
The CRA does not specify required qualifications for testers performing conformity assessment activities. However, for notified body assessments of Class II Important Products, the notified body will evaluate the competence of those who conducted manufacturer-side testing. Relevant credentials include CREST certifications, OSCP, CEH, or equivalent vendor-neutral qualifications. For Default and Class I products undergoing self-assessment, the manufacturer must be able to demonstrate that testers had sufficient knowledge of both the product and the relevant security testing methodologies. Formal training records and documented test methodology descriptions serve as evidence of competence.
Key CRA articles for QA Engs
Need a CVD policy template your team can deploy today?
Free CRA-compliant templates for every stage — from first CVD policy to full PSIRT programme.