How to Audit OAuth App Access After a SaaS Supply-Chain Breach

A SaaS integration can remain trusted long after anyone remembers approving it. It may hold organization-wide permissions, authenticate without a user, and continue operating even when the vendor's dashboard is unavailable. That makes a compromised software provider more than a problem for the provider: its application identity can become a path into every customer tenant that granted it access.

Microsoft's October 21, 2026 report on Storm-0940 and the ConnectWise Cloud Backup compromise makes that risk concrete. Microsoft says the actor used ARTEX to accelerate reconnaissance, password spraying, and OAuth application abuse. It reports attempts to sign in to more than 2,250 Microsoft 365 tenants and says some ARTEX-driven operations reached privileged cloud access in under three hours. Those are Microsoft's reported observations, not proof that every tenant was compromised or that every successful sign-in resulted in data theft. [1]

The practical response is not to panic-delete every integration. It is to identify the application by immutable identifiers, preserve evidence, inspect its sign-ins and permissions, and coordinate containment with the vendor. This guide walks through that process for Microsoft Entra ID. The same reasoning applies to other identity platforms, though their screens and log names differ.

This is a documentation-based response workflow, not a report of a hands-on incident investigation. Use it with your security and identity teams, and follow the affected vendor's current instructions when they apply.

Start with the trust relationship, not the display name

In Entra ID, an application has an application object and a tenant-local service principal. The service principal represents the application in your tenant and is where local permissions and assignments are applied. A familiar display name is not a reliable identity check: names can be changed, duplicated, or imitated.

For an incident involving a specific SaaS integration, collect the application IDs published by the vendor or incident responder. Microsoft specifically recommends inventorying the application IDs it lists, recording the local service-principal object ID in each tenant, and searching by application ID rather than display name. Review every tenant where the application is or was authorized, including tenants where the integration is no longer in active use. [1]

Before changing anything, create an incident record with:

• The application ID and service-principal object ID.
• The tenant ID and the integration's business owner.
• The date and time you began the review, including the time zone.
• The vendor's incident status and the exact containment instructions you are following.
• The people who approved containment and any resulting service impact.

This record prevents a common response mistake: confusing an app that has the same name with the app identified in the advisory. It also gives the team a baseline for reviewing multiple tenants consistently.

Preserve the evidence before making a destructive change

Do not start by deleting the enterprise application. Microsoft advises affected customers to keep application connections disabled until ConnectWise provides formal restoration instructions, but also says not to delete enterprise applications as the first response. Preserve configuration and evidence before irreversible changes. [1]

Capture the current application details, permissions, owners, credentials metadata, assignments, and relevant sign-in and audit logs. Export the records where your retention and incident procedures allow. Keep the original export unchanged and note who collected it. Do not copy secret values into a ticket or report; record credential identifiers and metadata, not the secret itself.

This distinction matters because removing an app can make later investigation harder. It may also obscure which permission grants, owners, or credentials existed before containment. Preserve the evidence first, then restrict access using the vendor's and your incident team's approved steps.

Step 1: Find each tenant-local service principal

In the Microsoft Entra admin center, open Entra ID > Enterprise apps > All applications and search for the application using its application ID. Confirm the result against the service-principal object ID from your inventory. Do not rely on the display name alone.

If an advisory lists several application IDs, search each one separately. Record whether it exists, whether it is enabled, when it was created if available, and which users or groups are assigned. A missing result in one tenant does not prove the integration never existed there; check your tenant's audit history and any centralized inventory as well.

Microsoft recommends reviewing all tenants where the affected applications are currently or were previously installed or authorized. That includes a tenant where a team believes the integration was removed months ago. Historical consent or authentication activity can still matter to the investigation. [1]

Step 2: Review the permissions the app actually received

Open the enterprise application's Permissions page. Examine both Admin consent and User consent. Admin consent applies across the organization; user consent can apply to an individual user or group. Microsoft documents these as separate views, and notes that user-consented permissions cannot be revoked from that portal view. [2]

For every permission, note:

• The resource: for example, Microsoft Graph, Exchange, or SharePoint.
• The permission type: application permission or delegated permission.
• The scope: the specific capability granted, including whether it can read, write, or administer data.
• The consent type: one user, selected users, or the organization.
• The business reason: who owns the integration and whether that access is still required.

Application permissions deserve special attention because they can allow a service to act without a signed-in user. Delegated permissions act in a user's context, but can still expose sensitive data or enable actions available to that user. Do not treat “Microsoft verified” or “admin approved” as a substitute for checking what access exists today.

Look for permissions that are broader than the integration's documented purpose, were not expected by the application owner, or cannot be explained by anyone. Broad permissions such as directory-wide *.All scopes or access to mail and files merit careful review, but a permission name alone is not enough to conclude it was abused. Microsoft recommends investigating highly privileged application permissions and grants to sensitive resources. [3]

Step 3: Examine service-principal sign-ins

Go to Entra ID > Monitoring & health > Sign-in logs > Service principal sign-ins. These are non-user sign-ins where an application or service principal authenticates using its own credential, such as a certificate or client secret. They are different from interactive user sign-ins, so a search limited to user sign-ins can miss this activity. [4]

Set the review window to the dates in the incident guidance. For the ConnectWise investigation, Microsoft recommends reviewing activity beginning at least October 15, 2026, and extending service-principal sign-in review to October 1 where records are available. Preserve relevant failed and successful events. [1]

For each event, compare the application ID, service-principal ID, resource, IP address, status, and time against normal activity and vendor documentation. Ask:

