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

# 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](https://docs.laavat.io/api/authentication/), and the
[`signing-tool` command-line client](https://docs.laavat.io/democlient/introduction/).

### 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](https://docs.laavat.io/usage/productguide/product/) and
[certificate profiles](https://docs.laavat.io/usage/productguide/pki/) 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](https://docs.laavat.io/usage/signing-encryption/raucsigning/),
[MCUboot](https://docs.laavat.io/usage/signing-encryption/mcuboot-signing/) and
[U-Boot FIT images](https://docs.laavat.io/usage/signing-encryption/fitsigning/);
[OCI container images](https://docs.laavat.io/exampleflows/ocisigning/);
[Windows binaries](https://docs.laavat.io/usage/signing-encryption/windows-signing/); and
[detached digest signatures](https://docs.laavat.io/exampleflows/detachedsigning/).

This is not the full list — see
[Secure boot and CRA](https://docs.laavat.io/cra-compliance/secure-boot-cra/) for a fuller picture,
and the [audit event reference](https://docs.laavat.io/appendixes/audit-events/) for the operation
names.

### My chipset is not listed. Can I still use it?

Usually yes. [Digest signing with a detached signature](https://docs.laavat.io/exampleflows/detachedsigning/)
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, ML-DSA-44/65/87 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](https://docs.laavat.io/appendixes/supported-keys/). For post-quantum signing, see
[the next question](https://docs.laavat.io/faq/#does-laavat-support-post-quantum-signing).

### Does LAAVAT support post-quantum signing?

**Yes.** ML-DSA (FIPS 204) is supported with ML-DSA-44, ML-DSA-65 and
ML-DSA-87 keys, held in the HSM like every other signing key. They can be used
for CA and end-entity certificates, for signing messages with a `DigestSigning`
operation, and (ML-DSA-65 and ML-DSA-87) as SRK keys for NXP AHAB signing with
SPSDK. See [Supported keys](https://docs.laavat.io/appendixes/supported-keys/#post-quantum-ml-dsa)
for what is supported and how it differs from RSA and EC.

The platform's model is algorithm-agnostic: keys are bound to certificate
profiles and product operations, so moving a product to ML-DSA is a new profile
and a new operation, not a new integration.

### 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](https://docs.laavat.io/usage/signing-encryption/signing-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](https://docs.laavat.io/security/).

### 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](https://docs.laavat.io/security/#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](https://docs.laavat.io/security/#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](https://docs.laavat.io/security/#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
**exportable tokens** — AES, RSA or EC keys a product holds only so that they
can be exported, with nothing signed or encrypted with them on the platform —
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.

See [Key custody and export](https://docs.laavat.io/security/#key-custody-and-export).

### Can signing keys be exported online?

**No.** The online export path is restricted to encryption keys and exportable
tokens, and neither is a signing key. The `extractable` flag is valid only on
encryption keys and the platform rejects it on a signing key, so no
configuration, not even a misconfigured template, gives a signing key an online
export path. Signing keys are recoverable only through the offline
crypto-officer ceremony.

See
[Key custody and export](https://docs.laavat.io/security/#online-encryption-keys-and-exportable-tokens).

### 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](https://docs.laavat.io/security/#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](https://docs.laavat.io/democlient/usage/).

## Access control and approvals

### Who can sign, and who approves?

Access is driven by your identity provider's groups —
[Microsoft Entra ID](https://docs.laavat.io/getting-started/onboarding/aad/) or
[Google Cloud Identity](https://docs.laavat.io/getting-started/onboarding/google/). 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](https://docs.laavat.io/usage/adminguide/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](https://docs.laavat.io/gui/approvals/image-signing/) 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](https://docs.laavat.io/usage/productguide/product/).

### Is there an audit trail?

Yes — platform activity is recorded as audit events, and
[audit trails](https://docs.laavat.io/gui/audit/trails/) can be generated over a time range and
downloaded. The event types and log fields are documented in the
[audit event reference](https://docs.laavat.io/appendixes/audit-events/).

## 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](https://docs.laavat.io/democlient/usage/), `--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](https://docs.laavat.io/isg/integration/jenkins/).

### 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](https://docs.laavat.io/api/authentication/) and the
[Jenkins example](https://docs.laavat.io/isg/integration/jenkins/).

### 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](https://docs.laavat.io/democlient/usage/).

### How do devices get their certificates in production?

Through [EST (RFC 7030)](https://docs.laavat.io/gui/est/configuration/) for automated enrollment
with mutual TLS, or by issuing
[device certificates](https://docs.laavat.io/exampleflows/devicecertificate/) from a device CA.
The full design — manufacturer and operator PKIs, an IDevID at the factory
over REST and an LDevID in the field over EST — is in
[Trusted device identities](https://docs.laavat.io/solutions/trusted-device-identities/).

## 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](https://docs.laavat.io/cra-compliance/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](https://docs.laavat.io/cra-compliance/article-14-reporting/)
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](https://docs.laavat.io/cra-compliance/).

### 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](https://docs.laavat.io/cra-compliance/secure-boot-cra/).

## Getting started

### How do we get set up?

Registration, identity provider integration and the initial writer and approver
groups are covered in
[Onboarding](https://docs.laavat.io/getting-started/onboarding/onboarding/), with an
[onboarding checklist](https://docs.laavat.io/getting-started/checklists/checklistonboarding/) to
work through. Then follow the [Quick start guide](https://docs.laavat.io/gettingstarted/).

### How do I install the client?

`pip install signing-tool` — it is published on PyPI with verifiable Sigstore
provenance, and [Setup](https://docs.laavat.io/democlient/setup/) shows how to check that provenance
before trusting the package.

### My question isn't answered here. What do I do?

Contact [support@laavat.io](mailto:support@laavat.io).