MSP supply chain attacks: when your IT provider’s tool is breached

An MSP supply chain attack is when someone breaks into a company that sells software to IT providers and uses that software’s access to reach the provider’s clients. Your business can be exposed without anyone touching your network or tricking your staff. Most of these tools connect to Microsoft 365, and the access they hold in your tenant stays there until someone removes it.

That last part is where most of the risk sits, and it’s what this post is about.

How an IT provider’s tool gets into your Microsoft 365

Most tools an IT provider uses to manage Microsoft 365 work the same way. The provider registers an app in its own tenant, then installs a copy of that app in each client’s tenant and grants it permissions. The tool’s vendor keeps the app’s secret (a long password for the app) so its software can act on the provider’s behalf.

Some of those permissions are broad. In the case below, the vendor listed what its app could do in every client tenant:

These are application permissions. The app uses them with its secret alone: no user signs in, and no MFA prompt appears. Someone holding the secret can reset an executive’s password, add their own phone as the second factor and sign in as that person.

Case file: a Louisiana MSP tool vendor breach in November 2026

What the record shows

The vendor is a Louisiana company that sells help desk and identity tools to IT providers; its privacy policy lists a Madisonville address, and its terms are governed by Louisiana law. It emailed its partners twice on Saturday, November 7, 2026. Partners were notified:

• that an attacker who broke into one of the vendor’s internal servers had access to a storage account on November 7, between 3:56 AM and about 8:40 AM Central
• that the storage held, for each partner’s integration, the app’s client ID and client secret, the refresh token from the admin account that connected it, and the partner’s list of client tenants with the roles granted
• that the vendor could not prove whether a given partner’s credentials were copied, and should treat them as compromised
• that anyone holding the app’s secret could use its permissions in client tenants “with no user sign-in or MFA”
• that the attacker used this kind of access against at least two partners’ client tenants on November 7
• that the vendor removed the attacker’s access, rotated its platform credentials, and the stolen storage key stopped working at 1:05 PM Central
• that rotating the secret “does not remove access the attacker may have created inside a client tenant”
• in the second email, to also rotate API keys connected to the vendor’s platform, starting with their ticketing system’s, and that its password reset and verification features were turned off for all partners until they were secure

What we don’t know

The emails don’t say how the attacker got into the internal server, which providers’ clients were reached, or what the attacker did inside those tenants. We don’t know how many providers had stopped using the tool but never removed it.

Questions for your office

• 01The stolen secret worked without MFA. Do you know which outside apps can sign in to your Microsoft 365, and what each one is allowed to do?
• 02The vendor told providers to act the same day. If your IT provider got this email on a Saturday night, who would read it, and when would your tenant be checked?
• 03The vendor said it couldn’t tell who was affected. How long does your tenant keep its sign-in and audit logs, and has anyone saved a copy?

Why cleanup takes more than deleting one secret

Deleting the app’s secret in the provider’s tenant is the first step the vendor asked for, and it stops the stolen secret from working. Five things make the rest harder.

Deleting the app doesn’t remove it from your tenant

Microsoft says deleting a multitenant app deletes its service principal only in the home tenant: “service principal objects in other directories will not be deleted” (Microsoft Learn). The copy in your tenant, with its permissions, stays until an admin removes it there. Search for it by the app’s ID under all applications; a filtered list or a name search can miss it (Microsoft Learn).

The attacker can leave a second key behind

With the permissions above, an attacker can add a new secret to a different app already in your tenant, such as a reporting or backup connector nobody watches. That new secret belongs to your tenant, not the vendor’s app, so it keeps working after the original secret is deleted. Partners were told to look for exactly this: new secrets or certificates on any app or service principal since November 7.

The evidence expires

On a tenant without Entra ID P1, the record of a November 7 password reset starts disappearing around November 14. Upgrading the license afterward doesn’t bring it back: Microsoft says retention changes “aren’t retroactive” (Microsoft Learn). Inbox rules and mail forwarding are recorded in the Microsoft 365 unified audit log, which Microsoft says is separate from Entra’s logs, so a review has to check both. If the log is empty after that window, it only tells you nothing was kept.

Attacker activity looks like normal vendor traffic

The stolen secret belongs to a real app the vendor uses every day. The attacker’s actions show up in your logs under the same app name as months of normal activity. An IT provider that knows which apps sign in to your tenant, from where and how often, can spot the difference in an afternoon. One that has never looked will chase false alarms or miss the real one.

A cancelled tool still holds the keys

Cancelling a subscription doesn’t remove anything from Microsoft 365. A provider that tried the tool a year ago and connected a dozen clients during setup may have left the app, and its permissions, in every one of those tenants. Nobody has used it in months, so nobody thinks to check, and that provider has the least reason to read the notice closely.

Louisiana’s breach clock may already be running

A compromised app isn’t automatically a reportable breach. It becomes one if someone actually got to protected information, and you can’t answer either way without the logs.

Louisiana’s law also lets a delay run past 60 days only if the business gives the Attorney General its reasons in writing within that window (La. R.S. 51:3074(E)). This is general information, not legal advice; bring in counsel early if you think personal or health information was reached. Our data breach response guide walks through the first steps.

What a prepared IT provider does the day the notice arrives

1. Deletes the vendor app’s secrets in its own tenant.
2. Revokes sessions for the admin account that connected the tool. Microsoft says this invalidates the refresh tokens issued to that user (Microsoft Learn).
3. Finds and removes the vendor’s app in every client tenant, searching by app ID.
4. Checks each client tenant from the start of the breach for password resets, new MFA methods, new app secrets, new users, role changes and new consents.
5. Checks mail forwarding and inbox rules in the unified audit log.
6. Exports the logs before retention runs out.
7. Rotates every other key it gave the vendor, including its ticketing system’s.
8. Tells each client, in writing, what was checked and what was found.

What we do for our clients

We monitor sign-ins to your accounts for impossible travel and block sign-ins from abroad, so a password reset by an attacker overseas doesn’t turn into a working session. When a new exploit is discovered and reported, we close that gap for every client. Endpoints run detection backed by a 24/7 security operations center that can isolate a device.

No client of ours has had a reportable data breach. If you already have an IT provider, our co-managed IT work can add a second set of eyes on your tenant without replacing anyone.

How this could happen in an office like yours

These are illustrations, not a description of any provider or client in the case above.

1. An office’s IT provider reads the vendor’s email on Monday. The attacker reset the office manager’s password on Saturday, and the tenant has no P1 license, so most of the record is already gone. What we would have done: blocked the sign-in from abroad and flagged the reset the same day.
2. A provider deletes the vendor’s secret within the hour and closes the ticket. The attacker had already added a secret to the office’s scanning app. What we would have done: checked every app in the tenant for credentials created after the breach began.
3. A provider cancelled the tool last spring and deletes the vendor’s email as irrelevant. The app is still in 12 client tenants with permission to reset passwords. What we would have done: removed the app from each tenant when the tool was cancelled.

Questions to ask your IT provider

• Which outside tools have access to our Microsoft 365, and with what permissions?
• When you stop using a tool, how do you remove it from our tenant?
• If one of your vendors is breached, how fast would you know, and how would you tell us?
• How long are our sign-in and audit logs kept, and are they exported anywhere?
• When did you last review the apps connected to our tenant?

Case log

• November 7, 2026: a Madisonville, Louisiana MSP tool vendor’s breach notices to its IT provider partners (emails to partners; not published).

If you can’t get clear answers to those questions, find out before the next vendor breach. Book a 15-minute call and we’ll go through which outside apps can reach your Microsoft 365 today. See our cybersecurity services for how we work.

Frequently asked questions