A four-year database credential was copied six months ago and used; what does shortening its validity now not undo?

The argument for short-lived credentials is sound, and the moment it gets overstated it becomes actively misleading. A shorter validity period is a statement about the **future acceptance of a value**, and nothing else. Reading it as containment of a leak that already happened produces the most common bad outcome in this material: a team changes a number, records the issue as handled, and leaves everything the attacker actually got exactly where it is. ## What expiry is an action against Three different things get described as "changing the credential", and only one of them is expiry: - **Expiry** — the value stops being accepted by itself, at a time fixed when it was issued. Nobody has to act, and nobody has to know. - **Withdrawal** — someone acts against the system that honours the credential so that the old value stops working now, before its own expiry. - **Replacement** — a new value is put in place. The old one keeps working until it is withdrawn or reaches its own expiry. A shorter configured validity changes the first of those, for values issued from now on. It is not an incident action, and it is not withdrawal. ## The three survivors | what happened during the six months | does the shorter validity reach it? | |---|---| | a table read out and copied away | no — the read already succeeded | | a second credential minted using the first | no — it has its own life and holder | | an account or rule created downstream | no — it must be withdrawn on its own | | the copy already deployed, stamped with four years | no — it keeps the expiry it was issued with | | a copy that escapes tomorrow, issued under the new number | yes — inert after an hour | The first row is the one candidates concede easily. The second and third are the ones that decide how an incident actually goes: an attacker holding a credential for six months rarely keeps using that credential. The useful move is to convert it into access that does not depend on the original value at all — a new account, an added rule, another credential minted from it. Every one of those is a separate object with a separate holder, and the original value expiring leaves all of them running. The fourth row is the mechanical one and the one most often got wrong out loud. Where a credential carries its expiry stamped on it at issue, the value already deployed is unaffected by a change to the configured validity: it keeps four years. Designs differ here — some systems decide acceptance against a stored record and can be made to re-evaluate, others honour only what was stamped at issue — so the safe statement in an interview is that a configured change binds the next issuance, and if you need the existing value to stop working, withdraw it. ## Why this matters for the argument about the number The honest case for shortening survives all of this intact, because the case was never that expiry repairs anything: 1. It bounds the exposure you will **not** detect, by ending copies nobody found. 2. It shrinks the value of every later copy of the same value, without anyone doing anything. 3. It changes nothing about a window that has already been used, which is why it is a control and not a remedy. Stating it that way also makes the *next* decision visible. If a credential that has been out for six months is the problem, the actions in play are withdrawal and replacement, in an order someone has to choose and pay for; a shorter lifetime for whatever is issued afterwards is a good change that does not belong in the same sentence. Teams that blur the two end up reporting an exposure as contained on the strength of a setting, and the accounts the attacker created are still there a year later. One more overstatement to avoid: "a short lifetime bounds the cost of the leak". It bounds the **time the value is accepted**, not the cost. A one-hour credential used in its second minute to pull a customer table cost the entire table. What shortening removes is the long tail — the same copy still working next year, found by someone else entirely.