What Is a Silver SAML Attack? How It Works and How to Prevent It

Introduction

A user can have a strong password, MFA is already enabled, the login page itself may never be compromised. And yet an attacker could still gain access to a federated application without knowing the user's password or completing their MFA challenge.

That's the real problem behind Silver SAML.

Silver SAML is a post-compromise identity attack technique in which an attacker abuses a compromised key to forge authentication responses that a connected application trusts. Rather than attacking the user's credentials directly, the attacker targets something deeper in the federation relationship: the cryptographic proof used to establish that a SAML response came from a trusted Identity Provider (IdP).

The technique was disclosed by Semperis researchers in 2024 and demonstrated against cloud identity environments using externally generated SAML signing certificates, including Microsoft Entra ID. It builds on the idea behind the earlier Golden SAML attack but shifts attention toward cloud-based SAML federation.

Does that mean SAML itself is insecure? No. The bigger issue is how signing keys are generated, stored, accessed, rotated, and monitored and how carefully Service Providers validate the SAML responses they receive.

Silver SAML exposes a part of identity security that's easy to overlook. Protecting the login is only one side of the equation. Organizations also have to protect the cryptographic trust that tells applications which login results they can believe.

What Is a Silver SAML Attack?

A Silver SAML attack is a post-compromise identity attack in which an attacker uses a compromised SAML signing private key to forge authentication responses and impersonate users to federated applications. Because the forged response carries a signature the Service Provider already trusts, it may be accepted as legitimate even though the real user never authenticated.

The attack targets the trust relationship between the Identity Provider (IdP) and Service Provider (SP) rather than starting with the user's password. In a normal SAML authentication flow, the IdP authenticates the user and sends a signed SAML response containing identity information to the SP. The SP validates that signature before granting access.

Silver SAML turns that trust against the application.

If an attacker obtains the private key associated with a trusted SAML signing certificate, they may be able to generate their own signed SAML responses. Those responses can assert the identity of another user, potentially including privileged accounts, depending on the affected application's configuration and the information the attacker possesses.

Silver SAML isn't primarily a password attack, and adding another authentication factor doesn't fix a compromised signing key. If an attacker can create a correctly signed SAML response that a Service Provider (SP) already trusts, the application may accept the asserted identity without the attacker going through the victim's normal authentication process.

This is why Silver SAML shouldn't be reduced to “tampering with a SAML response.” Simply editing an assertion would normally invalidate its cryptographic signature. The attacker needs something considerably more powerful: access to signing material that allows a fraudulent response to appear authentic.

Semperis discovered the Silver SAML technique in 2024 after researching cloud SAML configurations involving externally generated signing certificates. Its proof of concept focused on Microsoft Entra ID and demonstrated how possession of such a private signing key could be abused to impersonate users to SAML-connected applications.

The attack also highlights why protecting federation infrastructure requires more than protecting user credentials. A stolen password affects an account. A compromised signing key can potentially undermine the trust relationship used by multiple identities accessing an affected application.

Is Silver SAML a Vulnerability or an Attack Technique?

Calling Silver SAML a conventional software vulnerability can be misleading. Microsoft reviewed the behavior reported by Semperis and classified it as by design, rather than treating it as a product vulnerability requiring a traditional security patch.

Silver SAML is better understood as an attack technique that abuses compromised federation signing credentials. The dangerous condition arises when an attacker gains access to a trusted private signing key, particularly one generated or managed outside the identity provider in a way that allows the key material to be extracted.

That changes the defensive question. Instead of asking only, “Which patch fixes Silver SAML?”, organizations need to ask harder questions: Who can access our SAML signing keys? Can those keys be exported? Where are they stored? Who can replace them? And would we notice if the federation configuration changed unexpectedly?

Those questions get you much closer to the actual risk.

Why Compromised Signing Keys Make Silver SAML Possible

In a normal SAML authentication flow, a Service Provider (SP) trusts authentication responses signed by a trusted Identity Provider (IdP). Rather than storing user passwords, the SP verifies the signature attached to a SAML assertion before granting access.

This trust depends on a signing certificate. The SP uses the public certificate to verify signatures, while the IdP protects the corresponding private signing key.

Silver SAML becomes possible when an attacker gains access to that private key. Instead of modifying a legitimate SAML response, the attacker can create a completely new response and sign it using the trusted key. Because the signature is valid, the SP may accept the response as authentic.

