CRA compliance will be judged by the binary you ship

Many organizations still talk about the EU Cyber Resilience Act (CRA) as a 2027 problem. It stopped being one on Sept. 11, 2026. Since that date, manufacturers must report actively exploited vulnerabilities and severe incidents in products already on the EU market, legacy releases included. Full application follows on Dec. 11, 2027, when every new product must meet the Annex I essential requirements, carry technical documentation, and bear the CE mark.

Most CRA programs are being built from policies, supplier questionnaires, and software bills of materials (SBOMs) generated by the build system. That work matters, but it answers a different question than the one regulators, notified bodies, and customers will ask. They will test the software as it actually ships, and a conformity claim that the shipped binary contradicts is a liability, not a defense.

Here’s why focusing on the binary is key for staying compliant with the CRA.

The CRA regulates the product — and the product is the binary

Several Annex I requirements describe properties of the shipped bytes that no questionnaire can prove. “Delivered without any known exploitable vulnerabilities” (Annex I, Part I(2)) is a statement about what ships, not what was planned. Exploitation mitigation (Part I(2)(i)) maps directly to binary hardening controls such as address space layout randomization (ASLR), data execution prevention, stack canaries, and RELRO. Missing hardening doesn’t show up in any vulnerability feed. You find it only by examining the binary.

The SBOM gap is subtler and just as material. A build-system SBOM lists what the build system knows about, so statically linked, vendored, and repackaged components never get an entry. In an anonymized assessment we ran on a commercial network appliance, 41.4% of 20,561 bill-of-materials entries carried no package URL. A manifest-driven SBOM would have omitted every one of them, and an inaccurate SBOM doesn’t discharge the duty to identify and document components under Annex I, Part II(1).

For an executive, the consequence is simple. If you sign a declaration of conformity on the strength of paperwork alone, you are exposed to anyone who analyzes the artifact: a market surveillance authority, a notified body, a customer, or a security researcher.

Credible evidence starts by stating what can’t be proved

Binary analysis is not a conformity assessment, and presenting it as one undermines the whole exercise. Evidence from the final artifact is strong for a defined set of obligations: component inventory and specifications, known exploitable vulnerabilities, and exploitation mitigation. It partially evidences others, including embedded keys and weak cryptography, exposed attack surface, update channels, and remediation over time, because the artifact shows what is present but not how it behaves at runtime. It says nothing about risk assessment, secure development documentation, vulnerability disclosure policy, support-period declarations, product classification, or the Article 14 reporting process itself.

That is why I recommend structuring the output as a CRA conformance evidence report that records one of three outcomes for every provision:

• Supports conformance: the artifact evidences the requirement.
• Adverse to conformance: the artifact contradicts it, and the gap must be closed or explained.
• Not evidenceable from a binary: a process, legal determination, or runtime property, listed explicitly so no one assumes it was covered.

The third category is usually the largest section of the report, and it is what keeps the report honest. The method behind it is disciplined rather than exotic. Pin the exact release by file name, version, and SHA-256 hash, because evidence about a different build proves nothing. Analyze the complete package without source code, diff it against the previous release, cite the evidence behind every finding, and turn each adverse finding into a prioritized entry in a gap register owned by legal, vendor management, or AppSec.

What one scan of a shipping product revealed

The network appliance assessment shows what this looks like in practice. The product and manufacturer are anonymized; the numbers are real. The analysis verified 12,263 components and mapped 1,430 distinct CVEs to them. Of those, 597 had public exploit code and nine appeared in CISA’s Known Exploited Vulnerabilities (KEV) catalog. A total of 1,976 binaries shipped without ASLR, and 156 files combined a known CVE with missing memory protection, the worst possible pairing under the exploitation-mitigation requirement.

The configuration findings were harder to explain away. The image shipped a private key and certificate in cleartext, identical on every deployment. Its trust store held 18 distrusted root certificate authorities from WoSign and StartCom. The primary update endpoint used cleartext FTP, and the base operating system reached end of life in June 2024. On this evidence, the release could not credibly support a declaration of conformity.

The evidence cut both ways, which is the point. Compared with the prior version, the release closed 351 vulnerability instances and introduced 36, a supportive finding for the requirement to remediate without delay (Annex I, Part II(2)). The KEV entries, however, should lead any conversation. They carry public documentation of active exploitation, the condition that triggers Article 14 reporting once a manufacturer is aware of it, so they are a reporting-readiness question today rather than a 2027 question.

The same evidence serves both sides of the supply chain

Manufacturers carry the product obligations, and their question is whether a given release will survive scrutiny in December 2027. An evidence report lets them find adverse findings before an authority does, feed the Annex VII technical file, and demonstrate remediation release over release.

Buyers, integrators, and importers ask a different question: can this supplier keep selling into the EU, and does this component compromise my product? Integrators that embed third-party components become manufacturers of their own products and owe due diligence under Article 13(5), and importers must verify conformity. The same report lets them test supplier claims, reconcile a supplier’s SBOM against one derived from the artifact, and send the gap register back as a formal request. The stakes are direct, because a reportable vulnerability in an embedded component can trigger the integrator’s own Article 14 duty.

Where to start with CRA compliance

Start with the release you most need to defend, and produce the evidence before someone else does. This month, confirm Article 14 reporting readiness and identify any KEV-listed vulnerabilities in products already on the EU market. This quarter, produce an evidence report for your highest-risk product or supplier, and get counsel’s view on classification, since a Class II product removes self-assessment and puts a notified body on your critical path. Through 2027, re-scan every release and track adverse findings to closure well ahead of Dec. 11, 2027.

Harmonized standards will help, but they confer a presumption of conformity only once they are cited in the Official Journal. Until then, manufacturers must document the solutions they adopted, which puts even more weight on evidence. Paperwork describes intent, while the binary shows the outcome. For a closer look at what artifact-level evidence covers that a manifest can’t, RL’s white paper, Go beyond the SBOM, is a practical place to begin.

This article is not legal advice. Regulation (EU) 2024/2847 is the authoritative text; obtain qualified legal counsel before taking or communicating any conformity position.