Because encryption protects data states, not who can reach the data or how that access is managed over time. If access is broad, persistent, or weakly reviewed, an attacker or insider can still misuse legitimate access even when the data is encrypted.
Why This Matters for Security Teams
Encryption is valuable, but it is not an identity control. It protects confidentiality when data is stored or transmitted, yet it does not decide who may use the data, what an authenticated principal can do next, or whether access should still be valid months later. That gap is where identity governance risk accumulates: excessive privileges, stale secrets, weak offboarding, and long-lived service accounts.
NHIMG research shows the scale of the problem. In the Ultimate Guide to NHIs, only 5.7% of organisations report full visibility into their service accounts, while 97% of NHIs carry excessive privileges. Even strong encryption does nothing when an authorised identity is misused, over-permissioned, or never rotated. That is why guidance from the NIST Cybersecurity Framework 2.0 treats access governance as a separate discipline from data protection.
Security teams often discover this the hard way, after an encrypted datastore is accessed through a valid account that no one had reviewed in years.
How It Works in Practice
A practical governance model separates data protection from identity control. Encryption still matters, but it needs to sit alongside least privilege, credential lifecycle management, and continuous review. The goal is to reduce the time a credential can be abused and to limit what an identity can do if it is compromised.
For NHIs, the first control is inventory. Teams need to know which service accounts, API keys, certificates, and tokens exist, where they are used, and which systems depend on them. The Ultimate Guide to NHIs highlights why this is foundational: if identities cannot be found, they cannot be governed. From there, governance should enforce short-lived secrets where possible, rotation for long-lived credentials, and explicit approval for privileged access.
- Use encryption to protect data in transit and at rest.
- Use identity controls to decide who can decrypt, query, export, or administer that data.
- Apply role-based access only where roles are stable; otherwise use context-aware review and just-in-time elevation.
- Revoke or rotate secrets when ownership changes, systems are retired, or access is no longer needed.
Current guidance suggests pairing encryption with logging, entitlement review, and automated expiration so that a credential’s lifetime matches its business purpose. This aligns with the Top 10 NHI Issues, which emphasizes lifecycle and visibility as primary controls. These controls tend to break down in cloud-native and CI/CD environments because secrets are copied into pipelines, configs, and automation jobs faster than teams can review them.
Common Variations and Edge Cases
Tighter encryption often increases operational overhead, requiring organisations to balance stronger data protection against faster, more reliable access governance. That tradeoff is especially visible in environments where many systems need machine-to-machine access, because encryption by itself can make data harder to expose without reducing the blast radius of a compromised identity.
There is no universal standard for when encryption should be accompanied by hardware-backed key custody, per-request approval, or separate administrative roles, but best practice is evolving toward segmented trust boundaries. Highly regulated workloads may require both strong encryption and strict key management, while internal analytics platforms may rely more heavily on entitlement review and short-lived tokens than on manual approval.
Edge cases also matter. Backups, archives, and replicated data may remain encrypted for years, yet the real risk lives in the keys and the identities that can retrieve them. Similarly, third-party integrations often inherit access through shared API keys, so the governance problem is not the cipher but the standing privilege attached to the integration. In those cases, the right question is not whether the data is encrypted, but whether the identity that can reach it is still legitimate and necessary.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers secret rotation and lifecycle risk that encryption does not solve. |
| NIST CSF 2.0 | PR.AC-4 | Access management must govern who can use encrypted data after authentication. |
| NIST AI RMF | AI governance needs controls beyond data encryption when autonomous actors access systems. |
Review entitlements continuously and restrict decrypt-capable access to least privilege.