• Did the app authenticate from an unfamiliar source or outside expected vendor infrastructure?
• Did it access resources it does not normally use?
• Are there bursts, unusual timing, or failures followed by success?
• Did activity occur outside the expected region, operating window, or deployment pattern?
• Are there new sign-ins after the vendor said the integration was disabled?

Entra groups service-principal sign-ins when the service principal, status, IP address, and resource match. Expand grouped rows and inspect the individual timestamps before drawing conclusions. A single aggregated row may represent multiple events. [4]

Do not treat a published IP list as a complete allowlist. Microsoft says to investigate unfamiliar sources and activity outside expected vendor infrastructure, and not to limit review to the published IPs. An IP match is a clue to correlate, not proof by itself that an event is malicious or benign. [1]

Step 4: Check for newly added credentials and privilege changes

A stolen application identity can be used to add credentials or seek wider permissions. Review Entra audit logs for changes to application or service-principal credentials, new applications or service principals, new owners, app-role assignments, consent grants, and privileged role assignments. Microsoft calls out credential additions, application changes, and privilege modifications as investigation priorities in this campaign. [1]

In the audit logs, focus on the ApplicationManagement category and the operations associated with adding an app-role assignment, adding a delegated permission grant, or user consent to an application. Microsoft documents these audit activities as records of permission grants and revocations. [5]

Also inspect Microsoft 365 audit records for unusual directory, permission, and approval enumeration. Microsoft recommends reviewing those records for reconnaissance behavior, then checking for changes to users, groups, authentication methods, and Conditional Access policies. Preserve suspicious events even if the associated sign-in failed. [1]

A useful incident timeline links each event to an identity and a change: who or what authenticated, which application was involved, which resource was accessed, what permission or credential changed, and whether the change was expected. Do not assume the displayed actor is a human user; service principals can act without an interactive sign-in.

Step 5: Contain with a deliberate sequence

Follow the vendor's current instructions and your incident-response process. For the ConnectWise event, Microsoft's guidance is to keep affected application connections disabled until formal restoration instructions arrive, preserve the application's configuration and evidence, and avoid deleting it as the first step. The same guidance recommends revoking unnecessary permissions and rotating credentials when suspicious activity is confirmed. [1]

A measured containment sequence is:

1. Confirm scope. Match the application ID and tenant-local service-principal ID against the advisory.
2. Capture evidence. Export relevant permissions, sign-in events, and audit records.
3. Coordinate the disablement. Notify the integration owner and responders about the business impact and approved action.
4. Restrict the affected connection. Use the incident team's and vendor's instructions rather than improvising a permanent deletion.
5. Revoke unnecessary grants and rotate credentials when indicated. Keep the action tied to a confirmed identity and preserve a record of what changed.
6. Verify the result. Recheck the app's state and monitor for additional sign-ins, credential changes, or recreated grants.

Microsoft's Entra documentation provides portal, PowerShell, and Graph methods for reviewing and revoking application permissions. Its examples require high-privilege write scopes and can remove all permissions from an application. Do not paste a broad revocation script into a production tenant without adapting it to the exact service principal and reviewing the impact. A mistaken bulk revoke can break unrelated business workflows. [2]

Step 6: Decide what “clean” means before restoring access

A quiet log after disablement is not a complete recovery test. Before restoring an integration, require a documented vendor restoration notice, a clear list of affected application IDs and credentials, and an explanation of which permissions are necessary. Have the application owner confirm that the business function still needs the integration.

Then verify the security state: expected service principal, least-privilege permission set, known owners, approved credentials, and no unexplained recent grants or role changes. Re-enable access only through the change process, watch the next service-principal sign-ins, and record who approved restoration.

The incident should also produce a small durable inventory: application ID, owner, purpose, permissions, consent date, credential owner, renewal date, and last review date. That turns the next vendor incident from a tenant-wide scavenger hunt into a focused check.

A save-worthy OAuth incident checklist

• Search by immutable application ID, then record the tenant-local service-principal object ID.
• Review every tenant where the app is or was authorized.
• Preserve the application's configuration and logs before destructive changes.
• Inspect admin and user consent separately; distinguish application from delegated permissions.
• Review service-principal sign-ins, including failed events and grouped timestamps.
• Search audit logs for new credentials, owners, grants, and privileged role changes.
• Correlate IP, resource, time, and behavior; do not rely on one IOC alone.
• Disable or revoke only through the incident process, with vendor guidance and impact review.
• Verify the resulting state and monitor it before restoring access.

The ConnectWise case is a reminder that OAuth trust is an operational dependency, not a one-time setup screen. An integration can be both useful and powerful enough to deserve ongoing inventory, least-privilege review, and an incident playbook. The objective is not to remove every third-party application. It is to know exactly what each trusted identity can do, and to be able to contain it without destroying the evidence you need.

I write about developer tools, AI systems, and practical security. Subscribe for more grounded guides to the infrastructure behind modern software.

Have you audited the service principals and OAuth grants in your tenant recently? Which part of the review is hardest to keep current?

Save this checklist for the next SaaS integration incident, and adapt it to your identity provider's exact controls.

Sources

• [1] Microsoft Security: AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise
• [2] Microsoft Learn: Review permissions granted to enterprise applications
• [3] Microsoft Learn: Microsoft Entra security operations for applications
• [4] Microsoft Learn: Service principal sign-in logs
• [5] Microsoft Learn: View Activity logs of application permissions
• [6] ConnectWise: Trust Center Advisories