As of 18 October 2026.
In mid-October, news did the rounds in the admin community: attackers had signed in to more than 300 Microsoft 365 tenants. No stolen password, no MFA prompt, and not a single conditional access policy fired. They didn’t need to hijack a user account. Instead, they had the credential of an app that the affected organisations had themselves given access to their mailboxes and files.
The incident shows something uncomfortable: we have put a lot of effort into securing how users sign in and keeping their permissions tidy. With the apps we register in our tenants, we tear all of that down again.
One credential, more than 300 tenants
The exploited app is ConnectWise Cloud Backup, formerly SkyKick, a backup service for Microsoft 365. To do its job, it holds far-reaching rights in every customer tenant. Security vendor Todyl, which investigated the incident among its customers, describes them as tenant-wide read and write access to mail, OneDrive and SharePoint files, and Teams chats.
The backup service doesn’t sign in as a user. It signs in as an enterprise app in the tenant, using a credential held by the vendor. Nobody types a password, no phone asks for a second factor, and nobody checks whether the device is compliant. That is exactly how the attackers signed in too: as the app itself. That’s why MFA and conditional access for users simply didn’t apply. By 17 October, IT security provider Huntress had counted almost 1,000 tenants with such sign-in attempts, and in more than 300 of them, the attempts succeeded.
The affected organisations are not to blame. The credential presumably went missing at the vendor, ConnectWise, not through any mistake on their side. It sits in the vendor’s tenant, so no customer could have protected it. ConnectWise has since disabled the misused app identities and suspended the service.
A printer with a master key
None of this is new. We actually know the problem; we’ve all just been looking the other way. Me included. Of all things, it was a printer that showed me.
I set up a new printer. Sending scans via SMTP with Basic Auth was no longer an option, because Microsoft is retiring the method as insecure: at the end of December 2026, Microsoft will switch it off by default in existing tenants. The printer vendor had a solution: I registered its enterprise app in my tenant. Among other things, it requested two application permissions, Mail.Send and Mail.ReadWrite. I granted consent, and the printer was scanning again.
What I had approved is spelled out in Microsoft’s documentation. There, Mail.Send is called Send mail as any user: without a signed-in user, the app may send mail as any address in the tenant. That’s bad enough. Mail.ReadWrite is far more dangerous. It lets the app read, change, delete and create mail in every mailbox. Mail.Send is a postal worker who sends letters in your name. Mail.ReadWrite is a postal worker who may open, read, rewrite and throw away every letter in every letterbox, including contracts, invoices and password reset links. And they can slip in letters nobody ever sent.
I’d solved one security problem and created a much bigger one. A single mailbox would have been enough for a few scans.
Least privilege ends at the Accept button
With users, we’ve done things differently for a long time. They get rights only when they need them, and only as many as they need. Admin roles are activated through PIM for a limited time, and access is regularly re-checked in access reviews. When we think about authentication, we think in terms of phishing resistance, device compliance and locations. Anyone who wanted to give a user full access to every mailbox would need a very good reason.
Almost none of this carries over to apps. From the moment someone clicks Accept, an application permission applies to the entire tenant until someone revokes it. There is no time-limited activation and no second factor. At most, the app’s secret can expire; the permission stays. And few people use the tools that do exist. Who actually scopes Mail.Send to a single mailbox? For a long time, I didn’t even know that was possible, although Microsoft has offered it since late 2022. And who actually uses conditional access for workload identities?
The backup case shows where this leads. Among the attacked tenants, Todyl found nine that no longer had an active backup subscription. The app no longer served any purpose there, but it still had all its rights. The attackers got a token there as well. A user account that nobody had needed for months would not have survived the next access review.
What helps, and where it stops
We’re not completely without tools for apps. There are just fewer than for users, they kick in at different places, and each one has a hard limit. Four of them are worth it, in this order.
Clear out what nobody needs any more
Get rid of what you no longer need. It costs nothing. In the nine tenants without a backup subscription, it would have shut the door on the attackers. Nobody can abuse an app that’s no longer in the tenant, and you never have to review it again. The Service principal sign-in activity report under Usage & insights shows which apps still sign in at all. It requires Entra ID P1 or P2.
Cleaning up has become easier since apps can be deactivated. A deactivated app no longer gets new tokens, but its configuration and permissions are kept. If nobody speaks up, you delete it later. If someone complains, it’s back with one click. This applies to apps registered in your own tenant. For vendor apps like the backup service, you disable sign-in for the enterprise app in your tenant instead.
The same goes for new apps, just earlier. Preventing users from consenting to apps makes a lot of sense. But it doesn’t help against application permissions like the printer’s, because only an admin can grant those anyway. In the consent dialog, the control is you, the admin. Ask the vendor why their app needs a permission for every mailbox and whether it works with restricted access. The Cloud Security Alliance, an industry body, also recommends asking how the vendor generates, stores and rotates its secrets. And whether a single secret applies to all customers.
The limit: clearing out doesn’t protect you from the apps you really need. A backup service has to be able to read everything.
Limit mail permissions to individual mailboxes
For mail, Exchange Online offers RBAC for Applications. You assign the app’s service principal a role such as Application Mail.Send and restrict it to a management scope or an administrative unit, for example the single scan mailbox. Application Mail.ReadWrite works the same way. The blog Office 365 for IT Pros walks through the setup step by step.
The catch: permissions from Entra and from Exchange add up. As long as the tenant-wide consent for Mail.Send exists in Entra, the new role restricts nothing. You have to remove the permission in Entra.
The limits: RBAC for Applications only applies to data in Exchange Online, and only via Microsoft Graph and EWS. That works for my printer app, which sends via Graph. It doesn’t help with files in SharePoint or OneDrive. And you can’t meaningfully restrict a backup service that is supposed to back up every mailbox.
Conditional access for workload identities
Conditional access for workload identities exists, but it only covers single-tenant service principals registered in your own tenant. Third-party multi-tenant apps like the backup service are explicitly excluded. Managed identities aren’t covered either. You can control only one thing: blocking the sign-in when it comes from outside known IP ranges or ID Protection reports a risk. For that, you need Workload Identities Premium licences.
It pays off for the apps registered in your tenant: automations, scripts and integrations like my printer app. If they sign in from fixed addresses, a stolen secret is worthless anywhere else. For multi-tenant apps like the backup service, it does nothing.
Keep an eye on it
App sign-ins have their own tab in Entra, Service principal sign-ins. If you only look through user sign-ins, you’ll never see them. ID Protection also detects risk for workload identities, explicitly including multi-tenant apps. The Suspicious Sign-ins detection fires, for example, when an app suddenly signs in from an unfamiliar IP address. You can see the detections without an additional licence; the Security Reader role is enough. Full details and risk-based policies are only available with Workload Identities Premium.
The limit is the same as above: for vendors’ multi-tenant apps, Microsoft can detect the risk, but no policy blocks the sign-in. Keeping an eye on it doesn’t replace clearing out. It just tells you sooner that a key has gone missing.
Counting keys
In the ConnectWise case, the attackers didn’t have to trick a single user. The affected organisations had given the app its rights themselves, and the vendor lost the key to them. We would never give a user account access to every mailbox. I gave it to my printer.
It took us years to take the master key away from users. Apps still get it with a single click.
Cover image: fotoblend on Pixabay, Pixabay Content License.
