Frequently asked questions¶
Short answers to the questions that come up most often, each linking to the full documentation.
About the platform¶
What is LAAVAT?¶
A cloud PKI and code-signing platform for embedded and IoT device manufacturers. It signs firmware, secure boot images and software updates with HSM-held keys, issues and manages device identities, and runs the certificate authority hierarchy behind both. It is a SaaS platform, not an on-premise appliance.
Every operation is available three ways: a web GUI, a
REST API, and the
signing-tool command-line client.
What problem does it solve?¶
Code signing needs private keys, and private keys on a build machine are a liability — they can be copied, and any signature made with them is indistinguishable from a legitimate one. LAAVAT keeps signing keys in a hardware security module and exposes signing as an approved, audited operation, so the signature can be produced without the key ever being handed out.
Do I need to run my own HSM or PKI?¶
No. That is the point of the platform — the HSM, the CA hierarchy and the key lifecycle are operated for you. You define products and certificate profiles describing what you need signed and under which certificates.
Signing¶
What can LAAVAT sign?¶
Secure boot images for NXP i.MX (HAB and AHAB), STMicroelectronics (SBSFU) and Xilinx/AMD Bootgen; update and image formats including RAUC bundles, MCUboot and U-Boot FIT images; OCI container images; Windows binaries; and detached digest signatures.
This is not the full list — see Secure boot and CRA for a fuller picture, and the audit event reference for the operation names.
My chipset is not listed. Can I still use it?¶
Usually yes. Digest signing with a detached signature signs a hash rather than a specific container format, so a platform without a dedicated guide can generally be supported through it. Ask us about your silicon before assuming it is out of scope.
Which key types and hash algorithms are supported?¶
RSA 2048/3072/4096, EC secp224r1 through secp521r1, and AES 128/256, with SHA-256 and SHA-512. RSA 1024 exists for legacy cases and is not recommended. The full matrix, including which combinations are NIST-recommended, is in Supported keys.
Does the firmware image get uploaded to LAAVAT?¶
Not necessarily. With digest signing you compute the hash locally and send only the digest, so the image itself never leaves your build environment. Other operations do take the artifact — which applies depends on the operation. See Signing and encryption.
Keys and security¶
Where are the signing keys?¶
In AWS CloudHSM. Keys are generated inside the HSM and never exist in plaintext outside it — signing happens in the HSM, and the private key is never handed to your build systems or to ours. Your keys are owned by and access-controlled to your own crypto user, enforced by the HSM rather than by application logic.
See Security and architecture.
Is the HSM cluster dedicated to us, or shared?¶
Three models are available: a shared cluster with a dedicated crypto user per customer (the default, and the lowest cost of entry), a dedicated cluster managed by LAAVAT, or a dedicated cluster in your own AWS account that you administer. The last gives you full key custody and is the strongest position for business continuity.
See HSM deployment models for the comparison.
Is the platform itself multi-tenant?¶
Each customer gets their own copy of the application stack in a dedicated Kubernetes namespace — its own pods, tables and configuration. There is no shared application component in your signing path, and approval rules resolve against your own identity provider at request time.
See Platform tenancy.
What is the realistic worst case?¶
The risk is unauthorised use of your keys, not extraction of them. Signing keys have no online export path, so a compromise could permit unauthorised signing for its duration, scoped to your tenant — not extraction. Audit visibility means no use of your keys is silent.
See Residual risk for the full statement and the controls around it.
Can key material be exported, for backup or business continuity?¶
Yes, by two paths. Encryption keys often have to be exported: encryption is symmetric, so a device shipping encrypted firmware must hold the key that decrypts it, and that key has to be provisioned into the device. Those — and only those — can be exported online, wrapped to a client key you register in advance so they are never in the clear in transit. Every other key, signing keys included, can be wrapped out only under an offline crypto-officer ceremony requiring two authorised people.
Can signing keys be exported online?¶
No. The online export path is restricted to encryption keys — the
extractable flag is valid only on those, and the platform rejects it on a
signing key. No signing key has an online export path under any configuration,
so a misconfigured template cannot create one. Signing keys are recoverable
only through the offline crypto-officer ceremony.
Is LAAVAT ISO 27001 certified?¶
Yes. LAAVAT's information security management system is certified to ISO/IEC 27001:2022 (certificate 244147, British Assessment Bureau, UKAS accredited), certified since December 2022 and subject to annual assessment. The certified scope covers the cloud solution for centrally managing cryptographic keys, identities and operations. See Certification.
How do I keep tokens out of my shell history and CI logs?¶
Never put a token on the command line. signing-tool accepts a token three
safe ways: -n <config> (a config file referencing a token_file),
-t @/path/to/file, or -t @- to read it from stdin — which suits CI secret
managers. Note that interactive commands such as group add and escrow add
read stdin themselves and so cannot use -t @-; use a config file or
-t @file for those. See
secure token handling.
Access control and approvals¶
Who can sign, and who approves?¶
Access is driven by your identity provider's groups — Microsoft Entra ID or Google Cloud Identity. Groups are mapped to reader, writer and approver roles per area (product, CA, revocation and client), so the person who requests an operation need not be the person who approves it. See Configuration groups.
Can signing require approval?¶
Yes. Each operation carries an approval rule naming which groups may submit a
request and which may approve it, so a request stays pending until an approver
acts. Requests can be approved in the
GUI or via the client, and
signing-tool imagesigning get --wait blocks until the request is approved and
then downloads the result.
A rule can also name blanket groups whose submissions are auto-approved — which is how an unattended CI pipeline signs without a human in the loop. That deliberately bypasses two-person review, so scope those groups narrowly. See approval rules.
Is there an audit trail?¶
Yes — platform activity is recorded as audit events, and audit trails can be generated over a time range and downloaded. The event types and log fields are documented in the audit event reference.
Automation and CI/CD¶
Can I run signing from a build pipeline?¶
Yes, that is a primary use case. signing-tool is built for it: meaningful
exit codes, --json for parseable output, and --wait
so a pipeline can block on an approval-gated signature instead of polling by
hand. There is a worked
Jenkins pipeline example.
How do I authenticate a machine rather than a person?¶
With a service principal / client-credentials flow against your identity
provider, piping the resulting token in via -t @- so it never appears on a
command line or in the process list. See
API authentication and the
Jenkins example.
What do the exit codes mean?¶
0 success, 1 error, 2 usage or unresolvable token, 3 --wait timed out
with the request still pending (approve it and re-run), 4 the request was
rejected or failed and will never produce a payload, 130 interrupted. The
table is in Reference client usage.
How do devices get their certificates in production?¶
Through EST (RFC 7030) for automated enrollment with mutual TLS, or by issuing device certificates from a device CA.
CRA compliance¶
Does using LAAVAT make my product CRA compliant?¶
No, and treat any claim otherwise with suspicion. The Cyber Resilience Act covers your whole product and process — secure defaults, attack surface, SBOM, vulnerability handling and disclosure. LAAVAT provides the signing and identity infrastructure behind the integrity and trustworthy-update requirements. The rest is your product design and process. The Annex I mapping states plainly which requirements the platform supports and which remain yours.
When do the CRA obligations actually start?¶
The Act entered into force on 10 December 2024. The Article 14 reporting obligations apply from 11 September 2026, and the full essential requirements from 11 December 2027. Article 14 applies to products already on the EU market, not only new launches. See Key dates.
Why does secure boot matter for the CRA?¶
Because "vulnerabilities can be fixed" is only true if the device can tell a genuine update from an attacker's. Secure boot and signed updates are the mechanism that makes the update path trustworthy, which is what the remediation obligations assume exists. See Secure boot and CRA.
Getting started¶
How do we get set up?¶
Registration, identity provider integration and the initial writer and approver groups are covered in Onboarding, with an onboarding checklist to work through. Then follow the Quick start guide.
How do I install the client?¶
pip install signing-tool — it is published on PyPI with verifiable Sigstore
provenance, and Setup shows how to check that provenance
before trusting the package.
Something is not answered here¶
Contact support@laavat.io.