By NHI Mgmt Group Editorial TeamBased on Aembit: “Use Case” (November 14, 2025)

TL;DR: Extending zero trust and MFA-like controls to non-human identities can reduce lateral movement and secret exposure, but static credentials, policy drift, and limited workload visibility still undermine governance, according to Aembit. The real issue is not whether workloads need stronger access control, but whether IAM models can verify, govern, and revoke machine access continuously.


At a glance

What this is: This is an analysis of why zero trust for non-human workloads still breaks down when workloads rely on static credentials, inconsistent policy enforcement, and limited visibility.

Why it matters: It matters because IAM and PAM teams need controls that can verify, govern, and revoke machine access continuously, not only human access at sign-in.


Context

Zero trust for non-human workloads means applying identity verification and policy enforcement to applications, services, and other machine processes before they access resources. The gap is that many zero-trust programmes were built around human authentication flows, while workload access often still depends on credentials that are difficult to govern end to end.

For IAM, NHI, and PAM teams, the practical problem is not whether workload access should be controlled, but whether the control model can keep pace with secret exposure, policy drift, and the need for revocation. In this article's framing, workload identity becomes a governance problem as much as a technical one.


Key questions

Q: What breaks when zero trust is applied to workloads that still use static secrets?

A: Zero trust breaks down when the credential itself becomes the trust token. If a workload keeps a reusable secret, access is no longer tied to a fresh verification event, so compromise lasts longer and revocation becomes harder to prove. The control model still works only when credentials are short-lived and tied to a policy check at issuance.

Q: Why do standing workload credentials increase lateral movement risk?

A: Standing credentials increase risk because they let one valid access path keep working across multiple internal services without a new authentication step. If policy drift or overbroad permissions exist, an attacker can reuse that trust to move through the environment with the workload's own identity rather than a noisy exploit path.

Q: What are the signs that workload identity management is failing in a large environment?

A: Common warning signs include dormant identities that have not been reviewed for months, permissions that far exceed workload requirements, and no reliable visibility into which accounts are active. Another signal is hard coded credentials inside workloads, because that usually means access is being maintained manually instead of governed through a lifecycle process. These patterns point to weak control, not just poor hygiene.

Q: How should teams balance zero trust and workload identity controls?

A: Teams should use zero trust as the policy model and workload identity as the execution layer. That means every non-human access request should be evaluated against identity and context, while the credential itself remains short-lived, traceable, and revocable. Human-era MFA patterns are not enough on their own.


Technical breakdown

Why static secrets break zero trust for workloads

Zero trust assumes each access request can be verified against identity and context, but static secrets weaken that assumption because the credential itself becomes the lasting trust token. When a service account or workload keeps a reusable secret, the access decision is no longer tied to a fresh trust event. That makes compromise harder to detect and revocation harder to prove. The result is not just credential sprawl, but a governance gap between policy intent and actual runtime access.

Practical implication: replace standing secrets with short-lived workload credentials and tie issuance to policy evaluation.

How MFA-like conditional access changes machine identity governance

For workloads, MFA-like controls do not mean a human prompt. They mean combining identity, posture, location, timing, and policy signals to decide whether a workload should receive access at all. This is a different control pattern from human MFA because the subject is a non-human identity acting at runtime. If those signals are not continuously evaluated, the workload can inherit trust once and reuse it beyond the intended boundary. That creates a policy drift problem rather than a login problem.

Practical implication: define conditional access rules for workloads that are evaluated at issuance time and refreshed when context changes.

Why centralized visibility matters for workload-to-workload access

Workload-to-workload access is often invisible because it happens between services rather than through a single user-facing control plane. Without centralized visibility, access reviews become incomplete, secrets are hard to trace, and teams cannot easily determine which workload called what, under which policy, and with which credential. That visibility gap is especially important where multiple teams own parts of the stack. Governance fails when no one can reconstruct the trust chain across environments.

Practical implication: inventory workload identities and map each access path to an owner, a policy, and a revocation path.


Threat narrative

Attacker objective: The attacker aims to turn trusted machine access into a durable path for lateral movement and data theft.

  1. Entry begins when an attacker can use a valid workload credential or exploit a static secret that was intended for machine-to-machine access. Because the secret represents standing trust, the access path does not depend on a fresh human authentication event.
  2. Escalation occurs when the workload credential can reach additional internal services or APIs beyond its intended scope, especially where policy drift has left access broader than the original approval.
  3. Impact follows when that trusted workload path is used for lateral movement, sensitive data theft, or repeated access across systems before the credential is revoked.
  • SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.
  • Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Zero trust for workloads only works when trust is re-evaluated at issuance time, not inherited from the credential itself. The article's central tension is that non-human identities can be given MFA-like treatment, but static credentials still behave like standing trust. That means the real control boundary shifts from authentication events to credential lifecycle and runtime policy enforcement. Practitioners should treat workload access as continuously re-authorised access, not as a one-time grant.

