The Conventional Wisdom
You've enabled multi-factor authentication (MFA) across your Microsoft 365 tenant, believing it protects against credential compromise. Users can't sign in without a second factor, so even if a password leaks, your environment stays secure. That's what many organizations tell their boards.
The Overlooked Risk
This view misses a critical authentication pathway: application credentials. When ConnectWise's Cloud Backup credential was compromised, it accessed Microsoft Graph tokens across 162 customer tenants without triggering an MFA prompt. No user signed in, and no second factor was requested. The application authenticated directly using a credential stored in ConnectWise's environment.
Your MFA policy governs user authentication, not how third-party applications connect to your tenant. Applications use OAuth 2.0 client credentials, designed for service-to-service authentication without user interaction. This isn't a protocol flaw; it's how the system is intended to work.
The issue is conceptual, not technical. Security programs focus on user identities while granting applications extensive permissions. ConnectWise Cloud Backup needed broad access across Exchange Online, OneDrive, SharePoint, and Teams. When its credential was compromised, the attacker gained all those permissions.
The Evidence
Consider what the compromised credential could do. It obtained Microsoft Graph tokens allowing directory reads, potentially without audit trails. In one case, a ConnectWise application assigned itself the Global Administrator role and added credentials to other apps, including a Huntress-specific app, in just five minutes.
ConnectWise disabled seven application identities on October 17. These applications authenticated from IP address 144.172.64[.]128 on October 15, a hosting provider's address, not Azure's private IP space. Your sign-in logs recorded it, but the authentication was valid. The credential and permissions were legitimate, with no anomaly to block.
When ConnectWise suspended services, existing access tokens remained valid until expiration. Disabling the application identity stops new authentication but doesn't revoke tokens already in circulation or undo changes made in customer tenants. If an attacker added credentials to another application or altered a conditional access policy, those changes persist until you manually remove them.
Strengthening Your Security
Start with an application inventory. You can't protect what you don't know exists. In Azure AD, review Enterprise Applications and App Registrations. Document each third-party integration's permissions, when they were granted, and who approved them. Many organizations find applications with permissions like Directory.ReadWrite.All that nobody remembers authorizing.
Implement application-level conditional access policies. Azure AD supports conditions based on service principal risk and IP address ranges. You can require applications to authenticate only from known IP ranges or block authentication during investigations. This limits lateral movement if an attacker uses the credential from a different location.
Treat application credentials like privileged accounts. They need vault rotation schedules, expiration policies, and monitoring. If your PAM platform doesn't manage OAuth client secrets and certificates, you're missing a credential type with significant access. Rotate application credentials quarterly and set certificate expiration to force renewal.
Monitor application authentication separately from user authentication. Your SIEM should alert on application sign-ins from unexpected IP addresses or unusual token issuance patterns. The ConnectWise credential authenticated from a hosting provider IP instead of Azure's private space, which is detectable if you're monitoring for it.
Review application permissions during certification campaigns. When managers recertify user access, include a report on which applications can read their team's email or modify SharePoint sites. Many managers don't realize that granting consent to a backup application gives it ongoing access, not just a one-time snapshot.
Develop runbooks for application credential compromise. When ConnectWise disabled affected applications, customers needed to check for mailbox forwarding rules, modified conditional access policies, and added credentials on other applications. Your incident response plan should include steps to identify what an application with specific Microsoft Graph permissions could have changed.
When MFA Works
MFA is effective for user accounts. If this had been a user credential compromise, MFA would have blocked the attack. User-facing attacks are still the primary access vector. Phishing-resistant authentication using FIDO2 prevents credential theft at the user level. Conditional access policies requiring compliant devices stop attackers who steal passwords but can't meet device trust requirements.
However, assuming user-level controls protect the entire authentication surface is a mistake. Applications authenticate differently, hold different permissions, and leave different audit trails. Your security model must account for both.
ConnectWise's response shows conventional wisdom: they disabled compromised identities, revoked certificates, and suspended services. These are the right steps. But customers still need to manually review their tenants for persistence mechanisms because application-level compromise creates risks that user-focused controls can't address.
You can't rely on MFA alone to manage overprivileged application credentials. You need application governance, permission reviews, and monitoring that treats service principals as privileged identities.
