Topic starter
07/03/2026 1:27 am
TL;DR: SaaS-to-SaaS integrations now extend enterprise access through OAuth tokens, API keys, webhooks, and automation platforms, with the average environment connecting to 42+ third-party applications and attackers exploiting persistent bearer credentials outside MFA, according to Obsidian Security. The governance problem is no longer visibility alone, but managing hidden, long-lived access paths as NHI risk.
Editorial analysis by NHI Mgmt Group, based on content published by Obsidian Security: “Integration Security for SaaS Applications: Best Practices Guide”.
By the numbers:
- The average enterprise SaaS platform now connects to 42+ third-party applications through integrations.
Key questions
Q: What breaks when SaaS integrations are not governed as non-human identities?
A: Teams lose visibility into who or what can reach connected systems, and attackers can use trusted credentials to move through those integrations without triggering normal human-account controls.
Q: Why do third-party SaaS integrations create risk even when employees use strong passwords and MFA?
A: OAuth permissions can grant a third party ongoing access to user data without sharing a password.
Q: How can security teams tell when a trusted integration is being abused?
A: Look for drift from the approved behavioural baseline.
Practitioner guidance
- Inventory every SaaS integration grant Build a complete register of OAuth tokens, API keys, webhooks, iPaaS flows, and third-party apps across core SaaS systems, then tie each grant to an owner and business purpose.
- Revoke stale delegated access on a schedule Remove integration grants that no longer support an active business process, and force reauthorization for connections that have not been used or reviewed recently.
- Downscope overprivileged integration permissions Review existing scopes against actual workflow needs, then reduce write, admin, and broad-read permissions to the minimum required for the integration to function.
Bottom line: SaaS integrations create a hidden identity layer that can bypass MFA, persist after user change, and spread access across connected tools.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
08/10/2026 4:32 pm
Integration security is now an identity governance problem, not just an application control problem: SaaS-to-SaaS connections behave like delegated identities with their own issuance, scope, persistence, and revocation challenges. That makes lifecycle governance as important as initial authorization. The practitioner conclusion is straightforward: if the integration can act, it must be governed like an identity.
A few things that frame the scale:
- The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
A question worth separating out:
Q: When should organisations re-evaluate SaaS automation after a third-party breach?
A: Organisations should re-evaluate whenever a breach shows that delegated access, OAuth grants, or service accounts can be abused at scale. The right response is to review scopes, revoke stale credentials, test closure logic, and confirm that automation identities cannot exceed their intended purpose.
👉 Read our full editorial: SaaS integration security gaps are widening beyond traditional IAM