Spectra Assure Free Trial
Get your 14-day free trial of Spectra Assure for Software Supply Chain Security
Get Free TrialMore about Spectra Assure Free Trial
Key takeaways
Plenty of organizations still treat the EU Cyber Resilience Act (CRA) as a 2027 problem. It stopped being one on Sept. 11, 2026. Since then, manufacturers have had to report actively exploited vulnerabilities and severe incidents affecting products already on the EU market, older releases included. Full application follows on Dec. 11, 2027, when every product placed on the market from that date 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. A conformity claim that the shipped binary contradicts is a liability, not a defense.
Several Annex I requirements describe properties of the shipped bytes that no questionnaire can prove. Part I, point (2)(a) requires products to be made available on the market "without known exploitable vulnerabilities." That's a statement about the shipped product, whatever the plans said. Point (2)(k) calls for exploitation mitigation mechanisms, which in practice means 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.
These requirements are risk-based. They apply on the basis of the manufacturer's cybersecurity risk assessment and where applicable, so a binary without ASLR isn't automatically nonconforming. But every gap needs a documented justification, and you can't justify a gap you never found.
The SBOM gap is subtler and just as material. Annex I, Part II(1) sets the legal floor at an SBOM covering at least top-level dependencies, and meeting that floor is not the same as knowing what you ship. A build-system SBOM lists what the build system knows about. Statically linked, vendored, and repackaged components often 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, the usual signature of code a manifest-driven SBOM misses. The same provision requires you to identify and document vulnerabilities, and you can't do that for components your inventory doesn't contain.
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.
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, known exploitable vulnerabilities, and exploitation mitigation. It partly evidences others, including embedded keys and weak cryptography, exposed attack surface, update channels, and remediation over time. 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:
The third category is usually the largest section of the report, and it 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 and diff it against the previous release. Cite the evidence behind every finding. Then turn each adverse finding into a prioritized entry in a gap register owned by legal, vendor management, or AppSec.
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. Under the exploitation-mitigation requirement, that pairing is the hardest to justify.
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. That is a supportive finding for the requirement to remediate without delay (Annex I, Part II(2)).
The KEV entries should still lead any conversation, even though they don't trigger reporting on their own. The Commission's CRA guidance, C(2026) 5252, says a vulnerability in a third-party component is reportable under Article 14 only if it is actively exploited in the manufacturer's own product. A KEV listing proves someone exploited the flaw. It doesn't prove anyone exploited it in your appliance. What it tells you is where to look first. Confirm whether the vulnerable code is reachable. Look for evidence of exploitation in the field, from customer reports, telemetry, or threat intelligence. Then document the reporting decision. Do that now, because once you have reasonable certainty of exploitation, you have 24 hours to file an early warning.
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 show remediation release over release.
Buyers, integrators, and importers ask something different: can this supplier keep selling into the EU, and does this component compromise my product? An integrator that ships a product built on third-party components is the manufacturer of that product. It owes due diligence on those components 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. If a vulnerability in an embedded component is actively exploited in the integrator's product, the Article 14 duty belongs to the integrator, whoever wrote the code.
Start with the release you most need to defend, and produce the evidence before someone else does. This month, confirm Article 14 reporting readiness, including registration on ENISA's Single Reporting Platform, and check products already on the EU market for KEV-listed vulnerabilities. This quarter, produce an evidence report for your highest-risk product or supplier and get counsel's view on classification. A Class II product rules out self-assessment and puts a notified body on your critical path. A Class I product can self-assess only by applying harmonized standards, common specifications, or an EU cybersecurity certification. If no standard is cited in time, many Class I manufacturers face the same 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, and as of October 2026 none has been. Until then, manufacturers must document the solutions they adopted, which puts even more weight on evidence. Paperwork describes intent. 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.
Source scanners, SBOMs, certificate managers and questionnaires all answer a different question — and none of them inspects the software that shipped.
Post-quantum readiness depends on knowing where cryptography lives in the software you run, and a list of components can't tell you that.
-1400x732.jpg&w=3840&q=75)
