Choosing a store whose provider holds the protecting key means it never shows a locked state — what have you actually decided?
answer
- no locked state, so no consent moment
- open on demand equals open without you
- the dependency moved, it did not vanish
- you bound the claim, never prove the negative
- withdrawable key material is the middle position
basics
~20 sHanding the protecting key to a provider decides who must be present for the estate to start. It buys unattended recovery with no custody to run, and costs the ability to withhold consent or to show that only you can open the contents.
solid answer
~40 sThere is still a key protecting the contents; the decision is that somebody else holds and applies it. What you gain is real: restarts complete unattended, recovery time is not gated on finding people, and there is no custody arrangement to maintain or rehearse. What you give up is the moment of consent — no design that never locks can ever refuse to open — and with it the ability to demonstrate that nobody but you can read the contents, because the capability to open on demand is the same capability to open without you. Your availability floor also moves: if the provider cannot be reached, the store cannot open, and if the key is disabled the contents are unreadable. Middle positions exist, where the provider applies key material the customer can withdraw.
go deeper
Recall that even a store which never asks anyone to open it still has a key protecting its contents — somebody else is supplying it.
Explain what disappears along with the locked state: the moment at which opening required someone's deliberate action, and therefore anything to withhold.
Show where the dependency went — reaching the provider becomes part of opening the store, and disabling the key becomes the most consequential action in the estate.
Decide and record which party the estate's ability to start is staked on, name the evidence you require instead of a proof you cannot get, and treat withdrawable key material as the middle position it is.
## What "no locked state" means A store whose provider holds the protecting key does not present the start-up moment at all. The process comes back, the provider applies the key, and reads are served. There is still a protecting key and the contents are still ciphertext at rest — what has changed is the answer to *who supplies the input*, and therefore who must be present for the estate to start. This is the shape most teams end up with, usually without deciding it, because it is the one that never wakes anyone. It is a legitimate choice. It is worth being able to say what it commits you to. ## What it buys - **Unattended recovery, always.** Node replacement, region rebuild, scale-out and host failure all complete without a person. The recovery floor is the provider's, measured in seconds. - **No custody to run.** No parts to distribute, no holders to track as people join and leave, no rehearsal for the attended path — and no chance of the quiet failure where the parts end up together. - **No cold-start loop to design.** The failure where the input for opening the store is itself inside the store cannot arise, because you are not supplying an input. - **Fewer ways to lose it permanently.** A distributed-parts design has an ugly end state where too many parts are gone; a provider-held key removes that particular way to lose everything, and adds its own. ## What you can no longer demonstrate The uncomfortable half is a single sentence: **the capability to open on demand is the same capability to open without you.** A design that never locks has no moment at which anyone must consent, so there is nothing to withhold — not from a mistaken internal request, not from a compelled one, not from an intruder who reaches the control surface. That has concrete consequences: 1. You cannot prove the negative. "Nobody there can read our contents" is not a claim the architecture supports; the strongest honest form is "here is what bounds and records who could". 2. Your availability floor is theirs, in a new place. If the provider's key service cannot be reached, the store does not open — the dependency moved rather than vanished. 3. The most dangerous single action in the estate becomes disabling or deleting that key, which can render the contents unreadable with nothing to recombine and nobody to wake. ## The two ends, side by side | dimension | you supply the input | the provider holds the key | |---|---|---| | restart | attended or self-authenticating | always unattended | | moment of consent | exists, and can be withheld | does not exist | | can you show only you can open it | yes, structurally | no, only by evidence and bounds | | availability floor | your holders or your unwrap path | the provider's | | catastrophic loss looks like | too many parts gone | the key disabled or deleted | Neither column is the safe one. Both stake the estate's ability to start on something, and the decision is which something you would rather own. ## Where designs genuinely differ There is a real middle: some managed offerings apply key material the customer supplies or can withdraw, so the provider performs the unwrap but cannot continue once you revoke. That restores a form of consent — exercised once, in advance, rather than at each start-up — and it changes the failure story, because withdrawal is now a thing you can do and therefore a thing you can do by accident. Offerings differ in whether withdrawal takes effect immediately or is bounded by how long an already-open store keeps serving, and that interval is the question to ask, because it is precisely the window in which withdrawal has not yet happened. ## The standard to set Asking a provider for reassurance is not a control; asking for specifics is. What is the key held in, and can it leave? Which of their operations can cause it to be applied, and under what internal constraint? Are uses of it recorded somewhere your own people can see, rather than only theirs? What happens to the contents if the key is disabled, and is that reversible and for how long? None of these prove the negative — they bound it, and the bound is the deliverable. The decision to write down is not "managed or self-run". It is: for this store, is the estate's ability to start better staked on people we can wake, on a path our own nodes can authenticate to, or on a provider — and an external review will ask which of those you chose and what evidence you keep.
- Is there a middle position between holding the input yourself and handing the key over?Yes. Some managed offerings apply key material the customer supplies and can withdraw, so the provider performs the unwrap but cannot continue after revocation. Consent moves from every start-up to one standing decision. Ask how quickly withdrawal takes effect on an already-open store, because that interval is the real bound.
- What can you actually ask a provider for, given you cannot prove the negative?Specifics that bound the claim: what the key is held in and whether it can leave, which internal operations cause it to be applied and under what constraint, whether uses are recorded where your own people can see them, and what happens to the contents if the key is disabled and for how long that is reversible.
- Does a provider-held key mean the contents are less protected against a stolen disk?No — the at-rest position is the same in all three designs, and a stolen volume yields ciphertext either way. What differs is who can cause it to be opened, and that is the entire subject. Comparing the designs on encryption strength rather than on presence is the usual mistake.
saying these in an interview costs you the question
- Says a provider-held design means there is no protecting key.
- Claims managed key holding removes the start-up dependency rather than moving it.
- Argues that a stolen disk is more readable under one of these designs.
- Offers a provider's assurance statement as proof nobody there can open it.
- Ignores that disabling the key can make the contents unreadable.