You might not think you need this. Here is why you probably do.

The situation

From 11 December 2027, products with digital elements sold into the EU must demonstrate a secure update mechanism and protect the integrity of the programs and configuration they carry, with technical documentation kept for at least ten years and produced to market surveillance authorities on request. Internet-connected radio equipment has been under a narrower version of the same duty since 1 August 2025. Underneath both sits one mechanism: sign each release with a private key, and let the device check that signature against a trust anchor you control before anything runs.

The usual way it goes wrong

Most teams keep that signing key in a file on a build server or a developer’s laptop. If that machine is breached, attackers can sign malware that looks exactly like your official software, and every customer who trusts you will install it. This has sunk real companies. It also fails the paperwork: you cannot write a credible custody chain for a key that lived in CI, and that custody chain is what an assessor asks to see.

With SanctiKey

The signing key is created inside SanctiKey and can never be copied out, not even by you. Your build pipeline sends the release to be signed over a secure connection and gets back a signature. The key stays inside validated hardware the whole time, and every signing is recorded with the identity that asked for it, so the custody chain is a record you export rather than a paragraph you compose from memory.

The situation

If you store things like social security numbers, health records, or payment details, you are expected (often legally required) to encrypt them. Encryption scrambles the data with a key so that only someone holding that key can read it back.

The usual way it goes wrong

If the encryption key is stored in the same place as the data, in the same database, app config, or cloud account, then whoever steals the data usually steals the key too. The encryption was theatre: one break-in reads everything.

With SanctiKey

Your application sends a sensitive value to SanctiKey to encrypt, stores only the scrambled result, and calls back to decrypt when it genuinely needs the value. The key lives in a separate, isolated account and never sits next to the data, so a copied database is just noise.

The situation

As you grow, your servers, apps, and devices need to know which other machines are really yours before they exchange anything. The proven way is to give each one a digital ID card, called a certificate, issued by an authority they all trust. It is the same padlock idea your browser uses, turned inward onto your own network.

The usual way it goes wrong

Teams improvise: shared passwords copied between servers, long-lived keys pasted into scripts, or self-made certificates nobody tracks. Anything that gets a copy of a shared secret can impersonate a real system, and revoking access means hunting down every copy.

With SanctiKey

SanctiKey acts as your private certificate authority. Its root key stays locked inside, and it issues each server or device its own short-lived ID. Machines present their ID to prove who they are; anything without a valid, current one is turned away, and you can revoke a single ID without disturbing the rest.

The situation

Some keys are so important that losing them is a disaster: lose the key and the data it protects is gone forever. But keeping easy copies lying around is exactly what makes keys leak. You need a way to recover a key in a real emergency without leaving it exposed the rest of the time.

The usual way it goes wrong

The usual fallbacks are a key in a password manager, a copy on a USB stick in a drawer, or one person who 'has it.' Each is either too easy to steal or too easy to lose with the person who held it.

With SanctiKey

Critical keys are held in protected recovery inside SanctiKey. Day to day, nobody can extract them. Recovery requires the approvals you define, and every recovery attempt, successful or not, is logged. The key is reachable in a genuine emergency and unreachable otherwise.

The situation

The Cyber Resilience Act sets two dates you are already inside. From 11 September 2026 you must report actively exploited vulnerabilities on a 24 hour clock, and that duty reaches products you have already shipped. From 11 December 2027 the essential requirements in Annex I become enforceable with CE marking, and the technical documentation behind them must be kept for at least ten years after the product is placed on the market, or for the support period, whichever is longer.

The usual way it goes wrong

The usual pattern is that the engineering was fine and the file was not. Firmware was signed, but by a key that lived in the build system, held by whoever had pipeline access, with no record of who signed which release. When the assessor asks how the signing key was protected and who could use it, the answer gets written from memory in the two weeks before the meeting. That is the expensive way to discover that the trust anchor in a shipped bootloader cannot be changed.

With SanctiKey

The signing key is generated inside FIPS 140-3 Level 3 validated HSMs, is non-extractable, and lives in an AWS account outside your organisation, so a full compromise of your build environment still produces no signature your devices will accept. Every signing operation writes a tamper-evident record: which key, which identity, when, and the outcome. You export that record and put it in your technical file. SanctiKey does not assess your conformity and does not sign your declaration; it produces the artifact you submit.