The ConnectWise Backup Breach, and a Key That Is Not Shared

The ConnectWise backup breach is a vendor application identity used as if it were the customer. ConnectWise Cloud Backup, formerly SkyKick, holds Microsoft 365 application credentials so it can back up a tenant. Attackers used a compromised credential to sign in as that application across customer tenants. Huntress confirmed unauthorized access in at least 162 of them. By October 21 the service was still suspended, credentials were being reset, and customers were being told to look at their own tenants because the vendor cannot. This page is about that shape, and about the sign-in this site actually runs.

Huntress published the field report at its note on the vendor credential. ConnectWise's own timeline is on the Trust Center. The sign-in this origin uses is a wallet, the same identity idea as MATA's freedom guide. The verifier is part of the work at Remade With Rust.

How the ConnectWise backup breach crossed tenants

The backup product is supposed to reach Exchange, Teams, SharePoint, and the Graph on the customer's behalf. That reach is an application identity in the tenant, not a password the employee types. A stolen secret for that application is a sign-in as the backup product. Huntress saw the secret used on October 15, from a hosting network rather than the path the application normally takes, moving through accounts seconds apart. The same researchers saw related Cloud Management applications pick up administrator roles in a subset of the tenants they watch. ConnectWise has not confirmed that those role changes were the attacker rather than its own automation.

What the vendor could turn off

On October 17 ConnectWise disabled seven application identities and revoked certificates used for the affected connections. It said the shared Cloud Backup credential was no longer valid. Disabling the connection stops a new sign-in through that connection. It does not undo a change already made inside a tenant, including a credential an application added while it was administrator. ConnectWise also said that, by design, it cannot see downstream customer environments, so it cannot tell a customer whether their tenant was touched. The ConnectWise backup breach leaves that review with the customer. A ConnectWise backup breach outlives the secret that started it.

What October 21 still showed

Help Net Security's October 19 account still had Cloud Backup, SaaS Security, and Cloud Management suspended, with no scheduled backups and no restores. Reporting on October 21, including The Hacker News, still had the backup service offline while credentials were reset and restoration moved in reviewed steps. ConnectWise's statement on the archives is that they remained encrypted and isolated, and that it had no evidence they were accessed. That sentence is theirs. The ConnectWise backup breach is ongoing as a customer problem even after the vendor secret is dead, because a tenant change outlives the secret.

Sign-in here is not an application shared across customers

Sign in with MATA issues a nonce, the wallet signs it, and mid-verify checks the signature on this server. The audience is this origin. The nonce is single-use. The roster is checked for rollback. A bearer key is minted after that, and only a hash of it is stored. There is no application secret that, if copied once, opens every customer's mail. A second visitor has a second key. That is the property the ConnectWise backup breach did not have.

One key, one household

The same split shows up on a device. rusty_esp_mid mints a did:mata on the board. Adoption pins the owner's key. A stranger replaying the owner's record was refused on silicon. A pure Rust alternative to a vendor account is that refusal written as a product: the account that can take the device back is the thing this path does not create. Remade With Rust is where that identity work is described. Rust is the language of the checker. The protection is the key boundary, not a property of the compiler.

What a stolen key still does

The ConnectWise backup breach does not prove that wallet keys are immune. If the household's key is copied, the signature will verify. The Google button on this site is a further limit: it still exists, it yields a did:google, and that identity cannot own a device. People who want the device bound to them use the wallet. People who only wanted a website session can still take the other button, and that session is not adoption.

What this cloud is, and what it refuses

The MATA side of this house, in the freedom guide, is a key the person holds. dldeploy.com checks that key. It does not operate a backup product inside the customer's Microsoft 365 tenant, and it does not keep a credential that can list their mail. The home computer's device catalog is the seam in the MATA Home integration, a device the household adopted, on the LAN.

No tenant-wide backup identity

A ConnectWise backup breach works because the product's job is broad access, held by the vendor, repeated across tenants. This site's job is a session for one wallet, and a device record for one owner. Those records are not a copy of Exchange. Smart home access on your home computer is the same boundary for cameras and sensors: the vendor app is the thing being left behind. The Learn index is the set of pages that say what has actually run.

The sentence this page will stand on

The ConnectWise backup breach is a shared application secret plus a vendor that cannot see the tenant after the secret is used. Sign-in with MATA is a per-wallet signature, checked locally, with no Microsoft 365 backup product behind it. That is the protection. It is not a restoration guide for a tenant that already granted those applications administrator, and it is not a promise that a copied household key would fail the check.