Your SBOM Is One Artifact. The CRA Wants About a Dozen.

What a CycloneDX File Actually Is

Start with the file, because it's the thing most teams already have and the thing most teams overestimate.

CycloneDX is a format for writing down what's inside your software. It's a JSON or XML file listing every component that ships in your product: name, version, license, supplier, and a package URL (purl) that uniquely identifies each one. It's maintained by OWASP, the Open Worldwide Application Security Project, and version 1.6 was ratified as an Ecma International standard, ECMA-424, in June 2024. Version 1.7 became the 2nd Edition in December 2025.

The alternative format is SPDX (Software Package Data Exchange), maintained by the Linux Foundation and standardised as ISO/IEC 5962. Both describe the same thing. No EU regulation currently mandates one over the other. Pick based on what your customers' tooling reads.

A CycloneDX file is a software bill of materials, or SBOM: the ingredient list for your product. Here's a trimmed one:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    {
      "type": "library",
      "name": "zlib",
      "version": "1.3.1",
      "purl": "pkg:generic/zlib@1.3.1"
    }
  ]
}

That's it. A list, in a format a machine can read.

Now the part that trips people up: having that file is not the same as complying with the Cyber Resilience Act. The CRA (Regulation (EU) 2024/2847) treats the SBOM as one artifact among roughly a dozen. The file answers "what's in the product." The regulation also asks who to contact, what you did about a finding, how long you'll support it, and whether you told anyone in time.

Here's the rest of the list.

In the Repo: Five Files, Versioned Like Code

These live next to your source. A developer owns them and they change with each release.

SECURITY.md — your vulnerability-disclosure policy, in plain text at the root of the repository. Where to report a problem, how fast you'll acknowledge it, and a safe-harbor statement promising you won't take legal action against good-faith researchers. Without this, someone who finds a flaw in your firmware has no obvious way to tell you, and their next move is often a public post instead.

/.well-known/security.txt — the same information in a machine-readable form, defined by RFC 9116. About ten lines: a contact address, a link to your full policy, and an Expires date. Automated scanners look for this at a fixed path on your website. The Expires field is the one people forget; once it passes, the file signals that the contact may be stale.

sbom/<product>.cdx.json — the CycloneDX file above, regenerated by CI (continuous integration, the server that builds your code on every commit) and attached to every release. Regenerated, not hand-maintained. An SBOM edited by hand drifts from the binary within two releases.

CHANGELOG — release notes that name fixed vulnerabilities by their CVE ID. CVE stands for Common Vulnerabilities and Exposures: a public catalogue that gives every known flaw a unique identifier like CVE-2018-11235, so two companies discussing the same bug know they mean the same bug. Writing "security fixes" instead of the identifier means your customers cannot tell whether the one they're worried about is handled.

Signed release artifacts — a checksum and a cryptographic signature on what ships, so someone downloading your firmware can verify it came from you and arrived unmodified.

Together these are roughly an afternoon of work. That estimate is honest for the repo files and dishonest if you extend it to what follows.

Per Product: The Part That Takes Longer

These are company-level and mostly internal. They're where teams stall, because no single engineer owns them.

Technical File (Annex VII) — the evidence dossier: product description, risk assessment, the SBOM, test evidence, a description of how you deliver updates, and your coordinated vulnerability disclosure (CVD) policy. Article 31 requires you to keep it, and the EU declaration of conformity, available to market surveillance authorities for at least ten years after the product is placed on the market, or the length of the support period, whichever is longer.

Support period and end-of-life date — how long you guarantee security updates. Market surveillance authorities are required to monitor how manufacturers set this, and the regulation's administrative cooperation group publishes statistics on average support periods by product category. A five-year period is a common practical floor for industrial hardware, not a number the regulation states.

Vulnerability register — every finding logged with its source, the decision made, and the dates. This is the unglamorous one, and it's the one that decides whether you make the reporting deadline. It's also the thing that turns "are we affected?" from a week of archaeology into a query.

VEX statements — Vulnerability Exploitability eXchange. The structured way to say "CVE-X is present in product Y but not exploitable, because the affected function is never called." Without VEX, every CVE in a dependency becomes a customer email you answer by hand.

User information (Annex II) and, from 11 December 2027, an EU Declaration of Conformity plus CE marking — the conformity mark already on European electronics. Default-class products are self-assessed. Higher-risk categories need a notified body, an independent accredited assessor. Worth knowing: as of mid-2026, no notified bodies had yet been designated for the CRA in the Commission's NANDO database, though the rules for designating them started applying on 11 June 2026.

The Concrete Case

You ship firmware v2.3.1 for an industrial gateway built on Zephyr. Three weeks later a library you vendored two years ago, not something you wrote or watch, gets a CVE added to CISA's Known Exploited Vulnerabilities (KEV) catalogue: the US agency's list of flaws confirmed to be exploited in the wild, not merely theoretical.

The CRA clock starts when you become aware that a vulnerability in your product is being actively exploited. Not when it's published, not when you patch. From that moment: 24 hours for an early warning to your national CSIRT (Computer Security Incident Response Team) and ENISA, the EU's cybersecurity agency, through the Single Reporting Platform. 72 hours for a fuller notification. 14 days after a fix exists for a final report.

If your vulnerability register doesn't already know that library is in your shipped binary, you learn about the deadline after it passed.

This is what build-accurate means in practice: an SBOM derived from what the build actually produced, rather than inferred from a manifest, so a vendored .a archive appears whether or not anyone remembers adding it.

$ bomwerk scan . --format cyclonedx -o sbom/gateway-fw-2.3.1.cdx.json
[bomwerk] scanning . (vcpkg.json + 3 vendored libs)
[bomwerk] resolved 214 components
[bomwerk] diff vs sbom/gateway-fw-2.3.0.cdx.json: +2 components, 1 version bump
[bomwerk] wrote sbom/gateway-fw-2.3.1.cdx.json (CycloneDX 1.6)
exit 0

Exit 0 means the scan completed and nothing on the KEV catalogue is unresolved. Exit 1 or 2 means stop: a component didn't resolve, or a KEV hit has no VEX decision. The same check a human runs down the checklist by hand, except it runs every time rather than when someone remembers.

Two Dates, and Who Enforces Them

The reporting duty starts 11 September 2026, and it applies to products already on the market, not only new ones. The rest, conformity assessment, technical documentation, CE marking, applies from 11 December 2027.

Enforcement is national. Article 52 requires each member state to designate one or more market surveillance authorities, working under the existing Market Surveillance Regulation (EU) 2019/1020 for inspections and corrective measures. Germany has designated the BSI, its federal information security office. Several other states had not published a designation as of mid-2026. The rules are identical everywhere, because the CRA is a regulation rather than a directive; who knocks on your door differs by country.

Customers regulated under NIS2, the EU's directive covering operators of essential services, are already asking suppliers for SBOMs and CVD policies, ahead of both dates.

Where bomwerk Fits, Honestly

bomwerk scan produces a build-accurate SBOM today, in CycloneDX or SPDX. It does not yet scaffold SECURITY.md or security.txt for you; that's planned, not shipped. Everything in the per-product section above is still your paperwork, not something a scanner generates.

If you want to know what your own repository actually contains, that's the part we handle. We'll scan one repository free and show you the real inventory, gaps and low-confidence entries included. For the regulation itself rather than our reading of it, start with Regulation (EU) 2024/2847 on EUR-Lex and the Commission's own summary. If the CRA itself is new to you, our plain-English guide to the regulation covers scope, fines, and the reporting clock in more detail.