The OAuth Graph Is Your New Perimeter: Lessons From 2026's Supply-Chain Breaches

When the Salesloft Drift breach widened through 2025 and into early 2026, the attackers didn't kick down anyone's front door. They walked in through a hallway most companies forgot they'd built. A single compromised OAuth token, tied to a marketing chatbot integration, gave them a path into hundreds of downstream Salesforce environments. No phished passwords. No malware. Just a permission that someone, somewhere, had granted months earlier and never looked at again.

That pattern repeated all year. The breach didn't spread through stolen credentials — it spread through trust relationships that nobody was watching. And if you run a UK SME on Microsoft 365 and Azure, you almost certainly have dozens of those relationships sitting in your tenant right now.

What an OAuth grant actually is

Every time someone in your business clicks "Allow" on a screen asking an app to access their mailbox, calendar, files, or Teams chats, they create an OAuth grant. The app gets a token. That token lets it read or write data on a user's behalf — often indefinitely, often without ever needing the user's password again.

This is the plumbing behind the convenience everyone loves. A scheduling tool that reads your calendar. A CRM that syncs contacts. An AI note-taker that joins your meetings. A PDF signer that pulls files from SharePoint. Each one is a tidy little connection. Multiply that across thirty staff and three years of "just trying out" various tools, and you have a sprawling web of standing access that no one drew on a diagram.

That web is your real perimeter. Your firewall and your VPN protect a boundary that attackers increasingly ignore. They go for the SaaS-to-SaaS trust instead, because it's quieter, it's persistent, and it's almost never reviewed.

Why this is a supply-chain problem, not just an app problem

The word "supply chain" makes people picture container ships and dodgy hardware. In software, your supply chain is every vendor whose code touches your data. When you grant an app access to Microsoft 365, you inherit that vendor's security posture. If they get breached, the attacker inherits your access.

That's exactly what happened with the Drift incident. Customers who had connected the chatbot to their Salesforce never did anything wrong themselves. The vendor was compromised, and the token they'd been issued became a skeleton key. Snowflake customers learned a similar lesson in 2024 when valid credentials and tokens — not exploits — opened the doors. By 2026, attackers had clearly settled on a favourite tactic: don't break in, log in with something you were already given.

The uncomfortable part for SMEs is that token revocation often isn't on the breached vendor's critical path. When they post a status update saying "affected customers should rotate credentials," the burden lands on you. If you don't know which apps hold tokens in your tenant, you can't act, and the access just sits there.

The three failures that show up every time

Look at the post-mortems from the year's incidents and the same problems keep appearing.

Over-permissioned consent. An app asks for Mail.ReadWrite and Files.ReadWrite.All when it only needed to read one calendar. Users click Allow because the screen is confusing and they want to get on with their work.

User consent left wide open. In a default or poorly configured Microsoft 365 tenant, ordinary users can authorise third-party apps to access their own data without an admin ever seeing it. That's how shadow integrations accumulate.

No expiry, no review. OAuth refresh tokens can persist for a very long time. An app a former employee connected in 2023 may still hold a live grant. Nobody revokes it because nobody remembers it exists.

None of this is exotic. All of it is fixable with tools you already pay for.

A concrete audit you can run this week

Here is a practical sequence for an SME IT team or a managed provider. You don't need new products — Entra ID (the service formerly called Azure AD) and the Microsoft 365 admin centre cover most of it.

1. Pull the full list of enterprise applications and consented permissions. In the Entra admin centre, go to Enterprise applications and review what's registered. For a faster, exportable view, use Microsoft Graph PowerShell:

Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All"
Get-MgServicePrincipal -All | Select DisplayName, AppId, PublisherName

Then pull the OAuth grants themselves:

Get-MgOauth2PermissionGrant -All |
  Select ClientId, ResourceId, Scope, ConsentType

ConsentType of AllPrincipals means the app was admin-consented for the whole tenant. Principal means an individual user granted it. The individual ones are where the surprises live.

2. Flag the high-risk scopes. Sort by permission. Anything with .ReadWrite.All, Mail.Read, Files.Read.All, Directory.Read.All or full mailbox access deserves scrutiny. Ask a blunt question for each app: do we still use this, and does it genuinely need that level of access?

3. Check publisher verification and last sign-in. Unverified publishers and apps that haven't authenticated in 90 days are prime candidates for removal. The sign-in logs in Entra show when each service principal last used its token.

4. Cross-reference against your vendor list. Match what's in the tenant against the SaaS tools your business actually pays for and approves. Apps that don't appear on either list are shadow IT and should be challenged.

Remediate, then make it stick

Finding the grants is half the job. Closing them down and stopping the sprawl returning is the other half.

Revoke what you don't recognise or need. Removing an app's service principal kills its tokens. Do this for anything orphaned, unused, or from an unverified publisher. Communicate first if it's a tool a team relies on.

Turn off unrestricted user consent. In Entra, set user consent to allow apps only from verified publishers and only for low-risk, limited permissions — or require admin approval entirely. The admin consent workflow lets users request an app and routes it to you for a decision, so you keep visibility without blocking everyone.

Update-MgPolicyAuthorizationPolicy -BodyParameter @{
  defaultUserRolePermissions = @{
    permissionGrantPoliciesAssigned = @(
      "managePermissionGrantsForSelf.microsoft-user-default-low"
    )
  }
}

Set token lifetimes and use Conditional Access. Tie access to compliant devices and trusted locations where it makes sense, so a leaked token alone is less useful.

Schedule the review. This is the part most businesses skip. Put a quarterly OAuth review in the calendar like you would a patch cycle. The grant you remove today is replaced by three new ones next month if no one is watching.

Where this leaves you

The firms hit hardest in 2026 weren't careless about firewalls or weak on passwords. They simply had no map of who could reach their data through the side door. The fix isn't a heroic project. It's an afternoon's audit, a couple of policy changes, and a recurring habit.

Treat your OAuth graph as the perimeter it has quietly become. The apps are already connected. The only question is whether you know which ones — before someone else finds out for you.

If you'd like a hand running the audit across your Microsoft 365 tenant, that's exactly the kind of work we do for clients across Nottingham and the East Midlands. Get in touch and we'll start with the export.