The risk is particularly relevant in environments using externally generated SAML signing certificates. If private keys are exportable, copied between systems, or stored insecurely, attackers may be able to obtain signing material outside the Identity Provider itself.

This is why protecting signing keys is as important as protecting user credentials. Once a trusted signing key is compromised, the attacker targets the federation trust relationship rather than the login process.

How Does a Silver SAML Attack Work?

A Silver SAML attack doesn't usually begin with SAML itself. The attacker first needs access to something they should never possess: the private key associated with a SAML signing certificate trusted by the target application. That makes Silver SAML a post-compromise technique rather than an initial entry point.

Once that signing material is exposed, the attacker's position changes. Instead of trying to steal a user's password, intercept an OTP, or satisfy an MFA challenge, they may attempt to create a SAML response that tells the Service Provider the target user has already been authenticated.

A simplified attack path looks like this:

The first compromise is critical. An externally generated signing certificate may have been created on an administrator workstation, server, or another system before being uploaded to the identity environment. If the private key remains exportable or copies are stored insecurely, compromising one of those locations can expose the signing material.

The attacker then needs enough information about the federation relationship to construct a response the Service Provider will accept. That can include details about the intended application, expected issuer, audience, destination, user identity, and other assertion attributes. The exact requirements vary because Service Providers don't all validate SAML responses in exactly the same way.

Here’s where it gets interesting. The attacker isn't trying to alter a legitimate response after it has been signed. Doing that should invalidate the signature. Instead, a fraudulent response can be created and then signed using the compromised private key.

Cryptographically, the signature may validate.

That doesn't mean every forged response will automatically succeed. A properly configured Service Provider should perform additional validation beyond checking the signature, including expected issuer, audience, destination, time conditions, and request correlation where applicable. Weak or incomplete validation can make an already serious signing-key compromise even more dangerous.

Silver SAML in SP-Initiated Authentication

In an SP-initiated SAML flow, the authentication process begins when the user attempts to access the Service Provider. The SP generates an authentication request and sends the user toward the Identity Provider.

That request can provide an additional piece of information for defensive validation. When the IdP returns its SAML response, the SP can correlate the response with the authentication request it originally created, including through the InResponseTo value where applicable.

This doesn't make a compromised signing key harmless. But strong request-response correlation gives the Service Provider another condition to validate instead of trusting the signature alone.

Silver SAML in IdP-Initiated Authentication

IdP-initiated SAML presents a different challenge because the authentication flow doesn't begin with an authentication request from the Service Provider. The user starts from the Identity Provider side, and a SAML response is sent to the application without a preceding SP authentication request to correlate against.

That removes one potential validation signal.

In its Silver SAML research, Semperis demonstrated an IdP-initiated scenario in which a forged SAML response could be sent directly to the Service Provider without the normal authentication interaction with Microsoft Entra ID. This is one reason organizations should examine whether IdP-initiated SSO is actually necessary for a particular application rather than enabling it by default.

Still, Silver SAML shouldn't be interpreted as “IdP-initiated SAML is insecure.” The compromised signing key remains the fundamental problem. Flow design and validation determine how many additional barriers an attacker encounters after that compromise.

And that leads to the uncomfortable part of the attack: the victim's normal login may never occur at all. No stolen password. No intercepted OTP. Potentially no MFA prompt for the victim to approve or reject.

The application is being presented with fraudulent proof that authentication has already happened.

That is also what separates Silver SAML from many familiar account-takeover techniques and why the next comparison with Golden SAML matters.

Silver SAML vs Golden SAML: What’s the Difference?

Silver SAML and Golden SAML exploit the same fundamental weakness: if an attacker obtains a trusted SAML signing private key, they may be able to create authentication assertions that federated applications accept as legitimate. Neither attack needs to crack SAML encryption or defeat the underlying cryptography.

The difference is mainly where that trusted signing material comes from and the identity environment being targeted.

The comparison is easier to see side by side:

Area	Golden SAML	Silver SAML
Primary Environment	Traditionally associated with AD FS and hybrid/on-premises federation	Cloud identity environments, demonstrated with Microsoft Entra ID
What the Attacker Targets	Federation token-signing private key	Private key of an externally generated SAML signing certificate
What Is Forged	Trusted SAML authentication tokens/assertions	Trusted SAML responses/assertions
Victim Password Required	No	No
Victim MFA Required	Not necessarily	Not necessarily
Main Goal	Impersonate users to federated applications	Impersonate users to affected SAML applications
Attack Stage	Post-compromise	Post-compromise
Underlying Problem	Compromise of federation signing trust	Compromise of application signing trust

