Unused integrations become dormant trust relationships that still hold credentials and access scopes. If they are not removed after a proof of concept, a role change, or vendor abandonment, they can be abused later for data access or lateral movement. The control failure is not just excess inventory, but persistent privileged access with no current business need.
Why This Matters for Security Teams
Unused SaaS integrations are not harmless leftovers. They are active trust relationships that often retain OAuth grants, API keys, refresh tokens, webhook permissions, and delegated admin scopes long after the business case has disappeared. That means a vendor trial, a departed employee’s workflow, or an abandoned automation can still be used to access data or trigger actions across connected systems. NHI Management Group’s Ultimate Guide to NHIs shows why lifecycle control matters: only 20% of organisations have formal processes for offboarding and revoking API keys.
This is a governance failure as much as a technical one. The risk is not limited to one account or one app. A dormant integration can provide a quiet path into CRM, ticketing, storage, or CI/CD platforms, especially when it has broad scopes and no owner. The NIST Cybersecurity Framework 2.0 treats identity, access, and asset management as core security functions for a reason: if the organisation cannot see what still has access, it cannot remove what no longer should. In practice, many security teams discover these stale integrations only after an incident review, not through intentional offboarding.
How It Works in Practice
Offboarding unused SaaS integrations means more than deleting a record in a vendor console. Security teams need a repeatable process that identifies the integration owner, checks current business use, revokes all credentials, removes delegated scopes, disables webhooks, and confirms that downstream apps no longer trust the connection. The most reliable programs treat integrations as part of the NHI lifecycle, not as one-time procurement artifacts. NHI Management Group’s NHI Lifecycle Management Guide frames this as a lifecycle control, not a cleanup task.
- Inventory integrations across SaaS, iPaaS, CI/CD, and custom automation platforms.
- Map each integration to an owner, purpose, scope, and renewal date.
- Revoke OAuth grants, tokens, service accounts, and API keys when use ends.
- Validate that related secrets are removed from code, vaults, config, and automation runners.
- Log the offboarding event so future audits can prove the trust relationship was closed.
Current guidance from identity and zero-trust practice suggests that offboarding should be paired with least privilege and periodic access review. The NHI problem is rarely the presence of one secret; it is the accumulation of broad, long-lived trust that nobody feels responsible for retiring. The Top 10 NHI Issues research reinforces that visibility and rotation failures are common across modern environments. These controls tend to break down when integrations are embedded in shadow IT workflows because no single team can prove who still depends on them.
Common Variations and Edge Cases
Tighter integration offboarding often increases coordination overhead, requiring organisations to balance faster decommissioning against business continuity and owner attribution. That tradeoff is real in environments with shared SaaS tenants, vendor-managed connectors, or citizen-developer automations where the original requester is gone. Best practice is evolving, but there is no universal standard for how long an unused integration may remain disabled before permanent deletion is safe.
Some organisations also keep dormant integrations for contractual or forensic reasons. In those cases, the safer pattern is to quarantine the connection: remove broad scopes, rotate or revoke the underlying credentials, and re-enable only under explicit approval. This matters because breach cases such as the Salesloft OAuth token breach and BeyondTrust API key breach show how third-party integrations can become durable entry points when tokens remain valid. Organisations with weak owner tracking, inherited admin rights, or shared service accounts are the most likely to miss these stale trust paths.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Unused integrations are stale non-human identities that retain access and scopes. |
| NIST CSF 2.0 | PR.AA-1 | Identity and authentication management covers dormant SaaS trust relationships. |
| NIST Zero Trust (SP 800-207) | ID | Zero Trust requires continuous verification of each non-human access path. |
| CSA MAESTRO | IAM-1 | Agent and workload identity governance applies to SaaS connectors and automations. |
| NIST AI RMF | GOVERN | Governance is needed to assign accountability for automated access paths. |
Maintain an authoritative inventory of integration identities and remove inactive access promptly.
Related resources from NHI Mgmt Group
- What breaks when organisations do not map the access path of AI and SaaS integrations?
- What breaks when organisations leave standing privilege in SaaS integrations?
- What breaks when organisations cannot see shadow SaaS and third-party integrations?
- What breaks when organisations cannot inventory cryptographic libraries and algorithms in their products?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
