ConnectWise Cloud Backup Breach and the Long Tail of Previous Best Practices

Last updated: 20 October 2026. I'll update this post as the investigation develops.

As of 19 October, when I first wrote this, ConnectWise has suspended Cloud Backup, SaaS Security and Cloud Management. Scheduled backups, archive access and restores remain unavailable. There's no restoration date yet. The unfolding ConnectWise Cloud Backup security incident gives us a good reason to revisit how we secure third-party applications in Microsoft 365.We routinely grant third-party applications significant permissions to access our Microsoft 365 environments. We control which applications receive those permissions and can revoke that access. However, we generally cannot control the security of credentials held by the vendor. When those credentials are compromised, attackers inherit the permissions that customers legitimately granted.

That's effectively what happened with ConnectWise Cloud Backup, formerly SkyKick. According to Huntress's investigation, attackers used a compromised application credential to authenticate across customer Microsoft 365 tenants. They didn't need individual user passwords or MFA challenges. They authenticated as an application that already had permission to access customer environments. This is the exact scenario that we've been discussing in our webinars since the Midnight Blizzard attack on Microsoft occurred, although the entry vector there was different.

The blast radius turned out to be bigger than one app. Huntress has since linked the activity to ConnectWise's Cloud Management apps too, and by 17 October had seen sign-ins from the attacker's IP address in almost 1,000 tenants, more than 300 of them successful. It's been reported that in some tenants, those apps gave themselves admin roles. In one, the Teams app made itself a Global Administrator and added new secrets to other applications. That's the most worrisome part: once an app can grant roles and add credentials, revoking the original credential doesn't necessarily get the attacker out.

As of writing this on 19 October 2026, the investigation is still unfolding. ConnectWise has disabled affected application identities and suspended several services while remediation continues. The full extent of the compromise, including potential access to customer data, remains unclear. Huntress makes a point worth repeating: Graph directory reads leave no audit record, so a clean log can't prove a clean tenant. The ConnectWise Trust Center and Huntress investigation are worth following for updates.

There will undoubtedly be more technical analysis as the investigation progresses. What is interesting for today is how this incident relates to a problem we've been discussing for some time.

Introducing: The Long Tail of Previous Best Practices

In a recent ENow webinar, I used a phrase that I think describes a significant challenge facing Entra administrators: the long tail of previous best practices. I first coined this phrase in a book discussing Exchange architecture, in which I noted that I was encountering heaps of Exchange 2013 architecture designed based on Exchange 2010 and even Exchange 2007 principles. Few of us still run Exchange servers, but the point remains: we design today using what we assume is right, based on yesterday's knowledge.

Microsoft Entra has evolved considerably over the years. Application consent, credential management, permissions, and identity governance have all received attention, with new controls and recommendations introduced as Microsoft learns from attacks and improves its platform.

The problem, or opportunity, is that customers don't rebuild their environment every time Microsoft changes its guidance!

An application registered five years ago may have been configured according to the recommendations available at the time. It received administrative consent, was granted the permissions it needed, and went into production.

It worked, and it probably still works, but when was it last reviewed? Does it still need those permissions? Does the organisation even use the application anymore? Is there a better or more restrictive way of granting the rights needed for the application to function?

I've seen how difficult application governance can be in practice. Applications accumulate, responsibilities change, and nobody wants to disable something that might interrupt a business process. There are good reasons why organisations struggle to address this, the same reason SharePoint permissions accumulate. It's hard to stay on top of best practices in an operational environment. Meanwhile, attackers have moved on, as has Microsoft's guidance, leaving all of us carrying security decisions made under assumptions that may no longer hold.

Who Can Touch What in Your Tenant?

The ConnectWise incident adds some more spice to our dish: with multitenant applications, customers grant permissions to an application whose registration and credentials are typically controlled by the publisher. A single application identity can therefore have legitimate access to many independent customer environments.

Consider what that means if you've invested heavily in securing Microsoft 365 and done everything "correctly": you may have phishing-resistant MFA, carefully configured Conditional Access policies and well-managed privileged accounts. However, those protections don't necessarily extend to the applications accessing your data.

Microsoft's own documentation confirms that Conditional Access for workload identities does not cover third-party multitenant SaaS applications. What does this mean in practice? While customers remain responsible for the permissions they grant, they have limited control over how a vendor protects the credentials used to exercise those permissions.

There is an opportunity to challenge vendors more directly about this! How are application credentials protected? How many customers could be affected by a single compromised credential? What prevents an attacker from establishing additional access if that credential is stolen?

These are reasonable questions when we're granting applications access to potentially every mailbox, SharePoint site or OneDrive in an organisation. Seeing a compliance certificate in a trust center may tick a procurement requirement, but it doesn't mean much in practice unless there's demonstrable control on that application credential.

As it turns out, that last question was the important one! Huntress saw ConnectWise apps grant themselves admin roles and add secrets to other applications, access that can outlast the stolen credential.

Getting Out of the Long Tail: Reviewing Third-Party App Permissions

The ConnectWise incident does not establish that affected customers were following outdated security practices. A compromised vendor-controlled credential can pose a risk even to customers who follow current recommendations. However, inherited application permissions and forgotten integrations can increase the potential exposure.

We all need to become more deliberate about reviewing the applications we've already trusted.

Start with applications holding broad permissions, particularly those owned by external vendors. Understand what they can access, whether those permissions remain justified, and whether someone within your organisation is accountable for that decision.

Applications that are no longer required should be retired. Those that remain need periodic review, informed by current guidance rather than the recommendations that existed when they were installed. Otherwise, we're back to managing an application based on the long tail of previous best practices.

Application governance is an ongoing operational responsibility. An inventory is useful, but knowing that an application exists tells us relatively little about whether its access remains appropriate.

There is also a responsibility on Microsoft and application vendors to make this easier. The Entra platform has improved considerably, but identifying inherited risk and understanding the consequences of application permissions remain difficult tasks for many administrators!

Microsoft has years of experience observing how these permissions and application identities are abused. I'd like to see more of that experience translated into practical guidance that helps customers identify where their existing configurations have fallen behind current recommendations.

We also need to accept that application governance requires ongoing attention. The fact that an application was approved five years ago tells us very little about whether it should still have the same access today.