How do I identify whether cloud activity came from a linked third-party service?¶

Identify linked third-party activity through application IDs, delegated permissions, tokens, API events and consent records.

Evidential caution: that every cloud event originated inside the provider’s own application.

What this means¶

A third-party service may access files, messages, calendars, contacts or account settings through an approved integration.

The event may appear under the user account while the actual request came from another service.

Where the third party is itself a cloud service, it may hold separate records about the request, user and source system.

Delegated tokens or application credentials may remain valid until separately revoked.

Where a third-party service accessed several accounts or resources, assess whether the permission was user-specific or tenant-wide. That distinction can substantially change the potential scope.

What to check or do next¶

• Investigators should preserve the application name, client ID, publisher, permission scope, consent time, account or administrator who approved it and the associated token activity.
• Do not rely only on the displayed application name. Names may change or be copied.
• Check whether the application was user-consented, administrator-approved or installed across the tenant.
• Compare its activity with expected business use, device records and application logs.
• Preserve those records before revocation where possible.

Evidential limits¶

Do not assume that revoking the user password ends the integration.

Where the linked provider cannot be identified immediately, preserve the client ID, request IDs and consent record. Those technical identifiers may be the only reliable route to attribution.