A backup integration does not need a stolen user password to become an attacker’s route into a tenant. It already has a trusted application identity, approved permissions, and a place in normal operational traffic. A compromise involving a backup provider’s application credentials is therefore an identity incident first and a service outage second.

ConnectWise suspended its Cloud Backup service, formerly SkyKick, after reporting unauthorized access to application identities associated with the service. SaaS Security and Cloud Management were also suspended because they integrate with Cloud Backup. Scheduled backups, archive access, and restores remain unavailable while the investigation and remediation continue. ConnectWise’s advisory

TL;DR

  • ConnectWise reported unauthorized access to Cloud Backup application identities and disabled seven affected identities.
  • The vendor says its encrypted backup archives remain isolated and it has no evidence they were accessed. That does not establish whether a particular Microsoft 365 tenant saw unauthorized activity.
  • If your organization or customers use the service, review service principal sign-ins, application permissions, and tenant changes. A user-sign-in-only review misses the relevant log stream.

Why This Matters to Microsoft 365 Defenders

The most dangerous part of a SaaS integration is often not its dashboard. It is the relationship behind it: a non-human identity that can read mail, files, collaboration data, or directory objects in order to perform the job it was approved to do.

ConnectWise says that on October 17 it disabled seven application identities and revoked certificates used by affected connections. That prevents new authentication through those connections. It does not undo prior activity inside a customer tenant, and it does not automatically remove access that may have been created through a separate identity. ConnectWise technical update

This is not evidence that every customer tenant was compromised. ConnectWise explicitly says it has not identified confirmed downstream customer compromise and has no evidence that existing encrypted backup archives were accessed. It also says it cannot determine from its own investigation alone whether a particular customer environment experienced unauthorized activity. Those are different facts. Collapsing them into either “no issue” or “all data leaked” would be wrong.

Service Outage Is Not Tenant Compromise

The response needs two workstreams. The first is continuity: identify workloads with no current recovery point, track the coverage gap, and ensure temporary handling does not create an ungoverned copy of sensitive data. The second is security: determine whether the tenant shows unexpected application activity or changes that warrant containment.

Neither workstream substitutes for the other. A restored backup service does not prove that an application did not create a new permission grant. A clean-looking tenant does not mean the organization can safely accept an unbounded recovery gap.

The incident also illustrates why a third-party integration should be treated like an internal privileged workload. It needs an owner, a documented reason for each permission, logging, periodic review, and an offboarding path. “Vendor supplied” is not a security control.

Start With the Correct Log Stream

ConnectWise tells affected partners to review Microsoft Entra service principal sign-ins. In the Entra admin center, open Monitoring → Sign-in logs and select the Service principal sign-ins tab. The ordinary user-sign-ins view does not show the application authentication activity required for this investigation.

The vendor’s published hunt details identify application ID 506e08f9-6e9a-4da4-942b-a099a03644ae, suspicious source IP 144.172.64.128, and the observed user agents Python-urllib/3.12 and python-requests/2.31. Treat these as leads, not a verdict: ConnectWise states that an indicator match alone does not confirm compromise. ConnectWise IOCs and review guidance

For every relevant tenant, preserve the result set and record the period you could actually search. Log retention matters. A conclusion based on 30 days of logs is a conclusion about 30 days of logs, not a guarantee about the prior year.

Review areaQuestion to answerWhy it matters
Service principal sign-insDid the affected application authenticate outside its normal pattern?This is the vendor-directed activity source.
Enterprise application permissionsDid any application receive new, elevated, or unexpected consent?Revoking one connection does not remove separately created grants.
App owners and credentialsWere owners, certificates, or secrets added or changed?Those changes can create a durable path back into the tenant.
Tenant activityDid mailbox rules, privileged roles, or high-value files change after suspicious activity?The application sign-in is an entry point, not the whole investigation.

Do Not Hunt by IP Address Alone

An IP-address query is useful for triage, but it is a weak incident boundary. Cloud services use shared and changing infrastructure; attackers can switch origin, and a legitimate automation may produce unfamiliar traffic after a service change.

Build a timeline instead. Start with the application identity and correlate sign-ins to consent changes, directory audit events, mailbox configuration, file access, and administrator actions. Compare the result against a known-good period and expected integration behavior. If the environment lacks the needed audit sources, document that limitation rather than replacing it with confidence.

The same discipline applies to tokens. ConnectWise notes that previously issued access tokens may remain usable until they expire or are invalidated. That is a reason to verify the tenant state and follow vendor restoration instructions, not a reason to indiscriminately remove applications that other business services depend on.

What a Plausible Finding Changes

If the review uncovers suspicious authentication or unauthorized tenant changes, move into the organization’s incident-response process. Preserve audit records before cleanup. Scope what the identity could access, determine what it did access, and identify any new principals, credentials, permissions, sessions, inbox rules, forwarding settings, or data-transfer activity created in that window.

Containment should be evidence-led. Remove unauthorized grants and identities, revoke or rotate credentials that fall within the assessed scope, invalidate applicable sessions or tokens, and check whether downstream access persisted through a different application. A single disabled service principal is not proof that all access is gone.

An investigation that finds no suspicious activity should say exactly that: no suspicious activity was found in the sources reviewed for the documented period. It should not claim that compromise was impossible. Precision makes the result useful to technical teams and leadership.

The Recovery Test That Matters

During the service interruption, catalog which business systems no longer receive fresh recovery points. Establish who owns each risk decision and whether an approved secondary protection mechanism exists. Avoid emergency copies to personal cloud drives, unmanaged removable media, or ad-hoc accounts; those shortcuts can create a new incident while attempting to mitigate the old one.

When ConnectWise formally restores the service, validate three things independently:

  1. A new backup job completes for a representative workload.
  2. Archive access is available only through the expected authorization path.
  3. A representative restore succeeds into an isolated destination and the recovered data is usable.

A green service-status page is not proof of recoverability. A successful restore is.

What You Can Do Today

  1. Identify every tenant that uses ConnectWise Cloud Backup or the former SkyKick service; include customer tenants managed through a reseller or distributor.
  2. Keep affected connections disabled unless and until ConnectWise provides formal reauthorization instructions.
  3. Review service principal sign-ins for the vendor-provided application ID and indicators, then preserve the review timeframe and results.
  4. Review application consent, credential, owner, mailbox-rule, and privileged-role changes around any suspicious activity.
  5. Record the recovery-point gap and test an approved alternative recovery path where one exists.
  6. Inventory every third-party application with high-impact Microsoft 365 permissions and assign each one a business owner.

Sources

Research checked October 19, 2026. The vendor investigation and service status remain subject to change.

  1. ConnectWise Trust Center: Cloud Backup investigation and response guidance
  2. ConnectWise service status
  3. Microsoft Learn: Sign-in logs in Microsoft Entra ID
  4. Microsoft Learn: Secure application ownership