Why do encryption and data-at-rest protections not eliminate breach liability?

Encryption protects data content, but it does not excuse weak identity controls around who can reach the data, the keys, or adjacent systems. If the environment still permits broad internal access, regulators can conclude that technical and organisational safeguards were insufficient. Governance must cover reachability, not just confidentiality.

Why This Matters for Security Teams

Encryption reduces exposure of data content, but breach liability is usually assessed across the whole control environment: who can reach the system, who can use the keys, and whether adjacent identities are over-permissioned. If a database is encrypted yet broadly reachable by compromised service accounts, the control failure is still material. That is why NHI governance and identity hardening sit alongside data protection, not behind it.

NHIMG research shows how often identity issues turn into reportable incidents. In The 52 NHI Breaches Report, compromised non-human identities repeatedly enabled access that encryption alone did not prevent. Regulators and auditors generally look for evidence that protections were layered, monitored, and tied to least privilege. Current guidance suggests that encryption is a safeguard, not a liability shield, when access paths remain open.

That is consistent with NIST Cybersecurity Framework 2.0, which frames protection as a combination of identity, access, monitoring, and resilience controls. In practice, many security teams discover the weakness only after logs show legitimate access by a compromised identity, rather than through intentional review of reachability before the incident.

How It Works in Practice

Encryption at rest protects stored content, but it does not prevent abuse of the systems that decrypt, move, or process that content. If an attacker compromises an application identity, a CI/CD token, or a cloud role with read access, the data may still be retrievable through legitimate paths. The key question is not only whether the bits were encrypted, but whether the attacker could reach the keys, the service endpoints, or the backup and replication layers that expose decrypted material.

That is why control design needs to connect confidentiality with identity governance. A strong implementation usually includes:

• least privilege for human and non-human identities that can touch protected data
• short-lived secrets and tightly scoped key access
• separation of duties between data access, key management, and operational administration
• monitoring for unusual access patterns across databases, object stores, backups, and support tooling
• evidence that encryption keys are protected with stronger controls than the data they secure

The practical standard is evolving, but NIST SP 800-53 Rev. 5 Security and Privacy Controls is still useful for mapping how access control, audit, and cryptographic management fit together. NHIMG’s 2024 ESG Report: Managing Non-Human Identities found that 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, which shows how often the weak point is identity reachability rather than the cipher itself.

Where this breaks down most often is in cloud and SaaS environments where platform operators, automation accounts, and backup systems all have legitimate decryption paths that are difficult to separate cleanly.

Common Variations and Edge Cases

Tighter encryption and key controls often increase operational overhead, so organisations have to balance stronger assurance against developer velocity and recovery requirements. That tradeoff becomes more complex when backups, analytics pipelines, or incident response tooling need temporary access to plaintext or keys.

There is no universal standard for how much residual access is acceptable, but the current guidance suggests several common edge cases deserve special attention. Encrypting backups does not help if backup operators, support engineers, or automation agents can restore data without strong approval and monitoring. Tokenized secrets do not eliminate liability if the token service itself is overexposed. And if a compromised NHI can call internal APIs that decrypt data on demand, the breach analysis will still focus on authorization failure, not just storage protection.

This is why security teams should align encryption programs with identity reviews, key ownership, and escalation paths. The Ultimate Guide to NHIs — Key Research and Survey Results and the Schneider Electric credentials breach both reinforce the same lesson: once a valid identity is misused, encryption rarely stops the operational impact. For that reason, best practice is to treat encryption as one control in a larger reachability model, not as proof that breach liability has been removed.

Related resources from NHI Mgmt Group

• Why is it important to integrate identity and data governance?
• How should teams secure data at rest without relying on encryption alone?
• How should security and data teams govern data products across federated platforms?
• How should organisations govern libraries that download data after installation?