Effective and regular tests: what Annex I Part II(3) is actually asking for

Practical guidance, not legal advice. Annex references are drawn from Regulation (EU) 2024/2847. As the library's Annex VII article notes, parts 3 to 8 of Annex VII are described here rather than quoted. Check everything against the official text before you rely on it.

Annex I Part II(3) requires manufacturers to apply effective and regular tests and reviews of the security of the product with digital elements. That is the whole requirement. No method, no cadence, no standard, no threshold.

Which makes it either the easiest line in the assessment to wave through, or the one that decides whether the rest of the file is believed. Every claim you made about points (2)(b) through (2)(m) is an assertion until something tested it. This is the requirement that turns assertions into findings.

Three words doing the work

Effective. The measure is your own risk assessment. A test programme that runs weekly scans against the management interface while never touching the Bluetooth pairing flow your risk assessment ranked highest is not effective, however much output it produces. The link an assessor looks for is between the risks you identified and the surfaces you tested.

Regular. A cadence, not an event. One penetration test in 2027 is not a regular test in 2031, and Annex I Part II duties run for the whole support period under Article 13(8), which is at least five years and often more. Testing is a recurring cost long after the product stops being interesting internally, and budgeting for it once is the mistake.

Tests and reviews. Two different activities, and the point names both. Reviews are human: threat modelling, design review, reading the code that handles untrusted input. Tests are mechanical: scanners, fuzzers, scripted checks. A file containing only tool output has answered half the requirement, and it is usually the half that finds the shallow problems.

A regime that is defensible without being expensive

Layer it by how often you can afford to run each thing.

Every build

• Dependency scanning against the SBOM you are already producing for Part II(1), so a new advisory against a component you ship becomes a build signal rather than a quarterly discovery.
• Secret scanning, including on the built artefact rather than only the source, because keys get baked in at build time.
• Static analysis pointed at the security-relevant code, with a rule set you chose, tuned to the point where a finding means something.
• Build hardening checks, so the flags that answer point (2)(k) cannot disappear in a toolchain upgrade.
• The negative tests your Annex I answers already imply: no default credential on a factory image, an unsigned update rejected, an unauthenticated request to a privileged route refused, and a port scan of the release artefact matching the interface inventory you declared under point (2)(j).

That last group is the highest-value list in this article. Each of those tests exists because you made a claim in the technical file, and each one keeps the claim true after the person who made it has left.

Every release

• An authenticated dynamic scan of the network-facing surface, in the configuration you actually ship.
• Fuzzing the parsers that face untrusted input. For embedded products this is the single highest-yield technique available, and once the harness exists it costs nothing per release.
• A human review of the diff for anything touching authentication, cryptography, parsing, update handling or privilege.

Periodically

• A threat model refresh, at minimum whenever the architecture changes or a new interface appears. One page is fine. Not having one is what makes the effective test hard to argue.
• An external penetration test, at a cadence you can justify against your risk assessment rather than one you read on a blog.
• For hardware, a physical review: debug port accessibility on a production unit, fault injection, reading the flash off the board. Expensive, so scope it to the risk and repeat it when the hardware changes rather than annually out of habit.

And the free one

Reports arriving through your disclosure programme are test results. A vulnerability a stranger found is information about what your own testing missed, and the useful reaction is to ask why the regime did not catch it and to add whatever would have. That loop is what an assessor means by effective, and it costs nothing except the willingness to look at it that way.

What ineffective looks like from the outside

Three patterns, all common, all recognisable in about ninety seconds by someone who reads these for a living.

• Coverage that misses the risky part. A thorough web application test on the admin console and nothing at all on the radio interface, the update path, or the local API the companion app uses.
• Findings with no dispositions. A report full of unresolved high-severity items from two years ago is worse evidence than no report, because it establishes that you knew.
• Testing that never finds anything. If years of testing has produced no findings, the likeliest explanation is not that the product is unusually good.

The remedy for the second one is a findings register: every finding, its source, its severity, the decision, the reason, and the date. A finding you accepted as a risk with a written reason is fine. A finding with no row is not.

Third-party testing, and what it does not buy

Be clear about the limits before spending the money. A penetration test report is not a conformity assessment. It does not give a presumption of conformity, and neither does applying a standard, because no CRA harmonised standard has been cited in the Official Journal as of August 2026. Verify the current position rather than taking that from an article, including this one.

External testing is worth buying when you need someone who did not design the thing to look at the surface you designed, when a customer's procurement requires it, or when your conformity route already involves a third party because the product sits in Annex III Class II or Annex IV.

Several standards describe testing well enough to use as a syllabus even though they confer nothing under the CRA today. IEC 62443-4-1 sets out security verification and validation practices for a development process. ETSI EN 303 645 has a companion test specification, TS 103 701, that is unusually concrete about how each provision is checked. OWASP's ASVS and MASVS are useful for software and mobile respectively. Read them for the coverage checklists, cite them in your file as references you used, and do not describe them as compliance.

Where the result lands: Annex VII part 6

Part 6 of the Annex VII technical documentation asks for reports of the tests carried out to verify conformity of the product and of the vulnerability handling processes with the applicable essential requirements.

Read that twice, because it has two halves and the second one surprises people. Tests of the product, and tests of the vulnerability handling processes. Your process is in scope for testing too.

Testing a process means exercising it rather than describing it. Send a report to your own published security address from an outside account and confirm it reaches a human within the window your policy promises. Run the reporting drill against the Article 14 clock and record what broke. Confirm the security.txt expiry has not lapsed. Each of those produces a dated record, and each of them is the kind of evidence that distinguishes a live process from a published one.

What to actually file

Not the ninety-page scanner export. What belongs in the file is a test summary per release: what was tested, when, by whom, using what method, what was found, what was decided about each finding, and where the raw report is retained.

That last clause has a ten-year problem attached to it. Article 13(13) requires the technical documentation to stay available to market surveillance authorities for at least ten years after the product is placed on the market, or the support period, whichever is longer. A reference to a continuous integration artefact that expires in ninety days is not a reference. Export the reports you cite and store them with the file.

Part 5 of Annex VII is the neighbouring obligation worth knowing about here. Where you did not apply a harmonised standard, the file has to describe the solutions you adopted to meet the essential requirements. Since no standard is cited, that is where every CRA manufacturer stands today, and test evidence is a large part of what makes that description convincing rather than assertive.

A minimum viable regime for a small team

1. Dependency and secret scanning in continuous integration, failing the build on the classes of finding you decided in advance should fail it.
2. A one-page threat model, updated when the architecture changes rather than on a calendar.
3. A dozen negative tests derived directly from your Annex I answers, running on every build.
4. A fuzzer against your two riskiest parsers, running nightly on hardware you already own.
5. One external review a year, or every other year, scoped to the interface your risk assessment ranks highest.
6. A findings register with dispositions and dates, in a spreadsheet if that is what you will actually maintain.
7. One process drill a year against the reporting clock, with the gaps written down and closed.

That is affordable for a team of nine, it produces dated evidence for Annex VII part 6, and it is considerably more than most technical files will contain in December 2027.

The reporting playbook has the tabletop drill for item seven, and the SBOM article covers the dependency scanning in item one. Both produce records that belong in the same folder as your test summaries.