Annex I Part II (3) CRA security testing and reviews

What Annex I Part II (3) security testing requires under the CRA

Annex I Part II point (3) requires a manufacturer to apply effective and regular tests and reviews of the security of its product with digital elements. The obligation is not a single test before the product reaches the market. It runs for the whole support period, which means the manufacturer must keep checking that the product still resists the attacks and defects that matter when it is in use. The point addresses two sources of risk: vulnerabilities introduced by changes to the code, components or configuration, and vulnerabilities that were present from the start but only become known later, often because researchers, attackers or new threat intelligence reveal them.

The difficulty lies in keeping the test program current. A test plan written at release describes the threats known at that time, and those threats change. The Commission's guidance on the regulation (annex to C(2026) 5252, section 9.2.3) is explicit that regular testing does not mean mechanically repeating an unchanged test campaign at fixed intervals. The manufacturer must review whether new threats or newly discovered vulnerabilities require its tests to be updated, and then run the updated tests. The guidance also says the frequency, depth and content of reviews should be proportionate to the product's risk profile, how the product evolves, and the threat landscape, and it notes that regression testing after modifications may be part of the program.

For a product team, this turns testing into a documented decision cycle. Someone must own the review trigger list (new vulnerability disclosures affecting the stack, significant code or dependency changes, new threat reports relevant to the product's sector), decide which tests are added or re-scoped, and record why. Those decisions and the resulting test reports feed the technical documentation under Annex VII point 6, so the reports must show what was tested, when and against which risks. Ask your conformity assessment body and your legal advisers to confirm how they expect this review record to look for your product class before you design the process.

Which products, releases and teams fall under the testing duty

Annex I Part II (3) applies to the product, not to the company, so the first job is deciding which products, components and release channels are in scope. The cards below cover the decisions that most change how much testing is needed and who must own it, and where the duty reaches products already on the market.

Product class sets the depth

Whether a product is default, important (Annex III class I or II) or critical (Annex IV) affects the conformity route and how much assurance an assessor will expect from the testing record. Confirm the class against the Annex III and Annex IV descriptions and the Commission's technical descriptions before scoping test depth. A product that moves class after a design change needs its test plan revisited.

Third-party components in the product

Libraries, firmware blobs, container base images and embedded runtimes carry vulnerabilities the manufacturer must still test for. Decide which components get their own security tests, such as fuzzing or firmware analysis, and which are covered by monitoring and advisory tracking. Record the decision with the component inventory so reviewers can see why a dependency was or was not tested directly.

Cloud back ends and update channels

Where the product depends on hosted services, such as a cloud API, telemetry pipeline or update server, those systems shape the product's security as much as the binary does. Confirm whether the back end is inside the product's security boundary, who operates it, and how signed updates are delivered. Testing that covers the device or application but skips the update path leaves a gap an assessor will ask about.

Releases, patches and regression scope

Each release, security patch and configuration change can alter the risk picture, so reviews should cover what changed since the last test run. Define which changes trigger regression testing and which trigger a full review. The Commission guidance treats regression testing after modifications as a legitimate part of the review cycle, so the trigger rules belong in the written procedure.

Ownership across engineering and security

Product engineering usually writes the code, but security testing, vulnerability triage and sign-off may sit with a separate PSIRT, a security team or an outside tester. Name who owns each test type, who approves a deferred finding, and who records results in the technical documentation. Unclear ownership is the most common reason test records fail to show the review was actually performed.

Products already on the market

Products placed on the EU market before 11 December 2027 fall under the regulation only if they are substantially modified from that date. The Article 14 reporting duty, however, applies to in-scope products whenever they were placed on the market. Treat a major feature release or architecture change as a possible substantial modification and confirm the position with counsel before deciding which older products need the full testing regime.

How to build a risk-proportionate testing program

The sequence turns Annex I Part II (3) into a working program: an inventory of what the product is made of and exposes, a risk profile that sets how deep and how often to test, a baseline test set, review triggers and a record of results. Each step produces an artifact that an assessor can trace back to the requirement.

Map the attack surface and components
Product security, engineering and the people who run the product list every externally reachable interface, update channel, network service, administrative path, and third-party or open-source component. Start from the software bill of materials so that dependencies are not missed. The output is an attack surface and component inventory with owners, versions and data flows. It is done when every interface and component in the inventory has a named owner and a status for how it is tested.
Set a risk profile for each product
The product owner and security lead assign each product or major component a risk profile based on its function, the data it handles, its exposure, its connectivity, and the impact of a compromise. Record the reasoning alongside the manufacturer's cybersecurity risk assessment so the two stay consistent. The output is a risk profile sheet per product that states the depth and frequency of testing that the profile calls for. It is done when each product has a profile and an approver has signed it off.
Define the baseline test set
Based on the risk profile, the security team selects a baseline of tests. Typical elements include static analysis and secret scanning in the development pipeline, dependency and vulnerability review, penetration testing of exposed interfaces, and firmware or network traffic analysis where the product has embedded code or network behavior. Commission FAQ 4.4.2 lists fuzz testing, firmware analysis, side-channel analysis, red-team exercises and network traffic analysis as possible additional tests when components are integrated. The output is a test plan that names each test, its scope, its tooling and its owner. It is done when the plan has been reviewed against the risk profiles and gaps are documented.
Automate scanning in the delivery pipeline
Engineering wires the selected code and dependency checks into the build pipeline so they run on every change, not only before a release. Semgrep Community Edition can scan the languages a product uses and run in CI/CD with community or custom rules, and Wazuh or Fleet can correlate installed software on deployed hosts with vulnerability sources. Protected branches in GitLab Community Edition stop unreviewed changes from reaching the main line, which keeps the scanned code and the released code the same. The output is pipeline configuration and scan logs for each build. It is done when a failing scan blocks the change or raises a tracked finding.
Schedule reviews triggered by threats and changes
The product security team sets a review cadence proportionate to the risk profile, then adds event triggers. Commission guidance C(2026) 5252 says regular testing does not mean repeating an unchanged campaign at fixed intervals. Reviews should ask whether a new threat or a newly discovered vulnerability requires the test set to change, and whether a modification needs regression testing. The output is a review calendar and a trigger list that names the events that start an ad hoc review. It is done when each trigger has an owner and a documented way to start the review.
Run regression tests after each modification
When code, configuration, dependencies or hardware change, the team reruns the tests that cover the affected components and the earlier fixes that could be reopened. Results are compared with the previous baseline so that a fix does not quietly regress. The output is a regression test record linked to the change request. It is done when the record shows which tests ran, which passed, and who accepted any residual risk.
Record results in a findings register
Every test, review and automated scan writes into one findings register. Each entry records the affected product and component, severity, status, remediation owner and the verification that closed it. The register feeds the technical documentation, which Annex VII point 6 requires to include reports of tests verifying conformity with Annex I Parts I and II. The output is a current register and a review log that show what was tested, when, and what changed as a result. It is done when an independent reviewer can trace a finding from detection to verified fix.
Feed results back into the risk profile
At each scheduled review, the security lead compares the register with the risk profile. Recurring findings, new threat intelligence, or changes in exposure may raise a profile, which then adjusts the test set and cadence. The output is an updated risk profile and a revised test plan with a dated change note. It is done when the revision is approved and the next review cycle is scheduled from it.

How an assessor tests security testing and reviews

This table sets out what an assessor checks for each part of Annex I Part II (3), the evidence they ask to see, and where organizations usually fall short. Read each row as a question the assessor will put to the manufacturer, with the evidence that answers it.

Assessor check	What the assessor looks for	Evidence requested	Common finding
Test plan against risk profile	A documented test plan whose depth and frequency follow the product's risk profile, its evolution and the threat landscape	Current test plan, risk assessment it references, and dated approvals by the responsible owner	Test plan copied from a previous product with no link to the current risk assessment
Sampled test reports across releases	Reports for several releases showing tests ran against each version, not only the first release	Test reports for a sample of releases, with scope, tools, versions tested and results	Reports exist for the initial release only, with later releases shipped untested
Reviews reacting to new threats	Evidence that new threats or newly disclosed vulnerabilities led to a review and, where needed, updated tests	Review records dated after relevant advisories, with the decision taken and the test changes made	Reviews run on a calendar cycle that never change the test scope
Regression testing after changes	Regression tests run after modifications, including component updates and fixes	Change records linked to the regression tests executed and their results	Security tests not repeated after code, configuration or dependency changes
Findings tracked to closure	Each finding from tests or reviews is logged, prioritized, fixed or accepted with a documented reason, and retested	Findings register with status history, retest results and risk acceptance sign-off	Findings closed without retest, or open items with no owner or decision date
Coverage of components and integrations	Tests cover integrated third-party components, not only the manufacturer's own code	Scope statement listing components tested and any tests added for integrations	Testing limited to first-party code while inherited components were never examined
Independence and competence of testers	Testers are competent and, where practical, separate from the people who built the feature	Tester roles, qualifications or training records, and reviewer sign-off on reports	No record of who performed or reviewed the tests
Link to technical documentation	Test reports are included in the technical documentation that supports conformity	Technical documentation index pointing to the test reports for the product and its vulnerability handling processes	Reports exist but are not referenced or retrievable when the assessor asks

Why reviews must respond to threats, not just the calendar

Annex I Part II point (3) asks for effective and regular tests and reviews of product security across the support period, and the word that does the most work is *regular*. The Commission's guidance (C(2026) 5252, section 9.2.3) is explicit that regular testing does not mean rerunning an unchanged test campaign at fixed intervals. The question for the manufacturer is whether a new threat or a newly discovered vulnerability means the existing tests no longer prove what they claim to prove, and if so, the tests must be updated and run. A calendar can trigger a review, but it cannot decide what the review must cover. Each review should record the inputs it considered, such as new advisories affecting components in the SBOM, public exploit activity, and changes to the code or build pipeline, and the decision it reached about which tests to add, change or drop.

The same guidance says the frequency, depth and content of reviews should be proportionate to the product's risk profile, its evolution and the threat landscape, and it notes that reviews may include regression testing after modifications. Proportionality cuts both ways. A low-exposure product with stable code may need lighter reviews between major releases, while an internet-facing product with frequent changes needs deeper and more frequent checks. The manufacturer should be able to explain, in its technical documentation, why its chosen cadence and depth fit its own risk assessment. Confirm with your conformity assessment body or market surveillance contacts how they expect that rationale to be documented, since the guidance is non-binding. Illustrative example (hypothetical): a manufacturer of a networked sensor adds a new file-parsing library to its firmware image for a configuration feature. The existing annual penetration test never exercised that parser. A threat-responsive review would flag the change, add fuzz testing against the parser and a firmware analysis pass on the new image, and record the results in the test reports that Annex VII point 6 requires. The scheduled campaign would have stayed unchanged and missed the new attack surface until the next routine test.

Evidence that satisfies the testing requirement

Annex I Part II (3) asks for testing and reviews that are effective, regular and proportionate, so the evidence has to show a decision trail, not just a stack of scan outputs. The cards below cover the artifacts a market surveillance authority or notified body is likely to request, and how each one stays current between releases.

Risk-based test plans

A test plan links each test type to a risk identified in the manufacturer's cybersecurity risk assessment, the component or interface it covers, and the threat that prompted it. Record the frequency and depth chosen for each product and the reason for that choice. Check that the plan names owners, scope boundaries and what triggers an update, such as a new threat or a newly disclosed vulnerability in a component.

Test reports in technical documentation

Annex VII point 6 requires the technical documentation to include reports of the tests carried out to verify conformity with Annex I Parts I and II. Each report should state the product version tested, the test method, the tester, the findings and the pass or fail outcome. Keep reports for penetration tests, fuzzing and firmware analysis in the same versioned structure so they can be produced together.

Regression test records

Guidance C(2026) 5252 notes that regression testing after modifications can be part of a proportionate review. Keep a record for each release that lists which security tests were rerun, which were skipped and why. Gaps in this record are a common reason an assessor questions whether testing was regular in practice rather than only on paper.

Threat-driven review minutes

Regular testing does not mean repeating an unchanged campaign on a fixed schedule. Review minutes should show when the team looked at new threats and newly discovered vulnerabilities, what they decided to add, change or drop, and who approved the decision. Dated minutes that link to a specific trigger are the clearest evidence that reviews respond to the threat landscape.

Findings and remediation tracking

Every finding from a test or review needs a ticket with severity, affected version, owner, fix and verification date. Confirm that closed findings were retested and that accepted risks have a recorded approver. Assessors often sample a finding and follow it from the test report to the released fix, so the links between those records must hold.

Scanner and tool outputs

Tool output from code scanners, dependency checks and endpoint vulnerability detection shows that automated checks ran. Semgrep can run in CI/CD to scan repositories continuously, and Wazuh correlates agent inventories with vulnerability data. Retain outputs with timestamps, rule or data versions and the release they cover, and confirm that the scanner languages and targets match the product's actual code.

What meeting Annex I Part II (3) costs

This table compares the main cost components of running security tests and reviews across the support period, who is paid for each, and whether the cost is one-time or recurring. Read it to see where open-source tooling removes spend and where engineering time, evidence upkeep and external review still add cost.

Cost component	Who is paid	One-time or recurring	What drives it
Tooling and licenses	Tool vendors or none for community editions	Recurring when paid licenses apply; open-source tools remove license spend	Number of products and repositories scanned; hosting and operation of scanners such as Semgrep or Wazuh
Test design and setup	Internal engineers or implementation partner	One-time, then updated when threats change	Number of product interfaces, components and test types chosen, such as fuzzing or firmware analysis
Engineering time for triage	Internal product security or developers	Recurring with every release and every new finding	Release frequency, component count and the share of findings that are false positives
Regression testing after changes	Internal engineers	Recurring with each modification	Size of the change set and how much of the test suite is automated in CI/CD
External penetration testing or review	Independent testing firm	Recurring, usually per test cycle	Product complexity, attack surface, depth of scope and whether the firm retests fixes
Evidence upkeep	Internal compliance or engineering staff	Recurring, to keep test reports current in technical documentation	Number of products, retention rules and how test results are stored and linked to Annex VII records
Assessor effort	Independent auditor or notified body where applicable	Recurring, tied to the assessment route	Conformity assessment route, sample size and quality of traceable test records
Partner support	Implementation partner under a fixed-scope agreement or retainer	One-time for setup, optional recurring retainer for upkeep	Written scope, number of products to prepare and whether ongoing testing is included

Who runs the tests, who prepares evidence and who judges it

The manufacturer owns the security testing program and its results. Under the regulation, the duty to apply effective and regular tests and reviews sits with the manufacturer of the product with digital elements, not with any outside firm. That means the manufacturer decides what is tested, how often reviews happen, who signs off on findings, and what changes to the product follow from them. The manufacturer also keeps the test reports that feed the technical documentation.

Program ownership: A named owner is accountable for the testing program, its budget and its review cadence across the support period.
Risk-based scope: Internal teams document why each product area is tested at a given depth, tied to the product's risk profile and the threat landscape.
Findings decisions: Engineering and product leads decide how each finding is fixed, accepted or deferred, and record the reason.
Retained records: Test plans, raw results, retest evidence and reviews are kept as part of the technical documentation.
Triggered reviews: Process exists to update tests when new threats or newly disclosed vulnerabilities affect the product.

Before engaging anyone, confirm which of these decisions your own governance can make in-house and which need executive sign-off.

Where testing programs usually fall short

Most testing programs run, but they rarely connect to the risk profile, the product's changes or the record of what was fixed. The five gaps below are where an assessor or market surveillance authority is most likely to find that Annex I Part II (3) is not being met in practice.

Test plan not tied to risk

Many teams test the same surfaces every cycle because that is what the tooling covers, not because those surfaces carry the most risk. Annex I Part II (3) expects the frequency and depth of tests to be proportionate to the product's risk profile and the threat landscape. Check that every test in the plan traces back to a documented risk assessment entry, and that the plan records why each area was selected or left out.

Testing only at launch

A product can pass a thorough pre-release test and then run for years with no fresh testing, while new vulnerabilities are published against its components. The Commission guidance says regular testing means reviewing whether new threats require tests to be updated and running them, not repeating an old campaign on a calendar. Confirm that a named trigger, such as a new advisory affecting a component, prompts a review of the test plan.

Reviews that do not feed back

Security reviews often produce a report that never changes the threat model, the test scope or the backlog. Under Annex I Part II (3), the outcome of each review should update what is tested next and how deeply. Check that every review has a recorded output that changes the test plan, the threat model or the risk assessment, with the change dated and signed off by the person accountable for the product.

Component changes without regression tests

Teams update libraries, firmware, base images and third-party services without rerunning the tests that covered the earlier version. The guidance names regression testing after modifications as part of a proportionate review. For each release, check whether the change log lists the components modified and whether the regression set for those components ran against the new build, with results kept in the technical documentation.

Findings without documented closure

A finding that is fixed in a ticket but never retested, or accepted as a risk without a sign-off, leaves no evidence that the testing led to action. Annex VII point 6 requires test reports as part of the technical documentation, so each finding needs a traceable path from discovery to verified fix or documented acceptance. Check that every closed finding links to a retest result and that every accepted risk has an owner and a review date.

Questions buyers ask about CRA security testing

How much effort does security testing under the CRA take?

The effort depends on the product's risk profile, its size and how often it changes, so no single figure applies to every product. The CRA does not set a test count or duration. Effort is driven by the attack surface (network interfaces, APIs, update mechanisms, third-party components), the number of product versions still in support, how much of the testing is automated in the build pipeline, and how much existing test evidence can be reused. Ask any provider for a written scope that lists the test types, the systems covered, the versions in scope and the deliverables, then compare quotes against that same scope. Commission guidance on Annex I Part II (3) ties frequency and depth to risk, so the scope should show why each test is included.

Can we run CRA security testing in-house?

Yes, the regulation does not require an outside party to perform the tests. Manufacturers own the obligation and must be able to show effective and regular testing, with reports included in the technical documentation. Many teams cover routine checks in-house, such as static analysis in CI/CD, dependency scanning and regression tests after changes, and buy outside help for specialist work like penetration testing or firmware analysis. The practical question is whether your team has people with the skills to design tests, interpret results and keep records that an assessor can follow. Document who ran each test, when, against which version and with what outcome.

What does an implementation partner add to CRA security testing?

A partner adds capacity, specialist technique and a repeatable evidence trail. DeployOpen plans, implements and runs security testing for applications, APIs, cloud and infrastructure, and AI systems, and can set up the tooling and pipelines inside your own environment. Our work prepares the systems and test records that go into your technical documentation. We do not issue reports or certificates, and the conformity assessment remains with you, and where required, a notified body. Most engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work starts. Ask whether the partner will hand over reports, raw results and retest records you can keep.

How often do CRA security tests have to run?

The CRA does not set a fixed frequency. Commission guidance on Annex I Part II (3) says regular testing does not mean repeating an unchanged test campaign at fixed intervals. Instead, you review whether new threats or newly discovered vulnerabilities require tests to be updated, then run them accordingly. Frequency should be proportionate to the product's risk profile, how it evolves and the threat landscape, and reviews may include regression testing after modifications. In practice, set triggers such as a new release, a significant component change, a newly disclosed vulnerability in a dependency, or a change in threat intelligence, and record the reasoning behind each cadence in your documented process.

Is penetration testing mandatory under the CRA?

No, penetration testing is not named as a mandatory activity. Annex I Part II (3) requires effective and regular tests and reviews, and the Commission FAQ lists fuzz testing, penetration testing, firmware analysis, side-channel analysis, red-team exercises and network traffic analysis as possible additional tests when integrating components. Which of these you need depends on your risk assessment. A connected product with exposed interfaces will usually justify penetration testing, while a narrow backend component may rely more on fuzzing and automated analysis. Your risk assessment should explain which tests you chose and which you excluded, and why.

What does CRA security testing need from engineering and product teams?

It needs engineering time, product decisions and access to the build and release process. Engineers must keep test suites current, fix findings within your remediation process and provide build artifacts and version identifiers so each test result can be tied to a specific release. Product teams must define the product's intended use, the support period and which versions remain in scope, and they must approve risk decisions for accepted findings. Ask your team to agree on who owns test records, where they are stored and how long they are kept. Put these responsibilities in the written scope so a partner and your staff know what each side delivers.

How DeployOpen works on this

DeployOpen plans and runs the security testing that supports Annex I Part II (3) inside your own infrastructure, using self-hosted open-source platforms. We scope the work in writing, build the test and review tooling, and hand over the reports and records that feed your technical documentation, while your organization keeps ownership of the controls and of the conformity decision.

How we scope

Engagements are fixed-scope, with the products, components, test types and review cadence agreed in writing before work starts.
We map which products and components fall under the testing scope, and which risk profile drives the depth and frequency of reviews.
The written scope names the triggers for re-review, such as new threat information, newly disclosed vulnerabilities or significant code changes.

How we build

We configure vulnerability detection against your software inventory, using a locally hosted offline vulnerability copy where your network requires it.
We set up code scanning in your CI/CD pipeline and protected branch rules so that changes pass defined security checks before merge.
Additional tests such as penetration testing, fuzz testing or firmware analysis are scoped to the components you integrate, and run against your environment.

How we hand over

You receive documented test plans, test results and review records, structured so they can be placed in your Annex VII technical documentation.
Runbooks explain how each review is triggered, who signs off on findings and how regression testing follows a modification.
Your team keeps administrative access and the code, so the testing continues after the engagement ends without DeployOpen involvement.

How we support

Ongoing support, upgrades and continuous testing are available as retainers for the full support period of the product.
Retainers can cover periodic review of threat sources and tool configurations, so test scope keeps pace with new vulnerabilities.
Independent auditors or notified bodies assess conformity and issue any certificates or reports. DeployOpen prepares the systems and evidence for that assessment.