Disabling the Vendor App Is Not Full Containment

Contain, Trace, Reauthorize

This is the framework we use when a vendor connected application is compromised. It keeps three milestones apart: the vendor's service comes back, your protection comes back, and your containment is actually finished.

1. Contain

Shut down the compromised path and stop any further access.

2. Trace

Find out what the identity did, what it reached, what it changed, which credentials were touched, and whether anything was left behind somewhere else.

3. Reauthorize

Treat reconnecting as its own approval, made after the review is done, with a plan for any gap in protection.

According to ConnectWise's advisory (last updated October 29, 2026), someone gained unauthorized access to application identities and credentials tied to Cloud Backup, and the company disabled seven application identities on October 17. Their wording is careful: the findings "do not establish whether individual partner or customer Microsoft 365 tenants were affected."

That sentence matters most. Disabling stops new sign ins through those connections. Help Net Security reported ConnectWise saying it does not undo changes already made inside a customer's account, and that customers have to find and remove any credentials, roles, or access the attacker created.

Inside your Microsoft 365 tenant, a vendor app shows up as an enterprise application. Microsoft's guidance on disabling sign in for an application explains that turning off its service principal in your tenant stops tokens from being issued to it. That setting only covers your tenant.

Microsoft's incident post (October 21, 2026) adds a practical warning: don't delete the enterprise application as a first response, because you may need its configuration and logs as evidence. It also says to search by application ID, not display name, and to keep the affected connections disabled until ConnectWise gives formal restoration instructions. ConnectWise says access tokens issued before the shutdown may keep working until they expire. So containment is a process, not a click.

Not every finding means the same thing, and leadership should keep them separate.

A sign in attempt is not access. Microsoft reports attempted sign ins to more than 2,250 tenants and says most of that targeting failed. A successful sign in is not data theft either. Microsoft says an affected application or successful authentication "does not necessarily indicate that customer data was accessed or exfiltrated."

What some tenants saw is more serious than a login. Huntress reported that in about 50 tenants it monitors, ConnectWise Cloud Management service principals gave themselves directory roles, mostly Exchange Administrator. In one tenant, an application added itself to Global Administrator and changed other applications. Huntress also said it found no mail or file access in the tenant it reviewed closely, and that Microsoft doesn't log some application reads, so a clean log doesn't prove nothing was touched. Sophos reviewed its own customers and found no new role assignments, credentials, or consents. Those are different environments with different results, not a contradiction.

So far, public reporting has not confirmed that customer data was stolen. For a health or human services provider, that still matters because of how HIPAA treats access that wasn't allowed: it is presumed to be a breach unless a risk assessment shows a low probability the information was compromised. That assessment uses four factors, including whether the information was actually acquired or viewed. We don't give legal advice. Whether an event has to be reported is a question for your counsel and your compliance officer.

This is the real lesson of the incident. Microsoft warns that credentials added to other applications can remain active as a backdoor even after the original compromised application is remediated. Huntress found client secrets set to expire in 2028 added to two other applications in one tenant.

So the review has to go wider than the vendor app. Ask your provider to check for new credentials on other applications, new service principals, role assignments, consent grants, mail forwarding rules, and changes to access policies. Microsoft recommends looking back to at least October 15, and to October 1 where records exist. CoreView advises treating a confirmed sign in as a configuration change incident.

Then ask one more question: do we even have the logs to answer this? Huntress notes that sign in visibility depends on your licensing. If your plan can't show it, you want to know that now, not during the next incident.

While the applications were disabled, scheduled backups weren't running and customers couldn't use restore features, based on reporting on ConnectWise's status as of October 18 and 19. Cloud Backup is a Microsoft 365 data protection tool. So the outage left a hole in the very thing that's supposed to protect you on a bad day.

ConnectWise says existing backup archives are encrypted and isolated, with no sign of compromise. It also says that doesn't establish the state of any customer's tenant. If you're a nonprofit with a HIPAA contingency plan that depends on a backup plan to keep retrievable copies, a paused backup deserves a written note and a stopgap, not silence. Ask what was backed up last, when, and what's protecting you in the meantime.

ConnectWise began a phased restoration on October 28 with a new application, "ConnectWise Cloud Backup for M365." Partners are told to re authorize each tenant, not to turn the old disabled applications back on unless told to, and to review affected environments, because re authorization "does not replace the investigation steps."

Treat the reconnect as a brand new approval. A new application means a new set of permissions to read. Who signs off on it? What can it read and write? Is the review from the section above finished for your tenant? In New York, the SHIELD Act expects businesses that hold private information to pick service providers that can keep safeguards in place, and to require it by contract. Your reconnect decision is part of that vendor oversight record.

Three things can happen on three different dates. The vendor's service comes back. Your protection comes back. Your containment is finished. ConnectWise's own advisory keeps the first two apart, saying re authorization alone doesn't confirm backups have resumed. The third one belongs to you, not the vendor.

Write down each date. And if your provider says "it's back," ask which of the three they mean.

Don't settle for a green status light. Ask for proof that a new snapshot finished after reconnection, a test restore of a small sample to a clean location, and a record of what the new application is allowed to do. Compare its new permissions with the old ones.

Then write down the result, the date, and who signed off.

When a vendor has a bad day, you need someone on your side of the table. We bring 15+ years of IT experience, including more than 10 years running technology inside a New York City nonprofit. We know what it feels like when a backup tool goes dark at an agency holding case records, or at a firm days away from a closing. We help nonprofits and small law firms across New York City and Long Island decide what a vendor connected app is allowed to reach, trace what it did after an incident, and prove protection really came back, with every date and decision written down.

We don't guarantee any security or recovery outcome, and this article is not legal advice.

1. ConnectWise Trust Center advisory, "Cloud Backup (formerly SkyKick) Service Interruption" (published Oct 16, 2026; last updated Oct 29, 2026). connectwise.com
2. Microsoft Security Blog, "AI driven, large scale nation state campaign using ARTEX enables supply chain compromise" (Oct 21, 2026). microsoft.com
3. Huntress, "ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks" (Oct 16, 2026; updates Oct 17, 19, 27). huntress.com
4. Huntress, "AI, Scripts, Operator: Inside the ConnectWise Attack" (Oct 26, 2026). huntress.com
5. Sophos X Ops, "ConnectWise Cloud Backup application abused in cross tenant token sweep" (October 2026). sophos.com
6. Help Net Security (Oct 19, 2026). helpnetsecurity.com
7. BleepingComputer (Oct 17, updated Oct 18, 2026). bleepingcomputer.com
8. ITPro (Oct 20, 2026). itpro.com
9. CoreView Intelligence Labs (Oct 19, 2026). coreview.com
10. Microsoft Learn, Disable user sign in for application (updated Oct 15, 2026). learn.microsoft.com
11. 45 CFR 164.402 (Cornell LII). law.cornell.edu
12. 45 CFR 164.308 (Cornell LII) (last amended 2013). law.cornell.edu
13. New York Attorney General, SHIELD Act (law signed July 25, 2019). ag.ny.gov
14. Full source list and how we check claims: bitralynx.com/research sources