Notifications
Clear all
Topic starter
06/06/2026 2:22 am
TL;DR: As organizations expand across SaaS, cloud and automation, identity models split into three distinct problems: SSO for human users, federated identity management for cross-domain human access, and workload identity federation for secretless machine access, according to Aembit. The governance question is no longer whether to centralize identity, but how to apply the right trust model to each actor type without letting static credentials become the default.
NHIMG editorial — based on content published by Aembit: Managing digital identities for both human and nonhuman users
By the numbers:
- According to 1Password, 19% of employees use the same password across multiple work accounts.
- Only 5.7% of organisations have full visibility into their service accounts.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams govern workload identity federation in multi-cloud environments?
A: Security teams should govern workload identity federation as a machine access control, not as a user login substitute.
Q: Why do service accounts and static secrets create more risk than federated workload access?
A: Service accounts and static secrets create risk because they persist beyond the original task and can be copied, reused or leaked.
Q: What breaks when federation trust is not actively governed?
A: When federation trust is not actively governed, partner certificates, metadata and assertions can remain valid after the business relationship or security posture has changed.
Practitioner guidance
- Classify identity subjects before selecting controls Separate human users, external partners and workloads in your IAM design so that SSO, FIM and WIF are governed as different control planes rather than one blended access strategy.
- Remove hardcoded secrets from workload paths Inventory code, CI/CD pipelines and runtime configs for static credentials, then replace them with short-lived workload credentials issued through attested federation.
- Treat partner trust as a lifecycle process Apply certificate rotation, metadata validation and offboarding checks to every external federation relationship so trust does not persist after the business need ends.
What's in the full article
Aembit's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step patterns for implementing SSO, FIM and WIF across cloud, SaaS and on-premises systems
- Protocol-level examples for OIDC, SAML and SPIFFE-based workload identity flows
- Guidance on certificate management, metadata validation and trust boundary monitoring
- A comparison table that helps teams decide which identity model fits each access scenario
👉 Read Aembit's guide to SSO, federated identity and workload identity →
SSO, FIM and WIF: what identity teams need to change?
Explore further
06/06/2026 4:00 am
Identity governance fails when teams apply a human login model to machine access. SSO solves a human problem, but workloads do not authenticate like people and cannot rely on interactive login flows or MFA prompts. When service accounts, pipelines and microservices are forced into human-style assumptions, the result is persistent secret exposure and weak lifecycle control. The implication is that non-human identity needs its own governance model, not a re-skinned employee access process.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: What is the difference between SSO and workload identity federation?
A: SSO is designed for interactive human authentication inside a single organisation, while workload identity federation is designed for non-human systems that need secretless, task-scoped access across domains. The practical difference is that SSO relies on a user session, whereas workload federation relies on attestation and short-lived machine credentials.
👉 Read our full editorial: SSO, federation and workload identity: the new identity stack
