The Cyber Resilience Act Is Turning Hardware Security into an Evidence Question

By Arteris

September 10, 2026

A Passing Security Test Doesn’t Tell the Whole Story

A passing security verification report looks reassuring. Every rule passed. No alerts fired. Requirements seem satisfied. Yet that clean result can mean one of two very different things:

1. Either the protection mechanisms worked exactly as intended, or
2. The tests never exercised the design deeply enough to expose a weakness.

From a pass/fail result alone, it is impossible to distinguish between the two, and that ambiguity is becoming one of the biggest obstacles to trustworthy hardware security verification in the semiconductor industry.

The European Cyber Resilience Act (CRA) shifts the conversation from whether security testing occurred, to the availability of documented assurance produced by testing. Manufacturers, customers, and assessors will increasingly expect proof of what was evaluated, which weaknesses were considered, and how conclusions to fix or mitigate them were reached.

The CRA Article 14 reporting obligations start on 11 September, 2026, and the requirements, conformity assessment, and CE marking will apply from 11 December 2027.

This isn’t the first time the semiconductor industry has faced this kind of change. Decades ago, functional verification had a similar challenge: a passing simulation could show that the design behaved correctly under the tests that were run, but engineers eventually realized that passing tests alone didn’t say enough about how much of the design had actually been exercised.

Security Verification Needs its own Measure of Completeness

Functional coverage changed the definition of sign off by measuring the completeness of the verification effort. A passing regression with poor coverage was no longer considered sufficient proof. Hardware security has never had an equivalent; something that provides an objective way to measure the completeness of security verification.

That is where security coverage enters the discussion. Security coverage is not a security score, nor is it a measure of whether a design is secure. Instead, it measures how far verification stimulus actually propagated an asset through the design, relative to the declared protection boundary. In other words, security coverage grades the quality of the verification stimulus and the resulting evidence, not the quality of the hardware itself.

This distinction matters. A passing security test tells you what didn’t happen. Security coverage tells you how much evidence you have for believing it.

Building Evidence that Travels with the Design

The value of security evidence doesn’t stop with the team that created it. It becomes part of a cascade of proof that flows through the semiconductor supply chain.

Silicon providers increasingly need to provide evidence to their customers, who in turn need evidence to support their own products, technical documentation, and regulatory obligations. Security verification is no longer just about reaching sign –off, but about producing evidence that remains useful long after tape-out.

Increasingly, semiconductor suppliers will be expected to answer detailed customer questions. Which assets were protected? Which weakness classes were evaluated? What assumptions were made? Which security analyses were performed? What documentation supports those claims?

Those questions do not disappear after tape-out. They follow products through customer due diligence, supplier assessments, certification activities, and regulatory documentation. Evidence that is dated, documented, mapped to known hardware weakness classes, and generated as part of normal verification workflows becomes substantially more valuable than isolated test reports or anecdotal engineering knowledge.

Why the Evidence Question Is Arriving Now

The EU Cyber Resilience Act isn’t simply raising the compliance bar. It’s changing what constitutes credible engineering evidence. A security claim without supporting proof has limited value because every organization in the supply chain depends on evidence generated by the organizations beforehand.

In that environment, the question is no longer “Did you perform security verification?” It’s: “Can you show what that verification actually covered, in a form we can put in our own technical documentation?”

Based on our understanding of the current CRA requirements, that does not mean every semiconductor company suddenly becomes responsible for proving absolute security. Rather, they must provide defensible engineering evidence to support downstream manufacturers assembling complete products.

The final manufacturers are the ones on the hook to provide detailed documentation to demonstrate the security of their solution. And though integrating manufacturers will carry the largest burden, chips sold on their own are also regulated products.

Arteris addresses this challenge through information flow tracking with the Cycuity Radix technology. Radix observes how designated assets move through simulation and emulation environments used by verification teams.

Instead of manually enumerating every possible path, engineers define security rules around protected assets and boundaries, and Cycuity Radix then monitors the exercised routes. The resulting security coverage helps quantify how far protected assets were actually driven through the design, providing meaningful context for every passing verification run.

Rather than replacing existing verification investments, this approach strengthens them by producing evidence that engineers, customers, and assessors can understand and trust.

Every passing security test still carries two possible explanations: The protection worked, or the verification never reached the place where a weakness could have been exposed. The Cyber Resilience Act won’t eliminate that ambiguity, but it does is make it much harder to ignore. 

As security assurance becomes an increasingly important part of customer due diligence and technical documentation, engineering teams need more than successful verification runs. They need objective evidence that demonstrates the scope and quality of the verification behind them.

• Download the EU Cyber Resilience Act Readiness Guide
• Learn more about Cycuity Radix