Capability mapping

CRA Annex I, requirement by requirement.

This is written in the manufacturer’s language rather than ours, and for each essential requirement it says what the requirement asks of you and whether we produce anything you could put in front of an assessor for it. Most rows come back marked not covered, which is the honest shape of a key custody service measured against a whole product regulation.

We build the evidence. Your assessor judges it. SanctiKey is not a conformity assessment body and no tool makes a product compliant - anyone who says otherwise is selling you an asterisk.

Citations are to the final adopted text of Regulation (EU) 2024/2847. Numbering differs from the 2022 Commission proposal, where this list appeared as point (3) with different letters, and from the ENISA standards mapping, which still carries the proposal identifiers. If you are cross-referencing, check which version your source used. Control identifiers in the last column are from the published control catalog.

Part I: essential cybersecurity requirements

Point (2) applies on the basis of the cybersecurity risk assessment referred to in Article 13(2), and where applicable.

Annex I, Part I (2)(c)Partial

Ensure that vulnerabilities can be addressed through security updates, including where applicable automatic security updates installed within an appropriate timeframe.

What it demands of you: You must ship an update mechanism, default it on where applicable, notify users, and let them postpone or opt out.
What SanctiKey produces: The authenticity half: a signing key generated inside FIPS 140-3 Level 3 validated HSMs, non-extractable, plus the per-signature record proving which identity signed which release and when. The mechanism, the rollout and the opt-out UX are entirely yours.
Controls cited: SC-062, SC-055

Annex I, Part I (2)(f)Direct

Protect the integrity of stored, transmitted or otherwise processed data, commands, programs and configuration against any manipulation or modification not authorised by the user, and report on corruptions.

What it demands of you: You must be able to show that firmware, configuration and commands cannot be altered by an unauthorised party without detection.
What SanctiKey produces: Signatures produced by a key that has no export path, so a compromised build server yields no ability to sign. Algorithm and key-type combinations are validated on every call, so a weakened or mismatched signing request is refused rather than honoured.
Controls cited: SC-004, SC-053, SC-055

Annex I, Part I (2)(e)Partial

Protect the confidentiality of stored, transmitted or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state of the art mechanisms.

What it demands of you: You must encrypt the relevant data and be able to justify the mechanism as state of the art.
What SanctiKey produces: Encryption and decryption against keys held in an account outside the one holding the data, with encryption context enforced per call and a destination-key ownership check so data cannot be re-encrypted out to a key you do not own. What you encrypt, and where, stays your design decision.
Controls cited: SC-054, SC-055

Annex I, Part I (2)(d)Partial

Ensure protection from unauthorised access by appropriate control mechanisms, including authentication, identity or access management systems, and report on possible unauthorised access.

What it demands of you: Your product must authenticate and authorise its users and report suspected unauthorised access.
What SanctiKey produces: Per-device identity where you choose certificates over shared secrets: a private CA hierarchy with the root key under the same custody as your signing key. For access to the key service itself, authenticator-app second factor, breached-password blocking, and authorisation that is never cached so a revocation takes effect on the next request.
Controls cited: SC-007, SC-009, SC-042, SC-002, SC-003

Annex I, Part I (2)(l)Not covered

Provide security related information by recording and monitoring relevant internal activity, including access to or modification of data, services or functions.

What it demands of you: Your product records its own internal activity, access to and modification of its data, services and functions, and offers the user an opt-out.
What SanctiKey produces: Nothing from the device side, by design. Recording a device's internal activity means the device reporting it, and a product device that reaches out to a third-party key API is an attack surface we will not ask you to open. We keep a tamper-evident, monitored record of our own side, every cryptographic operation we perform for you, and that record is claimed where it belongs rather than mapped onto your product's telemetry.

Annex I, Part I (2)(a)(b)(g)(h)(i)(j)(k)(m)Not covered

No known exploitable vulnerabilities, secure by default configuration, data minimisation, availability of essential functions, limiting impact on other networks, attack surface limitation, exploitation mitigation, and secure deletion of user data and settings.

What it demands of you: These are properties of your product, assessed on your product.
What SanctiKey produces: Nothing. A key custody service has no honest claim on any of them, and we're not going to write one just to fill the column.

Part II: vulnerability handling requirements

These apply throughout the support period and are process obligations more than product properties.

Annex I, Part II (7)Direct

Provide for mechanisms to securely distribute updates for products with digital elements to ensure that vulnerabilities are fixed or mitigated in a timely manner.

What it demands of you: You must be able to distribute an update such that the receiving device can establish it is genuine and unmodified.
What SanctiKey produces: The signing key and the signature. Held in an account outside your organisation, so an attacker who fully compromises your build environment still cannot produce a signature your devices will accept.
Controls cited: SC-031, SC-004

Annex I, Part II (1)Not covered

Identify and document vulnerabilities and components, including by drawing up a software bill of materials.

What it demands of you: You must produce and maintain an SBOM covering at least the top-level dependencies.
What SanctiKey produces: Nothing. This is your build system and your SBOM tooling.

Annex I, Part II (2)(3)(4)(5)(6)(8)Not covered

Remediate without delay, test and review regularly, disclose fixed vulnerabilities, enforce a coordinated vulnerability disclosure policy, facilitate reporting, and disseminate updates without delay and free of charge.

What it demands of you: These are your vulnerability handling process obligations.
What SanctiKey produces: Nothing, beyond the example of our own disclosure policy if it is useful to you as a template.

Documentation, assessment and reporting

The parts of the file that outlive the engineering.

Article 13(13)Partial

Keep the technical documentation and the EU declaration of conformity at the disposal of market surveillance authorities for at least ten years after the product has been placed on the market, or for the support period, whichever is longer.

What it demands of you: You must retain the file, and be able to produce it on request, for at least a decade.
What SanctiKey produces: Evidence you must retain for ten years, exportable from day one. The retention duty is yours and stays yours; what we undertake is that nothing you need is trapped inside our console, and that the Keyout right can transfer the account holding the audit table into your sole ownership.

Article 13(2) and Annex VIINot covered

Carry out a cybersecurity risk assessment and include it, along with a justification for the support period and for any essential requirement treated as not applicable, in the technical documentation.

What it demands of you: You perform the assessment and write the justification.
What SanctiKey produces: Nothing. We can be cited in your file as the custody mechanism for named keys; we cannot perform your risk assessment.

Article 14Not covered

Report actively exploited vulnerabilities and severe incidents to ENISA and the relevant CSIRT, on a 24 hour, 72 hour and 14 day cadence. Applies from 11 September 2026, including to products placed on the market before full application.

What it demands of you: You register with the reporting platform and you make the notifications, on the clock.
What SanctiKey produces: Nothing procedural. Your audit trail may be useful evidence during an investigation, which is not the same as help with the filing, and we are not going to blur the two.

The dates, without spin

10 December 2024: the Regulation entered into force.
11 June 2026: Chapter IV applies, covering notification of conformity assessment bodies. This is about the bodies, not about you.
11 September 2026: Article 14 reporting applies. Under Article 69(3) it reaches products placed on the market before full application, so a product you shipped in 2025 is in scope for reporting.
11 December 2027: full application. Essential requirements, conformity assessment, CE marking and technical documentation become enforceable.

The signing key is the long-lead item on that timeline, because changing which key signs your firmware is a fleet-wide trust anchor migration rather than a configuration change, and doing it before the first device ships costs a fraction of what it costs afterward.

See pricing All four regulations The CRA use case