Notifications
Clear all
Topic starter
23/06/2026 9:10 pm
TL;DR: One enterprise recovered from the Salesloft breach by classifying nearly 1,000 stolen datasets, covering over 4 million files, in 12 hours, then rescanning data to find sensitive credentials that earlier tools missed, according to Cyera. The real lesson is that response speed without trustworthy scope and verification still leaves security teams making decisions in the dark.
NHIMG editorial — based on content published by Cyera covering the Salesloft breach: Recovering from the Salesloft Breach: 3 Lessons Learned
Questions worth separating out
Q: What breaks when a third-party OAuth token is stolen?
A: A stolen OAuth token turns a trusted integration into an attacker-controlled access path.
Q: Why do third-party integrations create NHI governance risk?
A: Third-party integrations create NHI governance risk because they are delegated identities with real reach into business systems.
Q: How do security teams know if breach scanning is accurate enough?
A: Security teams should look for corroboration across tools, file context, and the live target environment.
Practitioner guidance
- Inventory every third-party OAuth path Document which SaaS integrations can reach Salesforce, storage, and analytics systems, then assign an owner and revocation process to each connection.
- Revocation test integration tokens regularly Validate that disabling an integration actually removes downstream access and does not leave cached or shadow permissions behind.
- Classify stolen datasets before triage decisions Require data classification against the exposed environment so responders can separate credential material, regulated records, and low-risk content.
What's in the full article
Cyera's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step description of how the breach response team scanned nearly 1,000 datasets and validated findings across the target environment
- The sequence used to compare TruffleHog results with Cyera's own scan output and identify missed credentials
- Operational lessons on how the enterprise prioritised remediation after confirming exposure in Salesforce-connected data
- The vendor's free scan programme context for teams that need a hands-on response workflow
👉 Read Cyera's analysis of the Salesloft breach and recovery lessons →
Salesloft breach recovery: what does it change for IAM teams?
Explore further
25/06/2026 2:20 am
Delegated OAuth access is a standing NHI governance problem, not just a vendor incident. The Salesloft case shows that a stolen integration token can bypass the organisation’s normal perimeter and inherit the trust of downstream systems. That is a lifecycle issue as much as an authentication issue, because the access relationship remains valid until someone explicitly disables it. Practitioners should treat third-party OAuth connections as governed identities with scope, ownership, and revocation requirements.
A few things that frame the scale:
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, showing why delegated access remains a governance blind spot.
A question worth separating out:
Q: Who is accountable when a SaaS integration exposes customer data?
A: Accountability sits with the organisation that owns the delegated access path, even if the token originated from a third-party service. Security, application, and SaaS owners all need a defined revocation process and an incident playbook. If the integration can reach customer data, it must be governed like any other privileged identity.
👉 Read our full editorial: Salesloft breach recovery shows the limits of data-only visibility
