The application team is accountable, because these checks are part of the service provider’s trust boundary. An assertion must come from the expected identity provider, target the right application, and arrive at the exact ACS endpoint. If any of those values are off, the response should be rejected as unsolicited or misdirected.
Why This Matters for Security Teams
SAML trust is not just an identity team problem. When a service provider accepts an assertion with the wrong issuer, audience, or destination, it has crossed its own trust boundary and accepted a response it did not properly validate. That creates a direct path for account confusion, assertion replay, and misdelivery into the wrong application context. The accountable party is the application team because those checks are part of the relying party’s security controls, not the upstream identity provider’s.
This distinction matters most during incident response and integration review. A valid-looking SAML response can still be unsafe if it was minted for a different audience, posted to the wrong ACS endpoint, or signed by an unexpected issuer. NIST’s guidance on access control and authentication, including NIST SP 800-53 Rev 5 Security and Privacy Controls, reinforces that the relying system must enforce its own verification rules. In practice, many teams discover this after a misrouted assertion has already been accepted, rather than during design review.
The same pattern shows up in real-world identity failures discussed in the Hugging Face Spaces breach and other supply-chain incidents, where trust decisions at the application boundary proved more important than the nominal identity source.
How It Works in Practice
The application team should treat SAML validation as a set of explicit checks at the service provider boundary. The issuer must match the expected identity provider, the audience must match the exact application or entity ID, and the destination or ACS URL must match the endpoint that is authorized to receive the response. If any one of those values is wrong, the assertion should be rejected before any session is created.
Operationally, that means the application owner needs to own the configuration, testing, and monitoring for:
- issuer allowlists tied to the specific IdP tenant or metadata document
- audience restriction checks that prevent cross-application token reuse
- destination and ACS endpoint validation to stop misdirected responses
- time-based checks such as NotBefore and NotOnOrAfter to limit replay windows
- signature verification against the expected signing certificate and metadata
This is also a governance issue. The Klue OAuth Supply Chain Breach and the GitHub Repo Breach — Heroku and Travis CI OAuth Tokens show the same control lesson from adjacent identity failures: if the application accepts a credential or assertion without tight audience and destination binding, the trust relationship becomes too broad. Good practice is to log rejected assertions with enough detail for detection, but not enough to leak secrets or session data. These controls tend to break down when multiple apps share similar ACS paths, metadata is copied between tenants, or integration teams rely on IdP-side configuration alone because the relying party checks were never tested end to end.
Common Variations and Edge Cases
Tighter SAML validation often increases integration overhead, requiring organisations to balance security assurance against federation complexity. That tradeoff is real when a platform supports many tenants, multiple ACS endpoints, or legacy modules that cannot easily enforce strict audience matching.
There is no universal standard for every edge case, but current guidance suggests the application team should own the final decision point whenever the relying party can independently verify the assertion. In some environments, identity teams configure the IdP metadata, while platform teams own the ACS and session creation logic. The accountability still sits with the application team because it is the component deciding whether to trust the response.
Borderline cases include brokered SSO, gateway-mediated authentication, and multi-tenant SaaS integrations. In those settings, the party operating the trust boundary may be a shared platform team, but the control obligation remains the same: validate exact issuer, audience, and destination before accepting the response. This is also where misconfigurations can resemble legitimate traffic, which is why runtime enforcement matters more than policy documents alone. The broader NHI lesson from Ultimate Guide to NHIs is that trust must be constrained, observable, and continuously checked, not assumed from configuration ownership alone.
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, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | SAML trust decisions depend on strict access control at the relying party boundary. |
| NIST SP 800-63 | Federation assurance depends on validating assertions and trust relationships correctly. | |
| NIST Zero Trust (SP 800-207) | Zero Trust requires explicit verification of every access request, including federation assertions. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Misbound assertions are an identity trust failure at the application boundary. |
| NIST AI RMF | GOVERN | Accountability for trust decisions requires clear governance over the relying party controls. |
Treat SAML assertions as authenticated inputs and reject any that are misbound or unsigned.
