Published on gastropod.io on 09-06-2026

CRA Reporting Starts September 11 With Nine Percent of Organizations Running a Mature SBOM Program

Tags: software-supply-chain-security, vulnerability-intelligence, sbom, cyber-resilience-act, cisa, compliance, cyclonedx

On September 11, 2026, Article 14 of the EU Cyber Resilience Act starts to apply. Any manufacturer placing a product with digital elements on the EU market must report an actively exploited vulnerability within 24 hours of becoming aware of it, file a fuller notification within 72 hours, and submit a final report within 14 days of a corrective measure becoming available. Severe incidents follow the same 24 and 72 hour clocks with a one-month final report. Penalties reach 15 million euros or 2.5 percent of worldwide annual turnover.

Article 69(3) applies the reporting duty to products already on the market. A device first shipped in 2018 and still sold today falls in scope on day one. There is no grandfathering for the reporting obligation, only for the design requirements that arrive in December 2027.

Manufacturers file through one channel. Article 16 establishes ENISA's Single Reporting Platform as the sole mechanism, and ENISA's own FAQ confirms that email and national authority portals do not satisfy the obligation. I checked on September 6 and the platform is still not live. ENISA has not published the public access URL and says it will appear on the SRP page before go-live, so the instruction to manufacturers five days out is to keep refreshing that page. ENISA released step-by-step registration guidance on July 31 and updated it on August 3 and August 14, and the guidance asks a registrant to select a coordinating national CSIRT from a drop-down list that the member states have not finished designating. The platform offers no API at launch, so any automated pipeline terminates at a web form filled in by a person. On September 11 the platform will accept mandatory Article 14 and Article 24 reports only; voluntary reporting under Article 15 will not work yet.

Four months of SBOM policy, compressed

The CRA deadline is the visible edge of a much larger stack of documents published since May.

On May 12, CISA and its G7 partners, Germany, Canada, France, Italy, Japan, the United Kingdom, and the European Union, released Software Bill of Materials for AI: Minimum Elements. The G7 Cybersecurity Working Group produced it between August 2025 and February 2026, co-led by Italy's ACN and Germany's BSI. It extends component inventory to models, training and validation datasets, infrastructure dependencies, and security properties.

On July 27, the European Commission published practical guidance for manufacturers, developers, and businesses on meeting CRA obligations, including the point that decides every clock in Article 14: when a manufacturer is regarded as having become aware of a vulnerability.

On July 29, CISA, the NSA, the FBI, the Department of Energy, NIST, the Defense Department's Cyber Crime Center, and international partners released 2026 Minimum Elements for a Software Bill of Materials, replacing the NTIA baseline that had stood since 2021. Seventeen agencies across fourteen countries co-sealed it, and it incorporates more than 90 public comments.

On August 26, CISA and the NSA published A Shared Vision of Software Bill of Materials for Cybersecurity with 19 international cybersecurity organizations, alongside supporting statements from CERT-In, METI, KISA, and others.

Behind all of it, US procurement leverage moved to a different instrument in January. OMB Memorandum M-26-05 rescinded the mandatory self-attestation memos M-22-18 and M-23-16 in favor of an agency-led risk-based approach, while Executive Order 14028 remains in force. Agencies may now adopt contract terms requiring a producer to supply a current SBOM on request, and for cloud platforms the terms should specify that the request covers the runtime production environment. SBOM demands moved from a signed attestation form to a clause in a renewal, and most renewals arrive well before December 2027.

What the new baseline asks for

The 2026 minimum elements add ten data fields, revise eight, and remove one. The required data set roughly doubled, and CISA split it into SBOM Metadata describing the document and Component Data describing the software.

Component Hash Algorithm and Component Hash Value are new. A recipient can now verify that the component described is the component received, rather than accepting the inventory as an assertion. Component License is new, closing a gap that made open-source legal review awkward. SBOM Tool Name, SBOM Tool Version, and SBOM Generation Context are new, because an inventory generated from source and one generated after packaging can disagree, and a consumer needs to know which one is in hand. SBOM Author Signature is new, letting a recipient confirm the document is unaltered, though CISA notes that verifying an SBOM's accuracy goes beyond what the minimum elements cover.

