On Saturday, ConnectWise flipped a switch most of its customers never get a vote on. Seven application identities went dark. Cloud Backup went with them. If you ran Microsoft 365 restores through that stack, you learned about the cybersecurity problem the hard way: the same weekend the vendor admitted unknown actors had used those identities to reach customer tenants, the restore button stopped answering.

That is a messy morning. You are already hunting a multi-tenant identity grab, and the product you bought for the worst day just became unavailable by design. ConnectWise published at least one of the killed app IDs, ConnectWise Cloud Backup at 506e08f9-6e9a-4da4-942b-a099a03644ae, and said the investigation continues. You can read the statement as responsible containment. You can also read it as your disaster-recovery vendor choosing to vanish while you still have mailboxes to protect.

Customers inherited two incidents before the briefing landed

Most incident response plans assume you still have a restore path while you contain the breach. Saturday inverted that. The vendor’s containment move was to disable the very application identities that performed backup and restore. If those identities were the only way your tenant talked to the service, you lost the product at the same moment you learned the product had been abused.

Unknown actors got unauthorized access to ConnectWise application identities and used them against Microsoft 365 tenants. That is a supply-chain identity failure sitting inside a trusted consent grant. Your users did not click a lure. Nobody typed a password into a fake portal. A partner app that already had directory rights became the door.

You now own two clocks. One is the identity hunt: which service principals, which consent grants, which audit rows show those app IDs acting like a privileged workload. The other is availability. Can you still recover a mailbox, a SharePoint library, or a laptop image if someone starts encrypting tonight. Plenty of shops split those into separate tickets. They belong on the same war-room board.

Your firewall never saw a login worth paging

Threat detection programs still spend most of their calories on the obvious. A brute-force spray against VPN. A noisy hit on the firewall. A payload that detonates in a sandbox. None of that fires when a consented multi-tenant app presents a valid token. The session looks like the backup job you scheduled.

That is why this story should rearrange your threat-protection priorities. Defense in depth that stops at the edge is a poster on the SOC wall. The restore app already lives inside the identity plane. If your idea of cyber security is watching the perimeter for strangers, a familiar application ID will stroll past every rule you wrote last budget cycle.

Security hardening for Microsoft 365 has to include the apps you invited in. Publisher name is not a control. A consent screen from 2023 is not a review. If you cannot name the Graph permissions on every backup, remote-management, and “helpful” add-in in the tenant, you are trusting a vendor’s Saturday decision to be your only kill switch.

Cybersecurity after the vendor hits the kill switch

Do the tenant work now. Do not wait for a cleaner write-up from the publisher.

Start with Entra ID enterprise applications and service principals. Search for ConnectWise Cloud Backup and the published app ID. Disable the service principal in your tenant even if the vendor already flipped theirs. A vendor-side disable stops their cloud from talking. It does not pull the grant, the local service principal, or leftover tokens that still belong to you.

Walk the Unified Audit Log and Entra sign-in logs for that app ID across a window that starts well before Saturday. Look for mailbox access, file download, consent changes, and new credentials. Export the rows before retention eats them. If you have a second backup product that does not share this identity plane, run a restore test against a throwaway mailbox so you know the other path works. If you do not have a second path, you are in a restore outage. Tell the person who owns risk. Use that sentence.

Rotate anything the backup product could have touched: onboarding admins, mailbox impersonation accounts, storage keys, app secrets used during setup. Then look at Conditional Access for workload identities. Backup tools often sit in exclusions because a broken job is loud. Those exclusions are how a stolen app ID keeps a normal workday face.

Keep doing the unglamorous inventory. Every multi-tenant application with Mail.Read, Files.Read.All, Directory.ReadWrite.All, or full_access_as_app needs a named owner who is not the vendor’s account manager. Recertify the grant each quarter. Require a restore path that does not share the same publisher, the same app registration, or the same admin used to onboard the first tool. Test that path on a calendar.

Write the kill switch into the runbook and the contract. If the publisher can suspend the product to contain their incident, you need a documented failover and a person who can disable the service principal without opening a ticket with the same vendor. Boring. Also the difference between Saturday’s move and your Monday restore failure.

The grant in your tenant outlives their statement

ConnectWise can disable seven identities and pause Cloud Backup. That is their incident. Yours continues until you prove the app is gone from your directory, the logs are in your hands, and a restore still works through something they cannot unplug.

Vendors will keep shipping shared application identities because the architecture is convenient. Multi-tenant apps scale. They also concentrate blast radius. You will not shrink that with another appliance at the edge. You shrink it by treating every backup integration as a privileged workload identity, by keeping a second restore plane, and by assuming the publisher may pull the product while you are still bleeding. Saturday was a containment choice. Make sure that choice is not the last copy of the data.

Sources

• ConnectWise Suspends Cloud Backup After Attackers Compromise Microsoft 365 Tenants