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.
How to confirm a third-party application compromise in the tenant
Focus first on whether the tenant shows changes that should not occur under normal integration behaviour. Unexpected consent grants, new service principals, altered API permissions and tokens used from unfamiliar IP addresses or client IDs are the strongest signs because they indicate the application identity, not just a user account, may have been abused.
Review app registrations, audit logs and role assignments together, because a compromise often leaves a trail across consent, directory change, and authentication activity rather than in one place. Also check whether mailbox or directory access patterns changed at the same time, since attackers often use the trusted app to move quietly through data the app is already allowed to reach.
Why persistence through app secrets, refresh tokens, and over-privileged scopes matters
A third-party application can remain useful to an attacker even after a password reset or user sign-out if the underlying integration still has valid secrets, refresh tokens or broad OAuth scopes. That is why the important question is not only whether the app was used, but whether its standing permissions still let it keep accessing the tenant.
When scopes are broader than the business function requires, the blast radius grows quickly. A compromised integration may not need interactive logon at all if it can authenticate as the application itself, call APIs repeatedly, and continue to access mail, files or directory objects until consent is revoked, credentials are rotated, or the app is removed.
For practical governance of these risks, see SaaS-to-SaaS and OAuth App Governance Guide, which covers consent, scopes, token risk and revocation patterns for connected apps.
What to check when a tenant may already be exposed
Look for evidence of earlier compromise, not just current access. That means checking whether the app created new permissions, added credentials, or touched unusual resources before the alert was raised. If the tenant has multiple integrations, compare the suspected app’s behaviour with its normal baseline, especially around approval timing, token issuance, and API call volume.
If the app is a marketplace or partner integration, confirm whether the publisher changed, whether the consent screen was legitimate, and whether any sibling service principals or related integrations were created to preserve access. In multi-tenant environments, a single compromise can affect more than one tenant, so the investigation should include any related instances rather than stopping at the first suspicious app object.
For real-world patterns of this failure mode, ConnectWise Cloud Backup breach 2026 shows how a stolen app secret can enable tenant access and role abuse through service principals, while JumpCloud breach 2023 illustrates how compromised admin API keys can be used beyond the original entry point.
Risk and Threat Considerations
Third-party application compromise is high impact because the attacker inherits trust that the tenant has already extended to the integration. That can turn a single compromised app into broad data access, persistence through valid tokens, and hard-to-notice abuse of normal API pathways.
Failure mechanism: The attacker abuses an existing consented application, refresh token or secret to act as the integration, then expands access through added permissions, new service principals, or role assignment changes that blend into normal tenant administration.
Impact: Mail, directory, files, CRM data or other connected systems may be accessed without obvious interactive logon, and the compromise can persist until the app’s credentials, tokens and permissions are all reviewed and removed.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Stolen app secrets and tokens enable tenant access and persistence. |
| NHI-04 — Insecure Authentication | Compromised integrations often keep authenticating with valid tokens or client credentials. | |
| NHI-05 — Overprivileged NHI | Excessive OAuth scopes and roles widen tenant impact after compromise. | |
| Recommendation — Rotate exposed secrets and revoke any tokens that can still authenticate the app. Validate how the app authenticates and remove any weak or reusable auth paths. Reduce app permissions to the minimum set needed for its function. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Application secrets, refresh tokens and keys must be rotated and revoked on compromise. |
| AC-6 — Least Privilege | Excessive app permissions increase the blast radius of a compromised integration. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Audit logs are needed to spot consent, role and token anomalies in the tenant. | |
| Recommendation — Revoke and reissue compromised authenticators without delay. Restrict app permissions to the minimum required scope. Review audit records for consent, role and token changes tied to the app. | ||
| CIS Controls v8 | CIS-5 — Account Management | Tenant compromise often shows up through new principals, roles and access paths. |
| CIS-6 — Access Control Management | Permission drift and overbroad scopes are central indicators of app compromise. | |
| Recommendation — Inventory and disable unauthorized accounts, principals and access paths promptly. Review and remove unnecessary application access across the tenant. | ||
Practitioner Guidance
What to prioritise: Start with the app registration, granted consent and token history, then verify whether the permissions still match the business need. If the app can reach sensitive mail or directory data, treat it as a tenant-wide exposure question rather than a single-application issue.
What to verify: Confirm whether the suspicious activity is tied to a known integration owner, expected source IPs and a valid client ID. If not, rotate any application secrets, revoke refresh tokens, and review whether any service principals or delegated permissions were added outside change control.
Practitioner takeaway: A compromised third-party application is usually confirmed by permission and identity drift, not by one noisy login event, so the investigation must trace consent, credentials and role changes together.
Related resources from NHI Mgmt Group
- What are the signs that third-party application credentials may be compromised and need urgent rotation?
- What happens when an application consumes a compromised third-party API without validation controls?
- What are the signs that third-party application monitoring is failing?
- Why do compromised third-party web dependencies create such broad risk for application security?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 4, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org