Topic starter
30/07/2026 10:51 pm
TL;DR: A June 2026 compromise of OAuth tokens tied to Klue gave an attacker a trusted path into downstream Salesforce environments, including Commvault’s, and the affected data was limited to business relationship and sales information, according to Commvault. The incident reinforces that third-party integrations create identity and access exposure beyond the edge of the organisation.
Editorial analysis by NHI Mgmt Group, based on content published by Commvault: “When the Risk Comes From Outside: How Commvault Responds to Third-Party Incidents”.
Key questions
Q: What breaks when an OAuth-connected app is compromised in Salesforce?
A: When a Salesforce-connected app is compromised, the token becomes a trusted identity that can query data, export records, and search for embedded secrets without bypassing MFA.
Q: Why do third-party app tokens create more risk than direct user logins?
A: Because tokens can persist beyond the immediate user session and are often reused by automation, refresh workflows, or multiple tenants.
Q: How can teams tell whether access governance is actually working?
A: Look for short revocation times, low rates of stale entitlements, and repeatable access review outcomes across systems.
Practitioner guidance
- Audit every Salesforce-connected OAuth integration Identify each connected app, document its business owner, and verify the exact data and API scope it can access.
- Revoke and re-authorise risky third-party tokens Create a revocation process that can disable tokens immediately when a connected service is compromised, retired, or no longer trusted.
- Treat connected apps as governed NHIs Assign lifecycle ownership, access review cadence, and offboarding criteria to every external application that authenticates into core systems.
Bottom line: The incident shows that a compromised third-party OAuth token can become a downstream access path into core business systems even when the target platform itself is not breached.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
30/07/2026 10:54 pm
Third-party OAuth access is now a machine identity governance problem: The compromise of an integration token is operationally closer to NHI abuse than to a simple SaaS breach. The credential is delegated authority, not just a login session, so the real question is who owns the integration, what scope it carries, and how quickly it can be revoked. Practitioners should manage connected apps as identities with lifecycle controls, not as static vendor dependencies.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Should teams treat SaaS-to-SaaS integrations as privileged access?
A: Yes. A connected app can function like a privileged service identity if it can read, write, or export business data through APIs. Treating it as ordinary application plumbing leaves no clear place for certification, offboarding, or incident revocation, which is exactly where shared blast radius emerges.
👉 Read our full editorial: Klue OAuth token compromise shows third-party access risk in Salesforce