A backup app's stolen credential opened Microsoft 365 tenants in October 2026. This Canadian SMB checklist audits app access, permissions and restores.

Having Microsoft 365 backup is not the same as being safe. In October 2026, attackers got hold of a credential belonging to a backup application itself — not an employee's password — and used the access customers had already granted that app to sign in to Microsoft 365 tenants. If a backup tool connects to your tenant, its security is part of your security, and the checklist below shows how to check that connection.
Most owners file backup under "handled": someone set it up, the reports say "success," and everyone moves on. It deserves an hour of your attention, because what broke was not a password — it was a trusted app with broad permissions that nobody had re-checked since the day it was installed.
ConnectWise Cloud Backup (formerly SkyKick) is a service many IT providers use to back up Microsoft 365 data — email, OneDrive, SharePoint, Teams and directory information. On October 16, 2026, ConnectWise disclosed unauthorized access involving application identities associated with that service; the next day it disabled seven affected application identities and suspended Cloud Backup and its related SaaS Security and Cloud Management services while it investigated.
Microsoft Threat Intelligence described it as an active supply-chain attack: the attacker used the backup app's compromised OAuth identity to obtain access tokens across customer tenants, abusing permissions customers had previously granted the app — including, Microsoft noted, highly elevated ones such as Directory.ReadWrite.All. Microsoft observed successful sign-ins by the app's identity on October 15, plus Microsoft Graph API reconnaissance and attempts to add new credentials inside tenants to keep access.
Two things are worth separating, because headlines merge them. ConnectWise says its stored backup archives remain encrypted, isolated and preserved, with no indication those archives were compromised. The risk was in the live tenants — the mailboxes and files the app could reach with its granted permissions — and each tenant still has to be reviewed individually. As of its October 23 update, service restoration was proceeding in phases, with affected connections to stay disabled until ConnectWise issues reconnection instructions.
Read the primary source yourself: the ConnectWise Trust Center advisory (first published October 16, 2026, updated since) and CSO Online's reporting.
"We turned on multi-factor authentication — how does someone still get in?" Because nobody signed in as a person. A backup service works through an application identity (in Microsoft Entra terms, a service principal). Your business granted it permission, once, to read mailboxes and files so it could back them up. Whoever holds that application's credential can present it, receive tokens, and inherit every permission the app was granted — no password prompt, no MFA challenge.
That is not a reason to stop using backup services. It is a reason to treat every connected app in your tenant as a set of keys to the building — and to know how many sets exist, who holds them, and how wide each one opens the door. It is the same discipline behind a good Microsoft 365 and cloud setup.
You do not need to run these yourself — but you should be able to ask for each by name, of whoever manages your Microsoft 365, and get dated, written answers.
Is Microsoft 365's built-in retention enough, or do I need separate backup? For most SMBs, retention alone is not backup. Retention helps with accidental deletion and some compliance needs, but it lives inside the same tenant — not an independent copy you control. A separate backup gives you that copy, and this incident adds a duty: audit the access that backup holds.
How often should backups be tested, and who should sign off on the test? Test on a schedule you can defend — quarterly is a reasonable rhythm for a business of 30–80 people, and after any major change to your setup. Sign-off should be a named person, with a dated record of what was restored. If your provider tests, ask to see the record.
What Microsoft 365 settings should be turned on for security by default? Start with the control this incident was really about: application consent. Require admin approval for new app permissions, review the apps already in your tenant, and have someone review sign-in logs — including application sign-ins. MFA for every user still matters; it just isn't the whole picture anymore.
Does PIPEDA require us to report a data breach, and how fast? Generally: if a breach involving personal information poses a real risk of significant harm, it must be reported to the Privacy Commissioner of Canada and affected individuals notified, as soon as feasible — and records of every breach must be kept for 24 months. This is general information, not legal advice. You cannot meet those timelines if step 10 hasn't been thought through in advance.
Nothing in this incident argues against cloud backup. It argues against unexamined trust. The businesses that come out of a supply-chain incident well are the ones that can answer simple questions fast: what is connected to our tenant, what can it reach, when did we last restore, and who checks?
If you would like a second set of eyes on that list for your own tenant, our free assessment is a practical place to start — bring your app inventory, or ask us to build it with you.
Your comment will be published after our team reviews it.