Cyber Resilience Act (CRA)
The market-surveillance authority audits your product with digital elements; we ship the runtime evidence for the AI subsystem inside it. Regulation (EU) 2024/2847 (CRA) entered into force on 11 December 2024, with the substantive obligations applying from 11 December 2027. The CRA places its essential cybersecurity requirements and vulnerability-handling obligations on the manufacturer placing a product with digital elements (PDE) on the EU market — not on any audit-layer underneath. Adjudon's role on this page is to make the AI-decisioning component of a manufacturer's Annex I posture evidenced at runtime, the Article 11 active-exploit reporting cadence defensible, and the vulnerability-handling lifecycle auditable. We document this honestly so a manufacturer arriving here knows which CRA obligations the audit-layer covers and which sit outside the AI subsystem.
Scope
This page applies to manufacturers placing a product with
digital elements on the EU market that includes AI-driven
decisioning — the gen_ai.*-emitting subsystem inside a
larger PDE.
The CRA covers any "product with digital elements" sold or made available on the EU market, with three obligation tiers:
- Default class — self-attestation against Annex I; CE marking
- Important class I & II — third-party assessment required for certain categories (firewalls, IDS, password managers, smart-home hubs, …)
- Critical class — explicit conformity assessment by a notified body
Adjudon SaaS is not itself a product with digital elements in the
CRA sense — the regulation explicitly excludes
software-as-a-service models where the customer does not control
the deployment. The integration packages
(@adjudon/node, adjudon Python, the n8n / Zapier / Make
connectors) are open-source under permissive licences and fall
under Article 2(3) free-and-open-source-software exclusion.
Customers self-hosting Adjudon under a Custom plan inherit the
PDE classification of their own deployment context.
Roles
| Role | Party | CRA basis |
|---|---|---|
| Manufacturer | Your organisation placing the PDE on the market | Art. 3(13) |
| Importer / distributor | Your downstream channels (if any) | Art. 18 / 19 |
| Audit / policy infrastructure | Adjudon | Out of scope as a regulated entity |
| Market surveillance authority | National (e.g. BNetzA in Germany) | Art. 41 |
| ENISA single reporting platform | EU-level reporting recipient | Art. 14 |
The manufacturer carries the obligations, full stop. The CRA does not create a "service-provider liability" pathway; an audit-layer vendor cannot inherit a manufacturer's CRA obligations by association.
Annex I — essential requirements
The mapping below covers the AI-decisioning slice of Annex I. Other Annex I rows (memory protection, authentication, secure update channel for the wider PDE) live with the manufacturer's broader product-security stack.
| Annex I requirement | What Adjudon evidences |
|---|---|
| Part I (3)(a) Designed without known exploitable vulnerabilities | ML-BOM (CycloneDX 1.7) per trace lets manufacturers cross-check model components against vulnerability feeds |
| Part I (3)(b) Secure-by-default configuration | API keys are 64-hex single-use on display; Hash Chain default-on; PII scrubber non-disableable |
| Part I (3)(c) Vulnerability remediation via security updates | Out of scope — manufacturer's product-update channel |
| Part I (3)(d) Protection from unauthorised access via state-of-the-art mechanisms | JWT + per-agent API key + SCIM + SAML AuthnContextClassRef enforcement |
| Part I (3)(e) Confidentiality of stored / transmitted / processed data | TLS 1.3 in transit; PII scrubbing at ingest; Frankfurt eu-central-1 only |
| Part I (3)(f) Integrity of stored / transmitted / processed data | SHA-256 Hash Chain; tamper-evident, append-only, verifiable via three commands |
| Part I (3)(g) Process only data that is adequate, relevant, limited | Allow-listed metadata on onboarding; PII scrubber on every payload |
| Part I (3)(h) Protect availability of essential functions | Documented SLOs (99.9% Scale/Governance live; 99.99% Enterprise on roadmap); fail-open SDK posture |
| Part I (3)(i) Minimise own negative impact on third-party services | Per-agent rate limit; circuit-breaker + retry on outbound webhooks |
| Part I (3)(j) Limit attack surfaces (interfaces, ports, services) | Public surface is /api/v1/* only; Stripe webhook isolated; SCIM separately auth-bounded |
| Part I (3)(k) Incident-impact reduction techniques | Multi-Clock Incident Hub; alert engine; automated webhook retries |
| Part I (3)(l) Security-relevant information via logging mechanisms | Operations Audit Log + Hash Chain; structured JSON logs |
| Part I (3)(m) Secure deletion of data on configuration change | GDPR Right-to-Erasure on payload (audit shells preserved); per-org retention 7-3650 days |
Article 11 — active-exploit and vulnerability reporting
Article 11 imposes a staged cadence whenever a manufacturer becomes aware of an actively-exploited vulnerability in their PDE or a severe incident affecting its security. The Adjudon Multi-Clock Hub ships the CRA template out-of-the-box; the offsets are the regulators' law, not configurable per-org.
| Checkpoint | Offset from clockStartedAt | What the manufacturer submits |
|---|---|---|
| Vulnerability notification | 24 hours | Early-warning to the CSIRT designated as coordinator and to ENISA |
| Advisory publication | 72 hours | Detailed assessment plus available corrective or mitigating measures |
| Patch availability | 14 days | Final report with the corrective measure (typically a patched version) |
The 24-hour clock starts from the manufacturer's awareness, not
from public disclosure. The Hub stamps every checkpoint
completion with the operator's evidenceTraceId cross-link, so
when the auditor asks "show me the trace artefact for the 24-hour
notification", the answer is a single hash-chain anchor away.
Annex I Part II — vulnerability handling
Part II requires the manufacturer to maintain a vulnerability- handling lifecycle. Adjudon evidences the AI-subsystem slice:
| Part II requirement | What Adjudon evidences |
|---|---|
| Identify & document vulnerabilities and components | ML-BOM per trace; agent registry; component digests |
| Address & remediate without delay | Multi-Clock Hub Art. 11 cadence forces the timetable |
| Apply effective & regular tests | Documented at Penetration Testing |
| Once remediation is available, publicly disclose | Manufacturer's responsibility; Adjudon does not host disclosure pages |
| Coordinated-vulnerability-disclosure policy | Cross-link to Responsible Disclosure |
| Provide mechanisms to securely distribute updates | Out of scope — manufacturer's product-update channel |
| Free-of-charge security updates | Out of scope — manufacturer's commercial concern |
What this is NOT
- Not a CE-marking checklist. The CE mark is the manufacturer's self-attestation under Annex IV; Adjudon evidences a slice of the underlying Annex I requirements, not the CE attestation itself.
- Not a notified-body engagement. Critical-class PDEs require conformity assessment by a notified body. Adjudon-evidenced rows can be cited in the technical documentation; the notified-body audit is a separate engagement the manufacturer procures.
- Not vulnerability-disclosure hosting. The CRA requires manufacturers to host coordinated-disclosure policies and publish advisories. Adjudon does not host disclosure pages; the manufacturer's own security.txt + advisory channel does.
- Not an SBOM tool. Adjudon attaches an ML-BOM (CycloneDX 1.7) per trace specifically for the AI components. The full PDE-level SBOM (operating system, runtime, third-party libraries) sits with the manufacturer's broader build pipeline.
See also
- Multi-Clock Incidents — the deadline hub that runs the 24 h / 72 h / 14 d clocks
- Incidents API — the integration surface for incident creation and clock management
- Penetration Testing — the Annex I Part II testing-cadence disclosure
- Responsible Disclosure — the coordinated-vulnerability-disclosure policy
- NIS2 Compliance — the cybersecurity parallel for essential and important entities (often overlapping scope with CRA-regulated manufacturers)