Key Custody Modes

Understand SecuriTLS managed, Satellite encrypted, and HSM-backed private key custody, along with BYOK and certificate-only workflows.

Custody models

Model Where the key is generated What SecuriTLS stores
SecuriTLS managed SecuriTLS Encrypted private-key material
Satellite encrypted Satellite Satellite-encrypted private-key blob
HSM-backed Configured HSM provider HSM key reference

SecuriTLS custody

In the default model, private key material is encrypted before being written to a storage provider. SecuriTLS manages the wrapping keys required to use the storage DEK.

This model is simple to operate and supports certificate generation, renewal, rekey, deployment, and private key recovery workflows inside SecuriTLS.

Storage encryption BYOK

Business and Enterprise customers can configure AWS KMS so that the SecuriTLS generated storage DEK is wrapped by a customer controlled KMS key.

This improves control over encrypted assets at rest, but it is not the same as private key self custody. SecuriTLS may still use the unwrapped DEK to read encrypted private key material when performing platform managed workflows.

Satellite encrypted custody

With Satellite-encrypted custody, the private key is generated by the Satellite and encrypted inside the customer environment. The encrypted key blob can then be stored by SecuriTLS without SecuriTLS receiving the plaintext private key.

The Satellite's encryption configuration determines how this key material is protected. Supported configurations include local encryption, AWS KMS, Azure Key Vault, Google Cloud KMS, and HashiCorp Vault.

HSM-backed custody

HSM-backed custody uses a private key that remains under control of the configured HSM provider. SecuriTLS stores a key reference rather than private-key material, and the Satellite requests cryptographic operations such as signing when the key is needed.

HSM-backed private keys cannot be downloaded or deployed as private-key files because the private key does not leave the HSM-backed custody boundary.

CSR based workflows

When a certificate key is controlled by a Satellite, the Satellite can generate a CSR that contains the public key and requested subject information. A signing CA or signing Satellite can then issue the certificate from that CSR without receiving the subject private key.

This supports cross environment workflows where one Satellite controls the certificate key and another Satellite controls the signing CA key.

Certificate only imports

Imported X.509 certificates can be managed without importing a private key. In this mode, SecuriTLS can track inventory, expiration, issuer metadata, SANs, deployment status, CRLs, and alerts.

Certificate-only imports cannot deploy private keys, create combined key and certificate files, or renew using the same private key unless private key custody is later established through a supported custody model.

Satellite custody imports

If a customer already has a matching private key inside a Satellite environment, the Satellite can prove custody by generating a CSR from that key. SecuriTLS can compare the CSR public key to the imported certificate public key.

If the keys match, the certificate can be marked as Satellite custody without SecuriTLS ever receiving the plaintext private key.