External Key Store

A public-sector tenant is served from an in-country region, staffed locally, with customer-managed keys and a contract forbidding foreign access. The team calls it sovereign. Customer-managed keys inside the provider's own key service still means the provider's software performs the unwrap, so an order served on the provider can produce plaintext without anyone in the jurisdiction being involved.

An external key store moves that one function out. The data keys that encrypt records stay where they are; the master key that unwraps them lives in a key manager operated by the customer or by a separate in-jurisdiction entity. Every unwrap is an outbound call, and refusing it is an act performed by a system the provider cannot reach.

The pattern is sold as a sovereignty control and is better understood as a deliberate availability trade made in exchange for a revocation guarantee.

Why it matters

Sovereignty requirements arrive in three strengths that customers rarely distinguish: residency, meaning the bytes sit in-country; operational sovereignty, meaning only people in the jurisdiction can act; and jurisdictional immunity, meaning no foreign authority can compel disclosure. Residency is a deployment target. Immunity is not purchasable from a global provider by contract alone.

An external key store is the only widely available control that changes the answer to "what could a foreign order produce today". Without it the answer includes the data; with it, the answer for data at rest is ciphertext plus a request the key store can decline.

Implementation patterns

• Envelope encryption with the master key outside. Records are encrypted with data keys; data keys are wrapped by a master key held in the external store. The provider's service calls out to unwrap.
• A data-key cache with an explicit TTL. Without caching, every read pays a network round trip. With it, the TTL becomes the single most consequential parameter in the design.
• In-jurisdiction hosting for the key store and its own high availability, because it is now on the critical path of every read. Three nodes across three failure domains is the floor.
• A revocation runbook with a measured effect time, stated as "access ends within one TTL" rather than "immediately".
• Audit at the key store, not only at the application. Unwrap requests are the record of who read what, and they are the one log the provider cannot alter.

Industry example

Sovereign cloud offerings in Europe are commonly assembled from three parts, all of them in production today: an in-country region, locally incorporated operations, and customer-held key material through an external key manager. The interesting detail for architects is that the first two are procurement decisions and the third is an architecture decision with a latency and availability bill, which is why it is the part most often dropped during delivery.

Failure scenarios

• Key-store outage becomes a data outage. Once cached data keys expire, reads fail. A 5-minute TTL means the platform tolerates a 5-minute key-store incident and no more.
• The TTL set for performance and quoted for security. Operations picks 8 hours to cut latency; the compliance document says revocation is immediate. Both statements live in different documents for years.
• Sovereignty claimed while the control plane stays foreign. The deployment pipeline ships code that runs inside the region and reads plaintext after the unwrap, so the key store protects data at rest and nothing else.
• Backups encrypted with a different key hierarchy, so the restore path bypasses the control entirely.

Trade-offs

The TTL is one dial for two opposite goods. Short means fast revocation and a fragile platform; long means a resilient platform and a revocation promise measured in hours. Pick it from the promise you intend to make.

When not to use it

If the obligation in writing is residency only, this is an external dependency bought for a requirement nobody set, and it will cause an outage before it prevents a disclosure. The same applies where the data is not sensitive enough to justify a read-path dependency, or where the organisation cannot staff a key store to the availability the platform needs. Get the obligation classified as residency, operational sovereignty or immunity, in writing, before any of this is designed. Teams routinely spend a year answering the strongest reading of a requirement whose author meant the weakest.

Interview question

Q: You are asked to make a system sovereign for a government tenant. You have an in-country region and a contract. What do you build first, what does it cost, and what would you refuse to claim?

What a strong answer covers: external key custody first because it changes what a foreign order can produce; the TTL as the dial between availability and revocation speed, sized from the promise; the control plane, identity provider and telemetry backend as the next three paths, because data at rest is only one of four ways out; and a refusal to present the contract clause as a control, since it is a remedy after disclosure rather than a mechanism preventing one.

Quick check

Quiz: Your external key store is unreachable for 20 minutes and the data-key TTL is 5 minutes. What does the platform do? It serves normally for about 5 minutes on cached keys and then fails reads for the remaining 15, because there is no path to unwrap a data key.

Flashcard: What single parameter sets both the outage tolerance and the revocation speed of an external key store design? The data-key cache TTL: grace during a key-store failure and residual access after revocation are the same number.