Unreviewed integrations can turn a normal business connection into an attack path. If third party apps, API keys, OAuth tokens, or service accounts are not vetted and governed, they may retain access long after they are needed. That creates hidden data flows, weak revocation discipline, and a larger surface for account compromise or unauthorized data movement.
Why Unreviewed SaaS Connections Change the Risk Model
Trusted SaaS to SaaS links are not just convenience features; they are delegated access paths that can move data, trigger actions, and persist beyond the original business need. Once an integration is approved without review, the organisation has effectively extended its trust boundary into another vendor’s controls, support processes, and token handling discipline. That makes the quality of the integration decision as important as the quality of the SaaS itself.
In practice, the biggest failure is not that an integration exists, but that no one can quickly answer what it can read, write, or retain after the original owner has stopped paying attention. The OWASP Non-Human Identity Top 10 is useful here because it frames machine-access paths as a governance problem, not just an application permission problem.
NHI Management Group research shows why this matters: 92% of organisations expose NHIs to third parties, which means unreviewed SaaS links are rarely isolated exceptions. In practice, many security teams discover the blast radius only after a harmless-looking productivity integration has already been granted broad and durable access.
How SaaS-to-SaaS Trust Fails in Practice
Most SaaS integrations rely on OAuth grants, API keys, webhook secrets, service accounts, or delegated admin consent. Those credentials often outlive the person who approved them, and they may be scoped more broadly than the business owner realised. The technical issue is not simply authentication; it is unattended authorization. If the integration is not inventoried, reviewed, and periodically revalidated, the access path becomes invisible even while it remains valid.
This is where hidden data movement starts. An integration that only needed read access to one workspace can later be used to export records, sync attachments, or forward content into another tenant or external workflow. When the connected service is compromised, the attacker does not need to break the primary SaaS first; they can abuse the existing trust relationship. That is why current guidance from NHI Mgmt Group’s guide to non-human identities places visibility, rotation, and offboarding at the centre of control design.
Useful operational checks are straightforward:
- Identify which integrations can read customer data, files, messages, or tokens.
- Confirm who owns each grant and whether that owner still has a business need.
- Review whether the integration uses least-privilege scopes or blanket workspace consent.
- Test whether revocation actually breaks the connection immediately, rather than leaving cached or secondary access in place.
For teams dealing with multi-tenant SaaS, the practical control point is not just account review but lifecycle governance over every delegated token and application consent. These controls tend to break down when integrations are created by business users outside central inventory processes, because no one notices the permissions drift until data has already been synchronised elsewhere.
When Integration Convenience Becomes a Governance Problem
Tighter integration governance often adds friction, and that trade-off is real. Business teams want fast app approval, but every shortcut increases the chance that a low-friction connection becomes a long-lived access dependency. The right response is not to ban integrations outright; it is to distinguish low-risk, narrowly scoped links from those that can exfiltrate data, alter records, or impersonate trusted workflows.
One useful way to think about exceptions is whether the integration can be safely revoked without breaking a core business process. If the answer is no, the integration has become operationally critical and should be treated like any other privileged dependency. That means ownership, review cadence, and offboarding need to be explicit rather than implied. In environments where many business units can self-authorise apps, the main failure mode is control fragmentation: permission decisions get made locally, but the risk is absorbed centrally.
For SaaS-to-SaaS ecosystems, the most important judgement is that trust should expire unless it is actively renewed. Static approval is rarely enough when the access path can persist, replicate data, and survive staff turnover or vendor-side compromise.
Risk and Threat Considerations
Unreviewed SaaS integrations create both exposure and attacker opportunity. The risk is not limited to misconfiguration; it includes durable delegated access that can outlive the original business purpose, allowing unauthorized access, hidden data transfer, and privilege reuse across systems.
Failure mechanism: The mechanism is usually overbroad consent plus weak lifecycle control. OAuth grants, API keys, and service accounts remain valid after the business need ends, and attackers who compromise the connected app or the token store can reuse that trust path without needing to defeat the primary SaaS authentication.
Impact: The practical impact is data exposure, silent exfiltration, and difficult containment. Revocation can be incomplete, audit trails can be fragmented across vendors, and one compromised integration may provide access to multiple downstream systems at once.
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 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Unreviewed SaaS links rely on tokens and keys that must be governed as NHIs. |
| NHI-02 — Inventory and Visibility | The question centers on hidden integrations that expand access without oversight. | |
| NHI-07 — Lifecycle and Offboarding | Trusted integrations often retain access after the business need has ended. | |
| Recommendation — Inventory and rotate delegated tokens before they become durable, unowned access paths. Maintain a complete inventory of every SaaS-to-SaaS integration and its effective permissions. Revoke integration access promptly when ownership or business need changes. | ||
| CIS Controls v8 | 6 — Access Control Management | SaaS-to-SaaS trust is an access-control problem with delegated permissions. |
| 5 — Account Management | Service accounts and app consents need ownership and lifecycle handling. | |
| Recommendation — Review and remove unnecessary third-party app access under a defined approval process. Assign accountable owners to non-human accounts and retire them when unused. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | The issue is delegated access that should be authorized and bounded. |
| GV.5 — Risk Management Strategy | Unreviewed integrations create enterprise risk that needs explicit governance. | |
| Recommendation — Limit each integration to the minimum access needed and revalidate it periodically. Classify high-trust integrations as managed risks with review and exception handling. | ||
Practitioner Guidance
What to prioritise: Start with integrations that can read or write customer data, administer tenants, or export content into external systems. Those are the connections most likely to create material blast radius if they are left unowned or over-scoped.
What to verify: Confirm that every integration has a named business owner, a documented scope, and a tested revocation path. If you cannot show who approved it, what it can do, and how it is removed, it should be treated as an unmanaged access path.
What to measure: Track the number of active integrations without review dates, the percentage of grants using broad workspace consent, and the time required to revoke access end to end. Slow revocation is often the clearest sign that the organisation has delegated trust faster than it can govern it.
Practitioner takeaway: The key mistake is treating SaaS integrations as procurement approvals instead of standing identity relationships; once trust is delegated, it must be continuously governed like any other privileged access.
