Why does encryption at rest not fully solve NHI risk?

Because the decisive failure often happens after the attacker reaches privileged execution. If they can read memory or run code as root, they can still use the identity while it is live. Encryption helps against disk theft and low-effort copying, but it does not protect a compromised runtime.

Why This Matters for Security Teams

Encryption at rest is necessary, but it protects storage media, not a live non-human identity in use. Once an attacker gains privileged execution, reads process memory, or abuses a running workload, encrypted disks do nothing to stop token reuse, key extraction, or API calls made with the victim identity. That is why NHI risk is fundamentally a runtime and governance problem, not just a data-at-rest problem.

NHIs are already a material exposure area in most environments. NHI Mgmt Group notes that Ultimate Guide to NHIs reports 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. That finding aligns with the broader pattern documented in 52 NHI Breaches Analysis: the failure often appears after credentials are already active, not when they are merely stored. NIST’s Cybersecurity Framework 2.0 reinforces the need to manage identity, access, and continuous monitoring as operational controls, not one-time storage protections.

In practice, many security teams encounter NHI abuse only after a compromised container, CI job, or host has already used the identity to move laterally.

How It Works in Practice

Effective NHI protection starts by treating the credential as only one layer in a broader control set. Encryption at rest helps protect vaults, databases, and files from offline theft, but it does not stop an attacker who can execute code in the runtime where the NHI is loaded. That is why current guidance increasingly favors short-lived secrets, JIT credential issuance, workload identity, and policy checks at request time.

A practical control stack usually includes:

• Workload identity for the agent or service, so the system can verify what is making the request, not just what secret it presents.
• Ephemeral secrets with tight TTLs, so stolen values expire quickly and reduce replay value.
• Runtime authorization, where access is evaluated at the moment of use rather than granted broadly in advance.
• Rotation and revocation workflows that remove live access when a workload changes state or is terminated.
• Monitoring for abnormal use, because the same identity may behave differently across deployment, test, and production.

This is consistent with the broader NHI governance guidance in Top 10 NHI Issues, which highlights excessive privilege, poor rotation, and weak visibility as recurring failure modes. For implementation, the important distinction is between protecting where secrets are stored and controlling where they can be used. That distinction is also reflected in the CISA identity management best practices, which emphasise least privilege, lifecycle control, and continuous review.

These controls tend to break down when long-lived credentials are embedded in CI/CD pipelines or container images because the secret outlives the runtime and can be replayed elsewhere.

Common Variations and Edge Cases

Tighter secret controls often increase operational overhead, requiring organisations to balance faster developer workflows against stronger runtime containment. That tradeoff is real, especially in legacy systems, batch jobs, and third-party integrations where full workload identity is not yet available.

There is no universal standard for this yet, but current guidance suggests different environments need different emphasis. In static infrastructure, encryption at rest and vault hardening still matter because they reduce exposure from storage compromise. In dynamic platforms, however, the more important question is whether an attacker can use the identity after initial access. In those cases, JIT access, per-task tokens, and request-time policy enforcement provide better risk reduction than relying on disk encryption alone.

Edge cases also include backup systems, staging environments, and disaster recovery replicas. Those locations are often encrypted, yet still hold valid secrets, stale tokens, or exported key material. If a recovery image restores a running service with the same identity and permissions, the encryption boundary has already been crossed. NHI Mgmt Group’s Key Challenges and Risks guidance is useful here because it frames the problem as lifecycle, visibility, and privilege management, not just storage protection. For agentic or autonomous workloads, that gap is even wider because runtime behaviour can change faster than static access rules can keep up.

Related resources from NHI Mgmt Group

• Why do secrets managers not fully solve NHI risk?
• Why do encryption controls not fully solve identity governance risk?
• Why do developer endpoints increase the risk of cloud and NHI compromise?
• Why do CI/CD runners and build tools increase NHI risk?