Multi-Tenant SaaS App Credential Compromise Playbook: Contain One Secret Across Every Tenant

When the client secret or certificate of a multi-tenant SaaS application is stolen, the attacker can sign in as that application to every customer tenant that consented to it, with no user, no password prompt and no MFA anywhere in the path. In October 2026 a stolen ConnectWise Cloud Backup app credential produced confirmed unauthorised sign-ins in 162 Microsoft 365 tenants in one security vendor's customer base alone. This playbook template has two branches: Branch P for the SaaS provider that owns the application registration, and Branch C for a customer tenant that consented to it. It covers triggers, roles, decision points, evidence, credential replacement without breaking every customer, persistence hunting and notification, using Microsoft Entra ID as the worked platform. It is written for SaaS security and platform teams, incident managers and Microsoft 365 administrators; adapt the bracketed text before adoption.

How to use this template

• Replace text in square brackets, such as [Organisation], [App name] and [Incident Manager], with your own names. "Must" is mandatory; "should" is recommended.
• Decision points are marked D1 to D5. Record each decision, who made it and when.
• Platform steps reflect Microsoft documentation as checked on 28 October 2026. Re-check them yearly; other platforms (Google Workspace marketplace apps, Salesforce connected apps) need equivalent runbook steps.
• For a stolen user or integration token rather than an app credential, use the OAuth Token Theft Incident Playbook; for a supplier breach where you only receive a notice, the Vendor SaaS Breach Response Playbook.

1. Scope and triggers

This playbook applies when a credential (client secret, certificate private key or federated credential trust) of a multi-tenant application is suspected to be held or used by an unauthorised party. In Entra ID the application object lives in the provider's home tenant, and each consenting customer has a service principal for it; a token request with the app's credential against a customer tenant returns an app-only token carrying whatever application permissions that customer granted.

Out of scope: single-tenant service principal compromise inside one organisation, handled by the [Identity Incident Playbook].

2. Roles and contacts

3. Detection and triage

1. Confirm which credential. (P) List passwordCredentials and keyCredentials on the application object (GET /applications/{id}) and record every keyId, start and end date. Identify the one exposed, and any you did not create.
2. Find use outside your infrastructure. (P) Review sign-in activity for the app and your token issuance telemetry for source IPs outside [egress ranges]. (C) In Entra ID, open Sign-in logs, Service principal sign-ins, and filter on the app ID. Application sign-ins do not appear in user sign-in logs.
3. Check the audit log for persistence. Filter Application Management activities: "Update application" entries for certificates and secrets management, "Add app role assignment to service principal", "Consent to application", "Update Service Principal" and "Add Service Principal". Also check role assignment changes for any service principal.
4. Check risk signals. Identity Protection risky workload identity detections and, where licensed, Defender for Cloud Apps "Unusual addition of credentials to an OAuth app".
5. D1, declare and classify: exposure only (credential leaked, no confirmed use), confirmed use against some tenants, or confirmed use with persistence or data access. Severity follows the permissions the app holds: tenant-wide mail or file read and write is critical by default.

Evidence to preserve

• Service principal sign-in logs and directory audit logs for the app and all service principals, exported now. Todyl noted during the ConnectWise response that Entra ID Free keeps these logs for only seven days, so export before anything else.
• The application object's credential list, permissions (API permissions and app role assignments) and owners, as JSON, before any change.
• (P) Source-control history, CI logs or secret store access logs showing where the credential was stored and who read it.
• Mailbox, SharePoint and Graph activity for the app's object ID in the unified audit log, for the scoping window.

4. Containment

D2, cut over or shut off (P): if you can deploy a new credential to all production services within [hours], rotate (step 1 below). If not, or if use is confirmed and ongoing, disable the application's ability to obtain tokens first and accept the outage. The ConnectWise response disabled seven application identities and suspended the service for every customer, which shows the real cost of this decision.

1. Add a new credential, then remove the old one (P). Add a new certificate (POST /applications/{id}/addKey), deploy it, then remove the compromised credential immediately with removePassword or removeKey. Remove every credential you cannot account for at the same time.
2. Remove credentials on service principals (P and C). Microsoft advises repeating removal on every associated service principal (/servicePrincipals/{id}/removePassword and removeKey), which matters most for multi-tenant apps. Customers should check their own service principal for the vendor app for credentials added locally.
3. Disable, do not delete (C). Set the service principal's accountEnabled to false (Enterprise applications, Properties, Enabled for users to sign in: No). Disabling keeps consent and permissions so the app can be re-enabled without re-consent; export the permissions first.
4. Allow for live tokens. Access tokens already issued keep working until they expire. Microsoft assigns a default lifetime of 60 to 90 minutes, so continue monitoring for at least that long after removal, and treat activity inside that window as possible attacker use.
5. Do not rely on Conditional Access for this app (C). Conditional Access for workload identities applies only to single-tenant service principals registered in your tenant, not to third-party multi-tenant apps, and needs Workload Identities Premium. Use disablement instead.

