CRA security testing should provide evidence that the product's security controls work in normal, abnormal and adversarial conditions. A useful programme combines automated and targeted manual testing, negative tests, regression tests and risk-driven tests of important boundaries such as authentication, external interfaces, updates, cryptographic controls and resilience.
Annex I Explicitly Requires Effective and Regular Tests and Reviews
Annex I Part II point 3 requires manufacturers to apply effective and regular tests and reviews of the security of the product with digital elements. This is an explicit CRA requirement. The Regulation does not prescribe one mandatory test framework, toolset or fixed number of tests. The manufacturer therefore needs a testing approach appropriate to the product's architecture, cybersecurity risk assessment, applicable Annex I requirements and the significance of product changes.
- Security testing is explicitly required.
- Testing should be effective.
- Testing should be regular.
- Test scope should reflect product risk.
- Testing and security review are related but distinct activities.
Test Scope Should Follow the Cybersecurity Risk Assessment
Not every product needs identical security testing. A remotely administered infrastructure product can require a different test programme from a low-complexity local application. The cybersecurity risk assessment can help identify the controls and attack paths that deserve deeper verification. High-impact functions, exposed interfaces, privileged operations, authentication, update mechanisms and security-sensitive data flows often deserve stronger testing because failure could undermine several Annex I outcomes at once.
- Identify high-risk product functions.
- Identify exposed attack surfaces.
- Prioritise privileged interfaces.
- Prioritise security-critical controls.
- Adjust depth when risk or architecture changes.
Combine Positive and Negative Security Testing
Positive tests verify that intended product behaviour works. Negative testing verifies that unsafe, malformed or unauthorised behaviour is rejected. A login test should confirm that valid credentials work, but security testing should also confirm that unauthorised access is denied. An update test should confirm that a valid update installs, while negative testing should confirm that an invalid or tampered update is rejected. Both perspectives are important for demonstrating security properties.
- Test valid security behaviour.
- Test unauthorised access attempts.
- Test malformed inputs.
- Test invalid or tampered update packages.
- Test boundary and error conditions.
Automated Analysis Can Provide Continuous Coverage
Automated controls such as static analysis, software composition analysis, secret scanning and selected dynamic testing can provide repeatable coverage throughout development. These tools are useful for catching classes of defects early and for preventing regression. They should not be treated as complete security assurance. Automated findings require triage, and product-specific architecture risks may need targeted tests that generic tools cannot infer.
- Use static analysis where appropriate.
- Use software composition analysis.
- Use secret scanning.
- Use dynamic testing where appropriate.
- Triage and remediate meaningful findings.
Test Authentication and Access-Control Boundaries
Authentication and authorisation failures can expose high-value product functions. Testing should verify both successful access and denied access across relevant roles and privilege boundaries. Tests can cover missing credentials, invalid credentials, expired sessions, insufficient privilege and attempts to call protected functions directly. Where administrative interfaces or remote-management functions exist, their exposure and permission model deserve particular attention.
- Test valid authentication.
- Test invalid authentication.
- Test role and privilege boundaries.
- Test direct access to protected functions.
- Test session and recovery behaviour.
Test External Interfaces and Attack-Surface Controls
Annex I requires attack surfaces, including external interfaces, to be limited where applicable. Security testing can verify that unnecessary services are not exposed, interfaces require appropriate controls and malformed or unexpected traffic does not create unsafe behaviour. Network scanning, API security testing, protocol testing and targeted fuzzing can be appropriate depending on the product. The specific techniques should be selected from the risks and architecture rather than applied mechanically to every product.
- Verify expected exposed services.
- Check for unintended network listeners.
- Test API authentication and validation.
- Test relevant protocols.
- Use fuzzing where it addresses meaningful parser or protocol risk.
Test Security Update Mechanisms
Update mechanisms are security-critical because a weakness can undermine otherwise strong product controls. Testing can verify update authenticity, integrity checks, rollback behaviour, interrupted updates, version controls and failure handling. Negative tests should confirm that unauthorised, corrupted or improperly signed update packages are rejected. Update testing also needs to cover the actual distribution and installation path rather than only the cryptographic function in isolation.
- Test valid update installation.
- Test signature or authenticity verification.
- Test tampered packages.
- Test interrupted updates.
- Test recovery and rollback behaviour.
Regression Testing Prevents Security Controls From Quietly Breaking
Security defects can reappear when later product changes affect shared code, configuration or dependencies. Important security tests should therefore become part of regression testing where practical. A vulnerability fix can produce a new test demonstrating the original weakness no longer works. Authentication, update validation, configuration and other critical controls can also have recurring tests that run for later versions. Security regression creates evidence that later development did not silently undo earlier protections.
- Convert important vulnerability fixes into regression tests.
- Repeat critical access-control tests.
- Repeat update-security tests.
- Repeat secure-configuration checks.
- Review regression scope after architecture changes.
Testing Should Continue When Security-Relevant Changes Occur
The word regular does not require one identical calendar schedule for every product. Testing can include recurring activity and event-driven triggers. Significant changes to authentication, external interfaces, update mechanisms, cryptography, dependencies or deployment architecture can justify targeted testing before release. Post-release vulnerability findings can also reveal where the existing test programme needs stronger coverage.
- Define security-relevant change triggers.
- Retest affected controls after important changes.
- Use periodic testing where useful.
- Add tests after significant vulnerability findings.
- Keep the programme aligned with product risk.
Annex VII Requires Test Reports as Technical Evidence
Annex VII requires the technical documentation to include reports of the tests carried out to verify conformity of the product with digital elements and its vulnerability-handling processes with the applicable essential cybersecurity requirements. Test evidence should therefore be traceable to the product version, test scope and relevant security requirement. A useful report identifies what was tested, the environment or build, the method, findings, remediation status and final result.
- Retain reports of the tests carried out.
- Identify the tested product version.
- Identify the test scope and method.
- Record security findings.
- Record remediation or disposition.
- Connect results to relevant requirements.
Security Testing Is Evidence, Not a Substitute for Secure Development
Testing can reveal weaknesses but cannot efficiently compensate for every poor architecture decision. A product with unnecessary privileged interfaces or an unsafe trust model may require redesign rather than more scanning. CRA readiness works best when requirements, architecture, secure coding, security reviews and testing form one lifecycle. Testing then provides evidence that the implemented controls perform as intended and helps discover defects that earlier activities missed.
- Use testing to verify controls.
- Feed findings back into design and coding.
- Do not use scanning as a substitute for risk assessment.
- Use repeated defect patterns to improve the development process.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.