Topic starter
07/06/2026 9:14 pm
TL;DR: Attackers in the Salesforce breach exploited OAuth consent and API token reuse to bypass MFA, exposing how connected apps turn convenience into a persistent access path, according to HYPR. The breach shows that deterministic identity assurance and least privilege matter more than login hardening alone.
Editorial analysis by NHI Mgmt Group, based on content published by HYPR: “The Salesforce Breach Is Every RevOps Leader’s Nightmare: How to Secure Connected Apps”.
Key questions
Q: What breaks when OAuth consent is treated like a one-time setup step?
A: Consent turns into standing delegated access when teams stop tracking scopes, owners, and tenant-specific service principals after approval.
Q: Why do reusable tokens create more risk than a password reset fixes?
A: Because the token can remain valid independently of the user’s password or MFA state.
Q: How do security teams know if app secret governance is failing?
A: Look for secrets with unusually long expiry dates, repeated re-creation of credentials, and application records that still authenticate after the original human owner has changed.
Practitioner guidance
- Inventory connected apps and delegated scopes Identify every Salesforce-connected app, the scopes it holds, whether it has offline access, and who approved it.
- Shorten token lifetime and revoke stale access Replace permanent or effectively permanent refresh tokens with expiring credentials where the business process allows it, and revoke unused tokens on a fixed review cycle.
- Require phishing-resistant assurance before app approval Use phishing-resistant authentication and stronger proofing for administrators who can approve high-risk integrations, especially where the approval grants offline API access.
Bottom line: The Salesforce breach shows that connected apps can turn OAuth consent into a persistent access path that bypasses normal login protections.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
08/06/2026 9:06 am
Connected-app governance is now an identity governance problem, not an integration hygiene problem: the breach path existed because authorization was delegated to apps that could keep working after the original trust decision. That shifts the control surface from the login screen to consent, scope, token lifetime, and revocation discipline. Practitioners should treat every connected app as a governed identity with an access lifecycle.
A question worth separating out:
Q: Should IAM teams prioritise consent controls or login hardening first?
A: Consent controls should be prioritised when the breach path relies on delegated app access rather than direct account takeover. Login hardening still matters, but it does not stop a valid token from being reused. For connected apps, approval, scope, and revocation are the controls that decide whether access persists.
👉 Read our full editorial: Salesforce breach lessons for connected app identity assurance
This post was modified 3 days ago by NHI Mgmt Group