Frameworks · Laws and regulations

qodiqa and the EU Cyber Resilience Act

qodiqa checks each AI request before the call and keeps tamper-evident, offline-verifiable evidence. This page shows where that evidence supports the EU Cyber Resilience Act, and where it does not.

Law
European Union
Applies from 11 Dec 2027; reporting from 11 Sep 2026.
Verified 2026-11-01

Read the official text Back to all frameworks

Overview

What it is

Issuer: European Union
Type: Law
Status: Applies from 11 Dec 2027; Art. 14 reporting from 11 Sep 2026
Official text: eur-lex.europa.eu

Regulation (EU) 2024/2847, the Cyber Resilience Act. The Cyber Resilience Act sets cybersecurity requirements for products with digital elements placed on the EU market. Manufacturers must design products securely (Annex I, Part I), handle vulnerabilities for the product’s support period (Annex I, Part II) and report actively exploited vulnerabilities (Art. 14).

Who it applies to. Manufacturers, importers and distributors of products with digital elements, including software, made available on the EU market in the course of commercial activity. Obligations to report actively exploited vulnerabilities apply from 11 September 2026 and the main obligations from 11 December 2027.

Where it meets qodiqa

The parts of the EU Cyber Resilience Act where the evidence matters.

Robustness and security

Access control, integrity checks and fail-closed behaviour are security-by-design properties.

Record-keeping and logging

A tamper-evident record of relevant activity.

Accountability

A public disclosure route and open source code.

Traceability

A request hash ties each logged event to one request.

Risk management

Metrics and alerts show anomalies in the AI layer.

Human oversight

A kill switch lets an operator stop AI use while a vulnerability is being exploited.

Mapping

What qodiqa provides, and what stays with you.

Requirement or control	What qodiqa provides	What stays with you
`Annex I, Part I, point 2(d)` Protection from unauthorised access through authentication, identity or access management, and reporting on possible unauthorised access.	Per-actor signing keys, role-based operator access and a recorded authorisation decision for each request.	Authentication and access management in your own product.
`Annex I, Part I, point 2(f)` Integrity of data, commands, programs and configuration against unauthorised manipulation, and reporting on corruptions.	Signed artifacts and request binding make a changed request detectable, and audit chain verification reports a broken chain.	Integrity of the rest of your product.
`Annex I, Part I, point 2(l)` Security-related information by recording and monitoring relevant internal activity.	Hash-chained audit entries, a transparency log, metrics and alert rules.	The product’s own logging and an opt-out mechanism for users.
`Annex I, Part II, points 5–6` Coordinated vulnerability disclosure policy and a contact address for reporting vulnerabilities.	The public repositories publish a security policy, a private reporting route and a contact address.	Your own disclosure policy for your product.
`Art. 14` Reporting of actively exploited vulnerabilities through the single reporting platform.	Nothing automated. Alert rules and audit records can help you notice and reconstruct events.	Reporting. It is a manufacturer’s duty, and nothing in qodiqa does it.

The specification’s Regulatory Alignment Matrix does not cover the EU Cyber Resilience Act. This page maps the gateway documentation only.

How it fits

What the EU Cyber Resilience Act asks, and what qodiqa produces.

Unauthorised access (Annex I, 2(d)) is supported by Per-actor keys and RBAC (Recorded decisions).
Integrity (Annex I, 2(f)) is supported by Signed, request-bound artifacts (Chain verification).
Recording activity (Annex I, 2(l)) is supported by Audit entries and metrics (Alert rules).

Evidence

Evidence you can hand to an auditor.

Five artifacts, each checkable on its own

Consent artifact Signed with Ed25519, bound to one request, single use.
INTENT entry The audit entry written before the provider call.
Receipt A signed decision record that checks offline.
Audit export Hash-chained entries with a Merkle inclusion proof.
Anchor proof A signed checkpoint pinned outside the gateway.

Verify offline, from a clone of qodiqa-verify

node bin/verify.bundle.external.js \
  --keys examples/front-half/keys.json \
  --transparency-keys examples/front-half/transparency-keys.json \
  examples/front-half/bundle-with-proof.json

The example files ship with the repository and are signed with throwaway keys. The command exits 0 and prints "valid": true. For your own evidence, take keys and anchors from a source other than the gateway that wrote it.

Scope and limits

Technical evidence, not a compliance outcome

qodiqa produces verifiable technical evidence that supports parts of the EU Cyber Resilience Act. It is not a compliance certification, it is not legal advice, and no regulator or standards body has endorsed it. Whether your use meets the EU Cyber Resilience Act is a decision for you and your advisers.

What qodiqa does not address:

Conformity assessment, CE marking and a product’s technical documentation.
Whether the Act applies to qodiqa itself as open source software; this page does not interpret that.
Vulnerability handling and security updates over a product’s lifetime.
Only requests that pass through the gateway are checked, and a receipt proves a decision was recorded, not that it was correct.

Sources

Article, clause and control references were read in the official texts listed first. The remaining links are qodiqa’s own documents. Checked on 2026-11-01; rules change, so read the current text.

Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex accessed 2026-11-01
qodiqa-gateway: security policy accessed 2026-11-01
qodiqa-gateway: audit chain integrity verification accessed 2026-11-01
qodiqa-gateway: limitations accessed 2026-11-01

Next steps

See the evidence for yourself.

Read the spec section Run a simulation Quickstart