The MSP Process breach has spread from a software vendor into the Microsoft 365 tenants of the managed service providers (MSPs) that use it, and into some of their clients. According to The Stack’s report, published November 9 and updated November 10, attackers stole Entra app client IDs and secrets, admin refresh tokens and lists of partner admin relationships. Huntress, which monitors many MSP tenants, found malicious token grants in 47 tenants, The Stack reports.
MSP Process sells an AI service desk to MSPs. Its website says it answers calls, verifies users and logs each step in the MSP’s ticketing tool. To verify users and reset passwords, it needs access to client Microsoft 365 tenants. That access is what the attackers used in the MSP Process breach. This is the second MSP tool emergency today: N-able took its RMM tool offline this afternoon, as we covered in N-able takes N-central offline. Facts here are as of 5:40 p.m. ET on November 10, 2026.
The short version: ask your MSP tonight whether it uses MSP Process, so you know if the MSP Process breach touches you. If it does, find the MSP Process app in your Entra admin center, turn off its sign-in, check what it can do, and review sign-ins by apps since November 6. Then review your MSP’s admin roles and rotate any passwords or secrets kept in SharePoint or OneDrive files.
What happened in the MSP Process breach
No primary source has published the full story yet. As of this evening, MSP Process’s website and blog carry no incident notice, and the Huntress blog has no post on it. Huntress is the managed security firm that found the activity. Everything in this section comes from The Stack’s reporting, which cites Huntress’s timeline and MSP Process’s messages to customers.
According to The Stack:
- MSP Process serves more than 1,000 MSPs.
- On November 7, MSP Process warned customers that anyone holding an app’s client secret could use its permissions in client tenants with no user sign-in and no MFA.
- The app typically holds the User.ReadWrite.All permission and permissions over authentication methods in client tenants. In plain words, it can change user accounts and their MFA settings.
Timeline, per Huntress as The Stack reports it:
- On November 6, attackers tried password spraying against MSP staff accounts. Huntress saw no successful logins. Failed sign-ins using client secrets followed through the day.
- On November 7, the first successful token came at about 10:01. Test activity then reached many partner tenants. Hands-on activity in one MSP tenant ran from about 10:22 to 14:48.
- In that one tenant, Huntress saw the attacker grant roles to the MSP Process app, add extra secrets, create service accounts, take data and re-enable accounts Huntress had disabled.
The Stack reports that MSP Process CEO Patrick Leonard told customers the breach was "contained" and that Sophos is leading the incident response. Its Partner Center integrations remain disabled for new deployments until the response team confirms cleanup. Leonard said a post-mortem would follow. We did not find a Sophos statement on this incident tonight.
Why the MSP Process breach reaches your tenant
Most nonprofits and associations never log in to MSP Process. Their MSP does. Here is how a breach at the MSP’s vendor reaches your Microsoft 365.
App registrations. A tool like MSP Process connects to your tenant as an app. Your MSP, or an admin at your organization, approves the app once. After that, it shows up in your tenant as an enterprise application with the permissions it was granted.
Secrets. The app signs in with its own credential, a client secret or certificate. Microsoft’s page on service principal sign-in logs says these sign-ins "don’t involve a user." The app provides its own credential, such as a certificate or app secret. So there is no person to send an MFA prompt to. Whoever holds the secret can act as the app.
GDAP. Granular delegated admin privileges (GDAP) let your MSP manage your tenant through Microsoft Partner Center. The Stack reports that attackers took lists of these relationships. A list tells an attacker which client tenants an MSP can reach.
Microsoft’s own security best practices for app registrations address this risk directly. Microsoft says not to use password credentials, also called secrets, because they "are often mismanaged and can be easily compromised."
We covered the same pattern on the build server side in the npm supply chain post. One stolen secret can reach many systems. Our identity and access management explainer covers the basics of who and what can sign in to your systems.
Huntress has written about this pattern before. Its October 16 report on ConnectWise (SkyKick) vendor credentials describes an attacker signing in as a backup vendor’s Microsoft 365 app and reaching customer tenants. That report warns: "The credential works against every tenant the app is consented in."
A separate campaign: Todyl’s Key Eater
Do not mix this up with another campaign. Todyl’s Key Eater report, published November 3, describes an actor using stolen Entra app credentials to reach 27 organizations, including MSP clients; Todyl does not name MSP Process, and no one has shown the two are linked. Cybersecurity Dive reported on November 4 that Huntress also tracked that campaign. Huntress analyst Jon Semon told the outlet the attacker already held valid secrets for Entra app registrations.
Tonight: what to check after the MSP Process breach
These steps assume you or your MSP have admin access to the Microsoft Entra admin center. If your MSP holds all admin access, send them this list.
-
Ask your MSP if it uses MSP Process. Ask in writing. Ask whether it connected MSP Process to your tenant, and when.
-
Find the app. Go to Entra ID > Enterprise apps > All applications. Search for MSP Process, as Microsoft’s guide to viewing enterprise applications shows. Also look for apps you do not recognize, especially ones added recently.
-
Turn off its sign-in. Open the app, select Properties, and set Enabled for users to sign-in? to No. Microsoft’s page on disabling sign-in for an application says this "prevents all tokens from being issued for that application." You need at least the Cloud Application Administrator role. Huntress gave the same advice in October: disable, do not delete.
-
Check what it can do. On the same app, select Permissions. Microsoft’s guide to reviewing app permissions shows how to revoke admin-consented permissions there. Note anything like User.ReadWrite.All.
-
Revoke the connecting admin’s sessions. Huntress advises revoking sessions for the admin who first connected MSP Process, The Stack reports. Microsoft’s revoke access guide says Revoke sessions on the user’s page revokes refresh tokens. Access tokens already issued last 1 hour by default.
Why turn off the app instead of deleting it
Turning off sign-in is safer than deleting the app tonight. Microsoft’s delete guide suggests deactivating first for security incidents, since it keeps the setup for investigation. A deleted enterprise app stays in the recycle bin for 30 days.
This week: review sign-ins, roles and stored secrets
Once the app is off, look back at what happened since November 6, when the MSP Process breach began, per Huntress’s timeline as reported.
Review app sign-ins. In the Entra admin center, go to Entra ID > Monitoring & health > Sign-in logs. Microsoft’s sign-in logs page lists service principal sign-ins as their own log type. Filter for the MSP Process app and for unknown apps. Look at dates, IP addresses and failures.
Review audit logs. Huntress, via The Stack, says to look for new secrets added to apps, new role assignments, new service accounts and accounts re-enabled after being disabled. Check your App registrations page for apps you did not create.
Review your MSP’s admin roles. In the Microsoft 365 admin center, go to Settings > Partner relationships. Microsoft’s page on reviewing partner admin privileges recommends a quarterly review and shows how to remove roles. Microsoft’s customer-led GDAP removal page covers ending a GDAP relationship. Do not remove your MSP in a panic. Ask first which roles they need and why.
Rotate secrets kept in files. Huntress also advises rotating credentials stored in SharePoint or OneDrive documents. Many small teams keep a "passwords" spreadsheet or a vendor API key in a shared folder. If the attacker reached your tenant, assume they read it.
If your MSP uses Microsoft Authenticator for staff MFA, this is also a good week to confirm every account has a strong method. Our post on the Microsoft SMS MFA retirement covers the dates and options.
What to ask your MSP about the MSP Process breach
These are our suggested questions. A good MSP will answer them in one email.
- Do you use MSP Process for us, and since when?
- Was our tenant in the set that saw malicious token grants? Ask whether Huntress, Sophos or MSP Process has told them.
- Have you turned off the MSP Process app in our tenant? Ask for the date and time.
- What did you find in our sign-in and audit logs since November 6? Ask for a short written summary.
- Which GDAP roles do you hold in our tenant, and when do they expire?
- Did you store any of our credentials in SharePoint, OneDrive or your own tools? Ask what they rotated.
- When will you reconnect MSP Process, and what proof will you need first?
- Who else in your tool stack can sign in to our tenant as an app? It matters after this incident too.
Microsoft is also moving away from older sign-in methods across Microsoft 365. Our post on the Exchange Online EWS retirement shows how to find which apps still connect to your mail. The same habit of knowing which apps hold access helps here.
Frequently Asked Questions
What is MSP Process?
MSP Process sells an AI service desk to managed service providers. Its website says it answers calls, verifies users and logs work in the MSP’s ticketing tool. To verify users and reset passwords, it connects to client Microsoft 365 tenants.
How many tenants did the MSP Process breach reach?
The Stack reports that Huntress saw malicious token grants in 47 tenants. One MSP tenant saw hands-on activity. Those are Huntress’s numbers from the tenants it monitors, so the full count may differ.
Has MSP Process published a statement?
As of the evening of November 10, we found no incident notice on MSP Process’s website or blog. The Stack reports that its CEO told customers the breach was contained and that Sophos is leading the response.
Why did MFA not stop the MSP Process breach?
The app signs in with its own secret. Microsoft says service principal sign-ins do not involve a user, so there is no person to prompt. Anyone with the secret can act as the app.
Does revoking sessions stop the attacker?
It revokes a user’s refresh tokens. It does not stop an app that uses its own secret. Turn off the app’s sign-in as well. Tokens already issued can last about an hour.
Is the MSP Process breach the same as Todyl’s Key Eater campaign?
No link has been shown. Todyl reported Key Eater on November 3, involving stolen Entra app credentials and 27 organizations. Todyl does not name MSP Process.
We do not use MSP Process. Do we need to do anything?
Ask your MSP to confirm in writing. Then use this week to review your enterprise apps and partner admin roles anyway. Other MSP tools connect to tenants the same way.
Should we switch MSPs?
Not in the middle of an incident. Get answers to the questions above first. How your MSP handles this week will tell you a lot.
