A SAML forging attack is an attack where an adversary creates or alters a SAML assertion so it is accepted as a valid login or authorisation token. It targets the trust between an identity provider and a service provider, usually by abusing weak signing, certificate handling, XML parsing or assertion validation.
How a SAML Forging Attack Works
A SAML forging attack succeeds when an attacker manufactures or modifies a SAML assertion that a service provider accepts as if it came from a trusted identity provider. The core abuse is not the login screen itself, but the trust relationship behind it: if signature handling, XML parsing, audience checks or assertion validation are weak, the forged token can become a valid session.
This is why the attack is so powerful in federated environments. A single accepted assertion can bypass normal credential entry, MFA prompts and local password policy, because the application is trusting the assertion as proof of authentication and often as a source of identity attributes and roles.
Why SAML Forging Is Dangerous
The danger is that SAML is designed to make trust portable across systems. If an attacker can mint a believable assertion, they may be able to impersonate a user, escalate into a higher-privilege account, or reach applications that rely on federation for access decisions. When the target application treats the assertion as authoritative, the compromise can look like a legitimate login.
For defenders, this means the blast radius is often larger than a single account. Federated sign-on can connect many applications to the same identity trust chain, so one broken validation path or one stolen signing capability can affect multiple services. The strongest single point of control is often the assertion validation logic, not the application account database itself.
NHIMG’s SAML Security Guide covers the trust failures behind response forgery, XML signature wrapping and signing certificate rotation in more depth.
Common Exposure Checks and Failure Conditions
Exposure usually starts with inventory and trust mapping. Organisations should know which applications accept SAML, which identity providers issue assertions, where metadata is stored, and whether any services still trust legacy certificates or weak validation paths. Internet-facing single sign-on endpoints deserve special attention because they are the easiest place to probe.
Typical failure conditions include accepting unsigned or poorly validated assertions, checking the signature on the wrong XML element, failing to verify audience and recipient fields, or trusting attributes without confirming the assertion context. Weak certificate handling is also a major problem, especially when old signing keys remain trusted after rotation or when metadata updates are not tightly controlled.
For broader federated identity context, NHIMG’s Workforce Identity Security Guide connects SAML risk to federation, session theft and account recovery paths.
Detection, Containment and Recovery
SAML forging attacks are often detected by looking for abnormal federation behaviour rather than obvious malware. Security teams should review authentication logs for unusual IdP-to-SP relationships, unexpected audiences, impossible travel after federation, repeated assertion failures followed by a successful login, and sessions created from unusual source locations or user agents. Post-patch review matters because compromise may have already produced valid sessions before the weakness was fixed.
Containment often requires more than a software patch. If an assertion forgery is suspected, rotate affected signing certificates, invalidate active sessions where possible, review IdP metadata and trust anchors, and examine downstream access for privilege escalation or data access that occurred during the window of abuse. In many environments, the identity impact is the real issue: tokens, sessions and trusted signing material may all need to be reissued or revoked.
Risk and Threat Considerations
SAML forging is high impact because it attacks the trust boundary that federation is built on. If the attacker can manufacture a valid assertion, they do not need the user’s password, and they may bypass controls that were enforced earlier in the authentication flow.
Failure mechanism: The service provider accepts a forged or altered assertion because it validates the wrong XML content, trusts stale signing material, or skips key checks such as audience, recipient and signature scope.
Impact: The attacker can impersonate users, access federated applications, and potentially persist through trusted sessions until certificates are rotated and sessions are invalidated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Federated SAML logins still establish user authentication and trusted identity assertions. |
| IA-5 — Authenticator Management | SAML forgery often depends on weak signing certificate and trust-material handling. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Detecting forged assertions depends on reviewing federation and session anomalies. | |
| Recommendation — Validate federated authentication flows and ensure assertions are accepted only after full identity verification. Rotate signing material promptly and revoke trust in compromised or stale certificates. Correlate IdP and SP logs to spot abnormal assertion use and suspicious federated sessions. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Federated identity trust and assertion acceptance are identity-management concerns. |
| A.8.24 — Use of cryptography | SAML security depends on correct protection and validation of signing certificates and keys. | |
| Recommendation — Govern federation trust relationships and review which applications accept SAML assertions. Protect signing keys and enforce secure certificate handling for federated assertions. | ||
| MITRE ATT&CK | T1606.002 — SAML Tokens | The attack directly matches adversary abuse of SAML tokens and assertions for access. |
| Recommendation — Map observed federation abuse to T1606.002 and hunt for assertion forgery across IdP and SP logs. | ||
| CIS Controls v8 | 5 — Account Management | Federated access depends on controlling which accounts and trust paths remain active. |
| Recommendation — Remove stale federated access paths and review accounts tied to trusted identity-provider relationships. | ||
Practitioner Guidance
Why practitioners should care: SAML failures are rarely isolated to one application. Federation mistakes can become enterprise-wide access failures, so the control surface includes both the identity provider and every relying application.
What to watch for: Treat any SAML implementation that depends on manual certificate handling, permissive XML parsing or incomplete assertion validation as a priority review item. The safest posture is one where the service provider validates the full assertion context, not just the presence of a signature.
Practitioner takeaway: If a SAML forgery is plausible, assume the trust chain has been stressed, then verify certificate rotation, session invalidation and downstream access review before calling the incident closed.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org