Static and federated non-human identities need mixed governance

At a glance

What this is: This is an analysis of why static and federated non-human identities must be governed together, with the key finding that long-lived credentials still create the most durable attack surface in modern cloud and AI environments.

Why it matters: It matters because IAM, PAM, and NHI teams must manage mixed identity patterns without letting legacy secrets undermine zero-standing-privilege, federation, or lifecycle controls.

By the numbers:

• Breaches involving static credentials cost organizations $4.81 million on average and require 292 days to contain, the longest remediation timeline of any attack vector, according to IBM's 2024 Cost of a Data Breach.
• 61% of organizations have secrets, like cloud credentials, exposed in public repositories.

👉 Read Oasis Security's analysis of static and federated non-human identity governance

Context

Static credentials are the simplest form of non-human identity, but they are also the easiest to outlive their intended purpose. In cloud-first environments, access keys, API tokens, and long-lived passwords often survive vendor evaluations, backup projects, and temporary integrations long after the original need has ended, which turns convenience into standing risk.

The primary identity governance problem is not whether static or federated identity is better in the abstract. It is whether organisations can assign the right method to the right workload, then keep ownership, scope, rotation, and revocation aligned as systems move from legacy integrations toward ephemeral, policy-driven access.

Oasis Security’s framing is typical of the market at this point: most enterprises will operate mixed NHI estates for years, so the real maturity test is whether governance can steadily shrink standing privilege without breaking cross-service operations.

Key questions

Q: How should security teams manage a mix of static secrets and federated workload identities?

A: Treat them as one governed estate with different control requirements. Static secrets need ownership, scope limits, rotation, and explicit retirement. Federated identities need issuance policy, workload binding, and dependency mapping. The goal is to move each workload toward the least persistent option it can safely support while keeping the remaining exceptions tightly controlled.

Q: Why do static service accounts create so much breach risk in cloud environments?

A: Because they persist until someone revokes them, and that persistence gives attackers a reusable foothold. If the account is over-scoped, embedded in code, or forgotten after a project ends, the credential can survive long enough to support lateral movement and data access. The risk is endurance, not just exposure.

Q: What breaks when organisations try to govern non-human identities without lifecycle ownership?

A: Credentials linger after the business need has ended, permissions drift away from their original purpose, and revocation becomes slow or incomplete. That creates orphaned access, hidden dependencies, and elevated blast radius. Without lifecycle ownership, NHI governance becomes reactive cleanup instead of preventative control.

Q: How should teams decide when to keep a static secret versus migrate to federation?

A: Keep a static secret only when the target system cannot support a stronger pattern and the business value justifies the residual risk. Migrate when the workload can authenticate through a trusted issuer, when dependencies are mapped, and when short-lived access will not break production. The default should always be to shorten lifetime and narrow scope.

Technical breakdown

Why static credentials become durable attack paths

Static credentials stay valid until someone explicitly revokes them, which makes them fundamentally different from short-lived workload identities. In cloud and hybrid systems, that persistence is what creates risk: one leaked key can survive code changes, project completion, and staff turnover. Attackers value them because they are reusable, portable, and often over-scoped. Governance fails when ownership is unclear, rotation is manual, or the credential is embedded in places no one routinely checks. That is why static secrets are not just an operational nuisance. They are a structural identity control problem.

Practical implication: Treat every long-lived secret as a governed exception with an owner, expiry, and revocation path.

How federated workload identities change trust boundaries

Federated identity replaces shared secrets with assertions from a trusted issuer, usually an IdP or cloud provider. In practice, workload identity standards such as SPIFFE and SPIRE let services obtain per-process credentials that are bound to workload context rather than copied across systems. That shifts the trust boundary from secret possession to runtime authentication and policy enforcement. The important detail is that federation does not remove governance. It changes the control point from storage and rotation to issuance, scope, and policy alignment across clusters, clouds, and third-party dependencies.

Practical implication: Map each workload to the narrowest federated pattern its environment can support before defaulting to a static secret.

What zero-standing privilege means for mixed NHI estates

Zero-standing privilege means access should exist only for the task at hand and disappear when the task is complete. For NHI programmes, that often combines ephemeral credentials, policy-based issuance, and just-in-time provisioning. The mixed-estate reality matters because many systems still cannot support federation, so the control objective becomes reducing lifetime, scope, and blast radius even where static credentials remain unavoidable. This is not a binary migration story. It is an identity lifecycle discipline that keeps shrinking the exposed surface while preserving service continuity.

Practical implication: Use lifecycle controls to continuously shrink standing access, even where full federation is not yet possible.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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

NHI Mgmt Group analysis

Mixed NHI governance is now the baseline, not a transition state. The article is right that most enterprises will live with both static secrets and federated identities for years. That means the discipline is no longer choosing one model and declaring victory. Practitioners need governance that distinguishes between credentials that must be rotated, credentials that can be brokered, and workloads that can move to ephemeral issuance. The implication is that mixed estates should be treated as the normal operating model, not as technical debt to be ignored.

