Compliance
For your compliance lead
Where a key custody decision shows up in your evidence pack.
There are four regulations, plus one certification program, where the way you hold a key ends up visible in the file you hand an assessor. For each one we’ve written down what the law asks of you, which artifact we produce, and what stays entirely your job.
Four is the honest number, not the number that fills a page. We could list every acronym in the market, but a padded compliance page becomes a liability the first time a reviewer checks one entry and finds nothing behind it.
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.
The deadline that is already moving
EU Cyber Resilience Act
Regulation (EU) 2024/2847 · in force 10 December 2024
Article 14 reporting applies from 11 September 2026. Full application, including CE marking and technical documentation, from 11 December 2027.
If you place a product with digital elements on the EU market, you'll have to demonstrate a secure update mechanism, keep the technical documentation behind it for at least ten years, and produce that documentation to a market surveillance authority on request. The signing key sitting under the update mechanism is the part of the file where a custody decision either holds up or quietly falls apart.
What the law requires of you
- §Annex I Part I (2)(c): vulnerabilities can be addressed through security updates, where applicable automatic and installed within an appropriate timeframe.
- §Annex I Part I (2)(f): protect the integrity of stored and transmitted data, commands, programs and configuration against manipulation not authorised by the user.
- §Annex I Part II (7): provide mechanisms to securely distribute updates so vulnerabilities are fixed or mitigated in a timely manner.
- §Article 13(13): 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 is placed on the market, or for the support period, whichever is longer.
Which artifact SanctiKey produces
- +A firmware signing key generated inside FIPS 140-3 Level 3 validated HSMs, non-extractable, that was never present on a build server or a developer laptop.
- +A per-signature audit record: which key, which operation, which identity, when, and the result. Tamper-evident and exportable.
- +A key lifecycle record: creation parameters, algorithm pinning, and rotation state that control SC-062 makes non-optional at creation.
- +A private CA hierarchy for device identity, with the root key held under the same custody as the signing key.
What remains yours
- →The conformity assessment route, the CE marking, the EU declaration of conformity and the technical documentation itself.
- →The update client on the device: verification logic, the trust anchor in the bootloader, rollback protection, the rollout and the opt-out mechanism.
- →The cybersecurity risk assessment under Article 13(2), the SBOM, coordinated vulnerability disclosure, and Article 14 reporting.
- →Retaining the evidence for the full ten-year period. That duty is the manufacturer’s. Ours is to make the evidence exportable from day one.
This one fits without an asterisk because CRA conformity needs no publicly trusted CA at all. A manufacturer signs against a root it controls and embeds in its own bootloader, which is private trust, which is exactly what we serve, so there’s no attestation gap anyone has to explain away later.
What that buys you is firmware signed by a key you can prove was never on a build server, with an audit trail your conformity assessor can actually read, from $49 a month.
→ The full Annex I capability mapping, requirement by requirement
Already applying
EU Radio Equipment Directive, cybersecurity requirements
Directive 2014/53/EU Article 3(3)(d)(e)(f), activated by Delegated Regulation (EU) 2022/30
Applying since 1 August 2025, after the twelve-month postponement in Delegated Regulation (EU) 2023/2444.
Internet-connected radio equipment sold into the EU has had to meet network protection, personal data protection and fraud protection requirements since August 2025. The harmonised standards EN 18031-1, -2 and -3 give a presumption of conformity when applied in full, and two of their mechanisms are key custody questions in everything but name.
What the law requires of you
- §EN 18031-1 SUM (secure update mechanism): updates must be verifiable as authentic and unmodified. Where that is implemented with digital signatures, the signing key management and the bootloader verification chain must be documented in the technical file.
- §EN 18031-1 SSM (secure storage mechanism): confidential cryptographic keys must be stored so they cannot be read or replaced by an unauthorised entity.
- §EN 18031-1 CCK (confidential cryptographic keys) as an asset class, with a stated protection rationale for each key.
- §A technical file and an EU declaration of conformity referencing the additional essential requirements, or a notified body assessment where the harmonised standards are not applied in full.
Which artifact SanctiKey produces
- +Non-extractable key material as the SSM answer for the signing key: no export path exists, for anyone, including us.
- +The documented custody chain for the SUM signing key: where it was generated, under which validated modules, which identities could invoke it, and every invocation.
- +A per-key record you can paste into the CCK asset inventory: algorithm, usage policy, rotation state, partition and access group.
- +Certificate issuance for device identity where your protection objective calls for per-device credentials rather than a shared secret.
What remains yours
- →The on-device verification: bootloader trust anchor, signature checking, rollback protection. EN 18031-1 assesses the device, not the service that signed for it.
- →The technical file, the declaration of conformity, the CE marking and, where you do not apply the harmonised standards in full, the notified body engagement.
- →Every requirement in EN 18031-1, -2 and -3 that is not about key custody, which is most of them.
Note the restrictions: Implementing Decision (EU) 2025/138 cites EN 18031-1, -2 and -3:2024 in the Official Journal with restrictions, and the guidance and rationale annexes do not confer presumption of conformity. Read the citation, not a summary of it.
If you are an essential or important entity
NIS2
Directive (EU) 2022/2555 · transposed into national law from 17 October 2024
NIS2 won't tell you which cipher to use. It tells you to hold a policy on the use of cryptography and encryption, to control access, and to be able to show your management body that the measures actually work. In practice the cipher is never the hard part; producing evidence that the policy was enforced, rather than merely written, is where these assessments go sideways.
What the law requires of you
- §Article 21(2)(h): policies and procedures regarding the use of cryptography and, where appropriate, encryption.
- §Article 21(2)(i): human resources security, access control policies and asset management.
- §Article 21(2)(d): supply chain security, including the security of relationships with direct suppliers and service providers.
- §Article 20: management bodies approve the measures, oversee implementation, and can be held liable for failures.
Which artifact SanctiKey produces
- +Enforcement evidence rather than a policy document: control SC-062 means a non-rotating key cannot be created, so "keys are rotated" stops being an assertion and becomes a property of the system.
- +An access control record per key: partitions, the access group behind each one, and the per-operation trail showing which identity used which key.
- +A key asset inventory that stays current because it is the running state of the service, not a spreadsheet maintained beside it.
- +A published trust topology for the supplier assessment you will be asked to run on us, including the limits section most vendors omit.
What remains yours
- →Writing and approving the cryptography policy. We supply the enforcement surface and the evidence, not the policy text.
- →Everything in Article 21(2) that is not cryptography or access control: incident handling, business continuity, testing, training, MFA rollout across your estate.
- →Incident reporting under Article 23, and the supplier assessment itself.
The one everybody already has
GDPR Article 32
Regulation (EU) 2016/679 · security of processing
Article 32(1)(a) names encryption of personal data as an appropriate measure, and most organisations implement it, then discover at audit that the key was sitting in the same account, the same config store, or the same nightly backup as the data it was protecting. Encryption whose key travels alongside the ciphertext is a control that fails at the one moment you need it.
What the law requires of you
- §Article 32(1)(a): pseudonymisation and encryption of personal data, as appropriate to the risk.
- §Article 32(1)(b): the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services.
- §Article 32(1)(d): a process for regularly testing, assessing and evaluating the effectiveness of the measures.
- §Article 5(2) accountability: being able to demonstrate the above, not merely to have done it.
Which artifact SanctiKey produces
- +Key and ciphertext separated by an account boundary: the encryption key is held in an AWS account outside the one holding the data, so a copied database is not a copied key.
- +Encryption context enforced on every call, and a destination-key ownership check (SC-054) so data cannot be re-encrypted out to a key you do not own.
- +A per-operation record of every encrypt and decrypt: which key, which identity, when. This is the Article 5(2) demonstrability half.
- +A published, numbered control catalog you can cite in your own Article 32(1)(d) assessment rather than paraphrasing a vendor brochure.
What remains yours
- →The lawful basis, the records of processing, the DPIA, and the decision about what is appropriate to your risk. Article 32 is a proportionality test and only you can run it.
- →Data subject rights, breach notification under Articles 33 and 34, and processor agreements across the rest of your stack.
- →The rest of your estate. We hold the key. We do not hold the personal data.
A certification program, not a regulation
Matter: attestation custody, and where our claim stops.
A Matter device carries a Device Attestation Certificate, which chains to a Product Attestation Intermediate and, above that, to a Product Attestation Authority. A commissioner decides whether to trust that chain by reading the Connectivity Standards Alliance Distributed Compliance Ledger. The ledger is a federated trust store for the program, not a browser or operating system root program, and the difference is the whole of this section: Matter does not ask you to chain to a publicly trusted root, it asks you to publish a private chain somewhere every commissioner can find it.
There are two shapes of attestation authority. An open PAA issues for vendors other than its operator and carries the full CA audit framework. A VID-scoped PAA issues only under a single Vendor ID, is operable by the vendor that owns that ID, and is listable in the ledger against a periodic attestation of the internal audit rather than that framework, the class of engagement a SOC 2 Type II sits in. The second shape is the one a product company can realistically run, and it is the route this section describes.
What the program requires of you
- §Alliance membership and a Vendor ID of your own. Chains are listed against vendors, and neither the membership nor the VID is something a supplier can hold on your behalf.
- §A certificate policy and practice statement for the attestation CA, plus the periodic audit attestation the Alliance expects from a VID-scoped PAA operator.
- §Registration of the PAA in the Distributed Compliance Ledger, which is a Trustee-approved transaction, and from Matter 1.3 a reachable distribution point for the intermediate’s revocation list.
- §Certification of the device itself. An accepted attestation chain is a precondition of commissioning, never a substitute for certifying the product.
Which artifact SanctiKey produces
- +Custody of the attestation roots: PAA and PAI private keys generated inside FIPS 140-3 Level 3 validated HSMs, CMVP certificate #4884, non-extractable. The program sets its custody floor at FIPS 140-2 Level 3, so this sits above the floor rather than level with it.
- +The hierarchy itself: a self-signed root, an intermediate signed beneath it with the path length the profile fixes, CSR signing, issuance and revocation, over the same REST API as every other certificate we issue.
- +ECDSA P-256 over SHA-256 as the only algorithm an attestation profile accepts. A request naming anything else is rejected rather than quietly down-negotiated to something the profile would tolerate.
- +A published revocation list for the intermediate at a stable URL you can register, republished on a fixed interval rather than only when something is revoked.
- +A per-operation issuance record: which authority, which key, which identity, when. Tamper-evident and exportable, which is the evidence half of the audit attestation you will be asked to produce.
What remains yours
- →The membership, the Vendor ID, the practice statement, the audit engagement and the ledger submission. We produce evidence. We do not file paperwork on your behalf.
- →The factory: how a device key is generated, how the attestation certificate reaches the part, and the provisioning line that puts it there.
- →The device firmware and the commissioning behaviour, including which attestation failures your product treats as fatal.
- →Every Matter requirement that is not certificate custody, which is nearly all of them.
Two boundaries, both deliberate, both worth hearing on the first call rather than the fifth.
We do not operate an open PAA.We hold custody of a root scoped to your Vendor ID and issue beneath it. Issuing attestation certificates under someone else’s Vendor ID is a different business with a different audit obligation, and we are not in it.
We do not yet claim a production device attestation certificate. The certificate profiles for the authority, the intermediate and the device certificate are built and deployed, including the device-lifetime validity such a certificate needs and the no-expiry encoding the ecosystem uses for it. Vendor and Product ID are carried as the dedicated subject attributes under the Alliance’s own object identifier arc, never parsed out of free text in a common name, because a common name is not a structured field and treating it as one is how a factory run fails to commission. A chain issued by those profiles has been checked with chip-cert, the Alliance’s own SDK tool, and passed. What is not true yet is that the check runs against every change we make. Until it gates the pipeline, “ship this and it commissions” is a sentence we will not write. What we sell today is attestation root custody, the intermediate hierarchy beneath it, and the firmware signing those same devices need under CRA and RED.
One detail, because it is where attestation deployments actually break in the field. A commissioner reading a revocation list past its next-update time treats the list as stale, and stale can fail commissioning of brand new devices with nothing revoked at all. Our attestation revocation lists carry a next-update no more than thirty days out, and regeneration runs on a fixed interval sized so a published list is never close to expiring. That interval is deliberately not aligned to the calendar month: seven months are thirty-one days long, and a month-aligned rotation leaves no margin in those.
On price, when the device certificate does ship as a claim it will price as what it is, a signing operation on the same meter as any other, drawn from the operations your keys already bundle. There is no attestation tier and there is not going to be one.
An earlier version of this page said no configuration of this product would produce a device attestation certificate a commissioner accepts. That was wrong. It treated the Distributed Compliance Ledger as a public root program, which it is not, and it overstated our own limit in the process. The correction is worth more to you than the tidier sentence was.
What you can export
Evidence you must retain for ten years, exportable from day one.
The retention duty is yours, and under CRA Article 13(13) it runs for at least ten years after the product is placed on the market, or for the support period, whichever is longer. What we take on is narrower than that but more useful day to day: nothing you need is locked inside our console, and the export works from the first day of the subscription rather than the day you finally ask for it.
- Per-operation audit records
- Every cryptographic operation: key identifier, operation, invoking identity, partition, timestamp, outcome. Tamper-evident, with a monitored write path so a gap in the trail raises an alarm rather than passing quietly (SC-019, SC-029).
- Key lifecycle records
- Creation parameters, algorithm and key type, usage policy, rotation state, partition and access group membership. Rotation is enabled at creation or creation fails (SC-062).
- Certificate issuance records
- What was issued, against which authority in your hierarchy, on whose request, and when.
- The control catalog
- Ninety numbered controls, published, with a known-limits section. Self-attested and labelled as such, because a numbered specific catalog is worth more to your reviewer than a vague badge.
And if you would rather not depend on us for the export at all, the Keyout right transfers the AWS account holding the audit table into your sole ownership. How that works and what it costs.
What we do not cover
Six frameworks we researched and cut, with the reason for each.
Any of these could have been another section on this page, and we cut them because the first reviewer who checks a padded entry stops believing the ones that were real.
- DORA
- Regulation (EU) 2022/2554 governs financial entities and their ICT third-party providers, and supporting it meaningfully would mean contractual terms under Article 30, a register-of-information entry, exit strategies and audit rights we don't currently offer. Claiming the mapping without those would be a paperwork claim rather than a security one.
- HIPAA
- We don't sign business associate agreements, so the Security Rule mapping has nowhere to attach itself. Encryption is an addressable specification under 164.312(a)(2)(iv) and we could write a convincing paragraph about it, but without a BAA behind it that paragraph is decoration.
- eIDAS qualified trust services
- Qualified electronic signatures and seals need a qualified trust service provider that's been audited by a conformity assessment body and listed by a supervisory body, and we're none of those things. A signature produced here isn't a qualified signature.
- SOC 2 and ISO 27001 certification
- Our control catalog is self-attested and the security page says so plainly. Until there's a third-party report to hand you, presenting ourselves as a certified sub-service organisation would be exactly the asterisk we keep telling you not to accept from anyone else.
- FedRAMP, CMMC and US federal authorisation
- These need authorisation packages and boundaries we don't hold. FIPS 140-3 validated modules are one component of such a package, not a substitute for having done the work.
- Publicly trusted code signing
- Public code signing programs increasingly want per-key attestation artifacts that AWS KMS doesn't currently emit, and rather than build against that gap we serve private trust and say so up front. Signing against a root you control and embed yourself is fully served today.
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.