How should teams secure data at rest without relying on encryption alone?

Why This Matters for Security Teams

Encryption at rest is necessary, but it is not a complete control. If a service account, workload identity, or automation pipeline can decrypt data, then the security boundary has shifted from storage to identity governance. That is why data protection failures so often show up as excessive permissions, exposed API keys, or weak key custody rather than broken cryptography. The NIST Cybersecurity Framework 2.0 NIST Cybersecurity Framework 2.0 treats identity, access control, and governance as core risk reducers, not optional add-ons.

NHIMG research shows the scale of the problem: Ultimate Guide to NHIs — Key Research and Survey Results reports that 97% of NHIs carry excessive privileges and 79% of organisations have experienced secrets leaks. That means storage encryption can still leave broad read, decrypt, and exfiltrate paths open to identities that should never have had them. Teams that focus only on the storage layer often miss the real control point, which is who can obtain, use, and renew the keys that unlock the data.

In practice, many security teams encounter misuse of decrypted data only after an over-permissioned identity has already moved laterally, rather than through intentional access design.

How It Works in Practice

Effective protection starts by treating encryption as a layer, not the decision point. Data should remain encrypted at rest, but access to the key material must be governed with the same rigor as access to the data itself. That usually means separating key custody from application storage, enforcing least privilege on key management operations, and reviewing which non-human identities can call decrypt functions, unwrap envelope keys, or retrieve secrets.

For modern environments, the practical pattern is to pair strong key management with NHI governance. The identity that requests decryption should be a workload identity, not a long-lived shared secret. Where possible, use short-lived credentials, scoped access, and just-in-time elevation so the identity receives only the authority needed for a specific task. This aligns with the direction of the NIST Cybersecurity Framework 2.0, which emphasizes governance and access control across the full control plane.

Practitioners should also distinguish between encryption key rotation and secret rotation. Rotating the cipher or storage layer without revoking old credentials does not reduce misuse risk. NHIMG’s guidance on NHI lifecycle control, especially in the Ultimate Guide to NHIs — Key Research and Survey Results, is useful here because the operational failure is often credential sprawl, not algorithm weakness.

• Inventory every identity that can decrypt data, including automation, CI/CD, and backup systems.
• Restrict decrypt permissions to narrowly scoped roles and separate them from read-only access.
• Use short-lived keys and credentials with automatic expiry where the platform supports it.
• Review key-use logs for unusual decrypt patterns, especially bulk access or off-hours activity.
• Revoke dormant identities and rotate secrets on a defined cadence tied to business risk.

These controls tend to break down in legacy applications that embed static secrets directly in code or configuration because key rotation and revocation cannot be enforced cleanly.

Common Variations and Edge Cases

Tighter key governance often increases operational overhead, requiring organisations to balance misuse resistance against application reliability and release velocity.

Not every environment can adopt the same model. Databases, backup systems, object storage, and SaaS integrations each expose different decrypt paths, and there is no universal standard for this yet. Current guidance suggests prioritising the identities with the broadest blast radius first, especially backup operators, CI/CD runners, and shared service accounts. In high-throughput systems, ephemeral credentials may be preferable, but they can create failures if token renewal, clock sync, or metadata services are unstable.

Another edge case is regulated retention. Long-lived encrypted archives still need periodic access review, even if the data itself rarely changes. Encryption protects the file, but not necessarily the authority to restore, export, or mount it. Teams should therefore audit who can unlock archived data, who can approve break-glass access, and whether those events are logged and reviewed. Where third-party processors or managed services hold decryption capability, the organisation should confirm contractually and technically that the vendor cannot access more data than intended.

The practical lesson is simple: if an identity can decrypt, it can usually read, copy, or transform the data. In that environment, encryption alone is only evidence of protection, not proof of control.

Related resources from NHI Mgmt Group

• How should security teams prioritize sensitive data findings without relying on volume alone?
• What do teams get wrong about encryption as a data protection strategy?
• How should security teams govern AI agent access without relying only on behavioral monitoring?
• How should security teams harden SSH without relying on port changes alone?