CRA Compliance — accompanying documentation

This page is the formal information and instructions to the user (the “accompanying documentation”) required under CRA Art. 13(18) and set out in CRA Annex II, for the four CRE8EVE-shipped SDKs that are in scope under CRA Annex III as Class I important products (identity-management software):

@rakomi/node — packages/sdk/
RakomiSDK (Swift) — packages/swift/
rakomi_flutter (Dart) — packages/flutter/
@rakomi/react-native — packages/react-native/

Two package sets are referenced on this page and they are deliberately distinct:

CRA-scoped manufacturer products (overall): @rakomi/node, RakomiSDK (Swift), rakomi_flutter, @rakomi/react-native — the four customer-shipped SDKs in CRA Annex III scope.
JS-family publish set (published / publishable now): @rakomi/node, @rakomi/sdk-core, @rakomi/react, @rakomi/react-native — the four npm packages with per-package SECURITY.md. The completeness gate on this page clears the JS-family publish; native Swift/Flutter documentation is tracked separately and is not yet published.

Information and instructions to the user (Annex II)

The manufacturer must ensure products are accompanied by the information and instructions to the user set out in Annex II (obligation: Art. 13(18)). Rows marked † are part of the technical documentation (Art. 31 / Annex VII) held for market-surveillance authorities, not the user-facing Annex II set.

CRA Annex II requirement	Where it lives in this docs site
Intended purpose + intended user	Each SDK’s package README + Getting Started guide (each quickstart leads with intended purpose/user)
Manufacturer identification (CRE8EVE Sp. z o.o.)	`compliance/manufacturer.md` (+ root `SECURITY.md` § Manufacturer)
Conformity assessment evidence † (technical documentation — Art. 31 / Annex VII)	`https://github.com/rakomidev/rakomi-js/tree/main/security/cra-vulnerability-records/`
Cybersecurity risk assessment summary † (technical documentation — Art. 31 / Annex VII)	`security/threat-model/traceability-matrix.yaml` (categorised by CWE)
Vulnerability disclosure policy	Per-package `SECURITY.md` (`packages/{sdk,sdk-core,react,react-native}/SECURITY.md`) + `https://rakomi.com/.well-known/security.txt`
Coordinated disclosure contact	`security@rakomi.com` (CAA `iodef` channel for both `rakomi.com` + `rakomi.dev` zones)
Configuration recommendations + secure default settings	`sdk/secure-defaults` (one shared page, per-runtime subsections)
Support period / end-of-life (Art. 13(8))	SDK Support & Lifecycle + machine-readable `sdk-support.json` — dated windows of at least 5 years (60 months) per MAJOR attach at 1.0
Software bill of materials (SBOM)	Per-package `sbom.cdx.json` (CycloneDX format, not SPDX). Present today for `@rakomi/node` + `@rakomi/react`; generated at first publish for `@rakomi/sdk-core` + `@rakomi/react-native`
Patch / update policy	SemVer + `CHANGELOG.md` + GitHub Releases per package

The full dated, version-scoped completeness assessment lives at compliance/art10-completeness — the artifact the first public npm publish is gated on.

Essential cybersecurity requirements (Annex I, Part I)

The essential cybersecurity requirements are set out in Annex I, Part I (obligation: Art. 13(1)). The four SDKs above are scoped under Annex III §1. The Rakomi platform itself (API, dashboard, accounts, docs, status, playground, jwks-mirror) is not in CRA Class-I scope — it is hosted infrastructure delivered as a service, not a “product with digital elements” placed on the EU market.

The public OAuth playground (playground.rakomi.dev) is explicitly out of scope — it is a sandbox demo for evaluation, not customer-shipped software. Demo credentials are publicly documented; the demo persona is fictitious (GDPR Art.4(1) non-PII).

Vulnerability handling (Annex I, Part II)

CRA Annex I, Part II sets the vulnerability-handling requirements (identify and document vulnerabilities, address them without delay, distribute secure updates, operate a coordinated-disclosure policy); the manufacturer obligation to meet them is Art. 13(1). The separate statutory reporting deadlines (early warning within 24h, notification within 72h, final report within 14 days) are Art. 14 — see below. Rakomi operates a documented vulnerability-triage and incident-response process; it is available to auditors on request.

Vulnerability records & retention (Art. 13(13))

Each CRA-jurisdiction finding (cra_jurisdiction: true in the traceability matrix) gets a record file in security/cra-vulnerability-records/ with the retention note in the header. The 10-year retention aligns to Art. 13(13) — technical documentation and the EU declaration of conformity are kept at the disposal of market-surveillance authorities for at least 10 years. Records are immutable once closed (append-only edits). The manufacturer’s reporting obligations to the CSIRT coordinator / ENISA are Art. 14 (a distinct clock from this retention period).

JWKS audit transparency

The mirror at https://jwks.rakomi.dev/.well-known/jwks.json exists for auditors and compliance reviewers — a stable human-accessible URL serving the live signing keys plus a tamper-evident rotation log at https://jwks.rakomi.dev/transparency. SDKs DO NOT consume this endpoint (coupling the SDKs to the .dev host would force a breaking release across all four CRA-scoped packages); SDKs use https://api.rakomi.com/.well-known/jwks.json exclusively.