SSO, federation and workload identity: the new identity stack

At a glance

What this is: This is an analysis of how SSO, federated identity management and workload identity federation map to human and non-human access, with the key finding that machine identities need short-lived, secretless trust rather than human-style login flows.

Why it matters: It matters because IAM teams must stop treating workloads like users and start governing non-human access with federation, attestation and lifecycle controls that fit how machines actually authenticate.

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.

👉 Read Aembit's guide to SSO, federated identity and workload identity

Context

Identity architecture is now a three-layer problem: human sign-in, cross-organization trust, and machine-to-machine authentication. SSO reduces friction for people, federated identity extends trust beyond one organisation, and workload identity federation replaces hardcoded credentials for services, scripts and pipelines. The common failure is assuming a single control model can govern all three.

For IAM teams, the practical shift is to classify the identity subject before choosing the control plane. Human users need authentication controls such as SSO and MFA, while workloads need attestation, short-lived credentials and policy-driven access. That distinction is central to non-human identity governance, and it is where many programmes still blur the line between access convenience and access assurance.

Key questions

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. That means requiring attestation, short-lived credentials, resource scoping and explicit lifecycle rules for every workload identity. The goal is to eliminate standing secrets and make every access decision depend on current workload identity and policy.

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. Federated workload access reduces that risk by issuing short-lived credentials that expire quickly and are tied to a specific identity proof. That narrows replay opportunities and limits lateral movement.

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. That creates access that outlives accountability. The failure is not just technical drift, but lifecycle drift across external identities and their trust anchors.

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.

Technical breakdown

SSO versus federated identity management in enterprise access

Single sign-on centralises authentication inside one organisation, so a user authenticates once and then reuses a session token across approved applications. Federated identity management extends that model across trust boundaries, using signed assertions from a home identity provider to grant access in another domain. The technical difference is not just geography. SSO assumes one administrative boundary, while federation assumes at least two, with metadata, certificates and trust validation between them. That makes federation more flexible but also more brittle, because partner trust chains and certificate hygiene become part of the access path.

Practical implication: separate internal SSO controls from external federation governance and treat partner trust as a first-class security dependency.

Workload identity federation and secretless machine access

Workload identity federation replaces long-lived secrets with short-lived credentials issued after a workload proves who it is. The proof can come from OIDC, SPIFFE/SPIRE certificates or cloud-native identity documents, depending on the environment. The key architectural change is that the workload authenticates as a machine, not as a user, and the credential it receives is scoped to a task, resource or request path. That means the security model shifts from static secret protection to attestation, expiry and fine-grained policy enforcement at machine speed.

Practical implication: remove hardcoded credentials from code, CI/CD and runtime configs, then require short-lived workload credentials tied to attestation.

Why ephemeral credentials change zero-trust design

Ephemeral credentials matter because they reduce the value of stolen material and force re-validation on each request. In a zero-trust design, that means the workload does not become trusted just because it once authenticated successfully. Instead, every access decision depends on current identity, posture and policy. This is the core difference between human authentication and machine authorisation. Humans can tolerate a session model with MFA prompts and refresh cycles. Workloads need continuous, automated validation with no shared secrets to re-use later.

Practical implication: align machine access decisions with request-time verification, not with one-time login events or static trust grants.

Threat narrative

Attacker objective: The objective is to turn one trusted identity path into repeated access across connected systems without triggering fresh authentication or review.

1. Entry begins when static credentials, hardcoded secrets or over-broad federation trust are available to attackers or misused integrations. In workload environments, a single exposed key can become the initial foothold for machine-to-machine access.
2. Credential access or abuse follows when the attacker reuses long-lived tokens, partner assertions or session material to impersonate a workload or external user. The issue is not the protocol itself but the persistence of trust after the original context has changed.
3. Impact occurs when compromised machine or federated access is used for lateral movement across cloud, SaaS or production services, allowing the attacker to reach sensitive data or privileged systems.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

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

NHI Mgmt Group analysis

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.

