The Cyber Resilience Act (CRA) requires manufacturers to apply effective and regular tests and reviews of the security of products with digital elements. It does not prescribe one universal penetration-test package, one scanner, or one fixed calendar interval for every product. The practical task is therefore to build a testing programme that is proportionate to the product's cybersecurity risks, repeated often enough to remain meaningful, and documented well enough to support the manufacturer's technical and conformity evidence.
This requirement sits in Annex I Part II, which covers vulnerability handling. It matters both before market placement and during the support period because manufacturers must ensure that vulnerabilities are handled effectively throughout that lifecycle. Annex VII also requires technical documentation to include reports of tests carried out to verify conformity of the product and the vulnerability-handling processes with the applicable essential cybersecurity requirements.
What "effective and regular" means in practice
The CRA gives manufacturers an outcome to achieve rather than a fixed test catalogue.
Effective testing should be capable of finding or disproving security weaknesses that are relevant to the product's actual risks. A test that always runs but does not exercise the attack paths, interfaces, privilege boundaries, update mechanisms or security controls identified by the risk assessment is difficult to justify as effective.
Regular testing should recur as part of the product lifecycle rather than being treated as a one-time pre-release exercise. The Regulation does not set a universal frequency such as monthly, quarterly or annually. The manufacturer therefore needs a reasoned cadence that reflects product risk, change rate, exposure, vulnerability information and support obligations.
A useful test policy should answer four questions:
- Which security risks and requirements does each test activity cover?
- What triggers the test to run again?
- Which product, variant, release or supported version is in scope?
- What evidence shows the result and the follow-up decision?
This turns "we run security tests" into a process that another reviewer can reconstruct.
Start from the cybersecurity risk assessment
Article 13 requires the manufacturer to perform and document a cybersecurity risk assessment and to take that assessment into account during planning, design, development, production, delivery and maintenance.
Security testing should therefore be derived from that risk model rather than added as an independent checklist at the end.
For example, if the risk assessment identifies an externally reachable management interface as a significant attack surface, the testing plan should include evidence relevant to that interface: authentication and authorization checks, input handling, session behaviour, exposure under supported configurations and verification of mitigations. If secure update delivery is a critical control, the plan should exercise authenticity checks, rollback or failure behaviour where relevant, update transport assumptions and the handling of invalid packages.
The link should be explicit:
- A risk or essential requirement creates a test objective.
- The objective maps to one or more test methods.
- The test runs against an identified product or release.
- Findings become owned remediation or justified decisions.
- Retesting verifies the resulting change.
- The retained report links the result back to the requirement or risk.
The CRA does not require this exact workflow. It is a practical way to make the legal requirement auditable.
Use several test methods instead of one security gate
No single technique provides complete product-security coverage. An effective programme normally combines methods that answer different questions.
Automated security checks
Automated checks are useful for repeatable detection of known classes of weakness and for regression control. Depending on the product, this can include dependency analysis, static analysis, secret detection, configuration checks, binary analysis, container or firmware scanning, protocol tests and security-focused unit or integration tests.
Automation is strongest when the result is tied to the exact artifact or source revision tested. A report that cannot identify the release it covered becomes weak evidence once the product changes.
Manual security review
Manual review is useful where context and design intent matter: trust boundaries, authorization models, misuse cases, cryptographic design choices, security-sensitive configuration, privileged operations and interactions between components.
A security review should record the question reviewed, scope, assumptions, reviewer, material findings and resulting decisions. "Reviewed by security" without retained reasoning is difficult to evaluate later.
Penetration and adversarial testing
Penetration testing can test realistic attack paths and interactions that isolated automated checks may miss. Its value depends on scope. A generic external scan does not demonstrate that product-specific high-risk paths were exercised.
Record which interfaces and scenarios were tested, the configuration used, credentials or privileges assumed, excluded areas, limitations and the exact product build. When a test intentionally does not cover a risk identified in the risk assessment, document how that risk is covered elsewhere.
Verification after remediation
Fixing a finding is not the end of the test lifecycle. Retest the affected path and keep the verification result. Where the change could create adjacent regressions, include appropriate regression checks.
The retained chain should show: finding -> decision -> change -> verification -> final status.
Define triggers, not only dates
A calendar cadence can be useful, but change-triggered testing is often more defensible for product security.
Consider defining mandatory retest triggers such as:
- a new major or security-relevant release;
- changes to authentication, authorization or privilege boundaries;
- new or materially changed network interfaces;
- update, boot, signing or trust-chain changes;
- replacement of a security-relevant third-party component;
- a new vulnerability that changes the product's risk picture;
- a substantial architectural change;
- a material change to supported deployment conditions;
- evidence that an earlier test assumption is no longer valid; or
- a significant update to the cybersecurity risk assessment.
Periodic testing can then complement those triggers. The interval should be justified by the product's exposure and lifecycle rather than copied from an unrelated policy.
A low-change product can still require retesting when the external threat or vulnerability context changes. "No code changed" does not mean the security assumptions remained valid.
Keep test scope product- and release-specific
Security evidence loses value quickly when scope is ambiguous.
Every material test record should identify, as applicable:
- product and variant;
- version or release identifier;
- artifact hash, firmware image, package or build identifier;
- configuration and enabled features;
- relevant environment or deployment assumptions;
- test date and tool or method version;
- tester or responsible team; and
- any excluded components or scenarios.
This is particularly important where several supported versions exist at once. A penetration test against version 4.2 should not silently be used as evidence for version 4.5 if security-relevant code, dependencies, configuration or interfaces changed.
For automated tests, preserve enough metadata to reproduce the relationship between the result and the artifact. The CRA does not require the manufacturer to retain source code in a particular system; the key point is that the technical evidence must identify what was assessed.
Record negative results as well as findings
A useful test report is not merely a vulnerability list.
Where testing found no exploitable issue in the covered scope, retain the scope, method, assumptions and result. That makes a clean result reviewable. Without scope information, "zero findings" says little about what was actually exercised.
Where testing does find weaknesses, retain at least:
- finding identifier and description;
- affected product or release;
- severity or prioritisation rationale;
- relevant risk or essential requirement;
- evidence supporting the finding;
- remediation or mitigation decision;
- owner and target state;
- verification result; and
- final disposition.
Do not convert an internal severity score into a legal conclusion automatically. Severity helps prioritise work; CRA conformity depends on the applicable requirements, product context and evidence.
Test the vulnerability-handling process itself
Annex I Part II point 3 refers to tests and reviews of product security, while Annex VII requires test reports that verify conformity of both the product and the vulnerability-handling processes.
That means evidence should not stop at technical exploit tests. Manufacturers also need confidence that the vulnerability process works operationally.
Useful process exercises can include:
- submitting a test report through the published vulnerability contact;
- checking that intake creates an owned case with product scope;
- verifying escalation and triage paths;
- testing whether component and SBOM context can be retrieved;
- confirming that remediation reaches the correct supported versions;
- checking secure update distribution and advisory preparation; and
- rehearsing reporting decision paths where Article 14 could apply.
A tabletop exercise can be useful for process validation, but it should not replace technical testing of the product itself.
Make the evidence usable in technical documentation
Article 31 requires the technical documentation to contain relevant data about the means used to ensure that the product and manufacturer processes comply with Annex I, and Annex VII specifically includes reports of tests carried out to verify conformity.
A practical test report does not need to be unnecessarily long. It does need enough context to support the conclusion.
For each significant test activity, retain:
- objective and linked risk or requirement;
- product and release scope;
- method and tools;
- environment and assumptions;
- test cases or scenarios at an appropriate level;
- results and raw evidence references;
- findings and decisions;
- remediation and retest evidence;
- unresolved limitations; and
- approval or review record.
If evidence is stored in several engineering systems, keep stable references so the technical documentation does not become a set of broken links after teams or tools change.
Distinguish manufacturer testing from notified-body testing
Most CRA products can use internal control for conformity assessment, subject to the conditions in Article 32. Important Class I products may require third-party assessment where the conditions for internal control are not met, while Class II and certain critical-product routes involve the procedures specified by the CRA.
Under EU-type examination, a notified body examines technical documentation and supporting evidence and carries out, or has carried out, appropriate examinations and tests. The manufacturer may also need to provide results from its own or another testing laboratory where necessary.
This does not make ordinary manufacturer testing optional. Annex I Part II applies to the manufacturer's vulnerability-handling obligations, and test reports form part of the technical-documentation evidence. Third-party conformity assessment is a separate question about the applicable assessment route.
Treat standards as implementation support, not a substitute for the Regulation
The Joint Research Centre and ENISA have mapped existing cybersecurity standards against CRA requirements, and European standardisation work is continuing. The Commission's implementation timeline identifies further standardisation deliverables during 2026 and 2027.
Relevant standards and technical guidance can help manufacturers define test methods, assurance depth and evidence structures. Where harmonised standards are later cited in the Official Journal and are applicable, they can have a specific role in presumption of conformity.
Until then, a test programme should not be justified only by saying that a tool or framework is industry standard. Keep the rationale tied to the product's risks and the applicable CRA requirements.
BSI TR-03183 is also useful implementation guidance, but BSI describes parts of the guideline as evolving work. Treat such material as guidance rather than as the legal source of the CRA obligation.
A practical security-testing operating cycle
A compact operating model can keep testing continuous without turning every release into a large audit.
- Set the test basis. Confirm the applicable CRA requirements, current cybersecurity risk assessment and product scope.
- Select methods. Map significant risks to automated checks, review, penetration testing or other verification activities.
- Define cadence and triggers. Specify both periodic and change-based retest conditions.
- Run against identified artifacts. Capture release, configuration and environment.
- Triage findings. Separate signals from confirmed product weaknesses and assign owners.
- Remediate and verify. Retest fixes or mitigations and record residual limitations.
- Review coverage. Ask whether new architecture, dependencies, vulnerabilities or threat information created untested risk.
- Retain evidence. Keep the reports and decision chain accessible for technical documentation and conformity assessment.
The useful management metric is not simply the number of tests run. It is whether relevant product risks have current, product-specific verification evidence and whether failed tests lead to traceable decisions and retesting.
Security-test evidence becomes harder to defend when results, findings and release decisions live in separate systems. AA-sec is designed around traceability between requirements, security evidence, vulnerability work, assessments and release decisions so that records remain connected to the exact product or lifecycle context. It does not decide which tests are sufficient, make engineering decisions automatically or determine CRA conformity.
Key takeaway
The CRA's security-testing requirement is deliberately broader than a single penetration test. Manufacturers need a repeatable, risk-based programme that tests the product and supports the vulnerability-handling process throughout the relevant lifecycle.
For each material risk, be able to show what was tested, why that method was appropriate, which product or release was covered, what the result was, what changed after a finding, and how the fix was verified. That evidence is what turns "regular testing" into a defensible product-security process.
Official sources
- Regulation (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
- Commission publishes new guidance to support timely Cyber Resilience Act implementation — European Commission
- Cyber security standards — Cyber Resilience Act requirements standards mapping — European Commission Joint Research Centre
- BSI TR-03183: Cyber Resilience Requirements for Manufacturers and Products — German Federal Office for Information Security (BSI)