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.

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¶

Encryption keys are the only keys with an online export path, and they 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.

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 any other key, so no other key can be given an online export path, even by a misconfigured template. See exporting AES keys and AES image 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.

Clients and key export — the wrapping scheme and the steps to register a client and unwrap keys
Configuration groups — how reader, writer and approver roles map to your identity provider's groups
Audit trails — generating and downloading the audit record of platform activity
CRA compliance — how this infrastructure supports the Cyber Resilience Act's integrity and update requirements