We wrote on Saturday that ConnectWise's containment and its outage were the same switch. Four days into the incident, that switch is still off, and it has taken two more products with it.

What is suspended now

ConnectWise's advisory, updated at 01:15 UTC on 19 October, says that Cloud Backup, SaaS Security and Cloud Management all remain suspended. The reason the other two went down is given plainly: "Because SaaS Security and Cloud Management are integrated with Cloud Backup, we also suspended those services out of an abundance of caution."

The list of what that removes is the part worth reading slowly. "Scheduled backups, archive access, and restores remain unavailable, along with SaaS Security monitoring and alerting and Cloud Management user and license management."

So for the managed service providers that run on this stack: no backups are being taken, no existing backup can be read, no restore can be performed, the security monitoring product is not monitoring, and user and licence administration is unavailable. Across every customer tenant they manage.

ConnectWise does not minimise it: "We do not yet have a confirmed restoration time and will share a timeline as soon as we can do so reliably."

Seven identities, and one of them is Partner Center

The advisory now lists what ConnectWise switched off. At 07:00 UTC on 17 October it disabled seven application identities: Cloud Backup, Cloud Management, and five Cloud Management connectors for Microsoft Teams, Exchange Online, Microsoft Graph, Partner Center and SharePoint Online.

That list is the blast radius written out. Those are the places the compromised identities could reach, and Partner Center is the one to sit with: it is the interface through which a provider administers its customers' subscriptions.

Two operational notes in the advisory are worth lifting out, because both are the kind of thing that quietly breaks an investigation.

First: "A vendor action and a customer-tenant setting are different controls; this table does not document a separate local change in every customer tenant." ConnectWise disabling an identity centrally does not disable it in your tenant. Partners have to check and set it locally, per tenant.

Second: "Older installations may display SkyKick Cloud Manager names. Match on Application ID rather than display name, and record the local Object ID as well." A search by name will miss the ones that matter most, which are the oldest installations.

And a third, which echoes a theme from elsewhere this week: "Do not delete the application as the first response; preserve its configuration and evidence for investigation."

The good news, stated carefully

"Containment measures remain in place. Since implementing mitigations, we have not observed successful threat activity in the environments we monitor."

That sentence is doing honest work and it is worth not over-reading. It says no successful activity, in environments ConnectWise monitors, since the mitigations. It does not say the actor is out, and it does not speak to the tenants ConnectWise cannot see, which is most of them — the application was consented into partners' customers' tenants, not into ConnectWise's.

The company is publishing on a schedule, promising its next update by a stated time, which is better practice than most incidents of this size manage.

The second-order problem nobody planned for

There is a category of organisation whose disaster recovery plan assumes the backup product works. For four days it has not.

Nothing has been lost — ConnectWise has said the archive itself is intact and will be reachable once service returns. But a backup you cannot restore from is not a backup while you cannot restore from it, and the window in which that matters is exactly the window where something else goes wrong. Ransomware does not check whether your vendor is having an incident.

The same logic applies to the monitoring product. An MSP that bought SaaS Security to watch its customers' Microsoft 365 tenants has spent four days without that watch, during an incident whose entire mechanism was unauthorised access to Microsoft 365 tenants.

We wrote recently about a single contractor that sends the notices for every federal bankruptcy court. This is the same shape at a different scale: the thing that failed was not a product, it was a dependency that several other things sat on.

What to do

  • Keep the applications disabled until ConnectWise publishes formal restoration instructions. Its advisory asks for exactly that, and re-enabling early undoes the containment.
  • Work out, in writing, what your recovery position is without this product, and for how long you can hold it. If the answer is uncomfortable, that is the finding.
  • If you resell through a distributor or marketplace, make sure the administrator responsible for each customer tenant has actually received the guidance. ConnectWise flags this specifically, and it is where instructions get lost.
  • Keep reviewing your own tenant and every customer tenant against the indicators rather than waiting for a summary. The Trust Center is where the current state lives.
  • Do not treat "no successful threat activity observed" as all-clear. It is a statement about ConnectWise's visibility.

What is not established

  • When service will return. ConnectWise says it does not have a reliable timeline.
  • Whether any data was taken from any tenant. Nothing has been confirmed by ConnectWise or by anyone else.
  • How the application identities were compromised. Still unanswered four days in.
  • How many tenants were accessed in total. The 173 figure is one vendor's confirmed count in its own telemetry.
  • Whether the actor retains any access anywhere. The advisory speaks only to environments ConnectWise monitors.
  • Who is responsible. No attribution has been offered by anyone.