The distinction around scope matters. With Golden SAML, compromise of federation signing infrastructure can have broad consequences across services trusting that federation authority. Silver SAML can be more application-specific because the attacker may compromise signing material associated with a particular SAML enterprise application.

That doesn't make it trivial. A single affected application could still contain sensitive customer information, administrative functions, financial data, source code, or other high-value resources.

There is another practical difference. Golden SAML became closely associated with attacks against on-premises and hybrid identity infrastructure, particularly after federation compromise gained wider attention during the SolarWinds incident. Silver SAML highlights how similar trust assumptions can surface even as organizations move more authentication infrastructure into the cloud.

Cloud-hosted identity doesn't remove the need to protect signing keys.

The naming can make these attacks sound like two entirely separate techniques. They aren't. Both point to the same uncomfortable security lesson: a valid cryptographic signature proves that the corresponding private key was used. It cannot prove that the person using that private key was authorized to do so.

Once trusted signing material is stolen, the problem moves beyond ordinary credential theft. That is precisely why passwords and even MFA may not stop the next stage of a Silver SAML attack.

Why Silver SAML Can Bypass Passwords and MFA

Passwords and multi-factor authentication protect the point where a user proves their identity to an Identity Provider. Silver SAML targets a different part of the process. Instead of trying to pass the user's authentication challenge, the attacker attempts to create the trusted SAML result that would normally come after successful authentication.

That's why simply adding another authentication factor doesn't address the core Silver SAML attack path.

In a legitimate federated login, a user may enter a password and then complete an MFA challenge using an authenticator app, passkey, security key, or another approved factor. Once the Identity Provider is satisfied, it generates a signed SAML response that tells the Service Provider who authenticated and provides the information needed to continue the session.

With Silver SAML, the attacker may never participate in that sequence. If they already possess the trusted SAML signing private key and can construct a response that satisfies the Service Provider's validation requirements, they can attempt to forge the artifact that represents a successful authentication outcome.

The user's password isn't being guessed or stolen. There may be no OTP to intercept. The victim may never receive a push notification or security-key prompt.

In Semperis's proof-of-concept research, this technique was used to impersonate users to SAML-connected applications without possessing their passwords or MFA devices. That demonstrates why Silver SAML belongs in a different category from familiar credential-based account takeover.

Does That Make MFA Useless Against Silver SAML?

No. That conclusion would go too far.

MFA remains an important control for protecting user accounts and, critically, the administrative identities that can access identity configuration, certificate-management systems, and other sensitive infrastructure. Phishing-resistant MFA can make it harder for an attacker to obtain the privileged access that might eventually expose or modify signing credentials.

But once a trusted SAML signing private key has already been compromised, requiring MFA during the normal user login does not repair that trust relationship.

This distinction is easy to miss. Security teams may see MFA enabled for an application and assume that any successful session must have passed through the expected MFA policy. With a forged SAML response, that assumption may no longer hold.

The better defensive approach is layered. Protect privileged identities with strong authentication, restrict access to signing keys and federation configuration, prevent unnecessary private-key export, monitor certificate changes, and make sure Service Providers validate more than the presence of a trusted signature.

MFA still belongs in that strategy. It just shouldn't be treated as a Silver SAML fix.

The attack is a useful reminder of where federated authentication ultimately places its confidence. If an application trusts a signed identity assertion, protecting the authority that can produce that signature is just as important as protecting the user's login credentials.

What Makes an Environment Vulnerable to Silver SAML?

Silver SAML isn't triggered simply because an organization uses SAML or Microsoft Entra ID. The attack requires a specific chain of conditions, beginning with access to trusted SAML signing material. The way certificates are generated, stored, administered, and validated can either narrow that opportunity or make exploitation easier after an initial compromise.

That distinction matters because organizations shouldn't respond to Silver SAML by treating every SAML deployment as inherently unsafe. The more useful question is whether the environment exposes the signing trust an attacker would need.

Externally Generated SAML Signing Certificates

The scenario highlighted in the original Silver SAML research involved externally generated SAML signing certificates imported into Microsoft Entra ID. When a certificate and its private key are created outside the identity provider, the organization becomes responsible for protecting that private key throughout its lifecycle. Copies can become the problem.

A certificate might be generated on an administrator workstation, exported as a PFX file, transferred to another system, stored for backup, or shared during application configuration. Each additional copy or storage location creates another place where the private signing key could potentially be exposed.

