Look for persistent trust relationships, undocumented endpoints, shared credentials, and partner links that survive organisational change. Those are the places where integration becomes a hidden access problem. A clean review should answer who owns the connection, what it can reach, and what event would trigger its removal.
Why This Matters for Security Teams
Legacy integrations are often treated as plumbing, but they are frequently durable access paths into systems, data stores, and partner environments. When a connection survives an acquisition, a product sunset, or a team re-org, the original business purpose can fade while the trust still remains. That makes integration reviews a security control, not just an operations check.
The risk is not only exposed credentials. It is also undocumented endpoints, brittle allowlists, forgotten service accounts, and OAuth-style third-party links that bypass normal user governance. NHIMG notes that only 5.7% of organisations have full visibility into their service accounts, and 92% expose NHIs to third parties, which turns “temporary” integrations into long-lived attack surfaces in practice. For a broader identity baseline, Ultimate Guide to NHIs and NIST Cybersecurity Framework 2.0 both reinforce visibility and access governance as core security work.
In practice, many security teams discover the real risk only after a vendor incident, an audit request, or a failed decommissioning effort has already exposed how much old trust is still active.
How It Works in Practice
A strong legacy integration review starts by inventorying every trust relationship, then testing whether each one still has a current owner, a documented purpose, and a removal trigger. That means reviewing not just application-to-application links, but also API keys, shared service accounts, batch jobs, file transfers, webhooks, EDI links, and partner SSO or OAuth connections. The question is not “does it still work?” but “does it still need to exist, and what is it allowed to reach?”
Security teams should validate four things for each integration:
- Identity: what account, token, certificate, or key is proving the integration is allowed?
- Scope: which systems, APIs, queues, or data sets can it touch?
- Ownership: which business and technical team is accountable for it today?
- Exit criteria: what event, date, or change triggers revocation or redesign?
That review should also check for secrets stored outside managed vaults, hard-coded endpoints, stale IP allowlists, and missing rotation or expiry. The Ultimate Guide to NHIs highlights how often organisations retain long-lived secrets and over-privileged NHIs, while NIST Cybersecurity Framework 2.0 frames these checks as part of asset management, access control, and continuous risk monitoring. Current guidance suggests pairing the inventory with evidence from logs, ticketing, and CMDB records rather than relying on application owners’ memory alone.
These controls tend to break down when integrations are embedded in partner-managed systems, because the internal team may not have enough telemetry or authority to verify the connection end to end.
Common Variations and Edge Cases
Tighter integration reviews often increase operational overhead, so organisations have to balance security assurance against release speed and third-party coordination. That tradeoff becomes sharper when the integration is old enough that no one wants to touch it, but important enough that the business cannot easily replace it.
Some legacy links are intentionally persistent, such as payment rails, regulated data exchanges, or mainframe bridges. In those cases, best practice is evolving rather than fixed: current guidance suggests compensating controls like scoped credentials, network segmentation, stronger logging, and documented renewal reviews rather than assuming full redesign is always possible. The main exception is when the integration is owned by a vendor or partner with limited transparency. Then the review should focus on proof of access scope, revocation procedures, and contractual offboarding terms.
Security teams should also watch for “shadow integrations” created outside formal change control, especially in mergers, temporary projects, and automation scripts. Those links often survive longest because they appear low risk, even though they carry the least documentation. The most effective reviews look for breakpoints: contract end dates, system replacements, owner departures, and dormant traffic patterns. When those signals are missing, the integration is already functioning as hidden standing access.
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 NIST CSF 2.0 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-03 | Legacy integrations often fail on stale secrets and poor rotation. |
| NIST CSF 2.0 | PR.AC-4 | Integration reviews test whether access is authorized and still needed. |
| NIST AI RMF | Reviewing hidden trust paths supports AI-era and broader risk governance. |
Inventory integration secrets and enforce rotation, expiry, and revocation for every long-lived non-human credential.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