Static credential persistence is the real failure mode, not static identity in the abstract. The breach surface opens when long-lived keys remain valid after the business reason for them has expired. That is the control gap behind abandoned vendor evaluations, completed backup jobs, and hardcoded repository secrets. This is a standing credential exposure window, and it is the named failure mode this article exposes. The implication is that ownership, expiry, and revocation discipline matter more than the label attached to the identity.

Federation changes the control plane, but not the governance burden. Moving from secrets to managed workload identity shifts risk away from secret sprawl and toward policy quality, dependency mapping, and issuance scope. That is a healthier model, but only if organisations actually know which services depend on which credentials and where cutovers could break production. The implication is that lifecycle visibility becomes as important as the authentication method itself.

Zero-standing privilege is the correct end-state for any workload that can support it. Static access that persists for days, weeks, or months creates unnecessary blast radius even when rotation exists. Dynamic authentication is therefore not a convenience feature. It is the operational expression of least privilege for machines, and the governance question is how quickly each identity can move from persistent access to task-scoped access. The implication is that maturity should be measured by how much standing privilege remains, not by how many controls exist on paper.

From our research:

• 23.7% of organisations share secrets through insecure methods such as email or messaging applications, according to the 2024 Non-Human Identity Security Report.
• A separate finding in the same report shows that only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities.
• For a wider view of credential risk, see 52 NHI Breaches Analysis for recurring failure patterns across real incidents.

What this signals

Standing credential exposure window: the useful concept for this topic is that long-lived secrets remain attackable far longer than the business process that created them. As enterprises push more workloads toward federation, the remaining static identities become higher-value exceptions that need explicit lifecycle governance, not passive rotation.

With 23.7% of organisations still sharing secrets through insecure methods such as email or messaging applications, per the 2024 Non-Human Identity Security Report, the migration problem is as much behavioural as technical. Teams should expect ownership mapping, cutover discipline, and revocation workflows to become the real gating factors.

For practitioners, the next step is to align NHI controls with zero trust architecture and workload identity standards such as NIST AI Risk Management Framework only where AI systems are truly in scope, and otherwise to use federation and lifecycle controls to reduce standing privilege across clouds and runtimes.

For practitioners

• Audit every long-lived secret for ownership and expiry Build a living inventory of API keys, access tokens, and service passwords with a named owner, business purpose, environment, and planned retirement date. Prioritise credentials with no clear consumer or with access that survives the original use case.
• Move eligible workloads to federated issuance first Start with services that already run in supported clouds or clusters and replace copied secrets with managed workload identities, SPIFFE/SPIRE-based identities, or IdP-backed federation where the integration is mature.
• Enforce rotation as a containment control, not a final state Set maximum age limits, monitor first-use after rotation, and require service-side rollback plans so rotation shortens exposure instead of becoming a compliance ritual.
• Map dependency chains before cutover Document every service, pipeline, job, and third party that consumes each secret before migrating it, then canary the change and verify rollback paths so you do not break hidden integrations.

Key takeaways

• Static credentials remain the most durable form of non-human identity risk because they survive long after the need for access has disappeared.
• The evidence points to a real operational cost, with cloud breaches tied to static credentials taking months to contain and millions to remediate.
• The practical response is not to choose between static and federated identities, but to shrink standing privilege and move each workload to the safest supported pattern.

Key terms

• Static Credential: A static credential is a long-lived secret such as an API key, token, password, or certificate that remains valid until it is explicitly changed or revoked. In non-human identity programmes, its main risk is persistence, because a leaked credential can outlive the workload, the project, or the business need it was created for.
• Federated Identity: Federated identity is an authentication model where a trusted issuer vouches for a workload instead of the workload presenting a shared secret. For non-human identities, this usually means short-lived assertions, tighter scope, and better lifecycle control, but it still depends on accurate policy, ownership, and dependency mapping.
• Zero-standing Privilege: Zero-standing privilege is the practice of avoiding persistent access by issuing permissions only when a task requires them. For machines and agents, that means moving away from reusable secrets toward time-bound access that disappears after use, reducing the blast radius of compromise and simplifying revocation.
• Standing Credential Exposure Window: A standing credential exposure window is the period during which a long-lived secret remains usable after it has been created, exposed, or forgotten. The longer that window stays open, the more likely an attacker can reuse the credential for access, lateral movement, or persistence before the organisation notices.

Deepen your knowledge

Static credentials, federation, and zero-standing privilege are core topics in the NHI Foundation Level course, the industry's only accredited NHI security programme. If you are governing a mixed NHI estate, it is a practical place to sharpen that model.

This post draws on content published by Oasis Security: Govern the Mix: Static and Federated Non-Human Identities. Read the original.