The Cyber Resilience Act puts cybersecurity obligations on the product, not just the operator.

Log4Shell hit on a Friday. Nobody had the broken component on a list.

The Cyber Resilience Act names the software bill of materials once, and a lot of the industry has read that single line as the whole obligation. Generate the SBOM, tick the box, move on. That is a misread. Regulation 2024/2847 explicitly calls SBOM the minimum — “at the very least the top-level dependencies”. A broken cipher three suppliers upstream, a Log4Shell-class transitive vulnerability, a firmware bug you inherited without knowing — none of these show up on a standard SBOM, and all of them are still yours to answer for under CRA Article 13. The things most likely to hurt you are invisible to the artefact everyone is rushing to produce.

A PDF that lists your libraries is a description of a bill of materials, not one your customer can use. They cannot merge a document into their evidence pipeline, so on their side it may as well not exist. The right test for any vendor from December 2027 onwards is a simple one: can they produce a machine-readable SBOM this week, or would it take a quarter?

You can download our machine-readable SBOM right now in SPDX 2.3 JSON: /sbom.spdx.json. It lists every runtime component with SPDX identifier, version, licence, and supplier. Merge it into your evidence pipeline. Diff it between releases. Feed it into your vulnerability scanner. Machine-readable, right now, this week. No PDF, no quarter-long request.

This is why we position the wallet, the issuer and the verifier as “line-by-line at Aloaha Limited” throughout the site — see the web wallet explainer for the same argument on the client side. It is a deliberate architectural choice made in service of the CRA baseline — not a marketing claim after the fact.

Horizontal cybersecurity law for digital products.

The EU Cyber Resilience Act — Regulation (EU) 2024/2847 — was adopted in October 2024 and came into force on 11 December 2024. It is the EU’s first horizontal cybersecurity rulebook for “products with digital elements” (PDEs): hardware and software with direct or indirect data connections to a device or network. It does for software what the General Product Safety Regulation does for kettles — mandatory CE marking, conformity assessment proportional to risk, and lifecycle-long manufacturer responsibility.

Key obligations on a manufacturer:

• Secure by design and by default. Documented risk assessment, threat model, and design choices that reduce attack surface.
• Vulnerability handling. A coordinated-vulnerability-disclosure (CVD) channel, structured triage, and a public security policy.
• Software Bill of Materials (SBOM). A machine-readable inventory of components and dependencies.
• Support period. Free security updates for a declared period — minimum five years from placement on the market, unless the product’s expected service life is shorter.
• Incident reporting. Actively-exploited vulnerabilities reported to ENISA and the national CSIRT within 24 hours of awareness (early warning); full notification within 72 hours.
• CE marking. The product carries the CE mark only after the appropriate conformity-assessment route is completed.

Penalties go up to €15M or 2.5% of worldwide turnover, whichever is higher. So this has teeth.

Two deadlines, not one.

The CRA staggers its obligations — you can’t treat it as a single “December 2027” cliff.

• 11 Dec 2024
• CRA enters into force. 36-month transition begins for the main obligations.
• 11 Sep 2026
• Vulnerability-reporting duties apply. Manufacturers must have a CVD channel and the 24h / 72h reporting workflow operational. This is the early deadline most teams forget about.
• 11 Dec 2027
• All other obligations apply. CE marking required on in-scope products placed on the EU market. Conformity assessment must be complete.

Important Class I, in our reading.

The CRA splits products into four risk bands: default, Important Class I, Important Class II, and Critical. Higher bands need more independent assessment. Our reading of Annex III places CodeB in Important Class I because the platform includes identity-management functionality (the built-in OpenID Connect provider and the EU Wallet verifier) and is a network-management tool. That means:

• Self-declaration of conformity is not sufficient. We’ll need a recognised third-party conformity assessment against a harmonised standard — almost certainly EN 18031-1/2/3 once those land.
• The CE marking on the product (the software distribution and the documentation) will reference the chosen conformity-assessment route.
• Technical documentation (Annex VII) and the EU declaration of conformity (Annex V) must be available to market-surveillance authorities for ten years after the last placement.

What’s already in place.

The CRA does not stand alone.

Four EU regulations interact with CodeB’s posture. Buyers in regulated sectors usually need to satisfy several at once.

NIS2 — Directive (EU) 2022/2555

Regulates operators of essential / important entities across 18 sectors. Enforcement live since 2025. NIS2-covered entities buying a non-CRA-compliant product after December 2027 face a compliance gap on both sides. CodeB’s self-hosted posture and audit logging materially simplify NIS2 evidence-gathering.

DORA — Regulation (EU) 2022/2554

Applies to financial entities since 17 January 2025. ICT-third-party-risk obligations directly map to vendor questionnaires. CodeB’s data-residency-on-your-server posture removes most ICT-third-party-risk questions before they need to be answered.

EU AI Act — Regulation (EU) 2024/1689

Transparency obligations from 2 August 2026 require AI interactions to be disclosed to the user. CodeB Voice AI’s persona prompts already disclose “you are speaking to an AI” in the first sentence; see the AI-call privacy page.

eIDAS 2.0 — Regulation (EU) 2024/1183

EU Digital Identity Wallet acceptance becomes mandatory for private-sector strong-customer-authentication services from December 2027 — same date as the CRA cliff. CodeB’s EU Wallet verifier is shipped today; see the proof page.

What to ask any communications vendor right now.

If you’re evaluating a communications platform in 2026 for a deployment that has to be alive after December 2027, here’s the short questionnaire:

• What is your CRA classification (default / Important Class I / II / Critical)? Show the Annex III mapping.
• Where is the coordinated-vulnerability-disclosure channel published? Is RFC 9116 security.txt live today?
• What is the declared support period from last shipment, and is it in writing?
• Can you provide a CycloneDX or SPDX SBOM on request?
• Which notified body has been engaged for the conformity assessment?
• What is your 24-hour ENISA / national-CSIRT incident-reporting workflow, in writing?
• If the answer to any of the above is “we’ll get to it” — can you commit a date?

CodeB’s answers to all of the above are documented and available on request. Contact us for the current versions.

Related reading.

• Privacy manifesto — the broader CodeB privacy posture.
• AI-call privacy — AI Act alignment + AI processing data flow.
• EU Wallet verifier proof — eIDAS 2.0 readiness.
• All features — full technical surface.
• Contact — for the support-period declaration, SBOM, CVD policy or notified-body engagement letter.
• /.well-known/security.txt — live CVD channel.