The EU Cyber Resilience Act is the first horizontal law to impose cybersecurity obligations on products with digital elements across their whole lifecycle — secure-by-design and secure-by-default requirements, a mandatory coordinated vulnerability disclosure policy, vulnerability handling and security updates for the support period, an SBOM for the top-level dependencies, and reporting of actively exploited vulnerabilities and severe incidents to ENISA. Unlike the sectoral data mandates, it compels no API; it compels a set of provable processes, several of which are naturally expressed as machine-readable artifacts.
EU Cyber Resilience Act
Statute European Union
The EU Cyber Resilience Act does for product security what the AI Act does for AI: it regulates a horizontal property of software rather than a sector, and it attaches duties to whoever places a product with digital elements on the EU market. For an API provider, the important thing is that several of its obligations are not postures — they are artifacts somebody can ask you to produce.
- A coordinated vulnerability disclosure policy is mandatory - Manufacturers must have a policy and a single point of contact for reporting vulnerabilities. This is the obligation that turns a published disclosure policy from good manners into a legal requirement.
- Vulnerability handling across the support period - Identify, document, and remediate vulnerabilities without delay, and distribute security updates for the declared support period.
- An SBOM covering top-level dependencies - Machine-readable in practice, which is why CycloneDX and SPDX matter here rather than as an engineering nicety.
- Reporting of actively exploited vulnerabilities and severe incidents - To ENISA and the relevant CSIRT, on a short clock, which presumes you already know what your product does and who is affected.
- Secure by design and by default - Including a default configuration that is the secure one, not the convenient one.
Read against an API catalog, the CRA lands on exactly the artifacts this research already scores. A security.txt or published vulnerability disclosure policy is the single point of contact the Act requires. An SBOM is a machine-readable dependency contract. Incident reporting on a clock presumes operational transparency — a status surface, a changelog, an audit trail — rather than a quarterly PDF.
That is what makes the cybersecurity cohort’s numbers uncomfortable rather than merely ironic. 28% of the cybersecurity industry publishes a vulnerability disclosure policy, and in threat intelligence — the sub-sector whose product is telling customers about exposed infrastructure and unpatched software — it is two organizations in nine. The Act does not ask whether a company knows how disclosure works. It asks whether the policy is published and the contact point exists, and that is a question answered by an artifact or not answered at all.
Like the EU AI Act, the CRA compels no interface, which is why the Kin Score folds no Regulatory Posture facet into cybersecurity. It compels provable process, and process that has to be proved is process that is cheaper to publish than to reconstruct.
Referenced in API Evangelist papers
This regulation shows up in my published research. These reports read the machine-readable evidence provider by provider — and put this regulation in the context of a real sector.
The State of Compute & Hardware APIs
The first regulation in hardware's history requiring an ongoing structured data flow from manufacturer to customer — read against the RoHS precedent, where the same industry answered a per-part data mandate with spreadsheets.
The OpenAPI Standard
An OpenAPI document is increasingly the machine-readable inventory the CRA's SBOM and disclosure obligations get satisfied against.
The State of Cybersecurity APIs
The regime that turns a missing vulnerability disclosure policy from an irony into an obligation — 72% of the cybersecurity industry publishes none.
Reaches these HTTP headers
Where a regulation actually touches the wire. Mandated means the law, or a technical standard it makes binding, names this header. Evidentiary means no law names it, but it is the deployed control for an obligation the law does impose. Inferred means it would be good evidence and nothing requires it — interesting to read, never to score.
