Notifications
Clear all
Topic starter
04/06/2026 3:03 pm
TL;DR: Static credentials remain a persistent breach path in cloud and hybrid environments, with IBM data cited in the source showing they contributed to over 60% of cloud-related breaches and averaged $4.81 million in losses with 292 days to contain. The governance shift is clear: dynamic, policy-driven authentication should become the default while legacy secrets are steadily shrunk, not simply rotated.
NHIMG editorial — based on content published by Oasis Security: Govern the Mix: Static and Federated Non-Human Identities
By the numbers:
- 61% of organizations have secrets, like cloud credentials, exposed in public repositories.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
What's in the full article
Oasis Security's full blog covers the operational detail this post intentionally leaves for the source:
- A dependency-aware migration approach for moving from static credentials to federated identities without breaking service connections
- Practical guidance for handling vendor APIs, legacy systems, and cross-org workflows that cannot yet abandon static secrets
- Operational steps for vaulting, ownership assignment, rotation, and revocation when static credentials must remain in use
- Examples of policy-based lifecycle orchestration across clouds, clusters, and runtimes
👉 Read Oasis Security's analysis of static and federated non-human identity governance →
Static credentials and federated NHI governance: what changes now?
Explore further
04/06/2026 3:17 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Static and federated non-human identities need mixed governance
