Cryptography Policy
This policy describes when and how Bunker uses cryptography to protect the data entrusted by its customers and the secrets of its platform. On the cryptographic dimension, it implements the principles of our information security policy and covers controls A.8.24, A.7.10 and A.7.14 of the Statement of Applicability.
Our controls are self-assessed, aligned with ISO/IEC 27001, not certified by a third party to date. The status of each measure below reflects that self-assessment.
Purpose and scope
This policy applies to every flow and every store within the ISMS scope (the admin console, the API, the nuage CLI, node-to-node communications, infrastructure secrets, backups and the physical media in our three datacenters).
It states what we encrypt and with what. It claims no more than that. Encryption at rest applies on the storage layer and to application secrets, which is not the same as an arrangement where Bunker would be technically unable to read the data it processes on the customer's behalf. Use cases where the customer alone holds the key belong to specific services, not to a general property of the platform.
Principles
- Encryption in transit, always: no cleartext flow over a network we do not control; HTTP is redirected to HTTPS.
- Authenticated encryption only: secrets at rest are protected by an AEAD mode; a decryption that fails authentication fails outright.
- Key and data kept apart: the master key never touches the database it protects.
- Standard primitives, never home-grown cryptography: public, battle-tested algorithms, implemented by libraries audited by their community.
- Rotation by design: every encrypted record carries its key version, so the master key can change without rewriting all data at once.
- End-of-life media is not a leak: a disk that is removed, re-used or disposed of is unusable.
Measures
| Area | Measure |
|---|---|
| External traffic | TLS everywhere, HTTP redirected to HTTPS, TLS 1.2 minimum; certificates issued and renewed automatically at the ingress (A.8.24). |
| Internal traffic | Node-to-node traffic carried over an encrypted WireGuard mesh; operational access through a WireGuard VPN (Headscale) (A.8.24). |
| Application secrets at rest | Authenticated XChaCha20-Poly1305 envelope encryption: a randomly generated data-encryption key per record, wrapped by a 256-bit master key, with a 192-bit per-record nonce and additional authenticated data for domain separation (A.8.24). |
| Key handling in memory | Keys are wiped from memory as soon as they are no longer needed (zeroization), and secrets are redacted from logs (A.8.24). |
| Infrastructure secrets | Sealed Secrets: secrets are encrypted all the way into Git and decryptable only by the controller of the target cluster (A.8.24). |
| Rotation | A key version stored with each record, enabling progressive re-wrapping when the master key changes; secret rotation when a person leaves (A.8.24). |
| Storage media | Encryption at rest on the storage layer: removed media is unusable. Secure erasure and destruction at end of life (A.7.10). |
| Equipment disposal | Cryptographic erasure (crypto-erase) then physical destruction on disposal or before re-use (A.7.14). |
| Backups | Encrypted backups, with a copy in a geographically separate datacenter (A.8.24). |
Responsibilities
- The CISO (François-Guillaume Ribreau) owns this policy, the choice of algorithms and the custody of the master key.
- The engineering team applies these measures in code and infrastructure; introducing any new cryptographic mechanism goes through merge-request review.
- The operations team performs erasure and destruction of media at end of life.
- Any suspected key compromise is reported without delay to [email protected] and triggers a rotation.
Status and roadmap
Use of cryptography, protection of storage media and secure disposal of equipment are in place and operational (A.8.24, A.7.10, A.7.14).
We spell out two limits, because they weigh on a demanding buyer's assessment. The master key is supplied by the platform configuration. We use no dedicated hardware security module (HSM) to date, and key lifecycle management is not yet formalised in a written procedure separate from this policy. Two adjacent measures also remain open. Data masking and anonymisation (A.8.11) and a data leakage prevention capability (A.8.12) are planned, not deployed. The organisation-wide retention policy remains to be formalised (A.5.33, partial).
Review
This policy is reviewed at least once a year, whenever our primitives or key management change significantly, and whenever an advisory affects an algorithm we use.
Last reviewed: 31 August 2026.
See also
- Statement of Applicability (the status of controls A.8.24, A.7.10 and A.7.14)
- Security model (where cryptography sits in our defence in depth)
- Network Security Policy (the encryption of flows and the segmentation around it)
- Backup guide (protecting and restoring customer data)
- Information Security Policy (the ISMS framework this policy derives from)