What breaks when organisations treat third-party integrations as set-and-forget access paths?

Set-and-forget integrations create blind spots that let access persist long after the business need has changed. That can lead to dormant vendors, unnecessary permissions, and unnoticed data exchange between systems. The result is weaker zero trust, poorer governance, and a supply chain risk program that looks complete but leaves active exposure in place.

Why This Matters for Security Teams

Third-party integrations are often approved as if they are permanent business infrastructure, but most of them behave like living access paths: credentials age, scopes drift, ownership changes, and the original business case disappears. NHI Management Group research shows that 92% of organisations expose NHIs to third parties, which makes this a supply chain issue as much as an identity issue. The operational risk is not just exposure, but retention of access after trust has expired.

This is where set-and-forget thinking breaks down. The integration may still be technically working while the vendor has changed products, the internal owner has left, or the connected workflow is no longer needed. That leaves dormant permissions in place, weakens Zero Trust segmentation, and creates hidden data flows that are difficult to explain during audit or incident response. Guidance in the OWASP Non-Human Identity Top 10 and control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls both point to the same conclusion: third-party access must be continuously governed, not merely approved once.

In practice, many security teams discover this only after a vendor relationship has already ended or a downstream system has already been accessed without anyone noticing.

How It Works in Practice

Effective control starts with treating every integration as a non-human identity with a lifecycle, not as a static trust relationship. That means each connection needs an owner, a business purpose, explicit scopes, a review date, and a revocation path. If the integration uses API keys, OAuth tokens, service accounts, or certificates, those secrets should be tied to the minimum required privileges and rotated on a schedule that matches the exposure profile, not the convenience of the vendor.

Practically, organisations should combine inventory, policy, and telemetry. Inventory answers what exists. Policy decides what should still be allowed. Telemetry shows whether the integration is actually used. The Ultimate Guide to NHIs highlights why this matters: 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 91.6% of secrets remain valid five days after notification, which shows how slowly many environments remediate exposure. For real-world examples, the 52 NHI Breaches Analysis and the Klue OAuth Supply Chain Breach show how third-party access can persist or expand beyond the original intent.

• Register every integration in a central inventory with owner, purpose, data type, and expiry.
• Use least privilege scopes and remove broad, reusable permissions.
• Set review and revocation triggers for inactivity, contract end, or scope change.
• Prefer short-lived tokens and automated rotation over long-lived static secrets.
• Monitor for unusual data access, new endpoints, and dormant but still-valid credentials.

These controls tend to break down in SaaS-heavy environments where vendors self-rotate tokens, shadow integrations are created by business teams, and no single system has authoritative visibility into all active connections.

Common Variations and Edge Cases

Tighter third-party control often increases operational overhead, requiring organisations to balance faster onboarding against stronger access hygiene. That tradeoff is real, especially when integrations support revenue workflows, customer support, or incident response.

Some integrations are intentionally persistent, such as core payment, identity, or monitoring links. Current guidance suggests these should not be treated as exceptions to governance, only as exceptions to short-lived access. They still need periodic revalidation, scope minimisation, and documented business ownership. Other cases are more ambiguous, such as API-to-API connections embedded in application code or vendor-managed connectors that hide the underlying credentials. Those are high-risk because the access path can outlive the contract, the project, or even the staff who configured it.

The most common failure mode is assuming that a working integration is a healthy one. In reality, a functioning token can still represent unnecessary exposure if the workflow is inactive or the permissions are broader than the use case. Best practice is evolving toward continuous access attestation, especially for ecosystems with frequent vendor churn, mergers, and low-code automation. In those environments, the question is not whether the integration still works, but whether it still deserves trust.

Related resources from NHI Mgmt Group

• Why do third-party integrations create access control and governance challenges in modern applications?
• Why does NIST CSF 2.0 matter for organisations trying to govern access risks across cloud, application, and third-party environments?
• Should organisations treat third-party access as a privileged identity risk?
• When should organisations treat third-party SaaS access as privileged access?