An externally generated certificate isn't automatically insecure. But its private key needs to be treated as a high-value identity credential rather than an ordinary configuration file.

Exportable or Poorly Protected Private Keys

A signing key becomes considerably more dangerous when it can be easily exported or copied from the system where it was generated.

Attackers don't need to remain inside the Identity Provider if they can take the private key elsewhere. Once they possess usable signing material, they may be able to generate fraudulent SAML responses independently of the normal IdP authentication process.

Private keys stored in loosely protected file shares, administrator folders, scripts, backups, messaging attachments, or other uncontrolled locations can therefore create unnecessary exposure.

The problem isn't that the cryptography is weak. The secret that gives the cryptography its authority has escaped.

Excessive Administrative Permissions

Private-key theft isn't the only path worth considering. Administrative identities with permission to modify enterprise applications, manage signing certificates, or alter federation configuration can also become high-value targets.

An attacker who compromises an overly privileged administrative account may be able to change trusted signing material or manipulate application configuration in ways that support identity impersonation.

Least privilege matters here for a very practical reason. The fewer identities that can alter federation trust, the fewer accounts an attacker can target to gain that capability.

Administrative permissions should also be reviewed over time. Temporary access granted for an integration project can quietly become permanent access if nobody removes it afterward.

Weak Service Provider Validation

A valid signature should never be the only question a Service Provider asks about a SAML response.

The SP should also validate relevant conditions such as the expected issuer, audience, destination, assertion validity period, and Assertion Consumer Service (ACS) endpoint. In SP-initiated authentication, request-response correlation can add another useful control by checking that the incoming response corresponds to an authentication request the application actually created.

Here’s where teams sometimes get caught out: a response can be correctly signed and still be inappropriate for the application receiving it.

Strong validation makes the attacker satisfy more conditions than simply producing a trusted signature. It doesn't make a stolen signing key safe, but it can reduce the room available for abuse.

Unnecessary Reliance on IdP-Initiated SAML

IdP-initiated SAML can be useful, particularly when users launch applications from an identity-provider portal. But because the flow begins without an authentication request from the Service Provider, the SP doesn't have an original request to correlate with the incoming response.

That difference becomes relevant to Silver SAML.

Organizations should therefore consider whether each application genuinely requires IdP-initiated SSO. Where SP-initiated authentication is practical, request-response correlation can provide another validation signal. This isn't a reason to label all IdP-initiated SAML insecure; it is a reason to avoid enabling authentication paths that aren't needed.

Taken together, these conditions point toward a broader issue. Silver SAML risk increases when signing keys are portable, access to federation configuration is broad, and Service Providers place too much confidence in signature validation alone. Finding those conditions before an attacker does is the next challenge.

How to Detect a Silver SAML Attack

Silver SAML can be difficult to detect because a forged SAML response may carry a cryptographically valid signature. To the Service Provider, the response can look like it came from a trusted identity source. Traditional alerts built around failed passwords, repeated MFA prompts, or suspicious credential attempts may never fire because the attacker can avoid the victim's normal login process altogether.

Detection therefore needs to look beyond login failures and focus on changes to federation trust, signing certificates, administrative activity, and inconsistencies between IdP and application telemetry.

Monitor Unexpected SAML Signing Certificate Changes

Changes to a SAML signing certificate deserve scrutiny, especially when they happen outside an approved certificate rotation or application maintenance window.

Security teams should know which certificate is expected for each important SAML integration, when it was introduced, who authorized it, and when it is scheduled for replacement. An unexpected certificate, signing-key thumbprint, or configuration change should be investigated rather than dismissed as routine administration.

That doesn't mean every certificate change is an incident. Certificates expire and rotation is normal. Context is what separates expected maintenance from suspicious activity.

Watch Changes to Application Credentials and Permissions

Silver SAML risk isn't limited to someone stealing an existing private key. Attackers who compromise sufficiently privileged identities may attempt to modify the signing configuration itself.

Changes involving enterprise application credentials, service principals, application ownership, signing certificates, or administrators with permission to manage these objects can therefore provide useful warning signals.

For Microsoft Entra ID environments, Semperis specifically recommends monitoring changes involving SAML token-signing configuration, including the PreferredTokenSigningKeyThumbprint, and correlating those events with changes to service principal credentials.

A certificate change followed shortly by unusual application access deserves a closer look.

Correlate IdP Authentication With Application Access

