When ConnectWise disabled seven application identities on October 17, 2026, after detecting unauthorized access three days earlier, it exposed a vulnerability many MSPs overlook: your service applications hold more power over client environments than your admin passwords. If an attacker steals an application credential with delegated permissions, they can bypass individual customer defenses. They authenticate as your application and access every connected tenant.
This checklist helps you ensure your application credential management can withstand scrutiny from both attackers and underwriters. Each item includes the specific control you need and what a properly implemented version looks like.
Checklist Overview
Application identities in Microsoft Entra ID and similar platforms operate with permissions you've granted for tasks like backup, management, or monitoring. These permissions often include Global Administrator-equivalent access across multiple customer tenants. If an attacker obtains the application's client secret or certificate, they can request access tokens, add themselves to privileged roles, create new credentials, and establish persistence without ever touching a user password.
This checklist focuses on credential hygiene, permission scoping, monitoring configuration, and incident response readiness for multi-tenant service applications.
Prerequisites
Before starting this checklist, confirm:
- You maintain an inventory of all application registrations in your Entra tenant.
- You know which applications have delegated permissions into customer tenants.
- You can access Entra ID sign-in logs with at least 30 days of retention.
- You have documented your current application credential rotation schedule (even if that schedule is "never").
Credential Management Controls
1. Application credential lifetime is capped at 90 days or less
Check your application management policy settings in Entra ID. Verify that the maximum credential lifetime for client secrets is set to 90 days. For certificates, 365 days is acceptable if you have automated rotation.
What good looks like: Your policy prevents anyone from creating a client secret valid for more than 90 days. You have calendar reminders 30 days before expiration for manual rotations.
2. Client secrets are stored exclusively in a secrets management vault
Audit where application credentials currently live. They should never appear in configuration files, environment variables, or ticketing systems.
What good looks like: Secrets exist only in Azure Key Vault, HashiCorp Vault, or equivalent. Applications retrieve them programmatically at runtime. No human has viewed the plaintext secret since creation.
3. Application Administrator and Cloud Application Administrator roles are assigned to fewer than three people
Review directory role assignments. These roles allow adding credentials to any application registration, which means they can plant persistence mechanisms.
What good looks like: Only your security lead and one backup hold these roles. You have alerting configured for any assignment changes.
4. Multi-factor authentication is enforced for all accounts holding application management roles
Verify Conditional Access policies targeting directory role holders. MFA should be non-negotiable.
What good looks like: Your Conditional Access policy requires phishing-resistant MFA (FIDO2 or certificate-based) for anyone who can modify application registrations. No exceptions.
Permission Scoping and Monitoring
5. Each application holds only the minimum permissions required for its function
Review the API permissions granted to each application. Compare them against the actual operations the application performs.
What good looks like: Your backup application has Sites.Read.All and Files.ReadWrite.All, but not User.ReadWrite.All or RoleManagement.ReadWrite.Directory. You removed broad permissions and the application still functions.
6. Conditional Access for workload identities restricts sign-in locations
If you have the required licensing (Entra ID P1 or P2 for workload identity protection), configure location-based restrictions.
What good looks like: Your application identities can only authenticate from your documented datacenter IP ranges or Azure regions. Sign-ins from 144.172.64[.]128 (the IP address associated with the ConnectWise incident) would be automatically blocked.
7. Sign-in logs are monitored for application identity authentication from unexpected locations
Configure alerts in your SIEM or Microsoft Sentinel for service principal sign-ins from IPs outside your allowlist.
What good looks like: You receive a notification within 15 minutes when any application identity authenticates from an unfamiliar IP. You have a runbook ready to disable the application and revoke tokens.
8. Entra ID Protection monitors for risky service principals
Enable Entra ID Protection if available. Verify that risky service principal detection is active.
What good looks like: Your security dashboard shows risk detections for service principals. You've tested the alert path by simulating a sign-in from an anonymizing VPN.
Audit and Review Requirements
9. Application credentials are inventoried monthly with expiration dates tracked
Export all application registrations and their credential expiration dates. Verify nothing is expired or expiring within 14 days.
What good looks like: You have a spreadsheet or dashboard showing every application, credential type, creation date, and expiration date. Credentials expiring in under 30 days are highlighted.
10. Sign-in logs are reviewed weekly for all high-privilege applications
Filter Entra ID sign-in logs to show only service principal activity. Review for anomalies.
What good looks like: You spend 20 minutes each Monday reviewing application sign-ins. You know what normal looks like: expected source IPs, consistent timing patterns, typical resource access.
11. Customer tenant reviews happen quarterly for dormant application connections
Identify customer tenants where your applications haven't authenticated in 90+ days. Verify whether the connection is still needed.
What good looks like: You maintain a list of active versus dormant connections. You've contacted customers with dormant connections to confirm whether they still use your service. If not, you've removed the application consent.
Incident Response Readiness
12. You can disable all application identities within 30 minutes
Test your ability to quickly revoke application credentials during an incident.
What good looks like: You have a documented procedure with screenshots. You've practiced it during a tabletop exercise. Your on-call team knows where the runbook lives.
13. Token revocation procedures are documented and tested
Understand that disabling an application doesn't immediately invalidate issued access tokens. They remain valid until expiration (typically one hour).
What good looks like: Your runbook includes steps to force token revocation where possible and explains the gap period. You monitor for continued suspicious activity during that window.
14. Preservation of sign-in and audit logs is automated before containment
During the ConnectWise incident, partners were advised to preserve logs before taking containment actions. You need this capability automated.
What good looks like: Your incident response playbook triggers an automated export of the last 30 days of Entra sign-in logs and audit logs to immutable storage before any credentials are revoked.
Common Mistakes
Assuming application credentials expire automatically. They don't. A client secret created with a two-year lifetime remains valid for two years unless you manually revoke it or set a policy to prevent long lifetimes in the first place.
Treating application identities as less sensitive than user accounts. In multi-tenant scenarios, a compromised application credential is more dangerous than a compromised user password because it grants access to every connected customer simultaneously.
Forgetting that disabling an application doesn't revoke active tokens. As ConnectWise noted, "Previously issued access tokens may remain usable until they expire or are otherwise invalidated." An attacker with a valid token can continue operating for up to an hour after you disable the application.
Not reviewing which applications can add credentials to other applications. If an attacker gains access to an application with permissions to modify other application registrations, they can plant client secrets in trusted apps and maintain persistence even after you revoke the original compromised credential.
Next Steps
Start with items 1, 3, 9, and 12. These controls address the highest-impact gaps: credential lifetime limits, privileged role assignments, visibility into what you have deployed, and your ability to respond quickly when something goes wrong.
Then layer in monitoring (items 6, 7, and 8) before moving to the quarterly review cadence (item 11).
If you're preparing for a cyber insurance renewal, underwriters increasingly ask specific questions about application credential management in multi-tenant environments. Having documented evidence that you've completed this checklist puts you in a stronger negotiating position than answering "we follow recommended practices."