Depth is gone, replaced by Coverage. Supplier name becomes component producer, resolving the ambiguity that had accumulated around distributors. Known Unknowns becomes Explicitly Identifying Unknown Information, separating what a producer withholds deliberately from what the producer does not know.

CISA sets no deadline and states plainly that the document does not constitute compliance advice. The force comes from elsewhere: procurement clauses, and regulations that reference the baseline. The closing discussion section names four unresolved areas, and two of them matter here: validating that an SBOM is accurate, and correlating SBOM data with advisories such as VEX and CSAF.

The readiness data

ENISA surveyed 334 organizations at the end of 2025 and published the results on June 9, 2026. Sixty-five percent are EU-based and 80 percent are directly affected by the CRA.

Seventy-eight percent have started SBOM adoption. Forty-four percent are in a pilot or limited deployment. Nine percent report a fully mature, highly automated implementation.

Seventy-nine percent expect to reach the required maturity level before the CRA becomes fully applicable in December 2027, which leaves about one in five expecting to miss it and 12 percent unable to estimate a date at all. Sixty-two percent say achieving a high degree of SBOM completeness is quite or extremely difficult.

The supplier side is worse than the producer side. Thirty-nine percent of organizations never receive an SBOM for the commercial software they buy, another 39 percent rarely do, and 2 percent always do. Ten percent have a mandatory SBOM clause in supplier contracts. The CRA obliges a manufacturer to produce an SBOM; it does not oblige the manufacturer to hand it to a customer. That gap is what contract renewals are for, and 90 percent of organizations have not yet written the clause.

ENISA also recorded the barriers directly: incomplete software inventories, inconsistent data quality, difficulty obtaining SBOMs from suppliers, difficulty correlating vulnerabilities with software components, and a shortage of internal expertise. Thirty-three percent of respondents who had never heard of SBOM before the survey also reported that their organization places products with digital elements on the EU market.

The mechanical problem

A manufacturer cannot report what it cannot detect. The CRA's formal SBOM requirement is in Annex I Part II and does not become enforceable until December 11, 2027, but the September 11 reporting obligation is structurally unmeetable without one. When a researcher publishes an actively exploited flaw in a widely used library, the 24-hour clock starts when the manufacturer becomes aware. Determining which shipped products contain that library, at which versions, including copies pulled in three layers below anything a developer chose, is the entire task, and it has to finish inside a single business day. At current CVE publication rates, roughly 131 new records per day, manual correlation cannot keep up.

Most SBOM programs regenerate the inventory when a build runs. A model or a dataset can change with no build running at all, so an inventory keyed to release events records nothing. CISA treats the AI elements as supplemental rather than folding them into the general baseline, which means an organization shipping AI features now maintains two inventories with different triggers.

Where Gastropod fits

Gastropod produces a CycloneDX SBOM on demand rather than storing one you maintain. Every artifact it proxies or hosts resolves to a Package URL, a version, an ecosystem, a source, and a sha256 digest at the moment it passes through, so the inventory is reconstructed from what your builds actually pulled instead of from what a manifest declared. Asking for the SBOM is a query against that record.

That mechanism happens to match what the 2026 minimum elements now require. Component Hash Value and Component Hash Algorithm are native, because digest identity is how Gastropod names artifacts in the first place rather than a field it fills in afterward. Generation Context is unambiguous: the inventory comes from resolved artifacts after packaging, not from parsing a pom.xml or a requirements.txt. Coverage follows from the same source, since the record includes artifacts resolved transitively as well as the ones a developer named.

For the September 11 clock, the relevant capability is correlation speed. Gastropod matches OSV advisories against tracked artifact versions and maintains a transitive dependent graph, so "which of our products contain this component, at what version, and through what path" is a lookup rather than a survey of every team that ever ran a build. That answer is what fills in a 24-hour early warning, and it is the same answer a customer's procurement clause will start asking for when the renewal comes around.

Gastropod does not file the report for you, and it covers the artifacts your builds pull through it. Within that scope, the inventory already exists. The product page covers the digest identity model, the OSV correlation, and the dependent graph.

Sources