One of the more useful Silver SAML detection ideas comes from asking a simple question:

Did the Identity Provider actually authenticate this user?

If a sensitive SAML application records a successful session for an administrator at 2:15 a.m., but the Identity Provider has no corresponding authentication activity that explains that session, the mismatch may warrant investigation.

This isn't always straightforward. IdP-initiated flows, session reuse, application logging differences, clock skew, and retention gaps can all complicate correlation. Still, comparing Service Provider access with identity-provider authentication telemetry can reveal activity that isolated log analysis misses.

This is particularly useful because a forged response may bypass the normal IdP authentication path.

Look for Unusual SAML Access Patterns

Behavior after authentication can provide additional clues. Security teams can look for unusual access to sensitive applications, unexpected privileged sessions, unfamiliar source locations, abnormal timing, or sudden access patterns that don't match the user's normal behavior.

None of these signals proves Silver SAML on its own. An administrator traveling internationally could generate unusual activity for perfectly legitimate reasons.

The value comes from combining signals. An unexplained signing-certificate change, followed by application access from an unusual source, combined with no matching IdP authentication event tells a very different story than any one of those events alone.

Establish a Known Baseline

Detection gets considerably harder when nobody knows what “normal” federation configuration looks like.

Organizations should maintain an inventory of critical SAML applications, expected signing certificates, certificate thumbprints, expiration dates, authorized administrators, supported authentication flows, and planned rotation windows. Changes can then be evaluated against something concrete.

Without that baseline, a malicious configuration change may look exactly like routine maintenance.

Silver SAML also exposes a limitation of authentication monitoring that focuses only on users. Sometimes the identity being abused isn't the credential that needs the most attention—the trusted signing infrastructure is.

Monitoring both sides of that relationship gives security teams a better chance of spotting the attack before a forged identity becomes an accepted session.

How to Prevent and Mitigate Silver SAML Attacks

There isn't a single security setting that makes Silver SAML disappear. The attack depends on abusing federation trust, so prevention has to protect the signing key, restrict who can change that trust, strengthen what Service Providers validate, and make suspicious changes visible.

This is also why treating Silver SAML as a patch-management problem misses the point. If a trusted private signing key is stolen, updating an application doesn't automatically make that key untrusted. The federation configuration itself needs attention.

Prefer IdP-Generated, Non-Exportable Signing Keys

Where the identity platform supports it, organizations should prefer signing keys whose private material is generated and protected by the Identity Provider rather than creating exportable keys elsewhere and importing them.

This was one of the central recommendations from the original Silver SAML research for Microsoft Entra ID environments. When Entra ID generates the signing certificate, the corresponding private key isn't exposed through the normal configuration workflow for administrators to download and move between systems.

Externally generated certificates may still be necessary in some environments. If they are, the private key should be treated as a highly sensitive authentication asset. Limit where it can exist, restrict who can access it, and avoid unnecessary copies.

A .pfx file sitting in an administrator's downloads folder shouldn't become part of the long-term federation architecture.

Restrict Who Can Manage SAML Applications and Certificates

The ability to modify a SAML application's signing configuration is powerful. Administrative access to enterprise applications, service principals, signing certificates, and related identity configuration should therefore follow least-privilege principles.

Review who can create or replace signing credentials. Remove permissions that were granted temporarily and never taken back. Protect privileged administrators with strong authentication, ideally using phishing-resistant methods where appropriate.

MFA matters here, even though it doesn't directly stop a forged SAML response after the signing key has been compromised. Strong authentication can help prevent attackers from obtaining the administrative access needed to alter federation configuration in the first place.

Protect Private Signing Keys Throughout Their Lifecycle

Signing-key security starts before the certificate reaches the identity platform.

Organizations using externally generated certificates should consider where the key pair is created, whether the private key can be exported, where backup copies exist, how the certificate is transferred, who can retrieve it, and what happens to old key material after rotation.

Avoid sending private signing keys through email, chat, ticket attachments, or other uncontrolled channels. Where possible, use hardened key-management mechanisms and tightly restricted administrative systems.

Rotation deserves equal attention. Replacing a certificate doesn't help if forgotten copies of the old private key remain usable against applications that still trust it.

Strengthen Service Provider Validation

A Service Provider should verify more than whether a SAML response contains a valid signature.

Depending on the implementation, validation should include the expected issuer, audience, destination, assertion validity period, signature, and Assertion Consumer Service endpoint. For SP-initiated authentication, the application should also correlate the incoming response with the authentication request it generated, including validating InResponseTo where appropriate.

