TL;DR: Unosecur's analysis of the ConnectWise Cloud Backup breach shows how a stolen application credential enabled token abuse, self-assigned roles and planted secrets inside customer tenants, while vendor remediation left behind access paths the vendor could not remove. The core failure is assuming a supplier can clean up identity changes it never owns.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Unosecur's research: A stolen ConnectWise app credential enabled tenant-wide token abuse, self-assigned roles and planted secrets that survived the vendor's cleanup.
Why it matters: Identity teams need to treat third-party apps as governed identities, because vendor revocation does not automatically remove privileges and credentials planted inside customer tenants.
👉 Read Unosecur's analysis of the ConnectWise Cloud Backup breach and tenant persistence
Context
A third-party application that can write credentials and assign roles inside a tenant is not just a tool integration. It is a privileged identity with its own lifecycle, and that lifecycle has to be governed separately from the vendor's account hygiene. When the application can create durable access inside customer-owned identities, remediation becomes a tenant problem as much as a supplier problem.
The governance gap is ownership drift: the vendor can disable its own app identities, but it cannot revoke everything those identities changed inside the customer environment. That creates a mismatch between who caused the access and who can actually remove it. In practice, this is where tier-zero supplier controls become relevant, because the blast radius sits across both supplier and tenant boundaries.
Key questions
Q: What signs suggest a third-party application has been compromised in a tenant?
A: Signs include unexpected consent grants, new service principals, altered API permissions, unusual mailbox or directory access, and tokens issued from unfamiliar IP addresses or client IDs. A compromised third-party application often persists through application secrets, refresh tokens, or over-privileged OAuth scopes, so investigators should review app registrations, audit logs, and role assignments as well as user accounts.
Q: Why do stolen application credentials remain dangerous after the vendor disables its app?
A: Stolen application credentials can still be used to mint new access tokens, call APIs, or impersonate the application from outside the vendor’s control. Disabling the vendor’s app does not automatically invalidate every cached secret, refresh token, or delegated grant in the tenant, so incident response must revoke credentials, remove consent, and rotate any exposed secrets.
Q: How should teams govern third-party applications that can change tenant identities?
A: Teams should govern third-party applications with explicit ownership, least-privilege API scopes, approval workflows, and periodic review of consent and role grants. Treat each application as a Non-Human Identity with a defined lifecycle, secret rotation, and offboarding process, so stale app registrations, orphaned permissions, and untracked tenant-wide access do not remain in place.
Q: How do app-only tokens differ from user sessions in incident response?
A: App-only tokens authenticate the application itself, while user sessions represent a named human identity with interactive sign-in state and browser or device context. In incident response, app-only tokens usually point to machine-to-machine access, service principal abuse, or secret compromise, whereas user sessions require checking account takeover, MFA status, and conditional access history.
Technical breakdown
How app-only tokens turn a vendor secret into tenant-wide access
App-only authentication lets a service principal request access tokens without a human present. If an attacker holds the client assertion credential, the identity can continue to authenticate as the application until that credential is revoked or expires. In delegated flows, a human session is visible and interactive; in app-only flows, the actor is the app identity itself, so there is no MFA event to challenge and no user session to kill. That makes application credentials the real trust anchor, not the human operator behind them. See the Multi-Tenant SaaS App Credential Compromise Playbook.
Practical implication: Treat application credentials as the primary control surface, because user-session revocation does not stop app-only access.
Why self-assigned directory roles survive the original compromise
Once an application identity can grant itself or a sibling principal a directory role, the attacker no longer depends on the original credential path. The access has been reissued into a different identity object, which means deleting the first principal does not remove the persistence layer. This is a common failure mode in multi-tenant SaaS integrations: the initial foothold is only the start, and the durable risk moves into newly created or repurposed identities that now carry elevated rights.
Practical implication: Review every role grant made by service principals, because persistence often shifts from the original app to a sibling identity.
Why long-lived secrets on customer-owned apps are a separate backdoor
When an attacker adds secrets or certificates to an application the vendor does not control, the resulting credential becomes durable infrastructure inside the tenant. Those secrets can outlive the vendor's own remediation and remain valid until the customer discovers and removes them. The key point is that this is no longer just vendor compromise. It is tenant-side credential persistence embedded into local identities, logs and trust assumptions that were never designed for hostile lifecycle changes.
Practical implication: Inventory every credential added after the incident window and remove anything whose owner and purpose cannot be proven.
Threat narrative
Attacker objective: The objective was to convert one stolen vendor identity into persistent, tenant-owned access that could survive remediation and support broader cloud access.
- Entry occurred through a compromised application credential that allowed the attacker to request app-only tokens without a human login.
- Credential abuse followed when the actor used the stolen application identity to authenticate across many Microsoft 365 tenants.
- Escalation happened as the application granted itself or sibling principals directory roles and planted additional secrets in customer-owned apps.
- Impact included durable access paths, backup disruption and a tenant-level investigation problem because the new credentials outlived the vendor's fix.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- ConnectWise Cloud Backup breach 2026: A stolen ConnectWise Cloud Backup app secret gave attackers sign-ins to 160+ Microsoft 365 tenants, then admin roles via sibling service principals.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Third-party applications must be governed as tenant-local identities, not as disposable integrations. This breach shows what happens when a supplier identity can create durable access inside customer-owned apps and directory roles. The remediation boundary stops at the vendor's own objects, but the persistence boundary sits in the tenant. Practitioners should treat any consented app with write privileges as part of the identity estate, with an owner, scope and offboarding path.
Vendor cleanup does not equal access cleanup. The vendor can invalidate its own secrets and disable its own application identities, but it cannot remove credentials or roles already planted elsewhere in the tenant. That is a control gap in lifecycle governance, not just an incident response issue. The practical implication is that offboarding logic must include every identity object the app touched, not only the app that was compromised.
Persistent access moved from the original principal to sibling identities. Once the attacker began reassigning roles and planting new credentials, the incident stopped being about one compromised app and became about identity drift across the tenant. That is why the named concept here is vendor access without lifecycle offboarding: the relationship changed, the access did not, and the tenant kept the backdoor after the supplier acted.
Directory-role abuse is the real persistence layer in multi-tenant SaaS compromises. The dangerous step was not just token issuance, but the app granting itself elevated rights and shifting them to a different principal when one path failed. That pattern matters because it moves the threat from temporary session abuse into governed identity objects that survive the first remediation pass. The lesson for practitioners is to hunt role change history, not only token logs.
The blast radius is defined by what the application could change, not by what the vendor later revoked. Once a third-party identity can write secrets, grant roles or create sibling access, every tenant-owned object it touched becomes part of the incident scope. That changes how identity teams should think about third-party risk: the control problem is not just who signed in, but which identities can persist after the supplier is cut off.
What this signals
Vendor access without lifecycle offboarding: third-party app compromises now show why offboarding is a tenant governance problem, not just a supplier action. When a vendor identity can mint new secrets or shift privileges inside customer-owned apps, the remaining access becomes part of the customer's identity estate and must be hunted there.
Identity programmes should assume that app-only compromise can outlive the original principal. The practical shift is from checking whether the vendor disabled its own app to checking whether the tenant still has any elevated roles, sibling principals or long-lived secrets created during the compromise window.
For practitioners
- Map every consented app to a named owner Create and maintain an inventory of every application identity, the permissions it can exercise and the business owner who can justify those permissions. Without that ownership map, you cannot tell whether a role grant or secret change was legitimate.
- Review service-principal role grants after every incident window Pull directory role history for all applications, then look for self-assigned privileges, sibling principal grants and unexpected elevation to Global Administrator, Privileged Role Administrator or Exchange Administrator.
- Search for new secrets and certificates on tenant-owned apps List every credential added to applications during the compromise window, confirm who approved each change and remove any secret or certificate that cannot be tied to an approved workflow. See the Multi-Tenant SaaS App Credential Compromise Playbook.
- Separate application access revocation from user-session revocation Test whether your response process can disable app-only access, not just user logins. If the incident involved service principals or OAuth-style application access, session revocation alone will miss the durable path.
- Turn on logging for application activity where available Enable Microsoft Graph activity logging and comparable application-level audit sources so app reads, role changes and secret updates are visible during scoping and disclosure.
Key takeaways
- A compromised third-party app can leave behind durable access even after the vendor disables its own identities.
- The evidence in this case was role drift, planted secrets and app-only token abuse inside customer tenants.
- The limiting control is tenant-side lifecycle offboarding for every identity object the app touched, not just the original vendor principal.
Related NHI Mgmt Group resources: Multi-Tenant SaaS App Credential Compromise Playbook · Remote access and PAM vendors as tier-zero suppliers · Backup and Cyber Recovery Buyer's Guide · ConnectWise Cloud Backup breach 2026
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | The breach began with a third-party application identity that could be abused across tenant boundaries. |
| NHI-05 — Overprivileged NHI | The compromised app could write secrets and assign roles, which is excessive privilege for the trust model. | |
| NHI-07 — Long-Lived Secrets | The incident left behind secrets valid until 2028, creating persistent access after vendor remediation. | |
| Recommendation — Review third-party app trust boundaries and restrict delegated privileges to what the tenant can govern. Reduce application permissions so no third-party identity can create durable tenant access paths. Shorten secret lifetimes and continuously hunt for long-lived credentials attached to non-human identities. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Application credentials were the trust anchor, so credential lifecycle control is central to containment. |
| Recommendation — Apply authenticator lifecycle controls to rotate, revoke and inventory application credentials promptly. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The incident depended on excessive entitlements and role grants inside the tenant directory. |
| Recommendation — Continuously validate application entitlements and remove unauthorized directory permissions. | ||
| MITRE ATT&CK | TA0006;TA0004;TA0008 — Credential Access; Privilege Escalation; Lateral Movement | The attack combined credential abuse with privilege gain and movement across tenant identities. |
| Recommendation — Map tenant application abuse to credential access, escalation and lateral movement hunting. | ||
Key terms
- App-Only Token: An app-only token is an access token issued to an application rather than a signed-in user. It is used for machine-to-machine API calls and carries the application’s granted scopes or roles, so access depends on the app registration, its secrets or certificates, and any tenant consent attached to it.
- Service Principal: An application identity object in Microsoft Entra ID and Microsoft 365 that represents a specific app inside a tenant. It holds permissions, ownership, and configuration data that define what the application can do. In NHI governance, it is a high-value identity that should be reviewed like any other privileged account.
- Directory Role Grant: A directory role grant is an assignment that gives an identity administrative rights inside a directory service. It maps a user, group, service principal, or managed identity to a built-in or custom role, controlling what that identity can manage and often determining privileged access to tenant settings.
- Tenant-Local Persistence: Tenant-local persistence is the ability of an identity, application, or access path to remain active within one tenant even after the original source account, vendor relationship, or external control point changes. It usually comes from local app registrations, consent grants, service principals, or stored secrets that continue to authorise access.
What's in the full article
Unosecur's full analysis covers the operational detail this post intentionally leaves for the source:
- Tenant-by-tenant remediation sequence for disabling the affected application identities without destroying evidence
- Log collection and scoping steps for Microsoft Graph activity, service principal sign-ins and directory role history
- Recovery guidance for backup re-enrollment and partner-side tenant restoration after the incident
- Console and workflow detail for tracing secrets, certificates and privilege changes across affected identities
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on November 4, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org