By NHI Mgmt Group Editorial TeamPublished 2024-09-28Domain: General NHISource: Okta

TL;DR: SAML centralises authentication through identity providers, letting service providers trust assertions instead of repeated credentials, according to the source article. That improves sign-in consistency, but it also concentrates risk in the identity layer and leaves service-account governance, rotation, and offboarding outside the model.


At a glance

What this is: This is an explanatory article on SAML that describes how identity providers and service providers use federation to authenticate users and pass authorization data.

Why it matters: For IAM and NHI practitioners, it highlights how federation can reduce password sprawl while also sharpening the need to govern trust, roles, and lifecycle controls around non-human access paths.

By the numbers:

👉 Read the source article on SAML providers, flows, and SSO basics


Context

SAML is a federation standard, not an identity governance model. It helps one system assert that authentication happened, but it does not itself solve entitlement design, service-account lifecycle management, or the exposure created when downstream applications accept those assertions without strong local controls. That gap matters for NHI governance because machine access often relies on the same trust chain, just without a human behind it.

The article frames SAML mainly as a way to reduce login friction and centralise user management. That is directionally correct for user access, but practitioners should read it as a reminder that federation shifts where trust is placed rather than removing trust altogether. In mature environments, that shift must be paired with least privilege, strong session policy, and explicit lifecycle controls for non-human identities.


Key questions

Q: How should security teams govern non-human identities when they also use SSO for users?

A: Security teams should govern non-human identities as a separate population with its own inventory, ownership, rotation, and revocation controls. SSO simplifies human access, but service accounts, API keys, tokens, and certificates need lifecycle management that is not covered by federation alone. The practical goal is to remove standing machine access and make every non-human credential traceable to a business service.

Q: What is the difference between SAML and OpenID Connect for enterprise access?

A: SAML is assertion-based federation commonly used for enterprise web SSO, while OpenID Connect is token-based identity built on OAuth 2.0 and is better suited to modern app and API ecosystems. The difference matters because the right protocol depends on the workload, the session model, and how the application handles delegation. Choosing the wrong one often creates brittle compensating controls.

Q: When does federation create more risk than it removes?

A: Federation creates more risk when teams trust the login flow but ignore downstream entitlement scope, session duration, and revocation. If a compromised identity provider, stale assertion, or over-broad service-provider policy can open too much access, the convenience gain is offset by a larger blast radius. The control objective is to keep trust narrow and time-bound.

Q: Why do identity provider failures matter so much in federated environments?

A: Identity provider failures matter because the service provider treats the assertion as evidence of trust. If that assertion is forged, mis-scoped, or issued from a compromised source, downstream systems may accept access they should not. Practitioners should therefore harden the identity provider, validate every assertion, and limit the lifetime of trusted sessions.


Technical breakdown

How SAML assertions move trust between identity providers and service providers

SAML uses XML-based assertions to carry identity claims from an identity provider to a service provider. The service provider does not re-authenticate the user in the traditional sense. Instead, it evaluates the assertion and decides whether to create a session. Three assertion types matter: authentication assertions confirm that a login occurred, attribute assertions convey user data, and authorization assertions describe whether access should be granted. The architectural consequence is that the security of the downstream application depends heavily on the integrity of the upstream identity event. If the identity provider is over-trusted, compromised claims can cascade into broad access.

Practical implication: Treat the identity provider as a high-value trust anchor and enforce strict assertion validation, short session lifetimes, and tight audience restrictions.

Why federation simplifies user access but not NHI lifecycle control

Federation reduces repeated credential entry, which is useful for human users and federated SaaS access. But the same pattern does not automatically govern non-human identities such as service accounts, bots, or API-driven integrations. Those identities often authenticate outside the SAML flow, using tokens, certificates, or API keys that have their own rotation and revocation problems. In practice, organisations can have polished SSO for employees while leaving machine identities unmanaged. That creates a blind spot: access looks centralised at the login layer, yet the real credential estate remains fragmented across applications, pipelines, and integration points.

Practical implication: Map all machine-authenticated access separately from SAML SSO and apply dedicated inventory, rotation, and offboarding controls.

SAML versus OAuth and OpenID Connect in modern access architecture

SAML is common in enterprise web SSO, while OAuth and OpenID Connect are more common in API and application-native authentication patterns. The distinction matters because SAML is assertion-centric, whereas OAuth and OIDC are token-centric and more often used in mobile, cloud, and distributed app environments. That means the control surface differs. SAML may reduce interactive login risk, but it does not address delegated authorisation in the same way as OAuth, nor does it solve workload identity problems. Practitioners should think in terms of protocol fit, not protocol preference. The wrong protocol for the workload often produces compensating controls that are weaker than the original problem.

Practical implication: Use SAML where federation fits the workflow, but pair it with token governance and workload identity controls where applications and agents operate non-interactively.


  • Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
  • DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

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


