# Your Microsoft 365 Backup Can Be Attacked Too: A Canadian SMB Checklist After the ConnectWise Cloud Backup Incident

> Amen Security Team · 2026-10-23T13:28:35.407Z · cybersecurity · microsoft-365 · cloud-backup · cybersecurity · supply-chain · smb · canada

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.
What actually happened
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](https://www.connectwise.com/company/trust/advisories) (first published October 16, 2026, updated since) and [CSO Online's reporting](https://www.csoonline.com/article/4237087/connectwise-backup-credentials-exposed-multiple-microsoft-365-tenants.html).
Why MFA didn't stop it
"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](https://amensecurity.ca/en/services/cloud).
The checklist: ten things to do this month
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.
- Step 1 — List every application connected to your Microsoft 365 tenant. Review Enterprise applications in the Microsoft Entra admin centre. If nobody can produce this list, that is your first finding.
- Step 2 — Write down what each app is allowed to do. Flag broad permissions an app may not need — tenant-wide mail, files or directory read/write is the pattern to question.
- Step 3 — Review application sign-ins, not just user sign-ins. Look for service-principal sign-ins from unfamiliar IP addresses. If a ConnectWise app is or was connected to your tenant, follow ConnectWise's guidance to review activity and changes going back to at least October 13, 2026.
- Step 4 — Check for credentials or roles added recently. The reported technique included adding new credentials to applications to maintain access. Any app secret, certificate or admin role your team doesn't recognize needs an explanation in writing.
- Step 5 — Turn on the admin consent workflow. Staff should not be able to grant third-party apps access to company data on their own; new permissions should require an admin's deliberate approval.
- Step 6 — Remove dormant integrations. Old trials, retired tools and a previous provider's apps often stay connected for years. If it isn't used, disconnect it — standing access nobody monitors is exactly the risk this incident exposed.
- Step 7 — Ask your backup provider five plain questions. How are application credentials stored? What permissions does your app hold in our tenant — the full list, not a summary? How fast would you notify us of an incident? What is your service's status right now? And what should we review in our own tenant this week?
- Step 8 — Confirm you can restore while your backup service is down. During this incident, suspension paused scheduled backups and interrupted restore access. Know your second path: a separate export, a second copy, or a documented manual route for your most critical data.
- Step 9 — Actually test a restore, and sign off on it. Pick one mailbox and one SharePoint folder; restore them to a test location, and record who verified it and when. A backup that has never been restored is a hope, not a control. (Our [cloud migration checklist](https://amensecurity.ca/en/blog/cloud-migration-checklist) makes the same point.)
- Step 10 — Decide your breach paperwork before you need it. Under PIPEDA, a breach that poses a real risk of significant harm carries reporting and record-keeping duties. Write down now who makes that call, where records are kept, and who your outside help is. See also our [cybersecurity services](https://amensecurity.ca/en/services/cybersecurity).

Questions owners keep asking
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.
The honest takeaway
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](https://amensecurity.ca/en/contact) is a practical place to start — bring your app inventory, or ask us to build it with you.

## Topic: Cybersecurity & compliance
- [Main guide](https://amensecurity.ca/en/services/cybersecurity.md)
- [Managed IT vs Break-Fix: Side-by-Side Comparison](https://amensecurity.ca/en/guides/msp-vs-break-fix.md)

---
Source page: https://amensecurity.ca/en/blog/microsoft-365-backup-security-checklist
Markdown version for AI agents · Amen Security
Email: info@amensecurity.ca
Phone: +1 (204) 514-3536