ConnectWise Cloud Backup: the app never needed MFA

The attacker signed in as the app

Your users passed MFA. The attacker signed in as the app. That is the identity boundary behind the ConnectWise Cloud Backup incident: an application credential was used to request access under permissions already granted inside customer tenants. A control designed to challenge a human sign-in was never the gate on that path.

ConnectWise's advisory, checked on 20 October 2026, confirms unauthorized access to application identities and describes containment. It still leaves the original credential-exposure mechanism under investigation. This article is a source-based architecture analysis, not a reconstruction in a live tenant. The durable question is what access an integration retains when its operator's credential is in hostile hands. [1][2]

Consent creates an identity with standing permissions

Application permissions differ from delegated permissions. In the client-credentials flow, software authenticates as itself without a signed-in user. A multitenant application has a service principal in each tenant where it is used; consent and assigned permissions establish what that identity can do there. Resetting a user's password does not revoke the application's credential or rewrite those grants. [3][4]

This is why I start an integration review with the permission set rather than the vendor's product label. Backup and restore are legitimate reasons for broad data access, but a read capability, a write capability and permission to modify identities create different consequences. Record the exact grants and directory roles in your tenant. Do not assume every customer granted the same rights, or that the word backup limits the application to reading.

Conceptual app-only path

Vendor application credential
  -> token request for customer tenant
  -> customer service principal + granted permissions
  -> access token for a resource
  -> resource operation

No user password or MFA prompt is part of this flow.

Does your policy cover this kind of application?

Microsoft's workload Conditional Access documentation excludes third-party SaaS and multitenant applications from these service-principal policies. Buying the relevant license does not remove that scope restriction. The related workload Continuous Access Evaluation documentation also limits support to single-tenant service principals registered in the tenant. A feature name is not evidence that a specific identity is covered. [5][6]

The practical review is a mapping exercise: for each integration, name the control that evaluates its token request, the resource that accepts the token, and the permissions it can exercise. Where a policy does not apply, record the gap and the available compensating restrictions. User MFA remains valuable for user access; pretending it also governs app-only credentials leaves a separate identity unexamined.

Disabling an app answers only part of containment

Stopping new token issuance and invalidating existing access are different operations. Microsoft documents a default access-token lifetime of 60–90 minutes, but this is not a universal incident countdown. Token settings, resource behavior and supported revocation mechanisms matter. ConnectWise explicitly says previously issued tokens may remain usable until expiry or other invalidation. Use that distinction in the response plan instead of assuming disable means instant logout. [1][7]

There is a third state: access created through another identity. Huntress reports unauthorized credentials added to other applications in affected tenants. Disabling the original ConnectWise application does not remove those credentials. My closure model therefore has three separate rows: new issuance blocked, previously issued access accounted for, and unauthorized downstream access removed. Waiting ninety minutes cannot prove the third row. [2]

Containment question                 Evidence to request
New tokens still issued?             Application state + sign-in outcomes
Existing token still accepted?       Resource behavior + expiry/invalidation
New independent access established?  Credential, grant and role-change review

Elapsed time alone is not a closure record.

Successful sign-in is evidence of access, not every possible action

A successful service-principal sign-in proves something narrower than reading every mailbox. Todyl's published investigation describes sign-in activity without the persistence changes it looked for in its reviewed tenants. Huntress describes post-compromise changes elsewhere. These are different observation sets, not grounds to project the worst observed outcome onto every customer. Permission establishes capability; operation-level evidence establishes observed use. [2][8]

The opposite shortcut is unsafe too. An empty user sign-in view does not cover service-principal sign-ins, which Microsoft records separately. Nor do missing audit entries prove that every possible data read would have been logged. Keep the statement bounded: what telemetry was available, which identities and resources it covered, and which operations it can actually show. Unknown is a useful conclusion when it preserves the next investigation step. [2][9]

Follow changes from the original app to other identities

Search by application ID, then correlate service-principal sign-ins with audit events in the incident window. The Cloud Backup ID below is an initial anchor, not the complete affected-app inventory; use the vendor's current list for the wider app family. Preserve initiator, target, outcome and correlation identifiers. Follow changes where a listed app is the actor as well as changes made to that app. [1]

Review unfamiliar credentials, consent grants and role assignments against approved owner records before classifying them as malicious. Credential validity dates alone do not establish when they were added. Record what was removed, why, and which other identity it enabled. This produces a chain another reviewer can follow, instead of a screenshot showing that one enterprise application is disabled. [1]

Initial application ID: 506e08f9-6e9a-4da4-942b-a099a03644ae
Product label: ConnectWise Cloud Backup / formerly SkyKick

Investigation record:
  tenant + application ID + local service principal ID
  event time + initiator + target + outcome + correlation ID
  credential or permission change + approved owner record
  containment action + remaining access + evidence limits

Ask what survives the disable button

The acceptance question for a third-party integration should be written before an incident: if its credential leaks tomorrow, which customer-side action stops new access, what happens to tokens already issued, and how would we find permissions or credentials created elsewhere? Require named owners for those answers. An integration without a current owner still retains whatever access has not been removed.

The same questions define a useful remediation-verification engagement after an incident. I would check the evidence behind each containment state and trace changes to other identities before treating the original application as the whole problem. Restoring the backup service and proving the tenant's access is under control are related decisions that need separate evidence.