An interconnection is any documented link between the in-scope system and an external system, such as a cloud service, partner environment, or third-party application. The definition matters because each connection can expand risk and control requirements. Good documentation covers what is shared, how it is protected, and who owns the relationship.
Expanded Definition
In security and governance, an interconnection is more than a technical link or API call. It is a formally recognised relationship between two environments that can carry data, requests, authentication material, or management actions across an organisational boundary. For glossary purposes, the term is used broadly enough to include partner integrations, SaaS connections, federated identity pathways, remote administration links, and service dependencies that are operationally external even when they are hidden behind automation. Under the NIST Cybersecurity Framework 2.0, organisations are expected to understand and govern external dependencies as part of broader risk management, which is why interconnections should always be traced to an owner, a purpose, and a protection model. Definitions vary across vendors on whether a transient session, webhook, or identity trust edge counts as an interconnection, so the practical test is whether the link changes the system’s trust boundary or exposure. The most common misapplication is treating undocumented integrations as out of scope, which occurs when teams focus only on named vendors and overlook embedded service-to-service connections.
Examples and Use Cases
Implementing interconnection governance rigorously often introduces inventory and review overhead, requiring organisations to weigh integration speed against the cost of tracking trust relationships.
- A finance platform connects to a payroll SaaS provider so employee records and payment instructions can sync automatically. The interconnection must define what data is exchanged, how authentication is handled, and who approves changes.
- A cloud workload uses an external secrets vault to retrieve API keys at runtime. Even if the transfer is automated, the vault link is an interconnection because it affects credential handling and recovery procedures.
- An enterprise exposes a limited API to a logistics partner for shipment updates. The interface is not just a functional dependency; it is a governed boundary that should be reviewed for logging, rate limits, and access scoping.
- A remote support tool connects a third-party service desk into an internal environment. That access path should be documented as an interconnection because it can introduce privilege, audit, and session-control requirements.
- An identity federation relationship allows users to authenticate through an external identity provider. This is a classic interconnection because trust is extended across organisations, and failures can affect sign-in assurance and account lifecycle management.
For organisations formalising external dependency inventories, the NIST Cybersecurity Framework 2.0 is useful because it pushes teams to identify and manage relationships that shape operational resilience.
Why It Matters for Security Teams
Interconnections are where control assumptions often break down. A system may look well protected internally, yet a weak partner link, overly broad API scope, or stale federation trust can bypass normal safeguards and create a route for data exposure, privilege escalation, or service disruption. For identity teams, interconnections are especially important because they often carry authentication flows, tokens, service accounts, and delegated authority. In NHI governance, those connections can become the path by which non-human identities inherit excessive privileges or retain access long after a business relationship has changed. Security teams need a precise inventory so they can assess impact, enforce least privilege, monitor dependencies, and remove unused links before they become hidden attack paths. In practice, interconnection reviews also support incident response because they reveal which external parties may need notification, containment, or coordinated remediation. Organisations typically encounter the full operational cost only after a partner outage, authentication failure, or third-party compromise, at which point interconnection management becomes unavoidable to restore trust and continuity.
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 surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST SP 800-63 set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.SC-1 | External dependencies and suppliers are identified and managed as part of risk governance. |
| NIST SP 800-53 Rev 5 | CA-3 | Security authorizations cover interconnections and the controls protecting them. |
| ISO/IEC 27001:2022 | A.5.19 | Supplier relationships require defined information security requirements and oversight. |
| NIST SP 800-63 | Digital identity guidance is relevant when interconnections carry federation or authentication trust. | |
| OWASP Non-Human Identity Top 10 | NHI guidance addresses service identities and trust edges that frequently traverse interconnections. |
Record interconnection obligations in supplier controls and review them whenever the relationship changes.
