Buried in the Cyber Resilience Act is a sentence that will shape engineering budgets for years, and almost nobody outside compliance teams has read it.
Annex I, Part II, point 3 requires manufacturers to apply "effective and regular tests and reviews" of the security of any product with digital elements. That is the entire instruction. No method specified. No frequency defined. No template provided.
Manufacturers have to decide what that means for their own product, and be able to defend the decision.
The Cyber Resilience Act (Regulation (EU) 2024/2847) is the EU regulation that sets mandatory cybersecurity requirements for hardware and software products with digital elements placed on the European market, across their whole lifecycle.
On testing, its core requirement is a single line in Annex I: manufacturers must apply effective and regular tests and reviews of their product's security, choose how to do it, and be able to justify that choice.
What the regulation does not say matters as much as what it does. There is no mandated test type, no minimum number of tests per year and no required report format. The burden of defining "effective" and "regular" sits entirely with the manufacturer.
The CRA has been in force since December 2024, but its obligations arrive in phases. The first hard deadline has now passed: since September 11, 2026, manufacturers must report actively exploited vulnerabilities and severe incidents through ENISA's single reporting platform, on a strict clock. An early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days of a fix being available for an exploited vulnerability, or within one month for a severe incident.
The full set of essential cybersecurity requirements, including the testing duty above, applies from December 11, 2027.
One detail catches manufacturers off guard: these reporting obligations reach backward. Products already on the market, including ones that have not been touched or modified since, can still fall under the reporting duty. "We'll deal with this when we ship something new" is not actually an option for a lot of companies.
On July 27, 2026, the European Commission published its first major guidance on applying the CRA in practice. It runs to roughly 80 pages, was built from a public consultation, and is aimed squarely at the companies finding the regulation hardest to interpret. It is nonbinding, but it is the clearest signal yet of how the rule will actually be enforced.
One line from the Commission's own communication accompanying that guidance is worth sitting with. It explicitly cites recent developments in frontier AI models with cybersecurity capabilities as a reason the CRA's swift and correct implementation now matters more, not less. The regulator that wrote this rule is telling you, directly, that the AI accelerated vulnerability landscape is part of why the timeline matters.
| Date | What applies |
|---|---|
| December 10, 2024 | CRA enters into force |
| June 11, 2026 | Obligations for conformity assessment bodies |
| July 27, 2026 | First Commission guidance published |
| September 11, 2026 | Vulnerability and incident reporting to ENISA |
| December 11, 2027 | Full application, including essential requirements and testing |
Read together with two other CRA provisions, the requirement that products ship without known exploitable vulnerabilities (Annex I, Part I) and the requirement that technical documentation include reports of the tests used to verify security (Annex VII), the testing duty adds up to something specific: manufacturers must test, act on what they find, and keep evidence of having done so.
That last part is where most existing practice quietly falls short. A handful of habits get harder to defend once an auditor is asking about them directly:
None of these are unusual. They are just not going to survive a conversation with a market surveillance authority.
The CRA does not set a testing interval, and that is deliberate rather than an oversight. Article 13 already requires manufacturers to assess the cybersecurity risk of their product and factor that into how it is designed, built and maintained. The natural reading is that testing cadence should follow the same logic: driven by the product's risk and how fast it changes, not by a fixed calendar date that has nothing to do with either.
In practice, testing stops being a prerelease checkbox and becomes something triggered by the events that actually change your risk:
There is no universal answer to "how often." There has to be a defensible answer to "why this cadence, for this product."
Put plainly: you can build a testing record incrementally, starting now, while the full deadline is still more than a year away, or you can try to reconstruct one under pressure after a regulator, or a customer's procurement team, has already asked for it.
This happens to be exactly the record that continuous, human validated testing produces as a byproduct, not as a separate compliance exercise. When every finding is confirmed exploitable before it reaches you, remediation gets retested before it is marked closed, and everything that was attempted and didn't succeed gets recorded alongside what did, you end up with the artifact Annex VII is actually asking for: a documented account of what was tested, what was found, and what was verified fixed. Produced as you went, not reconstructed after the fact.
That is the same principle behind how UNGUESS Security works. Its network of European ethical hackers reports on every attempted exploit, not just the successful ones, and the model charges only for confirmed, validated findings rather than for activity. It turns out the discipline that makes a bug bounty program cost efficient is the same discipline a regulator wants to see documented.
The companies that build this habit now reach December 2027 with a testing record already in place. The ones that don't will be assembling one retroactively, under a deadline they don't control.
See what continuous, validated testing evidence actually looks like