5. Eradication

• Hunt across every application, not only the vendor's (C): list credentials on all app registrations and service principals and remove any added since [start of the scoping window]. In the ConnectWise case, new client secrets valid until 2028 were added to an MSP management app and a security vendor's app, so disabling the vendor app alone would have left the attacker in.
• Remove unrequested roles (C): review directory role assignments for service principals; remove Exchange Administrator, Global Administrator or other roles a vendor app gave itself.
• Close the source (P): remove the credential from wherever it leaked (repository history, build logs, a compromised host), rotate any credential stored alongside it, and determine how it was obtained. Commvault's 2025 incident shows the source can be the provider's own cloud environment: see the Commvault Metallic Breach.
• Rotate downstream secrets: if the app could read Key Vault or other secret stores, rotate secrets that were read first, then the rest of the exposed vaults, as Microsoft's compromised application guidance sets out.
• D3, data exposure: decide, per tenant, whether audit evidence shows data was read. Absence of read records only counts if the relevant audit logging was enabled and retained.

6. Recovery

1. Replace secrets with stronger credentials (P). Prefer a federated credential, such as trusting a user-assigned managed identity (audience api://AzureADTokenExchange), which Microsoft supports for multi-tenant apps accessing other tenants, so no secret exists to steal. Otherwise use a certificate whose private key is held in an HSM-backed key store.
2. Lock service principal properties (P). Enable the app instance property lock for credentials used for verification and signing, so credentials cannot be added to the app's service principals in customer tenants. Microsoft says the lock is enabled by default for new applications since June 2026; check existing apps.
3. Reduce permissions (P). Drop application permissions the service does not need before customers re-consent, such as Directory.ReadWrite.All where read is enough.
4. D4, re-enable (C): re-enable the vendor service principal only after the provider confirms in writing that compromised credentials are removed, and after your own persistence hunt is complete. Monitor its sign-ins for [30] days.
5. Monitor for re-enablement or recovery: alert on "Update Service Principal" with account enabled set to true and on "Add Service Principal", so a disabled app cannot quietly return.

7. Communication and notification

• D5, customer notice (P): notify every consenting tenant, not only those with confirmed sign-ins, with: the app ID, the window of exposure, attacker IPs, what you rotated and when, and the specific hunt steps in section 5. Provide machine-readable indicators.
• Tell customers what not to do: advise disabling rather than deleting the service principal, so they can recover without re-consent and keep evidence.
• Regulatory and contractual: [Legal and Privacy] assesses personal data breach obligations per tenant and contract notification clauses. Record the reasoning, including where the provider is a processor and the customer the controller.
• Platform provider: open a security case with Microsoft or the relevant platform for help with tenant-wide notification and indicators.
• Customers (C): inform your own downstream clients if you are an MSP, and record service impact while the app is disabled (for example, backups not running).

8. Post-incident review

• How was the credential stored, who could read it and why did it work from outside the provider's network?
• Was there an inventory of every credential on the app, with an owner and an expiry, before the incident?
• How long from first unauthorised sign-in to detection, to credential removal and to customer notice?
• Could a federated credential or certificate in an HSM have replaced the secret?
• (C) Which vendor apps hold tenant-wide permissions, and is service principal sign-in logging retained long enough to scope the next one?

Implementation guidance

• Prepare before an incident (P): keep a register of every multi-tenant app, its credentials and their consumers, and rehearse a full credential rotation once a year so step 4.1 takes hours, not days.
• Pre-build customer guidance (P): keep a customer notice and hunt guide drafted per app, with the app ID and permission list.
• Know your vendor apps (C): list enterprise applications with application permissions, assign an owner to each, and stream service principal sign-in logs to [SIEM]. See the SaaS and OAuth App Governance Guide and the Entra ID Applications and Consent Guide.
• Contract for it (C): require vendors to state how they protect app credentials, how fast they notify, and that they will provide indicators. See the Third-Party Access Guide.

Standards and references

• Microsoft: Compromised and malicious applications investigation
• Microsoft: Conditional Access for workload identities
• Microsoft: Configure app instance property lock
• Microsoft: Configure an application to trust a managed identity
• Microsoft: Access tokens in the Microsoft identity platform
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: ConnectWise Cloud Backup Breach 2026 · SaaS and OAuth App Governance Guide · Azure Entra Client Secrets Security Guide · Compromised MSP Playbook · Storm-0940 Password Spray Botnet Profile Guide