A storage control that protects secrets while they sit on disk or in a file. It reduces casual disclosure, but it does not guarantee that only the original actor can request decryption, so it must be paired with runtime scoping and identity-aware access rules.
Expanded Definition
Encrypted at rest means the secret, token, certificate, or key material is protected while stored on disk, in object storage, in a database, or in a file system snapshot. In NHI security, it is a storage-layer safeguard, not an identity control. That distinction matters because a file can be encrypted and still be broadly readable by a process, backup job, or operator with the right decryption path. The control is therefore useful for limiting casual exposure, data theft from stolen media, and opportunistic discovery, but it does not by itself answer who can request decryption at runtime.
Definitions vary across vendors when encryption is bundled with key management, vaulting, or access policy, so the term should be read narrowly unless the implementation explicitly states otherwise. In practice, encrypted-at-rest controls are strongest when paired with runtime scoping, short-lived credentials, and identity-aware authorization. For NHIs, that means the storage layer protects the artifact, while the surrounding control plane governs whether an agent, service account, or automation job can actually use it. The most common misapplication is treating encrypted storage as a substitute for access control, which occurs when teams assume disk protection alone prevents unauthorized secret use.
Examples and Use Cases
Implementing encrypted-at-rest rigorously often introduces operational overhead, because teams must manage keys, rotate them safely, and ensure recovery paths remain available, requiring organisations to weigh stronger storage protection against added administrative complexity.
- A CI/CD system stores API keys in an encrypted secrets store rather than in plain files, reducing exposure if a build artifact is copied.
- A database column containing an NHI token reference is encrypted at rest so that a backup file does not reveal usable credentials if exported.
- An operator follows the guidance in Ultimate Guide to NHIs to separate storage protection from rotation, revocation, and visibility controls.
- A platform uses the NIST Cybersecurity Framework 2.0 to align encrypted storage with broader protection and recovery practices.
- A cloud workload keeps certificates encrypted on disk, but a workload identity policy still determines which service can decrypt and use them at runtime.
These use cases are especially important when secrets move through backups, snapshots, or replicated storage, because encryption can limit what an attacker learns from copied data even when a live system remains compromised.
Why It Matters in NHI Security
Encrypted-at-rest controls matter because NHI compromise often begins with exposed storage rather than a direct attack on the live workload. NHIMG reports that 96% of organisations store secrets outside of secrets managers in vulnerable locations, and 79% have experienced secrets leaks, with 77% of those incidents causing tangible damage, from the Ultimate Guide to NHIs. Encryption at rest can reduce the blast radius of those failures, but only when paired with meaningful key governance and access scoping. Otherwise, the protected file is still available to any process or administrator that can trigger decryption.
For NHI governance, the key question is not whether data is encrypted, but whether the right entity can decrypt it only when needed. That is why storage encryption must be assessed alongside key custody, secret rotation, vault configuration, and runtime identity checks. It also supports broader resilience objectives reflected in the NIST Cybersecurity Framework 2.0, especially where recovery from compromise depends on limiting the value of stolen backups or exported files. Organisations typically encounter the full operational cost of this control only after a backup, snapshot, or config store is exposed, at which point encrypted at rest becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Encrypted storage supports safer secret handling, but OWASP-NHI still requires access and rotation controls. |
| NIST CSF 2.0 | PR.DS | NIST CSF addresses data protection measures that include encryption for stored information. |
| NIST SP 800-63 | Digital identity guidance informs how stored credentials are safeguarded, though it is not encryption-specific. | |
| NIST Zero Trust (SP 800-207) | Zero Trust requires verification of access requests beyond storage protection. | |
| OWASP Agentic AI Top 10 | Agentic systems need protected secret storage, but runtime tool access must still be tightly governed. |
Treat encrypted-at-rest as supporting control and still enforce strong authenticator handling and lifecycle rules.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
