> Markdown version of https://docs.laavat.io/security/ from the LAAVAT PKI and Signing Platform documentation. All pages: https://docs.laavat.io/llms.txt

# Security and architecture

This page describes how the platform protects your signing keys: where the keys
live, who can reach them, how the platform is separated between customers, and
what the realistic residual risk is.

It is written for engineers and security reviewers evaluating LAAVAT. It states
the limits of the design as well as its strengths, because a security review
that discovers those limits on its own is worse than one that reads them here.

## Where keys live

Signing keys are generated inside **AWS CloudHSM** and never exist in plaintext
outside it. Signing happens in the HSM: the private key is never handed to your
build systems, or to ours.

Keys are owned by, and access-controlled to, a **crypto user that belongs to
you**. This is enforced by the HSM itself rather than by application logic — no
other customer's crypto user can reference your keys, whatever happens in the
software above.

## HSM deployment models

Three models are available. Which you choose determines both your isolation and
your business-continuity position.

| Model | Hardware | HSM administration | Suits |
| --- | --- | --- | --- |
| **Shared** (default) | Shared CloudHSM cluster, dedicated crypto user per customer | LAAVAT | Lowest cost of entry — no dedicated HSM to fund |
| **Dedicated, LAAVAT-managed** | Your own cluster — single HSM, or an HA pair | LAAVAT | Physical isolation and a higher service level, without running HSMs yourself |
| **Dedicated, customer-managed** | Your own cluster, in your AWS account | **You** | Full custody and control — strongest continuity position |

### Shared

The default, and the option with the lowest cost of entry: there is no
dedicated HSM to fund. Your keys sit on a shared cluster but remain owned by
and access-controlled to your own crypto user. The cluster is always
provisioned — there is no per-signing-window bring-up.

### Dedicated, LAAVAT-managed

The same operating model on hardware that is yours alone, as a single HSM or an
HA pair. Choose this where you need physical isolation, or a higher service
level than the shared cluster offers, without taking on HSM administration
yourself.

> **Note: Availability**
> Service levels are agreed per customer rather than fixed. A dedicated
> cluster — particularly an HA pair — supports a materially higher
> availability commitment than the shared cluster. Discuss your requirement
> with us as part of choosing a model.

### Dedicated, customer-managed

The cluster runs in your own AWS account, and **you hold the HSM administrative
role**. This is the strongest position for business continuity: you hold the
crypto-officer credential, so key custody is yours and recovering your own key
material does not depend on LAAVAT at all.

Holding that role does not mean going it alone — LAAVAT supports customers
running this model, including the HSM administrative procedures involved. Talk
to us about what that covers for your setup.

## Platform tenancy

Each customer gets their own copy of the application stack in a dedicated
Kubernetes namespace: its own pods, its own database, its own
configuration. **There is no shared application component in your signing
path.**

- Configuration and audit data are separated at the **data layer** — separate
  database, not filtered views over shared data.
- The tenant-scoped crypto-user credential exists only inside your namespace.
  Your stack can only sign against your keys, and no other stack can sign
  against them at all.
- Approval rules and quorum are configured per tenant and resolve against
  **your own identity provider at request time**, so every signing request is
  authorised against a directory you control before the platform proceeds.

A dedicated Kubernetes cluster is available as an option; most customers run
the namespace model.

## Key custody and export

Keys are not locked in with no way out. Two export paths exist, with
deliberately different controls.

### Online: encryption keys and exportable tokens

**Encryption keys and exportable tokens are the only keys with an online export
path.** Encryption keys need one. Encryption is symmetric: if you ship encrypted firmware, the device has to
hold the key that decrypts it, or it cannot boot. That key therefore has to
leave the platform and be provisioned into the device — typically fused or
written into secure storage during manufacturing.

This is not a weakening of the security model; it is what encrypted firmware
requires. The design goal is to move the key from the HSM into your device
without exposing it along the way. So an encryption key can be exported
programmatically with a `SecurityEngineer` client, wrapped to a client key you
register in advance: only the holder of that private key can unwrap it, and it
is never in the clear in transit. Every export is recorded as an audit event.

Handling once unwrapped is yours. The key is only as protected as the
provisioning environment you unwrap it into, so use a controlled manufacturing
host rather than a general-purpose build machine.