Secretless access is the real control objective, not just credential rotation. The article is right to frame WIF as a replacement for hardcoded secrets, because the control problem is larger than rotation cadence. Static secrets create a standing trust path that can be copied, leaked and reused outside the original context. A short-lived federated credential changes the blast radius, but only if it is paired with task scoping and verified identity documents.

Federation expands the trust boundary, so partner lifecycle becomes part of access security. FIM is often treated as a convenience layer for external users, but it also introduces certificate management, metadata validation and partner offboarding obligations. If the external identity provider, certificate or assertion trust is not actively governed, access can outlive the business relationship. Practitioners should treat partner trust as a lifecycle issue, not a one-time integration decision.

Workload identity federation is becoming the baseline for modern NHI governance. The strongest signal in this article is that machine access now spans clouds, SaaS and automation pipelines, which means the traditional service account model is too blunt. 95% of organisations still lack full visibility into their service accounts is a different numeric figure would be the wrong focus here; the real shift is architectural. Teams need identity-first controls that assume every workload is a governed actor with its own trust boundary.

Named concept: identity plane separation: Human SSO, external federation and workload federation should be governed as separate identity planes with different threat models, assurance signals and lifecycle rules. Conflating them leads to controls that look consistent on paper but fail in operation. The practitioner takeaway is to map each actor type to the right trust mechanism before standardising policy.

From our research:

• 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.
• That lifecycle gap is why the NHI Lifecycle Management Guide is the right next step for teams mapping rotation, offboarding and revocation into operational controls.

What this signals

Identity plane separation is now a practical requirement, not an architectural preference. Human sign-in, partner federation and workload federation need different assurance signals, different lifecycle controls and different failure analysis. Teams that collapse them into one IAM programme usually end up with strong policy language and weak enforcement at machine scale.

With 96% of organisations storing secrets outside of secrets managers in vulnerable locations including code, config files and CI/CD tools, according to the Ultimate Guide to NHIs, the operational gap is already visible. The next programme shift is to treat every pipeline, service and automation path as a governed identity with expiry, attestation and revocation.

The governance priority is moving toward secretless access and lifecycle-bound trust. That means security teams should expect more emphasis on workload federation, stronger partner offboarding and tighter evidence for every trust relationship that crosses an identity boundary. SSO is not going away, but it is no longer sufficient as the default model for everything that authenticates.

For practitioners

• 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.
• Align workload access to task scope Scope machine credentials to the specific resource or request path they need, and avoid broad reusable tokens that can be replayed across environments.

Key takeaways

• SSO, federation and workload identity solve different identity problems, so treating them as one architecture creates control gaps.
• Static secrets remain a major exposure point, especially when code, CI/CD tools and workload configs still carry reusable credentials.
• Practitioners should move toward secretless machine access, partner lifecycle governance and identity-plane separation now, not later.

Key terms

• Workload Identity Federation: A method for giving services, pipelines and automation short-lived credentials based on a trusted identity proof rather than a stored secret. It allows machine-to-machine access without hardcoded keys and supports least privilege through expiry, scoping and attestation.
• Federated Identity Management: A trust model that lets one organisation accept authenticated identity assertions from another organisation’s identity provider. It is used for cross-boundary human access and depends on certificates, metadata and lifecycle governance to keep external trust valid and bounded.
• Single Sign-On: A user authentication model that lets a person sign in once and then access multiple approved applications without re-entering credentials. It improves user experience and centralises control, but it is designed for interactive human sessions rather than machine identities.
• Secretless Access: An access pattern that removes reusable credentials from code, pipelines and runtime environments, replacing them with ephemeral, verified credentials. In practice, it reduces the value of theft and makes access depend on current identity proof instead of a copied secret.

Deepen your knowledge

Workload identity federation, secretless access and identity-plane separation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance programme for human, partner and machine identities at the same time, it is worth exploring.

This post draws on content published by Aembit: Managing digital identities for both human and nonhuman users. Read the original.