Your database is encrypted. The sales rep mentions "integrated KMS." Then an incident: who decrypted the test backup at 2 a.m.? Nobody knows — KMS logs are not exported, host admin access is not correlated, and the contract only says "encryption enabled."
A Key Management Service is not just another technical option. It is where verifiable separation plays out between whoever stores data and whoever can read it. Well designed, it produces evidence. Poorly designed, it adds jargon without changing the trust model.
Architecture: where keys and data live
The principle is simple: encrypted data stays on disk or object storage; master keys live elsewhere, in a dedicated service with strict access policies.
In practice, three patterns recur among European hosts:
Native cloud KMS. One key per project, region, or resource. Automatic rotation possible. Decrypt calls are logged — if you have access to the logs.
External KMS or customer HSM. You supply the key; the host stores only references (envelope encryption). Stronger control, higher complexity on availability.
Shared KMS without IAM isolation. Multiple customers share an instance; keys are logically separated but platform admins remain powerful. Must be documented explicitly.
| Element | Question to ask | Healthy signal |
|---|---|---|
| Key scope | One key per environment? | Prod / staging / backup separated |
| Rotation | Automatic or manual? | Dated policy + post-rotation test |
| KMS logs | Exportable to SIEM? | Retention ≥ audit window |
| Break-glass | Emergency procedure? | Written, tested, traced |
Separating keys and data is useless if the same admin account can touch both.
IAM and separation of duties
KMS rarely fails on the algorithm. It fails on who can call which API.
Verify that nobody at the host — or on your side — unchecked combines:
- key creation / deletion ;
- decryption of production data ;
- deletion of key usage logs.
Least privilege applies to KMS as it does to servers. Ideally: two people for destructive operations, alerts on mass Decrypt, correlation with incident tickets.
For an ISO audit or customer questionnaire, show an anonymized log excerpt proving key access matches a documented change — not a verbal promise.
Common project mistakes
One key for everything. Production, backups, and analytics share the same master key. One leak or revocation paralyzes all.
Rotation without restore test. The key rotates; old backups become unreadable for lack of version documentation.
KMS in one region, data in another. Latency, compliance, and availability diverge. Cross-region copies sometimes replicate keys without the DPO knowing.
Total dependency on host KMS at exit. Without key export or transition period, reversibility becomes a one-sided lever.
Each mistake is fixed by mapping: which resource uses which key, who can revoke it, how long logs are kept.
The climax: KMS does not replace the contract
Here is what "cloud security" slides gloss over.
The peak of the analysis: require proof of separation, not an acronym. In a crisis meeting, you must know who can cut key access within an hour — and whether that person is on your side or theirs.
Decide and move forward without blind spots
List encrypted resources (databases, buckets, volumes, backups). For each, note key ID, KMS region, IAM owner, and rotation frequency.
Ask two shortlisted hosts: KMS log export for 30 days, rotation policy, revocation scenario. Cross-check with our compare tool and the encryption at rest guide to align keys and data.
Test rotation on staging, then restore an dated archive. Without that test, KMS policy stays theoretical.
Frequently asked questions
What is a KMS in a hosting context?
A Key Management Service centralizes creation, storage, rotation, and audit of encryption key usage. It logically separates keys from encrypted data — provided access rights are properly isolated.
Provider-managed KMS or external KMS?
The host's native KMS simplifies integration but often shares the same operational perimeter. An external KMS strengthens independence if you manage availability and latency.
How do you prove a key was not misused?
Through API call logs correlated to IAM identities, with sufficient retention and read access limited to your security team or auditor.
What happens if the KMS is unavailable?
Dependent services may fail to start or read data. Document high availability, backup keys, and break-glass procedures.
A KMS is only worth what your logs and rights let you prove — not what the product sheet promises.