An **exportable token** is a key that exists to be exported: a product
operation of type `ExportableToken` holds an AES, RSA or EC key generated in the
HSM and has no operation behind it. It is how you get key material for use
elsewhere — an SSH key for a device's crypto chip, for example — generated with
the HSM's random number generator rather than on a build machine. The platform
never signs or encrypts with it: an image signing request against it is refused
with `400` ("operation type has no signing operation: ExportableToken"), so it
is not a signing key. It is always extractable and leaves the platform by the
same wrapped path, RSA and EC keys as PKCS#8 private keys. See
[exportable tokens](https://docs.laavat.io/usage/productguide/product/#exportable-tokens), and the
[exportable tokens example](https://docs.laavat.io/exampleflows/exportabletoken/) for one used as a
device's SSH key.

For an encryption key the path is enabled per key by the `extractable` flag when
the product is created. That flag is valid only on encryption keys — the
platform rejects it on a signing key, so no signing key can be given an online
export path, even by a misconfigured template. See
[exporting keys](https://docs.laavat.io/usage/clientguide/clients/#exporting-aes-keys-with-a-securityengineer-client)
and [AES image encryption](https://docs.laavat.io/usage/signing-encryption/aes-encryption/).

### Offline: the crypto-officer ceremony

Keys with no online export path — signing keys, and any encryption key not
marked extractable — can still be wrapped out under a **crypto-officer
ceremony** when there is a genuine business-continuity need.

This is deliberately a manual procedure rather than an API call. The
crypto-officer credential is held offline, under dual control, so the ceremony
requires two authorised people acting deliberately — **no software compromise
can invoke it**. Keys are wrapped only while the ceremony is performed, so no
wrapped copies of your keys sit at rest anywhere.

Customers commonly take a backup once they reach a steady state — the products
they need created and in active use, with no new ones expected shortly — rather
than repeating the ceremony for every new key. Where that point falls is a risk
decision that depends on your continuity requirements and on your own ability
to store extracted keys securely. Contact LAAVAT to arrange a ceremony.

Where you hold the HSM administrative role yourself, the question largely goes
away: key custody is yours, and recovering your own key material does not
depend on LAAVAT.

## Residual risk

Worth stating plainly, because it is the question a security review is actually
asking: **the risk is unauthorised use of your keys, not extraction of them.**

Signing keys have no online export path — not by configuration, but because
the platform does not permit one to exist. A compromise of the stack serving
you could therefore permit unauthorised signing for the duration of that
compromise, scoped to your tenant, but it could not extract the keys.
Extraction is possible only through the offline, dual-control ceremony
described above.

The authorisation check that gates signing is enforced in the application
layer. That is the honest location of the residual risk, and it is where the
controls are concentrated:

- **No shared signing path.** Per-tenant deployment, with a signing credential
  scoped so it cannot cross tenants.
- **Authorisation against your directory.** The approval gate resolves against
  your own identity provider at request time.
- **Operational hardening.** Patching, logging, monitoring and alerting across
  the stack.
- **Detection.** You receive a complete audit log of all signing activity under
  your tenant, so no use of your keys is silent.

The remaining case at the HSM layer is administrative access. Administrative
operations run under dual control, and the crypto-officer credential is held
offline under dual control — not present in, or reachable from, any online
system. On a customer-managed dedicated cluster this case does not
apply to LAAVAT at all, because you hold that role yourself.

## Certification

LAAVAT's information security management system is certified to
**ISO/IEC 27001:2022**, certificate number 244147, issued by British Assessment
Bureau (Amtivo Group) under UKAS accreditation. It has been certified since
December 2022 and is subject to annual assessment.

The certified scope is *"the provision of a cloud based solution to centrally
manage cryptographic keys, identities and operations for manufacturers and
integrators of IoT devices worldwide"* — that is, the platform described on this
page rather than a subset of the business.

The ISMS is what governs the operational controls referenced here: dual control
over HSM administrative operations, offline custody of the crypto-officer
credential, and the access, logging and change-management practices around the
deployment. A copy of the certificate is available on request.

## Related

- [Clients and key export](https://docs.laavat.io/usage/clientguide/clients/) — the wrapping
  scheme and the steps to register a client and unwrap keys
- [Configuration groups](https://docs.laavat.io/usage/adminguide/groups/) — how reader, writer
  and approver roles map to your identity provider's groups
- [Audit trails](https://docs.laavat.io/gui/audit/trails/) — generating and downloading the audit
  record of platform activity
- [CRA compliance](https://docs.laavat.io/cra-compliance/) — how this infrastructure
  supports the Cyber Resilience Act's integrity and update requirements