Time limits matter too. Assertions shouldn't remain acceptable indefinitely. Keeping validity windows appropriately narrow reduces opportunities for replay and misuse.

These checks don't make a compromised signing key harmless. They do force an attacker to satisfy more of the federation contract before a response is accepted.

Prefer SP-Initiated SAML Where It Fits

SP-initiated SAML begins with an authentication request created by the application. That gives the Service Provider something to correlate against when the SAML response returns.

IdP-initiated SAML doesn't provide that same request-response relationship because no SP authentication request exists at the beginning of the flow.

Where an application doesn't genuinely require IdP-initiated SSO, organizations can consider using SP-initiated authentication instead. The goal isn't to declare one SAML flow universally secure and the other unsafe. It is to retain additional validation signals when the application's user experience and architecture allow it.

Monitor and Document Certificate Rotation

Certificate rotation should be predictable enough that an unexpected change stands out.

Maintain records of current signing certificates, thumbprints, owners, expiration dates, planned rotation windows, and affected Service Providers. Where supported, automated metadata and certificate rollover can reduce manual configuration errors, but changes should still be monitored.

This becomes particularly valuable during an incident. Security teams shouldn't have to reconstruct from old tickets which certificate each application was supposed to trust.

Consider OIDC for Suitable Applications

Silver SAML doesn't mean organizations should immediately replace every SAML integration. SAML is still widely used, particularly for enterprise federation and applications built around SAML-based SSO.

For newer applications that support modern alternatives, however, OpenID Connect (OIDC) may be worth considering as part of the architecture decision. Moving to OIDC changes the federation model and can remove this specific SAML signing-certificate attack path, although OIDC introduces its own implementation and key-management requirements.

Migration should therefore be driven by application requirements and security architecture—not by the assumption that changing protocols automatically removes identity risk.

The practical lesson from Silver SAML is narrower and more useful: don't let possession of a portable signing key become an unchecked authority to impersonate users. Keep signing material tightly controlled, limit administrative access, validate federation responses rigorously, and monitor the trust configuration itself.

Here is a quick Silver SAML prevention checklist:

• Inventory all SAML certificates

• Disable exportable keys

• Review federation admins frequently

• Monitor any thumbprint changes

• Review IdP initiated SSO

What to Do If a SAML Signing Key Is Compromised

A compromised SAML signing private key should be treated as an identity security incident, not simply as an expired or misplaced certificate. Once an unauthorized party has access to trusted signing material, changing a user's password or resetting their MFA factors doesn't address the underlying problem. The attacker may still possess the key that federated applications use to establish trust.

The immediate priority is to stop affected Service Providers from trusting the compromised signing key.

Organizations should generate a replacement key pair through an approved, securely controlled process and update the federation configuration for affected applications. The compromised certificate or signing credential should be removed from active trust as quickly as the environment allows.

This needs coordination: changing the Identity Provider side without updating Service Providers correctly can interrupt legitimate SSO, while leaving the old certificate trusted for too long extends the exposure window.

Traditional certificate revocation also shouldn't be treated as the entire response. SAML federation commonly establishes signing trust through configured certificates or federation metadata rather than relying solely on browser-style certificate revocation checks. The affected federation relationships therefore need to be explicitly reviewed and updated.

Once trust has been replaced, the investigation moves backward. How did the private key become accessible?

Check where the certificate was originally generated, whether the key was exportable, which administrators or systems could access it, and whether copies were stored elsewhere. Workstations, servers, backups, deployment scripts, shared drives, password vaults, ticket attachments, and other administrative systems may all need review depending on how the certificate was handled.

Then look at what may have happened while the key was exposed. Review Identity Provider audit logs alongside Service Provider access logs and other relevant security telemetry. Unexpected privileged sessions, application access without corresponding IdP authentication, changes to SAML configuration, or unusual activity involving affected users can help establish whether the stolen key was actually abused.

Existing sessions deserve attention as well. Where supported and appropriate, revoke sessions or tokens associated with potentially impersonated accounts and require fresh authentication after the federation trust has been restored. High-privilege identities should receive particular scrutiny because a forged session involving an administrator can create additional persistence beyond the original SAML attack.

There is another mistake worth avoiding: rotating the key and declaring the incident closed.

If an attacker obtained the private key because an administrator endpoint was compromised, excessive permissions existed, or signing material was routinely exported and shared, generating a new certificate without fixing that exposure can recreate the same problem with a fresh key.

