What breaks when agencies keep SAML applications but expect modern access controls to work everywhere?

Where the mismatch actually lives

The break is architectural, not cosmetic. SAML was designed around browser sign-in, signed assertions, and a trust relationship that is established once and then reused, so it does not naturally support continuous, per-request policy evaluation across every downstream app action. That means a modern access layer can sit in front of it, but it cannot make a legacy app natively understand dynamic authorization if the app only knows how to consume a SAML assertion at login.

In practice, the limitation shows up when teams expect one control plane to enforce step-up authentication, conditional access, or fine-grained policy inside an application that was built for coarse session acceptance. A useful comparison is the difference between federation and modern OpenID Connect Core 1.0 style flows, where the identity layer is more naturally aligned with current policy-driven access decisions.

SAML can still be stable and secure for what it was intended to do, but it is usually a poor fit when the business wants runtime policy to change by user risk, device posture, location, or transaction context without app changes.

Why “modern access controls everywhere” fails in SAML estates

The common failure is treating federation as if it were a universal policy substrate. SAML applications often bind access to a session established at sign-in, then trust that session until expiry, which means the application may never re-check the facts that modern access programs care about. If the app cannot consume current signals, the policy engine can only influence the edge, not every meaningful action inside the app.

That gap becomes sharper in mixed estates. Some apps can accept external identity decisions cleanly; others need local roles, embedded authorization logic, or session lifetimes that were never designed for continual reevaluation. This is why identity, session, and application control need to be aligned, not just connected. NHIMG’s Identity Provider and SSO Security Guide is a good reference point for the trust and session side of that boundary, while the Authorisation Models Guide helps clarify why policy expressiveness matters once access decisions move beyond simple login.

For agencies, the practical issue is not whether SAML is “old.” It is whether the application can support the access decision model the organisation now requires. If the answer is no, then the modern control must be enforced outside the app, or the app must be modernised.

What agencies should change before they add more policy

The right fix is to separate authentication, session handling, and authorization design instead of assuming one legacy federation stack can do all three. Where the app is staying, agencies should decide which controls can be enforced at the identity layer, which must be translated into app-native roles, and which simply cannot be achieved without replacing the application or inserting a mediation layer.

That planning is especially important when a SAML app is being fronted by a gateway or access proxy. The gateway can reduce exposure and enforce entry conditions, but it does not magically create per-request decisions inside an application that only understands a login assertion. In identity and access programmes, that is the point at which governance has to acknowledge application capability, not just policy intent. IAM and IGA Basics is useful here because lifecycle, entitlement, and access review controls only work cleanly when the application can actually express and consume them.

When the agency cannot change the app quickly, the safest stance is to scope the control objective realistically: harden the IdP, shorten trust duration where possible, reduce standing access, and treat the legacy app as a constrained endpoint rather than a fully policy-aware system.

Risk and Threat Considerations

SAML estates become risky when organisations assume that a modern identity control at the perimeter automatically protects every action inside the application. The exposure is session persistence, stale trust, and inconsistent enforcement, especially when old assertions or long-lived sessions outlast the context that justified them.

Failure mechanism: An attacker who obtains a valid session, token, or federation path may keep using a legacy app even after risk signals change, because the application cannot re-evaluate policy at the point of use. Weak session handling and trust assumptions can turn a one-time login into broad downstream access.

Impact: The result is overbroad access, weaker incident containment, and a larger blast radius when user context, device trust, or account state changes but the application continues to accept the original session.

Practitioner Guidance

What to verify: Check whether the application can enforce authorization after login, or whether it only consumes a one-time SAML assertion. If it cannot make runtime decisions, do not promise continuous policy enforcement at the app layer.

Decision rule: If the application cannot express per-request access logic, move the modern control point to the gateway or IdP, and keep the app on a tightly bounded session model. If the application must decide at transaction time, treat it as a modernization or replacement candidate, not a policy retrofit.

Practitioner takeaway: The key question is not whether SAML still works, but whether the application can honor the access model the agency now expects. If it cannot, the control is only as modern as the oldest trust boundary in the chain.

Related resources from NHI Mgmt Group

• What breaks when teams keep using legacy access controls for modern cloud data access?
• What breaks when agencies try to use modern security controls without adapting access policies for changing context?
• How can organizations keep legacy apps compatible with modern access controls?
• Why do attribute-based access controls fit modern cloud applications better?