Data at rest is information stored on disks, databases, backups, or object storage when it is not actively moving through a network or application flow. Protection usually relies on encryption, access restrictions, and strong key handling so stored information is not readable if the storage layer is exposed.
Expanded Definition
Data at rest is stored information that is not actively traversing a network or being processed in memory, including records in databases, snapshots, archives, object storage, endpoints, and backup media. In NHI security, the term matters because service account tokens, API keys, certificates, and cached secrets often live alongside the data they protect. Protection is typically built from layered controls: encryption, access restriction, tokenization where appropriate, and careful key management. NIST treats this as part of broader data protection and access governance in the NIST Cybersecurity Framework 2.0, but no single standard fully resolves every storage scenario across cloud, SaaS, and distributed systems.
Definitions vary across vendors when backups, replicas, and object versions are included, so practitioners should treat “at rest” as a storage-state control boundary rather than a file-type label. The distinction is important because a secret can be “at rest” even when it is immediately usable by an application, such as an API key in a configuration store or a certificate in a vault. The most common misapplication is assuming encryption alone is sufficient, which occurs when stored credentials remain broadly retrievable through over-permissive access paths.
Examples and Use Cases
Implementing data-at-rest protection rigorously often introduces recovery and operations friction, requiring organisations to weigh confidentiality against backup restore speed, key rotation complexity, and application compatibility.
- Database encryption protects customer records and embedded service credentials if a storage volume or snapshot is exposed.
- Object storage policies limit who can read archived logs that may contain API keys, session tokens, or connector secrets.
- Backup encryption and segregated key access reduce the blast radius when offline copies are stolen or misrouted.
- Vault-backed secret storage keeps long-lived credentials out of source code and local config files, aligning with guidance in the Ultimate Guide to NHIs — Key Research and Survey Results.
- Cloud snapshot controls and lifecycle rules prevent old replicas from becoming forgotten repositories of sensitive operational data.
In practice, teams often pair these controls with identity-aware access rules and external guidance such as the NIST Cybersecurity Framework 2.0 to reduce exposure from both storage compromise and credential misuse.
Why It Matters in NHI Security
Data at rest is where NHI failures often become durable. If a service account secret, private key, or token is stored insecurely, the exposure can persist across backups, replicas, and exports, making a single mistake repeatable across environments. NHIMG research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs — Key Research and Survey Results. That pattern turns “at rest” into a governance problem, not just an encryption problem.
For NHI programs, the real issue is whether stored data can be read, copied, or replayed by an identity that should not have standing access. This is why key custody, secret segregation, backup access reviews, and database permission hygiene must be governed together. Without that linkage, encrypted storage can still leak operational control through overly broad roles or forgotten replicas. Organisaties typically encounter the consequences only after a snapshot leak, backup restore test, or misconfigured storage bucket exposes credentials, at which point data 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 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers improper secret storage and exposure in repositories, backups, and storage systems. |
| NIST CSF 2.0 | PR.DS | Data security controls explicitly address protecting stored information and backups. |
| NIST SP 800-63 | Supports assurance around credential handling, though it does not define data-at-rest storage directly. |
Treat stored NHI credentials as high-assurance assets and protect them with strong retrieval controls.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