The recovery process should therefore end with changes to how signing credentials are managed. Reduce unnecessary administrative access, remove forgotten copies of private keys, tighten certificate-generation procedures, establish clear rotation ownership, and improve monitoring around federation configuration changes.

A compromised password can often be reset. A compromised SAML signing key requires something broader: re-establishing which cryptographic authority applications are allowed to trust and determining what happened while that trust was exposed.

How Silver SAML Changes SAML Security Strategy

Silver SAML doesn't mean SAML is fundamentally broken. It exposes something more specific: federated authentication is only as trustworthy as the cryptographic keys, configuration, and validation rules supporting that federation.

For years, many identity security programs have concentrated heavily on what happens before authentication succeeds. Strengthen passwords. Add MFA. Detect suspicious login attempts. Block credential stuffing. Train users to recognize phishing. Those controls remain important, but Silver SAML targets a different layer.

The attacker may not need to defeat the user's authentication at all.

That shifts some attention from protecting individual credentials to protecting the authority that asserts identities on behalf of many users. A SAML signing private key can carry considerably more security weight than a single password because applications rely on it to decide whether an authentication assertion came from a trusted source.

Here's where teams can underestimate the risk. A signing certificate may be treated as routine SSO configuration, something generated during integration, stored somewhere convenient, and revisited when expiration approaches. The private key behind that certificate deserves a very different level of attention.

Organizations should know where signing keys are generated, whether they are exportable, where copies exist, who can access or replace them, and which applications trust them. Certificate rotation also needs to be treated as part of the identity lifecycle rather than a last-minute maintenance task.

Service Providers have a role too. Signature verification is essential, but it shouldn't stand alone. Validating issuer, audience, destination, timing conditions, expected endpoints, and request correlation where applicable creates additional checks around the assertion being presented.

Monitoring needs to expand in the same direction. Authentication logs tell security teams what the Identity Provider believes happened. Application access logs show what the Service Provider accepted. Comparing the two can reveal gaps that neither side exposes by itself.

This also changes how organizations should think about MFA. Strong MFA, particularly phishing-resistant authentication, remains valuable for protecting users and privileged administrators. But security teams shouldn't assume that seeing “MFA enabled” beside an enterprise application means every accepted SAML session necessarily passed through that MFA process.

Silver SAML demonstrates why identity security can't stop at the login screen.

Passwords and MFA protect authentication. Signing-key custody, federation configuration, certificate lifecycle management, rigorous assertion validation, and cross-system monitoring protect the trust created after authentication. Mature SAML security needs both.

How LoginRadius Helps Strengthen SAML Authentication

Silver SAML puts a spotlight on an often-overlooked part of federated identity: securing the authentication flow isn't enough if the trust configuration behind it is poorly managed. Organizations also need a deliberate approach to SAML integration, assertion validation, authentication policies, and the broader identity journey surrounding federation.

This is where a Customer Identity and Access Management (CIAM) platform such as LoginRadius fits. LoginRadius supports standards-based SAML federation, helping businesses connect applications and identity systems without building and maintaining every authentication flow independently.

Within a SAML environment, proper configuration remains critical. The Service Provider needs to validate the SAML response it receives, including relevant elements such as the issuer, audience, signature, destination, and assertion validity. Authentication and federation policies should also be applied consistently rather than being recreated differently across applications.

LoginRadius can complement SAML-based SSO with broader authentication capabilities, including multi-factor authentication, passwordless authentication, and other modern authentication options. These controls don't replace the need to secure SAML signing keys, nor should they be presented as a direct fix for Silver SAML. They address different parts of the identity architecture.

That distinction is worth keeping clear. Silver SAML is fundamentally a federation trust problem. If a trusted signing private key is compromised, the response has to include securing and rotating that signing material, reviewing federation configuration, and investigating potential misuse. Adding another login factor after the fact doesn't repair a compromised cryptographic trust relationship.

A stronger identity architecture, therefore, treats SAML security as more than just enabling SSO. It considers how users authenticate, how assertions are validated, how federation relationships are configured, and how authentication requirements change with risk.

For organizations modernizing customer authentication while still supporting SAML-based federation, LoginRadius provides a centralized CIAM foundation for bringing those identity experiences together without treating SAML, MFA, or passwordless authentication as isolated security controls.

Conclusion: Silver SAML Is a Trust-Key Problem, Not Just a Login Problem