Credential persistence is the named concept that explains why workload zero trust so often fails in practice. A reusable secret turns a workload identity into a durable bearer of trust, which is exactly what zero trust tries to avoid. The longer that secret lives, the more policy drift accumulates between the approval decision and the actual access path. Practitioners should measure how much of their machine access still depends on credentials that outlive the session or the job.

Access review processes assume access lasts long enough to be reviewed, but workload access often exists as a sequence of machine calls rather than a stable entitlement. That makes traditional certification weak unless the organisation can reconstruct the workload, the policy, and the credential state at the moment of access. The implication is that governance must move closer to runtime control and away from periodic after-the-fact inspection.

Workload identity governance is now a cross-functional control problem, not a tooling category. The article links security, DevSecOps, and compliance concerns because machine access crosses all three domains. Centralised visibility, conditional policy, and secretless access are not separate initiatives here; they are the same governance problem seen from different teams. Practitioners should align ownership before they try to automate enforcement.

Zero trust for non-human identities validates the direction of the market, but it also exposes how human-era IAM assumptions still dominate design. The article shows a category-level shift toward runtime machine identity controls, yet many programmes still depend on static secrets, manual provisioning, and human-centred review rhythms. Practitioners should expect NHI governance to become a core part of zero trust, not an adjacent enhancement.

From our research library:

What this signals

Credential persistence: Workload zero trust fails when the trust decision is effectively embedded in a long-lived secret rather than re-evaluated at runtime. That is why machine access governance has to move toward short-lived issuance, traceable ownership, and revocation that is tied to the actual identity path.

Aembit’s framing also reinforces a broader programme issue: teams that still separate IAM for humans from governance for non-human identities will keep missing the access paths attackers prefer. The governance model has to cover service accounts, APIs, and workload-to-workload access as first-class identity surfaces.


For practitioners

  • Harden workload secret lifecycle controls Inventory every service account, API key, token, and certificate used by workloads, then define rotation and revocation ownership for each one.
  • Move workload access decisions to runtime policy Require identity plus context checks before issuance, including the workload's environment, time of request, and policy state.
  • Map workload-to-workload access paths Document which workloads can call which services, which credentials they use, and which team can revoke each path.
  • Reduce standing trust in machine credentials Replace long-lived reusable secrets with short-lived, purpose-scoped credentials wherever the platform can support it.

Key takeaways

  • The core risk is not that workloads cannot be governed, but that static credentials and policy drift keep old trust alive after the approval moment has passed.
  • The article points to three pressure points at once: secret lifetime, runtime policy enforcement, and visibility into workload-to-workload access paths.
  • Teams that want zero trust to work for machine identities need governance that can verify, trace, and revoke access continuously, not only at provisioning time.

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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-02 — Secret LeakageStatic workload secrets are the main governance weakness described in the article.
NHI-07 — Long-Lived SecretsThe article centres on long-lived credentials that outlast the trust decision.
NHI-05 — Overprivileged NHIPolicy drift and broad workload access create overprivileged machine identities.
Recommendation — Scan workload secrets for leakage and revoke exposed credentials immediately. Replace long-lived secrets with short-lived workload credentials and enforce rotation. Tighten workload entitlements to the minimum access needed for each service call.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article focuses on governing access permissions for non-human identities.
Recommendation — Apply PR.AA-05 to review and constrain workload entitlements continuously.
NIST Zero Trust (SP 800-207)Zero Trust Architecture — Zero Trust ArchitectureThe article is explicitly about extending zero trust principles to workloads.
Recommendation — Use zero trust principles to verify every workload request before granting access.
MITRE ATT&CKTA0006;TA0008 — Credential Access; Lateral MovementThe threat path discussed is credential abuse leading to lateral movement.
Recommendation — Map workload secret exposure to TA0006 and TA0008 to prioritise detection and containment.

Key terms

  • Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
  • Zero Trust For Workloads: Zero Trust for workloads applies continuous verification to machine-to-machine access instead of assuming internal trust. Access decisions depend on identity, policy, and current workload state, not just network position or static secrets. This approach is used to reduce standing access and limit the blast radius of compromised non-human identities.
  • Secretless Access: Secretless access is a pattern where workloads authenticate and receive access without relying on long-lived embedded credentials. It typically uses runtime identity verification, federation, and short-lived authorization decisions. The goal is to reduce exposure from hardcoded or reusable secrets while keeping machine-to-machine access functional.
  • Policy Drift Detection: Policy drift detection is the process of identifying when an access policy no longer matches the intended rule or the current business context. It helps teams catch unauthorized changes, stale permissions, and exceptions that have quietly become the new normal, so governance stays aligned with actual identity and app usage.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on May 31, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org