A security incident involving ConnectWise Cloud Backup has put third-party application access under renewed scrutiny after malicious activity was reported in Microsoft 365 environments. ConnectWise disabled customer access to the service while the incident was investigated. Huntress reported observing activity involving at least 162 tenants in its environment, while the full scope remained unclear.
The risk can sit in an application identity
Cloud integrations often use service principals or other application identities to access mailboxes, files and administrative resources. These identities do not behave like a typical employee account, and their activity can be overlooked if monitoring focuses mainly on interactive sign-ins. The impact depends on the permissions granted and whether credentials or tokens can be abused.
ConnectWise said it had no evidence at the time of reporting that stored backup archives were compromised and described those archives as encrypted and isolated. That statement is separate from the question of whether live Microsoft 365 tenants were accessed. Organisations need to assess both their backup data and activity inside the production tenant.
What Microsoft 365 administrators should review
Check service-principal sign-in logs, application credentials, OAuth grants, role assignments and activity involving Exchange, SharePoint, OneDrive and Teams. Follow the vendors’ current guidance for identifying affected application identities and revoking credentials. Disabling an integration may stop some access, but teams should verify whether existing tokens or other credentials remain valid.
The broader lesson is to grant third-party applications only the permissions they need and to monitor them as carefully as human accounts. Cloud backup products can be essential to recovery, but their access paths must be included in incident response, identity governance and routine security reviews.
Review the permissions behind the backup
Cloud backup products often hold broad permissions because they must discover, copy and restore information across many accounts. That access makes them valuable operational tools and potentially attractive targets. If an attacker compromises a backup service or its application identity, the concern is not limited to the service's own interface; it may extend to the cloud resources the identity is authorised to access.
Microsoft 365 administrators should review application registrations and enterprise applications with the same care they give human accounts. An application identity may have permissions that persist even when an employee password is changed. Teams should verify the publisher, intended purpose, consent history and granted permissions, then remove or reduce access that is no longer required. Unfamiliar entries should be investigated before being deleted so that legitimate integrations are not accidentally disabled.
Recovery readiness is the real test
Backup status needs to be assessed independently from the security of the production tenant. Administrators should confirm which restore points exist, whether they remain accessible and whether any backup data was modified or deleted. A successful backup job does not guarantee recoverability, so periodic restore tests are important. Copies that are isolated from everyday administrator credentials provide a stronger recovery option if an attacker gains broad access.
During an incident, organisations should preserve audit logs, identify the affected service identities and determine the period in which suspicious activity may have occurred. Revoking a token or disabling an application can be necessary, but the action should be coordinated with evidence collection and continuity needs. Security teams should also check for unexpected mailbox access, new application grants and changes to retention or backup policies.
The central lesson is that a backup strategy is only as strong as its access model and recovery testing. Cloud backup reduces the risk of accidental deletion and service disruption, but it introduces another privileged component that must be patched, monitored and governed. Least-privilege permissions, independent recovery copies and a documented incident process help ensure that the safety net remains available when it is needed.
After reviewing application permissions, administrators should test the recovery process with a controlled restore and confirm that the restored information is usable. A backup dashboard showing green status is not enough if the organisation cannot access the data during an identity compromise. Where possible, separate backup administration from everyday tenant administration and require strong authentication for changes to retention, restore points and service permissions. The incident is a reminder to treat backup software as privileged infrastructure: it deserves monitoring, access reviews and incident planning just like identity systems and production workloads.
Application permissions should be reviewed periodically, not only after a security incident. Record why each integration exists, who owns it and which data it needs. Remove stale grants through a controlled process and alert on unexpected permission changes. For backup services, test restores using the same identity boundaries that would apply during a real recovery. This turns backup from a passive promise into a capability that has been showd under realistic conditions.