What attacks target SPID?

What kinds of attacks most often target SPID?

SPID is usually attacked by techniques that try to capture or replay trust, not by breaking the identity protocol itself. Phishing aims at the user, SIM swap aims at the phone number used for recovery or second-factor delivery, and account takeover aims at the account state. Fraudulent authentication requests pressure relying services to accept assertions they should challenge more carefully.

Those attack types sit at different points in the trust chain. Phishing and social engineering try to steal credentials or one-time codes. SIM swap shifts control of a recovery path. Account takeover often follows when an attacker combines stolen credentials, weak recovery, or session abuse. Fraudulent authentication requests exploit weak validation at the service side rather than the identity provider side.

SPID deployments are safest when the relying service treats every authentication event as something to validate, not simply to accept. The practical question is whether the service checks the integrity, freshness, and audience of the assertion and whether it reacts to unusual enrolment, recovery, or login patterns that often precede abuse.

How attackers turn SPID abuse into account compromise

The most common path is to start with something users or help desks will trust, then pivot into the account lifecycle. A successful phishing message may collect credentials or an MFA response. A SIM swap may let an attacker intercept recovery steps or second-factor delivery. Once the attacker can authenticate, they can often change recovery data, add new devices, or exploit weak session handling to keep access.

Relying services are especially exposed when they assume that any successful authentication is legitimate enough to grant full access. That assumption breaks down if the service does not distinguish normal sign-in from high-risk sign-in, unusual device enrolment, or a recovery action that should trigger extra scrutiny. Attacks become much more effective when the service fails to correlate login success with transaction risk.

For a broader view of how identity compromise, token theft and service-account abuse are used in real incidents, see The State of NHI & AI Agent Breach Report 2026, which shows how stolen access material and compromised trust paths are repeatedly used after initial entry.

What defenders should watch in SPID-facing environments

Defenders should look for signals that the trust relationship is being stressed rather than only watching for repeated password failures. Bursts of failed logins can be a precursor, but unusual enrolment activity, recovery changes, sudden second-factor resets, and high-risk transactions after a fresh authentication are often more revealing. The goal is to detect when an attacker is trying to convert one foothold into durable access.

Relying services also need to validate authentication assertions correctly. That means checking the intended audience, rejecting stale or replayed assertions, and making sure the authentication result matches the service context. Where possible, use phishing-resistant second factors and step up verification for recovery, device changes, and unusual transaction patterns.

For identity assurance and phishing-resistant authentication patterns, NIST SP 800-63 Digital Identity Guidelines is the most useful reference point. For service-side control design, NIST Cybersecurity Framework 2.0 helps teams frame detection and response around identity misuse as an operational risk.

Risk and Threat Considerations

SPID abuse is risky because the attacker does not need to defeat the entire identity system, only the weakest trust edge around it. If phishing, recovery workflows, or relying-service validation are weak, an attacker can move from a stolen credential or intercepted factor to durable account control. That makes SPID compromise particularly sensitive where the account can approve transactions or access regulated services.

Failure mechanism: An attacker captures credentials, diverts a recovery path, or submits a fraudulent authentication request, then relies on weak assertion validation or weak step-up controls to gain trusted access.

Impact: The result can be account takeover, fraudulent sign-in acceptance, unauthorized transactions, and repeated abuse of the relying service even after the original theft vector is discovered.

Practitioner Guidance

What to verify: Confirm that relying services validate the full authentication context, not only the fact that a login succeeded. Freshness, audience, recovery events, and step-up triggers should be checked independently, because that is where replay and fraud usually surface.

What to prioritise: Put the most scrutiny on recovery and enrolment flows. If those paths are easy to trigger or hard to observe, they often become the attacker’s shortest route to persistent access.

Practitioner takeaway: The key judgment is to treat SPID compromise as a trust-validation problem, not just a credential problem; strong second factors help, but only if the relying service also resists replay, fraud, and abnormal recovery behaviour.

Related resources from NHI Mgmt Group

• Guide: Digital Identity, eID and Identity Wallets Guide
• Who should own identity risk when attacks target both people and third-party access?
• How should security teams handle vishing attacks that target SaaS support workflows?
• Why do supply-chain attacks increasingly target secrets instead of just code integrity?
• Why do supply chain attacks target package publishing and lockfiles so often?