The advice to wipe a secret "promptly after use" assumes there is an after. What do you do about a decrypted signing key that every request needs for the lifetime of the process, and how should the handling rules differ between a secret held for milliseconds, one held for a session, and one held for the life of the process?

## The assumption hiding in "wipe promptly" Memory-hygiene advice is written for a value that is used and then finished with. Plenty of real secrets are not like that. A signing key, a database credential, a decryption key for stored data — these are needed on every request, so the plaintext must be resident for as long as the service runs. Applying "wipe after use" to them produces either theatre (wipe and immediately re-derive) or a false sense of completion. The fix is to classify by lifetime first, then choose controls, because *the effective control is a function of the class*. ## Class 1 — transient (microseconds to milliseconds) Examples: the submitted password during authentication; a card number during a single transform; a decrypted field being reformatted for a response. Here the entire risk is a copy still lying around when something later takes a memory snapshot, so residency reduction is exactly the right lever: - keep it in a wipeable buffer end-to-end and avoid the conversion to an immutable string, which creates a copy you cannot erase; - never store it in a field, a request-scoped context object, a cache, an audit record or an exception payload; - stream it into the consuming operation rather than materialising the whole value where possible; - wipe as soon as the operation returns, including on the error path — a `finally`-shaped guarantee, since exceptions are exactly when dumps get taken. This is the class where the classic advice is fully load-bearing. ## Class 2 — scoped (seconds to hours) Examples: a decrypted document held while a user edits it; a token cached for the duration of an outbound call chain; a session-bound derived key. The risk shifts from "a copy lingered" to "the scope is larger and fuzzier than intended." Controls: - make the scope explicit and mechanical — an object with a defined close, a request-bound holder cleared at the end of the request — rather than relying on a variable falling out of use; - keep the value out of anything whose lifetime is set elsewhere: a cache with its own eviction policy, a session store, a thread-local that outlives the task on a pooled thread, an asynchronous continuation that may retain it long after the request finished; - decide the maximum dwell time deliberately and treat cache TTL as a security parameter, not a performance one; - prefer holding a *reference* that can be re-resolved over holding the plaintext across an await boundary. The subtle failure here is retention by accident: pooled threads, memoisation, and captured closures quietly promote a scoped secret into a process-lifetime one. ## Class 3 — process-lifetime (indefinite) Examples: a private signing key, a database password, a data-encryption key. Residency is a requirement, so residency-reduction controls have nothing to do. Four substitutions: **Delegate the operation instead of holding the key.** The strongest move, and the same structural-separation rung that tops every ladder in this area: if a keystore, a hardware security module, an enclave or a dedicated signing service performs the operation, the application holds a *handle* — an identifier plus permission to invoke — and never possesses the key. A memory dump of the application then yields nothing that survives revocation of that handle. Costs are real: a network or device round trip per operation, availability coupling, and throughput limits. **Shorten the credential rather than the residency.** If you cannot avoid holding the material, hold material that expires: a short-lived, automatically renewed credential turns a memory capture from a permanent compromise into a bounded one. This is the same instinct as short-lived tokens elsewhere, applied to the in-memory copy — you cannot reduce dwell time, so reduce the value's usefulness after capture. **Harden the container.** Since the exposure now depends entirely on who can read this process, the controls are environmental: disable core dumps and mark the process non-dumpable, disable or restrict automatic heap dumps, restrict debugger and tracing attachment, keep memory-capturing profiling agents outside the production boundary, encrypt or disable swap on those hosts, and treat host snapshots as sensitive artefacts. **Isolate and minimise.** Keep the key in the smallest possible process with the smallest possible attack surface, rather than inside the large application that also parses untrusted input. A memory-disclosure bug in a request parser is much more likely than one in a fifty-line signing helper, and the split means the two do not share an address space. ## The classification is the deliverable What an interviewer is really testing is whether you apply rules mechanically or diagnose first. A strong answer says: I would inventory each secret the service holds, assign it a lifetime class and a required residency, and note for each what the *actual* bounding control is — wiping for transient, explicit scope for scoped, delegation and short validity for process-lifetime. That inventory also exposes accidental promotion, which is the most common real defect: a transient secret that ended up in a cache, or a scoped one captured by a pooled thread, is now a process-lifetime secret with none of the process-lifetime controls applied. ## Answering the question Say directly that wiping presupposes an "after" and that a process-lifetime key has none. Give the three classes with their distinct controls. For the signing key, lead with delegation to a keystore or hardware module so the process holds a handle rather than a key, then short-lived material, then dump and debugger restrictions, then isolation into a small process. Close on accidental promotion between classes as the defect to look for in review.