Topic starter
06/11/2026 6:55 pm
TL;DR: Encrypted data still depends on plaintext keys that appear in memory, dumps and build runners, according to Anjuna's analysis of key custody. Practitioners have to govern where keys become cleartext, because vaulting alone does not remove that exposure window.
Editorial analysis by NHI Mgmt Group, based on content published by Anjuna: “Where Should I Put My Keys?”.
Key questions
Q: Why do vaults still leave encryption keys exposed at runtime?
A: Vaults still leave encryption keys exposed at runtime because an application must decrypt or unwrap them in memory to use them for TLS, file encryption, or signing.
Q: How does attested computing protect sensitive key use?
A: Attested computing protects sensitive key use by proving to a trust service that code is running inside a specific measured hardware or enclave state before secrets are released.
Q: How do teams reduce plaintext key exposure in memory?
A: Teams reduce plaintext key exposure in memory by avoiding long-lived secrets in application processes, using hardware-backed keystores or HSMs, and loading credentials only for the shortest possible runtime.
Practitioner guidance
- Map every plaintext key exposure point Inventory where signing and encryption keys become cleartext in memory, dumps, runners, containers, and hardware-mediated workflows, then assign an owner to each exposure point.
- Harden build and CI secret handling Use short-lived credentials, isolate runners, and ensure crash dumps, logs, and workspace artifacts cannot retain decryptable material after a job ends.
- Move high-value key use into attested execution For sensitive workloads, require measured execution paths that keep plaintext out of the host OS and hypervisor, then verify attestation freshness before release.
Bottom line: The article's core warning is that encryption fails operationally when keys become plaintext inside environments attackers can inspect.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:56 pm
Key custody has become a runtime governance problem, not a storage problem. The article's central point is that encryption succeeds mathematically while operational custody fails at the moment of use. That shifts the control objective from protecting files and vaults to controlling where plaintext appears, how long it exists, and which systems are allowed to observe it. For identity and NHI programmes, that means the governing unit is the credential's live exposure window, not the storage location.
A few things that frame the scale:
- Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
A question worth separating out:
Q: What should teams do first after a key appears in a dump?
A: After a key appears in a dump, teams should treat it as compromised, revoke or disable it, rotate every dependent secret, and search for where it was used. They should also scope the blast radius by checking logs, replacing certificates or tokens, and removing the secret from memory, crash artefacts, and any replicated backups.
👉 Read our full editorial: Key custody fails when attackers can search live memory