Aligning With the EU CRA: Security Best Practices, and Where Static Analysis Fits

The EU Cyber Resilience Act is no longer a future problem. Its Article 14 reporting obligations apply from September 11, 2026 — meaning manufacturers of products with digital elements sold in the EU must already be able to report actively exploited vulnerabilities within 24 hours of becoming aware of them. The full set of essential cybersecurity requirements follows on December 11, 2027.

The good news: the CRA does not demand exotic new technology. It demands something most engineering organizations already aspire to — a disciplined, documented, security-aware development process. This post walks through what the regulation actually asks for, the development practices that get you there, and how static application security testing (SAST) fits the bill.

What the CRA Actually Wants

Strip away the legal language, and the CRA has three goals: make vendors accountable for the security of their software, improve security through better processes and better software/hardware architecture, and give customers the information to make their own security decisions.

The requirements that matter to a development team live in three places:

Annex I, Part I — secure by design. The regulation expects vendors to implement secure-by-design development. This is fundamentally about software development best practices — notably, the CRA does not dictate which technologies you must use. How you get there is up to you.

Annex I, Part II — vulnerability handling. Vendors must identify and document known exploitable vulnerabilities, update documentation and software when needed, and communicate new vulnerabilities to their users.

Article 14 — incident and vulnerability reporting. Actively exploited vulnerabilities and severe incidents must be reported on a strict 24-hour / 72-hour / final-report cadence — and this is the part that is already in force.

If you read nothing else, read the European Commission's official summary at digital-strategy.ec.europa.eu/en/policies/cra-summary. It is genuinely readable.

Not Every Warning Is a Vulnerability

Here is where teams new to the CRA tend to panic, so let's be precise about definitions.
The CRA defines a vulnerability as "a weakness, susceptibility or flaw of a product with digital elements that can be exploited by a cyber threat." That sounds impossibly broad — until you look at the two qualified terms that carry the actual obligations:

• An exploitable vulnerability is one that can be effectively exploited by an adversary under practical operational conditions. Those two qualifiers narrow the broad definition considerably.
• An actively exploited vulnerability is one where there is reliable evidence that a malicious actor has exploited it in a system without permission. This is the trigger for the 24-hour reporting obligation under Article 14.

The practical consequence: you do not have to report every static analysis warning, every defect, every problem to your users. Only findings that are exploitable — or actively being exploited — carry disclosure obligations. A SAST warning is a lead, not a confession. Your job is to triage it: fix it, or assess and document why it is not exploitable in your product's operational context. Let’s not kid ourselves: this requires an organized process, and discipline in enforcing it - but we will get back to it later.

Two more terms worth knowing. A 0-day is a vulnerability the community doesn't know about yet — though you might, if your static analysis or testing has surfaced it. An N-day is a published vulnerability, N days since disclosure or patch, typically in third-party content. Once it's published and affects your product, you have to inform your customers. Which brings us to scope.

Know Your Attack Surface, Know Your Scope

Before any tooling decision, two pieces of homework:

Understand your attack surface. How could a bad actor get into your product? Ethernet, USB, serial interfaces, the engineering workstation itself — enumerate the entry points. This isn't busywork: your attack surface is the key input for scoring whether a given vulnerability is exploitable in your product, which is exactly the assessment the CRA asks you to make.

Understand your product's composition. A typical embedded product is a mix of your own IP, third-party code, an SDK, and hardware. The tooling strategy splits along that line: run static analysis on the code you build — your IP and the source you integrate — and cover the rest with SBOM tooling that maps your third-party components against published CVEs. The set of known vulnerabilities is not static; new issues in third-party code are reported constantly, so this monitoring has to be continuous, not a one-time audit.

Build Security Into the Process

To meet the demands the CRA places on product, you need a strong DevSecOps and CI/CD culture, and this is where most of the practical work takes place.

CI/CD is the foundation. You should be doing continuous integration. Continuous deployment is genuinely hard in embedded — it takes investment and focus — but the goal is achievable and worth stating plainly: always be ready to deploy, and always know where you stand. Concretely, you need a CI/CD platform (GitLab, GitHub, Azure DevOps, Atlassian, or self-hosted), a workflow in which developers build features in isolation, automation to test those features before integration, and traceability of who did what and who approved it.

SAST on every change. Integrate static application security testing into the workflow and run it on every release and every code change — not as a quarterly audit that dumps ten thousand findings on a demoralized team. With CodeSonar in CI/CD, the pattern looks like this:

• Analyze every feature branch before it integrates.
• Give developers results fast — under 15 minutes — so feedback arrives while the code is still in their head.
• Annotate or fix every warning, with or without AI assistance.
• Focus triage on the warning classes that matter for the CRA. CodeSonar categorizes findings into five significance classes — security, reliability, redundancy, style, and diagnostic — and for CRA purposes, security and reliability are the ones that count.
• Use the score to drive criticality: above 55, fix it; at or below 55, review it.

Automated testing alongside analysis. Static analysis is one part of a pipeline that should also include unit, integration, system, regression, and performance testing, plus code coverage — on host, in emulation or simulation, and on hardware.

A defined release process. Release deliberately: store the test and analysis results with each release and use them to gate the release. Ideally, you release often, but the CRA doesn't require frequency — you should still have a process and document it.

Document as you go. To meet the CRA demands, you should document both your process and its outputs. Your CI/CD platform is already generating most of this evidence; the discipline is in keeping it.
And a principle to keep the whole effort honest: 'good' over 'perfect' — perfect does not exist. The regulation is looking for a well-thought-out process, not an unattainable zero-defect guarantee.

Don't Forget the People — or the Toolchain

Your team is your biggest asset. Developers want to be proud of their work, and the worst feeling in engineering is dread: Will my work be accepted? Did I violate a coding rule? Did I break a test? Did I crash the device? Fast feedback from analysis and testing in CI replaces that dread with learning. A pipeline that tells a developer within 15 minutes that their change introduced a buffer overrun isn't surveillance — it's the fastest way to get better.

One last thing that's easy to overlook: your toolchain is part of your software supply chain, and it can be an attack surface too. AdaCore has taken a distinctive approach here — fully pristine builds, with SBOMs, at SLSA Build Level 3. We've written about it before: Your Compiler Is Part of Your Software Supply Chain and AdaCore Software Supply Chain Security Evolution.

What If You're Not There Yet?

Many projects don't run static analysis in CI/CD today, and many have limited automated testing. That's reality, and the CRA's secure-by-design expectations don't require you to fix everything overnight. A daily or weekly analysis run is not ideal, but it's fine — and far better than nothing. Start where you are: empower your engineers, track your progress, and improve continuously.

Your CRA To-Do List

1. Read the CRA summary at digital-strategy.ec.europa.eu/en/policies/cra-summary.
2. Evaluate and document your attack surface.
3. Evaluate and document your gaps — hardware and software; process, security, and quality.
4. Commit to continuous improvement — SAST on every change, automated testing, gated releases.

AdaCore can help you deploy the SAST solutions that you need to comply with the CRA. In addition, our secure software lifecycle, the SBOM we provide, and the vulnerability notification process we have in place ensure that our tools fit into your CRA-compliant supply chain.

The CRA's reporting clock is already running. The teams that will meet it comfortably aren't the ones with perfect code — they're the ones with a process that finds problems early, triages them honestly, and documents everything along the way. Static analysis is how that process sees.