CRA security test documentation should prove more than the fact that testing happened. The evidence should show what was tested, which product and configuration were tested, why the test mattered, which Annex I requirement or risk it verified, what result was expected, what actually happened and how failures were corrected and retested.
Annex VII Expressly Requires Test Reports
Annex VII point 6 requires reports of tests carried out to verify conformity of the product with digital elements and the vulnerability-handling processes with applicable essential cybersecurity requirements in Annex I Parts I and II. Testing evidence therefore needs to cover more than product functionality. Manufacturers should be able to show how relevant product-security properties and operational vulnerability-handling processes were verified.
- Test applicable Part I product requirements.
- Verify relevant Part II vulnerability-handling processes.
- Retain identifiable test reports.
- Connect reports to technical documentation.
- Use results as conformity evidence.
A Test Report Should Identify the Product
Security results can become misleading if the tested product cannot be identified precisely. Record product name, hardware revision where relevant, software or firmware version, build identifier, configuration and significant deployment characteristics. If the report covers several product variants, identify which controls and results apply to each. This prevents an old penetration test against a substantially different version from being reused as though it verified the current marketed product.
- Product name.
- Product version.
- Build identifier.
- Hardware revision where relevant.
- Security-relevant configuration.
- Deployment profile.
Define the Test Objective
Every important test should explain the security outcome being verified. The objective can reference a risk-treatment control, security requirement, Annex I requirement or vulnerability-handling process. A statement such as perform security testing is too broad to establish what the result proves. A clearer objective can be verify that unauthenticated users cannot invoke administrative operations or verify that update packages with invalid signatures are rejected.
- Security requirement.
- Risk identifier.
- Annex I reference.
- Control identifier.
- Expected security outcome.
Document Test Scope
Test scope should identify components, interfaces, roles and functions included in the activity. It should also identify important exclusions. A network penetration test that excludes local interfaces does not verify the security of those interfaces. A test of one update path may not verify every supported update mechanism. Clear scope allows compliance reviewers to understand which conclusions are supported and where separate evidence is required.
- Components in scope.
- Interfaces in scope.
- User roles.
- Deployment environment.
- Explicit exclusions.
Document the Test Environment
The test environment should be representative enough that results are meaningful. Record network topology, supporting services, identity configuration, external dependencies and other conditions that materially affect the control. Where production cannot be reproduced exactly, document the differences and why they do not invalidate the result. This is especially important for cloud-connected products, distributed systems and availability testing.
- Network configuration.
- External services.
- Identity configuration.
- Test accounts and roles.
- Relevant platform versions.
- Differences from production.
Document Test Method
The report should identify how the test was performed at a level that allows a qualified reviewer to understand the result. Depending on the control, methods can include automated security testing, code review, configuration review, protocol testing, fuzzing, penetration testing, load testing, update testing or process review. The CRA does not require every product to use every testing technique. The method should be appropriate to the risk and security property being verified.
- Testing technique.
- Tools where relevant.
- Manual review where relevant.
- Input conditions.
- Execution date.
- Responsible tester or team.
Record Expected Results Before Interpreting the Outcome
A verification test should have a defined expected result. Without one, teams can observe product behaviour and declare it acceptable after the fact. The expected result should derive from the security requirement or design control. For example, a malformed update package should be rejected without altering installed software. A user without administrative privileges should be prevented from changing protected configuration. Clear expectations make pass or fail conclusions more defensible.
- Expected control behaviour.
- Expected failure behaviour.
- Security boundary being verified.
- Acceptance criteria.
Record the Actual Result
Document what actually happened during the test. Include relevant evidence such as output, logs, screenshots, traces, configuration records or generated reports where appropriate. Avoid marking a test pass without enough supporting information to understand why. For automated tests, preserve tool versions or relevant rule versions where they materially affect reproducibility. The technical documentation can reference controlled attachments rather than embedding every raw artefact in the main report.
- Observed behaviour.
- Pass or fail conclusion.
- Relevant logs or traces.
- Tool output.
- Supporting evidence references.
Document Findings Separately From Raw Tool Output
Automated security tools can generate large numbers of alerts. A test report should distinguish raw observations from confirmed security findings. Findings should identify affected component, product version, technical condition, security consequence and relationship to the tested requirement. False positives and non-applicable findings can be retained with assessment rationale rather than silently deleted. This preserves an auditable record of how the manufacturer interpreted the testing evidence.
- Finding identifier.
- Affected component.
- Technical condition.
- Security consequence.
- Assessment status.
- Supporting evidence.
Do Not Treat Finding Severity as Product Risk Automatically
A testing tool or tester can assign severity to a finding, but that value does not automatically establish the product-specific cybersecurity risk. Feed confirmed findings back into the Article 13 risk assessment where appropriate. Reachability, deployment conditions, existing controls, affected assets and consequences can modify the product-specific conclusion. The report can retain both the testing severity and the resulting product-risk assessment where they differ.
- Record test severity.
- Assess product-specific risk.
- Document important differences.
- Link to the relevant risk record.
Document Failed Tests and Remediation
A failed security test is useful evidence if the manufacturer responds to it in a controlled way. Record the issue, affected control, remediation decision, responsible owner and target version. The original failure should not simply disappear after a fix because the history demonstrates how verification influenced the product. Where the issue affects the cybersecurity risk assessment, update that record as appropriate.
- Failed test identifier.
- Related finding.
- Remediation action.
- Responsible owner.
- Target product version.
- Risk-assessment impact.
Retest After Remediation
A code change or configuration change does not by itself prove that the original issue has been fixed. Retest the original condition and relevant adjacent behaviour. Record the new product version or build and the result. For important vulnerabilities, regression testing should also determine whether the correction introduced a new security weakness or broke another required control.
- Reproduce the original test.
- Verify the correction.
- Record the fixed version.
- Perform relevant regression testing.
- Update the final result.
Test Annex I Part I Product Security Properties
Depending on applicability, Part I verification can include access-control tests, secure-default checks, confidentiality and integrity verification, data-minimisation review, resilience testing, attack-surface inspection, exploitation-mitigation testing, logging and monitoring verification, secure data removal and security-update testing. The test programme should be derived from the risk assessment and control mapping rather than use the same generic checklist for every product.
- Access controls.
- Secure defaults.
- Confidentiality and integrity.
- Availability and resilience.
- Attack-surface controls.
- Exploit mitigations.
- Logging and monitoring.
- Data removal.
- Security updates.
Verify Annex I Part II Vulnerability-Handling Processes
Annex VII point 6 also refers to tests verifying the conformity of vulnerability-handling processes with Annex I Part II. Evidence can therefore include checks that component and SBOM processes operate, vulnerability reports reach the correct workflow, remediation decisions are traceable, coordinated disclosure procedures work and update packages are securely distributed. Some of this verification is process-oriented rather than conventional product penetration testing.
- Component and SBOM process.
- Vulnerability intake.
- Security testing and review process.
- Remediation workflow.
- Coordinated disclosure process.
- Secure update distribution.
Penetration Testing Is One Technique, Not the Entire CRA Test Programme
Penetration testing can provide valuable adversarial evidence, but the CRA does not prescribe penetration testing as the universal method for verifying every product or Annex I requirement. Annex VII requires reports of tests carried out to verify conformity, but it does not prescribe one testing technique that must be used for every product or requirement. Some requirements are better verified through design review, configuration inspection, automated tests, resilience exercises, build checks or process evidence. Manufacturers should create a verification programme based on applicable requirements and product risks rather than treating one annual penetration test as the complete compliance package.
- Use penetration testing where appropriate.
- Use architecture review.
- Use configuration verification.
- Use automated and integration testing.
- Use resilience testing.
- Use process verification.
Record Test Limitations
Every security test has boundaries. A test can be time-limited, exclude destructive techniques, omit unavailable external services or use a non-production environment. Record significant limitations so that the report is not interpreted more broadly than the evidence supports. Limitations can identify where additional testing, operational monitoring or other evidence is required.
- Time limitations.
- Scope exclusions.
- Environment differences.
- Unavailable dependencies.
- Testing restrictions.
- Remaining evidence needs.
Version Test Evidence With the Product
Test results should remain tied to the product version, configuration and architecture they verified. Material changes can invalidate earlier results. A new authentication system can make old access-control tests obsolete. A changed update mechanism can require new integrity testing. Product-change review should therefore determine which security tests need repetition and which historical reports remain valid evidence.
- Product version.
- Build identifier.
- Configuration.
- Architecture baseline.
- Test date.
- Retest trigger.
A Practical CRA Security Test Report
A practical report can include report identifier, tested product and version, test objective, risk or requirement reference, Annex I mapping, scope, environment, method, expected result, actual result, findings, limitations, remediation, retest status and evidence attachments. The exact format is not prescribed by the CRA. The important outcome is that the report demonstrates how the manufacturer verified relevant product-security properties or vulnerability-handling processes.
- Report identifier.
- Product and version.
- Test objective.
- Annex I reference.
- Scope.
- Environment.
- Method.
- Expected result.
- Actual result.
- Findings.
- Limitations.
- Remediation.
- Retest status.
- Evidence references.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.