Yes — if it connects to Microsoft 365 the way most backup tools do, as an application with its own identity. MFA challenges people at sign-in. An application signs in as itself, with a secret, using permissions your organization granted it — sometimes years ago. There is no person to challenge, so there is no MFA prompt to fail.
That is not a theory. It is what happened this week with ConnectWise Cloud Backup.
What happened
On October 15, 2026, an attacker used the backup application’s own credential to sign in to customer Microsoft 365 tenants as the application. Microsoft Threat Intelligence called it an active supply-chain attack: the threat actor “compromised the trusted OAuth App of the backup application ConnectWise Cloud Backup… to obtain access tokens across customer tenants,” likely abusing permissions customers had already granted the app, including Directory.ReadWrite.All. Huntress counted at least 162 compromised tenants in its own telemetry; other reporting put the count at 173 tenants. The sign-ins were scripted, seconds apart, from a single IP address.
Because the application already held broad, previously granted permissions in each tenant, those sign-ins carried the technical ability to read and write mail and attachments, OneDrive and SharePoint files, and Teams chats. In nearly 50 tenants Huntress monitors, the app’s service principals assigned themselves directory roles, mostly Exchange Administrator. In one tenant, the attacker added credentials to other applications — a backdoor meant to outlast the incident itself.
ConnectWise shut down Cloud Backup application access on October 17 and later revoked the certificates and invalidated the shared credentials the service used. The company says it has no evidence that stored backup archives were accessed. How the attacker obtained the credential has not been disclosed.
Why the grant outlives the vendor
The critical fact for continuity planning is where the permission lives. When an admin consents to a backup app, Microsoft Entra ID creates a service principal — the app’s identity — inside your tenant, holding your grant. That grant does not expire when the contract does. It does not disappear when the vendor shuts the service down. It survives until someone in your organization goes and removes it.
One administrator’s report from this incident makes the point plainly: a Microsoft PIM alert on October 15 flagged a SkyKick service principal — the backup product’s former name — assigning itself the Exchange Administrator role in a tenant that had not used the app in years. The subscription was long gone. The standing access was not.
Cleanup has the same trap. Disabling an application stops new tokens from being issued, but tokens already issued stay valid until they expire. Revoking user sessions does nothing to application access, because no user session is involved. A shutdown announcement from a vendor is not the end of your exposure; removing the app’s identity and credentials from your tenant is.
The continuity lesson
Backup is a resilience control. This incident is what it looks like when the resilience control becomes the exposure: a trusted, always-on connection into the exact data the organization would need to recover — mail, files, chats, and the directory itself.
Treat every third-party app grant as standing access, because that is what it is. Keep an inventory of the applications consented in your tenant and the permissions each one holds. When a vendor relationship ends — any vendor, backup above all — revoke the application’s access in your tenant as a formal offboarding step, the same way you would collect a badge and disable an account. And review the app’s credentials and sign-ins, not just your people’s: application sign-ins appear in Entra’s service principal sign-in log, a separate view from user sign-ins that many review routines never open.
If your organization used ConnectWise Cloud Backup
- In Microsoft Entra, open Monitoring → Sign-in logs → Service principal sign-ins and filter by the Cloud Backup application ID, 506e08f9-6e9a-4da4-942b-a099a03644ae. Look for sign-ins from addresses you do not recognize, especially around October 13–15, 2026.
- Review credentials on every application in the tenant for additions since October 13 that nobody on your team made — the persistence move in this incident was adding credentials to other apps.
- Disable the implicated ConnectWise applications, including the Cloud Management family. In older tenants they may be listed under “SkyKick Cloud Manager.”
- Review OAuth grants and directory role assignments for the app’s service principals, and remove roles the app granted itself.
Sources: BleepingComputer’s incident report, SpecterOps’ tenant-check guide, and Microsoft Threat Intelligence’s advisory as reported by The Hacker News. Vendor and researcher findings are attributed as reported; the investigation is ongoing and details may change.