How can organisations tell whether an integration is still safe to keep?

Why This Matters for Security Teams

An integration is safe only while its business purpose, owner, and privileges remain current. The practical test is not whether the connection still exists, but whether it is still justified, monitored, and revocable. That matters because dormant integrations often become hidden access paths after projects end, vendors change, or teams forget a token exists.

NHIs Management Group has found that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which means many teams cannot confidently answer who owns an integration or whether it should still be active. The NIST Cybersecurity Framework 2.0 reinforces the same operational need through asset visibility, access control, and ongoing governance.

Security teams often assume that if an integration has not broken, it is still safe. In practice, many organisations discover stale API keys, service accounts, or third-party connections only after a breach review or failed audit, rather than through intentional lifecycle management.

How It Works in Practice

The safest way to judge an integration is to treat it like a living identity with an owner, a scope, and an expiry condition. A current review should confirm four things: the integration still supports an active process, the permissions match that process, the credentials are still being used as expected, and revocation is documented and testable.

In mature environments, that review includes telemetry and policy, not just paperwork. Teams check last-used timestamps, auth frequency, source systems, and failure patterns to see whether the integration is genuinely active or merely present. They also verify whether the connection uses short-lived tokens, certificate-based trust, or another mechanism that can be revoked without manual cleanup. Guidance from the Ultimate Guide to NHIs is especially useful here because it frames lifecycle control as part of core NHI governance rather than a one-time inventory exercise.

• Confirm the business owner can name the system, use case, and shutdown trigger.
• Check whether permissions are narrowly scoped or inherited from a broad role.
• Verify secrets, tokens, and certificates have rotation and revocation paths.
• Compare observed activity against expected activity over a recent time window.
• Require a re-certification date for integrations tied to vendors, pilots, or seasonal workflows.

The NIST Cybersecurity Framework 2.0 is useful for translating those checks into repeatable access governance and continuous monitoring tasks. These controls tend to break down when integrations are embedded in legacy middleware or shared automation platforms because ownership is diffuse and revocation can disrupt multiple business processes at once.

Common Variations and Edge Cases

Tighter integration governance often increases operational overhead, so organisations have to balance stronger assurance against delivery speed and support burden. That tradeoff is real, especially when the integration is business-critical or owned by multiple teams.

Best practice is evolving for long-lived machine-to-machine connections that cannot be easily reissued. Some environments still depend on static credentials, but current guidance suggests compensating with shorter TTLs, tighter network boundaries, and explicit review checkpoints. For third-party integrations, a connection may remain technically active while still being unsafe if the vendor contract ended, the data path changed, or the original approver left the organisation.

Edge cases also appear in shared service accounts, CI/CD automations, and backup systems. Those integrations often look dormant because they run infrequently, yet they can still hold broad privilege and valid secrets. If ownership is unclear, or if revocation would require tribal knowledge to repair downstream jobs, the integration should be re-certified before it is treated as safe.

In practice, the safest rule is simple: if no one can explain why the integration exists today and how it would be removed tomorrow, it should not be trusted to stay live.

Related resources from NHI Mgmt Group

• How can organisations tell whether an MCP integration is safe to keep in production?
• How do organisations decide whether to replace an identity platform or keep extending it?
• How can organisations tell whether guardrails are actually working?
• How can organisations tell whether NHI governance is actually working?