Silver SAML exposes an uncomfortable gap in the way federated authentication is sometimes secured. An organization can enforce strong passwords, require MFA, and closely monitor failed login attempts and still face serious risk if a trusted SAML signing private key is compromised.

The reason comes down to where the attack happens. Silver SAML doesn't need to beat the user's normal authentication process. It abuses the cryptographic trust that applications rely on after authentication is supposed to have succeeded. A forged SAML response signed with compromised trusted key material may look legitimate to the Service Provider unless other controls expose the abuse.

The response, then, has to go beyond the login screen. Protect signing keys as high-value identity assets. Limit who can modify federation configuration. Monitor unexpected certificate changes. Validate SAML responses rigorously. And have a clear plan for rotating signing credentials and investigating affected sessions if a key is ever exposed.

SAML can still support secure enterprise federation. Silver SAML simply makes the conditions clearer: trust should never depend on a sensitive signing key that nobody is closely protecting or monitoring.

For businesses supporting SAML alongside modern customer authentication, LoginRadius provides a centralized CIAM foundation for building secure, standards-based identity experiences across applications.

Want to strengthen your SAML authentication and reduce gaps across your broader identity architecture? Talk to the LoginRadius identity experts to see how secure federation, modern authentication, and centralized customer identity management can work together.

FAQs

Q: What is a Silver SAML attack?

A: Silver SAML is a post-compromise attack where an attacker uses a compromised SAML signing private key to forge trusted authentication responses and potentially impersonate users to federated applications.

Q: How does a Silver SAML attack work?

A: An attacker obtains a trusted SAML signing private key, creates a fraudulent SAML response, and signs it with that key. If the Service Provider accepts the response, the attacker may gain access as the impersonated user.

Q: Is Silver SAML a Microsoft Entra ID vulnerability?

A: Not exactly. Semperis demonstrated Silver SAML using externally generated signing certificates in Entra ID, while Microsoft classified the reported behavior as by design rather than a software vulnerability requiring a traditional patch.

Q: What is the difference between Silver SAML and Golden SAML?

A: Both abuse compromised SAML signing keys to forge trusted authentication. Golden SAML is traditionally associated with federation infrastructure such as AD FS, while Silver SAML demonstrated a similar technique against cloud SAML configurations.

Q: Can Silver SAML bypass MFA?

A: Yes, potentially. Silver SAML can bypass the victim's normal authentication process by forging the trusted SAML result that would ordinarily be generated after successful authentication, including MFA.

Q: Can Silver SAML bypass passwords?

A: Yes. An attacker with the required signing key may not need the victim's password because the attack targets the federated authentication result rather than attempting to complete the user's normal login.

Q: What type of certificate does Silver SAML target?

A: The original research focused on externally generated SAML signing certificates and their private keys. If the trusted private signing key is compromised, it may be abused to create fraudulent signed SAML responses.

Q: How can organizations detect Silver SAML?

A: Monitor unexpected signing-certificate and federation configuration changes, privileged administrative activity, and unusual SAML application access. Correlating Service Provider sessions with IdP authentication logs can also reveal suspicious gaps.

Q: How can Silver SAML attacks be prevented?

A: Protect SAML signing private keys, prefer non-exportable IdP-managed keys where appropriate, restrict federation administration, strengthen SP validation, monitor certificate changes, and maintain secure key-rotation processes.

Q: Are IdP-initiated SAML flows more exposed to Silver SAML?

A: IdP-initiated SAML lacks the request-response correlation available in SP-initiated flows, removing one useful validation signal. The fundamental Silver SAML risk, however, remains compromise of trusted signing material.

Q: Is SAML still secure after the Silver SAML disclosure?

A: Yes. Silver SAML doesn't break the SAML protocol or its cryptography. It demonstrates why organizations must protect signing keys, carefully manage federation trust, and rigorously validate SAML responses.

Q: Should organizations replace SAML with OIDC?

A: Not necessarily. SAML is still widely used for enterprise federation. OIDC may be appropriate for newer applications, but protocol choice should reflect architecture, compatibility, and security requirements rather than Silver SAML alone.

Q: Who discovered Silver SAML?

A: Silver SAML was publicly disclosed by Semperis researchers in 2024 as part of research into cloud SAML environments and externally generated signing certificates.

Q: Is Silver SAML related to the SolarWinds attack?

A: Not directly. However, the SolarWinds incident demonstrated how compromise of trusted federation signing infrastructure could enable identity impersonation attacks, increasing industry attention on federation trust risks.