How TrustInSoft Analyzer Supports CRA Readiness

The Regulatory Clock Is Ticking 

Cybersecurity failures have caused major outages to logistics and services worldwide, and governments are responding — with real consequences for the software now embedded in nearly every consumer product. 

In Europe, the EU Cyber Resilience Act (CRA) is already in motion. The first deadline lands on September 11, 2026: Manufacturers of any product with digital elements sold into European markets including software, IoT devices, embedded systems, mobile apps,  must be able to report actively exploited vulnerabilities to EU authorities within 24 hours of detection. Full enforcement, including mandatory CE marking and secure-by-design certification for higher-risk products, follows on December 11, 2027. The CRA applies regardless of where a company is headquartered. A US-based IoT vendor shipping into Germany is just as subject to it as a European one. 

In the United States, CISA's Secure by Design initiative is voluntary today but gaining real momentum. Hundreds of technology manufacturers have signed the pledge, committing to measurably reduce entire vulnerability classes in their products. CISA's updated Cybersecurity Performance Goals 2.0, released in December 2025, reinforces the same principles across both IT and operational technology environments – and goes a step further, collapsing what used to be separate IT and OT guidance into a single unified set of goals. Voluntary frameworks have a way of becoming baseline expectations; today's pledge signatories are tomorrow's competitive standard. 

The direction of travel is unmistakable: regulators want security built in, not bolted on. Proven assurance, the kind TrustInSoft provides, is exactly what "secure by design" looks like in practice. 

What "Secure by Design" Actually Demands  

Article 14 of the regulation goes beyond documentation of a vulnerability management process. It requires that you prove the security posture of the code being shipped well enough to know when something in that code is being actively exploited.  

The language is purposefully vague – in regulating the result, the EU leaves it to enterprises to determine how they comply without providing a bar against which to measure against. Most teams discover vulnerabilities through fuzzing, penetration testing or – the reason why legislators are getting involved – in an incident after the code has shipped. Each of those methods find some class of bugs some of the time. None of them can tell you, with certainty, that an entire category of vulnerability is absent from the codebase.  

This is the gap formal verification is built to close. 

Why "Proof of Absence" Matters for CRA Specifically 

Most security tooling is built to find bugs. It searches for patterns that look dangerous and flags them for a human to triage. That's useful, but it has a structural limit: A tool that finds bugs can never tell you when it's done finding them. Silence isn't proof of safety; it might just mean the tool didn't look in the right place. Because a missed bug is costly, these tools err toward over-flagging – burying real issues in false positives that cost time to triage. 

TrustInSoft Analyzer (TISA) works differently. Using abstract interpretation, it mathematically proves the absence of entire classes of undefined behavior and runtime errors including buffer overflows, use-after-free, uninitialized memory, integer overflow  across every possible execution path and input value, not just the ones a test suite happens to exercise. 

That distinction maps directly onto what regulators are asking for. The CRA's vulnerability-handling and secure-by-design requirements aren't satisfied by "we tested for it and didn't find anything." They're satisfied by being able to show, with evidence, that a vulnerability class genuinely cannot occur. That's the difference between a best-effort security practice and a documented, defensible compliance posture. 

Where AI-Written Code Raises the Stakes  

The compliance picture gets more complicated as AI-assisted development becomes standard practice on embedded teams. AI coding assistants are now writing meaningful portions of production code, including in safety- and security-relevant components. That code still has to clear the same CRA bar as code written by hand — but the tools teams use to review AI output are often the same probabilistic methods (linting, pattern-based static analysis, code review) that already struggle to keep pace with human-written code. 

TrustInSoft's position here is direct: It doesn't matter who or what wrote the code. AI-generated, human-written, or some blend of both, it gets held to the same mathematical standard. For a compliance team trying to build an audit trail that covers an entire codebase, regardless of provenance, that consistency matters more than ever.  

What This Looks Like in Practice 

An analyst using TrustInSoft Analyzer starts by setting the terms: Target coverage, the compilation target and hardware platform and which modules matter the most such as critical paths, recent changes, anything flagged as high risk.  

The analyst then launches TrustInSoft Analyzer, defining the parameters of the analysis and using the AI-assisted methods to write the entry point identification, driver generation, and analysis configuration – and the analysis runs on the code.  

A report is then generated identifying with certainty which code can cause potential challenges so that these lines can be corrected. The analysis report is validated and can be run again until no lines are flagged as potential pathways for issues. The TIS Analyzer report is mathematical proof that no alarms exist in the code. And because alarms are mapped to a CWE identifiers, the findings are expressed in the same vocabulary regulators expect in a CRA incident report  – meaning that there is no translation step between what TrustInSoft Analyzer found and what goes in the documentation.  

TrustInSoft Analyzer shows that not only does the code do what it is written to do, but also does not contain any undefined behaviors or potential cybersecurity vulnerabilities. The analyst or user remains the final authority in the end. It provides infrastructure that CRA compliance actually rewards: Not faster guessing but a documented process where every claim of “no vulnerability here” traces back to something a person verified, not just something an AI asserted, confirmed with mathematical proof.

Building Compliance Evidence Before the Clock Starts 

September 11, 2026, isn't a deadline to start thinking about vulnerability reporting — it's the date by which your process needs to already be in place. Teams that wait until the deadline to figure out what counts as adequate evidence of secure design will be building their compliance program under a 24-hour reporting clock, which is the worst possible time to discover gaps. Teams that fail to present that report are looking at a fines up to €15 million or 2.5% of the company’s global annual revenue. The fines will be determined by national market surveillance authorities – meaning that the CRA is once again leaving its execution up to a consortium of individuals.  

The teams in the strongest position will be the ones who can already point to mathematical proof beyond test logs for the parts of their codebase that matter most.