NHI Mgmt Group analysis

SAML improves authentication consistency, but it does not close the governance gap around downstream trust. The article describes a useful federation pattern, yet the security decision still shifts to the service provider after the identity provider issues an assertion. That means access control quality depends on how well downstream systems validate claims, session scope, and revocation. Practitioners should treat federation as a control plane for authentication, not as proof of complete identity governance.

SAML-era access models were built for users, not for autonomous software identities. Non-human identities typically authenticate with tokens, API keys, or certificates, which makes them visible in different systems and subject to different failure modes. When teams assume SSO coverage equals identity coverage, machine access stays under-governed. Practitioners should separate human federation strategy from NHI lifecycle management and avoid conflating the two.

Federation without lifecycle discipline creates hidden identity drift. Centralising sign-in can make access management look cleaner while stale entitlements, orphaned service accounts, and over-permissive integrations continue to accumulate in the background. That is the identity drift problem: the access story looks modern, while the underlying credential estate ages silently. Practitioners should pair federation with continuous review of account ownership, privilege scope, and revocation paths.

The real control question is who can assert trust, for how long, and under what revocation model. SAML answers the first part, but mature governance needs answers for the rest. If a session or assertion outlives the business need, the federation layer becomes a durability problem rather than an access convenience. Practitioners should design to minimise standing trust and tighten the path from authentication to revocation.

From our research:

  • 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
  • Only 5.7% of organisations have full visibility into their service accounts, which is why federation without inventory discipline leaves machine access exposed.
  • For a broader control baseline, review the Ultimate Guide to NHIs before treating SSO coverage as complete identity governance.

What this signals

Ephemeral trust still needs lifecycle control. Even when SAML reduces repeated logins, the underlying access paths for applications, APIs, and service accounts still need ownership, expiry, and revocation. The governance lesson is that modern IAM cannot stop at authentication success. Teams should watch for the growing gap between polished sign-in experiences and unmanaged non-human credential estates.

With NHIs outnumbering human identities by 25x to 50x in modern enterprises, federation strategies that focus only on employee access miss the larger operational risk. The programme implication is straightforward: align SSO, API auth, and workload identity under one inventory model, then connect that model to review and offboarding workflows.


For practitioners

  • Inventory non-human identities separately from SAML users Build a distinct register for service accounts, API keys, certificates, and bots so machine access is not hidden inside the human SSO catalogue.
  • Validate assertion trust boundaries Review how service providers validate issuer, audience, signing, and expiration checks, and confirm that sessions expire quickly enough to limit abuse.
  • Apply least privilege after federation Do not let successful SSO become a proxy for broad authorisation. Enforce role scoping, entitlement review, and approval steps after the assertion is accepted.
  • Separate workload identity from user federation Use protocol-specific controls for applications, pipelines, and agents instead of assuming SAML solves token issuance, rotation, or credential revocation.

Key takeaways

  • SAML reduces repetitive login friction, but it does not by itself govern downstream authorisation or machine identity risk.
  • The larger security issue is not the protocol itself, but the organisational habit of treating successful federation as complete access control.
  • Practitioners should separate human SSO from non-human identity lifecycle management and validate trust at every service boundary.

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 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
NIST CSF 2.0PR.AC-1Federation depends on reliable identity verification and access enforcement.
NIST Zero Trust (SP 800-207)Zero trust requires continuous verification beyond the initial federation event.
OWASP Non-Human Identity Top 10NHI-01Identity sprawl and unmanaged non-human access are central to the article's governance gap.

Treat SAML as one signal and keep reauthorisation, segmentation, and expiry controls active.


Key terms

  • SAML Assertion: A SAML assertion is the signed XML message that carries authentication and access claims from an identity provider to a service provider. It tells the receiving system who was authenticated, what attributes were shared, and whether access should be granted, so the trust in the session depends on the quality of that assertion.
  • Identity Provider: An identity provider is the system that authenticates a user or workload and issues the trust signal used by downstream applications. In federated environments, it becomes a high-value control point because compromise, misconfiguration, or over-trust at this layer can affect many services at once.
  • Service Provider: A service provider is the application or service that consumes an identity assertion and decides whether to allow access. It is responsible for validating the assertion, enforcing local authorisation, and limiting session scope, which means federation still requires strong downstream control.
  • Non-Human Identity: A non-human identity is any credentialed software or workload identity, including service accounts, API keys, tokens, certificates, bots, and AI agents. These identities often operate outside human sign-in flows, which makes inventory, ownership, rotation, and revocation central to governance.

Deepen your knowledge

SAML federation, identity trust boundaries, and non-human identity lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to connect SSO governance with machine access control, it is worth exploring.

This post draws on content published by the source article on SAML: Security Assertion Markup Language, provider types, and authentication flows. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2024-09-28.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org