A store deletes its record of a credential it generated for a service — why may that service's access to the downstream system continue?
answer
- bookkeeping is not enforcement
- two places, one credential
- the accepting system decides
- drop the downstream account, not the row
- confirm by expecting a refusal
basics
~10 sDeleting the store's record removes only the store's bookkeeping. The account, role or key that credential names still exists in the downstream system, which keeps accepting it until that system itself withdraws it.
solid answer
~40 sA credential the store generated lives in two places at once: the store's record of it, and a real object — an account, a role, a key entry — inside the downstream system that honours it. Only the second one decides whether a request is accepted. Deleting the record makes the store forget the value; it sends nothing to the accepting system, so every holder of that value keeps working. Withdrawal is an action against the accepting system: drop the account, revoke the grant, remove the key entry. Stores differ in how far their reach goes — some were given a privileged identity downstream precisely so they can do it, others hold only what a person typed in and have no reach at all. Establish which you have before you call a credential dead.
go deeper
Recall that a generated credential exists twice over: as a record inside the store, and as a real account inside the system that accepts requests carrying it.
Explain that withdrawal is a call to the downstream system — drop the account, remove the grant — and that the store's record around it is bookkeeping, not enforcement.
Show how you confirm: attempt the credential and expect a refusal, then look in the accepting system's own access records for successful use after your cutoff.
Weigh what it costs to require every downstream system in the estate to expose a withdraw operation, against accepting that some credentials can only be waited out.
## Where a generated credential actually lives When a secret store **generates** a credential for a consumer rather than handing back a value a person typed in, that credential comes into existence in more than one place, and the places are not equally important. - **The store's record.** A row carrying the credential's name, its value, the identity that asked for it, when it was issued and when it stops being valid. This is bookkeeping. It lets an operator see what exists and lets the store answer questions about it. - **The object inside the accepting system.** An account, a role, a key entry, a grant — whatever the downstream system recognises when a request arrives carrying that value. This is the only thing in the picture that decides whether a request succeeds. - **The copies already handed out.** Whatever the consumer did with the value after fetching it: held it in process memory, wrote it into a rendered configuration file on the host, passed it to a connection pool. Deleting the store's record touches the first of those and nothing else. The accepting system was never told, and it goes on accepting. ## Withdrawal is an action against the accepting system **Revocation** in this material means making the system that honours a credential refuse it. That is a call to *that* system, not a state change in the store. | Action | What it changes | What still works | |---|---|---| | Delete the store's record | The store forgets the value | Every holder; the downstream object is untouched | | Mark the record revoked | The store's view of the credential | The same, except you now believe it is dead | | Drop or disable the downstream account | The accepting system refuses new authentications | Sessions and connections already established under it | | Drop it, then end what is established | Both, and you can say so | Nothing under that name, once you have confirmed it | Two neighbouring words get swapped here constantly and each swap hides a live credential. **Deleting** removes a value; **withdrawing** removes the ability to use it. **Rotating** puts a new value in place; **revoking** makes the old one stop working — a rotation that never withdrew the old value left it live alongside the new one. ## Stores differ in how far their reach goes This is a place where designs genuinely differ, and an answer that states one design as a fact about stores is wrong for whoever runs the other: - Some stores were deliberately given a **privileged identity** inside the downstream system, exactly so they can create an account on request and remove it on withdrawal. There, revocation is one call and the record and the downstream state move together. - Some stores hold only what a person put into them. They have no reach anywhere, and revoke can only ever mean forget. Every withdrawal is then a human action in another system. - Between those sits the dangerous middle: a store that attempts the downstream call and, when it fails, records the failure somewhere quieter than the revocation itself. The operator's screen says revoked and the account is still there. ## Confirming instead of assuming The work is not finished by the call that makes it; it is finished by evidence. 1. Make the withdrawal at the accepting system, using whatever operation it offers — drop, disable, remove the grant. 2. Attempt the credential yourself and expect a refusal. A refusal is evidence. A green tick on a revocation screen is a claim about the store. 3. Query the accepting system's own access records for **successful** use under that name after the moment you withdrew it. This is the signal that catches a survivor, because a credential that is still live does not generate failures — it succeeds, quietly, exactly as it always did. Watching for failed authentications will show you nothing. 4. Write down which of those three you actually did, for which credential, and at what time. An external audit later asks who could have used this name and when, and the answer has to come from the accepting system, not from your intention. ## Why the habit matters at scale One credential done carelessly is one live account. The same habit applied across an estate that mints credentials per consumer produces a population of downstream accounts that the store has forgotten and nobody owns — created by a request that is now six months old, granted rights that still work, attached to no inventory. They are found by reconciling the accepting system's account list against what the store believes it issued, and the reconciliation only works if withdrawal was ever a real event on the downstream side. If it was only ever a deleted row, the two lists never disagreed in the first place, and the survivors are invisible.
- The store shows that credential's record as removed, but nobody can reach the downstream system to check — what do you report?Report it as unconfirmed, not revoked. A removed record proves only that the store forgot the value. Until the accepting system either refuses an attempt with it or shows no successful use under that name, treat the credential as live and state the assumption in the record, so the next person does not inherit it as a fact.
- A downstream system offers only disable for an account, never delete — is that enough to call a credential withdrawn?For stopping the next authentication, usually yes, provided the disable itself is recorded so nobody re-enables it quietly. What it does not do is end anything already established under that account. The confirmation step is unchanged: look for successful use under that name after the moment you disabled it.
saying these in an interview costs you the question
- Says a credential is dead once the store's entry is gone
- Treats deleting a value as the same action as withdrawing it
- Assumes every store can reach the downstream system to drop an account
- Confirms revocation by re-reading the store rather than trying the credential
- Expects holders to notice a deleted entry and stop using their copy
- Looks for failed authentications as proof the credential stopped working