Key management FAQ

A key management service creates, stores and uses cryptographic keys on your behalf. The defining property is that key material does not leave it: you send data to be encrypted or decrypted rather than fetching the key. That boundary is the whole point — a key that never leaves cannot be copied off a compromised server.

A KMS handles cryptographic keys and performs operations with them. A secrets manager stores arbitrary strings — database passwords, API tokens — and hands them to applications that need them. Most organisations need both, and most confusion in this category comes from tools that do some of each without saying which they are.

Encrypt your data with a locally generated data key, then encrypt that data key with a key held in the KMS and store the result alongside the data. You get one small KMS call rather than sending gigabytes through the service, and revoking the KMS key makes every data key it wrapped useless at once.

Bring your own key: you generate key material and import it into the provider, which then holds it. Hold your own key: the key never enters the provider at all — it stays in your system and the provider calls out to you for every operation. BYOK is about provenance, HYOK is about control, and only HYOK lets you technically deny the cloud access. Google’s External Key Manager and Fortanix are the practical routes to it.

If a key’s compromise would be materially serious, or a regulator names FIPS 140-3, yes. An HSM is hardware built so key material cannot be extracted even by someone with administrative access. The cloud KMS services are already HSM-backed at their higher tiers, so for most teams this is a tier choice rather than a procurement project.

No. Vault moved to the Business Source License 1.1 in August 2023, which is not an OSI-approved open source licence — it restricts offering a competing hosted service. HashiCorp is now part of IBM. OpenBao is the community fork made from the last MPL-licensed release and is governed by the Linux Foundation, and it is the usual answer for teams that need a genuinely open licence.

Cloud KMS is cheaper, simpler and already integrated with everything you run there — for a single-cloud estate it is usually right. A neutral platform earns its cost when you are genuinely multi-cloud, when the same policy must apply everywhere, or when your threat model includes the cloud provider itself. Be honest about which of those is true before paying for the abstraction.

Automatically, and often enough that rotation is boring. All three cloud services rotate on a schedule for you. The harder problem is data encrypted under old key versions: keep old versions available for decryption, and re-encrypt on read or in a background pass. A rotation policy nobody has tested against real ciphertext is a plan, not a control.