Across an estate, how long should a store keep earlier versions of a secret before destroying them?

## What history is for, and what it costs Value history exists for one everyday reason: someone writes the wrong value to the right name, and the cheapest fix in existence is to read the previous version and write it back. That is a real operational benefit and it is worth paying something for. What it costs is usually left unstated. Retained history is a readable copy of every credential that name has ever held, reachable by anyone holding the ordinary read right on it — not by an administrator, by a consumer. Multiplied across an estate, unbounded history turns the store into the most complete credential archive the organisation owns, and one that no rotation has ever cleaned out. So the question is not "is history good", it is "how long", and the answer is a number you have to be able to defend. ## The inputs that set the number - **How long a wrong write takes to be noticed.** This is the dominant input, because it is the only thing the window actually buys. If a mistaken value surfaces within a deploy cycle — minutes to hours in most estates — then a window of a few days carries a large margin already, and a quarter carries none of the benefit and all of the cost. - **Whether anything else holds the value authoritatively.** Where the correct value exists elsewhere, history is a convenience rather than the only route back, and the window can be short. - **What the name reaches.** A credential one batch job uses and a credential a whole environment authenticates with are not the same asset. The second deserves the shorter history, even though instinct reaches the other way. - **Why the value was replaced.** A scheduled replacement and a replacement forced by an exposure want opposite treatment of the old version. - **Whether the store gives you a usable retirement operation at all.** Designs differ: some let a read refuse anything below a chosen version, so a whole span retires in one move; others only enable and disable individual versions, which makes retirement per-version work; some names can be configured to keep nothing. A standard that assumes the first and runs on the second silently does nothing. ## A defensible default 1. **Retire on replacement.** After a write, earlier versions should stop being servable straight away, so a plain read is the only read that works. Undo does not need them servable — a recovery is an operation, not a read. 2. **Keep a small number of versions, for a short window.** Size it against detection time with margin, and write the assumption down: "a wrong write is noticed inside a deploy cycle, so this window is days." 3. **Destroy on a schedule, not on memory.** A retention that depends on someone remembering to clean up is not a retention, and it is the most common way an estate ends up with years of history. 4. **Tighter on the widest-reach names.** For the handful of values whose exposure would be an estate-level event, keep minimal or no history and accept that a mistaken write there is a replacement rather than an undo. 5. **Destroy explicitly after an exposure.** If the value was replaced because it got out, the exposed version should be destroyed as part of closing the incident rather than left to age out — and that is only half the job, because the credential also has to stop being accepted where it was used. ## What you standardise and what you leave alone Standardise the default, the scheduled destruction, and the requirement that a longer window be documented with a reason. Leave the exceptions to the teams who own the names, because they are the ones who know what else holds the value. Who may perform a destruction is a separate question about rights and duties, and it is decided in the access rules rather than in the retention number. ## What you must be able to answer afterwards A retention standard is only as good as the questions it lets you answer quickly: - For any name, how many earlier values are currently held, and how many are still servable. - When the oldest of them will be destroyed, and by what mechanism rather than by whom. - Which names are exceptions, and the recorded reason for each. If those three cannot be answered from the store itself, the standard exists on paper only — and the review three months after a replacement will find exactly what it always finds. ## The failure mode to name out loud The common estate-level failure is not a bad number. It is no number: history defaults inherited per name, never revisited, cheap in storage and invisible in every dashboard, until a review asks whether last quarter's password can still be fetched and the honest answer is that every password since the store was installed can.