02: The Identity Provider is the Attack Surface

*This is post 2 of 6 in Avertium's "The Trust Problem in Enterprise Security" blog series

By Sarah Clarke, Consultant - QSA and AI Architect

In April, ADT confirmed an employee's Okta single sign-on credentials had been phished. The attacker called the employee posing as IT support, walked them through a real-time adversary-in-the-middle authentication flow, and ended the call holding valid SSO tokens. From there the group, attributed to ShinyHunters, pivoted directly into Salesforce and pulled roughly ten million customer records. No malware was deployed, no lateral movement was needed, and no CVE was exploited. The IdP credential gave them everything downstream.

This wasn't an isolated event. The same group has been running the same playbook against companies using Okta, Microsoft Entra, and Google SSO since at least late 2025. Okta itself published a report in January documenting a market for adversary-in-the-middle vishing kits sold as a service. Across all of them, the compromise model is the same: an attacker who takes the IdP doesn't need to defeat each downstream application separately. The previous post in this series introduced the IdP as one of a handful of trust components most enterprises run on. Of those components, the IdP's failure cascades farthest, because everything else depends on it to know what's legitimate.

From the assessor side of the table, this is a scope failure. The diagrams accurately show the systems inside the scope boundary. What they miss is everything else the IdP touches.

what the idp actually is

Most organizations describe their identity provider as a tool. It handles single sign-on, enforces MFA, and centralizes account management. Those descriptions are accurate but they miss what makes an IdP compromise so destructive.

The IdP is the system that decides whether everything else in your environment will trust an action. When a user authenticates to Salesforce, the trust signal originates at the IdP. An EDR agent reporting up to its console uses an API key tied to a tenant the IdP defines. An AI copilot reaching into a SharePoint library does so through an OAuth grant the IdP issued.

The IdP doesn't sit alongside your other systems — they depend on it to know what's legitimate. When it falls, every downstream trust decision becomes suspect. The systems are still running. They just no longer have a reliable way to tell which authentications are real.

what this looks like in pci scope

Here's where it gets uncomfortable on the assessor’s side.

PCI DSS 4.0 scoping is driven by what stores, processes, or transmits cardholder data, and by what's connected to or could impact the cardholder data environment. Requirement 7 governs role-based access; Requirement 8 governs authentication. Both run through your IdP whether you've drawn it that way or not.

Most scoping diagrams I see show the CDE as a contained zone, with the IdP off to the side, labeled as part of "general corporate IT." That picture is wrong almost every time. Anywhere the IdP authenticates users into the CDE, authenticates admins into the systems that manage the CDE, or issues an OAuth grant for service accounts that touch cardholder data, it's in scope. All three conditions are common in real environments.

The same logic applies under HIPAA for ePHI and under SOC 2 for any service organization committing to security or confidentiality controls. Though the wording in each framework is different, the scope implication is the same.

When the IdP is in scope and the IdP is the breach, every system rooted to it lands on the assessor's interview list.

the ai layer now lives here too

There's an AI angle to this that gets less attention than it should.

When you connect an AI copilot to your SharePoint, your code repositories, your ticketing system, or your CRM, you almost certainly do it through an OAuth grant or a service principal that the IdP issues. Agents don't have a separate trust path — they ride the same identity infrastructure your humans do.

That means an IdP compromise is now also an AI compromise. An attacker who controls a federated identity can issue tokens that look exactly like a legitimate AI agent's. The agent's privileged access to data, actions, and other systems is available to anyone holding the IdP's signing keys or session state.

And because most organizations haven't built distinct monitoring for AI agent behavior, the attacker doesn't need to mimic a human. They can act through the agent. The logs show normal agent activity. The behavioral anomaly that would have flagged an unusual human user isn't there to catch a tool that runs at scale by design.

what compensating architecture looks like

I don't write posts that end with "rip out your IdP." Most organizations can't, and they shouldn't have to. What they can do is design around the assumption that the IdP will sometimes hand over the keys.

Here are a few things worth pushing on with your IdP, in rough order of leverage:

• Phishing-resistant authentication: The vishing campaigns work because push-based MFA and OTPs can be relayed by an attacker on a phone call. FIDO2 hardware keys and platform authenticators are bound to the device they were registered on, which breaks the flow. Privileged accounts, IdP admins, and break-glass accounts all need to be on a phishing-resistant factor. This is the single highest-leverage change available.
  
  
• Session and token controls: Short session lifetimes, continuous access evaluation, and conditional access policies that re-evaluate on signal changes (new device, new geography, anomalous behavior) shorten the window during which an exfiltrated token is useful.
  
  
• IdP admin separation: The accounts that administer your IdP shouldn't live inside the IdP they administer. Break-glass paths and out-of-band admin accounts exist for the scenario where the primary trust root is compromised.
  
  
• AI agent identity hygiene: Every AI agent should hold a distinct, narrowly scoped identity with explicit permissions, logged actions, and a documented owner. Treating agent identities as a separate population from human identities makes the agent's compromise look different in your logs.
  
  
• Detection at the trust edges: Instead of trying to catch a compromise inside the IdP, instrument the systems that depend on it. Unusual OAuth grants, new federation relationships, sudden token issuance patterns, MFA factor changes followed by access changes — these are signals at the trust boundary, observable from the systems doing the trusting.

While this won’t stop a determined adversary holding valid credentials, it will compress the window in which those credentials are useful and to make the post-compromise actions visible.

an exercise for you: What to do this week

A scope exercise specific to your IdP. No tooling required.

• SaaS apps,
• infrastructure consoles,
• internal apps, 
• anything with OAuth or SAML federation,
• every AI agent or service that holds an  IdP-issued critical

2. Next to your list, draw/create three columns

3. Next to each, write three things:

• Whether the system stores, processes, or transmits regulated data
• Whether the IdP's compromise would give an attacker direct access to that data
• Whether you could detect the compromise from outside the IdP itself

Most organizations can populate the first two; the third is where things break down, because confident detection from outside the IdP is rare.

That gap, between systems you've built dependencies into and systems where you could see the dependency being abused, is what an assessor should be asking about. In most environments, it's also where the next breach will originate.

 Stay tuned for our third post in the series, ”When AI Agents Pull Themselves Into Scope,” which will publish on June 17, 2026 at 10:00 am EST.