Multi-factor authentication (MFA) is often touted as your frontline defense against unauthorized access. The common advice is to enable MFA everywhere, closing the door on most credential-based attacks.
The ConnectWise breach just proved that advice dangerously incomplete.
Why MFA Alone Leaves You Exposed
When attackers compromised ConnectWise's Cloud Backup service and accessed at least 162 Microsoft 365 tenants starting October 15, they didn't need to bypass MFA. They didn't need to phish users or crack passwords. They authenticated directly as the application itself using service principal credentials.
MFA never entered the equation.
Here's what happened: ConnectWise's backup service operates through application identities called service principals in Microsoft Entra ID. These identities carry permissions you've already granted, often broad ones like Directory.ReadWrite.All. When the attacker obtained the application's secret, they could sign in as that application and inherit every permission your organization had previously approved.
No user login meant no MFA prompt. The authentication was legitimate from the system's perspective. According to Todyl's analysis of nine compromised tenants, the attacker could read and write mail, access OneDrive and SharePoint files, and view Teams chats, all through permissions the application already held.
Your MFA policy didn't fail. It simply didn't apply.
The Evidence Points to a Blind Spot
The attack pattern reveals how application identity management has become a critical gap in most security programs. Huntress observed that on nearly 50 monitored tenants, ConnectWise's Cloud Management service principals assigned themselves directory roles, primarily Exchange Administrator. In at least one tenant, the attacker established persistence in under five minutes by granting the Cloud Management app Global Administrator rights and adding credentials to other management tools.
Microsoft characterized this as an active supply-chain attack. The threat actor used existing permissions, likely including Directory.ReadWrite.All, to conduct reconnaissance through the Microsoft Graph API and attempt to add additional credentials.
The attacker operated from a single IP address (144.172.64[.]128) using automated scripts with user agents like python-urllib/3.12 and python-requests/2.31. The sign-in activity started as early as October 13, two days before the main compromise wave.
ConnectWise shut down customer access to the Cloud Backup service on October 17 and disabled seven application identities. But here's the problem: disabling an application stops new tokens from being issued, but existing tokens remain valid until they expire. And if the attacker already planted credentials in your tenant, removing the vendor's access doesn't remove those backdoors.
What to Do Instead
Stop treating application permissions as a set-it-and-forget-it configuration. Your third-party SaaS tools and backup services operate with standing privileges that bypass your user-focused controls.
Start with an application permission audit. Review every service principal in your Entra ID tenant. For each one, document what permissions it holds and when those permissions were last reviewed. ConnectWise recommends filtering service principal sign-ins by application ID and examining unexpected source addresses. Do this now for the seven ConnectWise application IDs if you use their services, but extend the practice to every third-party integration.
Implement conditional access policies that apply to application identities, not just users. While you can't apply MFA to service principals, you can restrict sign-ins by IP address, require compliant devices for certain operations, and enforce session controls.
Review application credentials continuously. Huntress found that attackers added secrets and certificates to applications between October 13 and the disclosure date. Your security team should monitor for unauthorized credential additions across all applications, not just during incident response. Set up alerts for any changes to application secrets, certificates, or permissions.
Build application identity management into your vendor risk assessments. Before you grant a third-party tool access to your tenant, document exactly what permissions it requires and why. If a backup service needs Directory.ReadWrite.All, understand what that permission enables and whether the vendor has controls to protect those credentials. Ask about their secret rotation policies, access monitoring, and incident response procedures.
When you onboard a new SaaS tool, create a process for reviewing and removing unnecessary permissions after the initial setup. Many applications request broad permissions during installation but only use a subset during normal operations.
When MFA Is Still Essential
None of this means MFA is obsolete. For user authentication, it remains one of your most effective controls. The ConnectWise breach doesn't diminish the value of requiring MFA for every user account, especially privileged accounts.
MFA protects against credential stuffing, password spraying, and most phishing attacks. It stops attackers who've obtained usernames and passwords through data breaches or social engineering. If an attacker had tried to compromise a ConnectWise administrator's user account, MFA would have blocked that path.
The lesson isn't that MFA failed, it's that MFA addresses only one attack vector. Application identities represent a parallel authentication path that most organizations haven't secured with the same rigor they apply to user accounts.
Your security program needs both: strong user authentication controls and robust application identity management. The ConnectWise incident shows what happens when you focus on one and ignore the other. At least 162 organizations learned that lesson the hard way.
