The exposure created when a third party sits between an organisation and the transaction, system, or service it depends on. In crypto governance, intermediary risk includes counterparty failure, rebranding, jurisdictional change, and the possibility that a seemingly legitimate service is enabling illicit flows.
Expanded Definition
Intermediary risk describes the additional exposure introduced when an organisation relies on another entity to move value, process transactions, host services, hold credentials, or broker access between counterparties. In practice, the intermediary can be a payment processor, exchange, custodian, cloud service, managed service provider, reseller, or compliance platform. The risk is not limited to technical failure. It also includes governance drift, sanctions exposure, jurisdictional change, opaque ownership, weak due diligence, and the possibility that a legitimate-looking intermediary is used to mask illicit activity.
For NHI Management Group, the key issue is that intermediary risk often sits at the intersection of cyber trust, identity assurance, and operational resilience. A third party may be granted privileged access, API keys, certificates, or delegated authority long before its control environment is fully understood. That makes intermediary risk closely related to third-party risk management and to control expectations in the NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where access, monitoring, and supplier oversight intersect.
The most common misapplication is treating intermediary risk as a procurement checkbox, which occurs when organisations approve a service based on onboarding paperwork but never reassess ownership changes, jurisdictional shifts, or downstream transaction behaviour.
Examples and Use Cases
Implementing intermediary risk controls rigorously often introduces friction, because tighter due diligence and monitoring can slow onboarding, limit service flexibility, and increase the cost of using specialised providers.
- A crypto platform uses an offshore payment intermediary that later changes ownership, creating uncertainty over sanctions screening, recordkeeping, and escalation paths.
- A bank relies on a custody provider for digital asset storage, but the provider’s operational outage disrupts access to client funds and triggers continuity concerns.
- An enterprise outsources API authentication to a managed identity provider, then discovers that a subcontractor has been given broad administrative access without equivalent oversight.
- A marketplace integrates a seemingly legitimate broker that aggregates multiple counterparties, making it harder to detect suspicious transaction routing or commingled funds.
- A regulated firm uses a software intermediary for onboarding and KYC checks, but a jurisdictional change alters data handling obligations and creates compliance gaps.
These scenarios show why intermediaries must be evaluated for more than uptime and price. A useful control lens is whether the organisation can still verify who is acting, where the service is operating, what data it can reach, and how quickly that trust can be revoked. Guidance for supplier oversight in frameworks such as the NIST Cybersecurity Framework 2.0 helps translate that question into concrete governance.
Why It Matters for Security Teams
Security teams need to treat intermediary risk as an operational trust problem, not just a legal one. When a third party sits in the path of identity, funds, or system access, it can become a single point of failure for confidentiality, integrity, availability, and compliance. That is especially important where the intermediary receives secrets, issues tokens, or can act on behalf of users or services, because compromise of the intermediary often expands into privilege misuse or fraudulent transaction flow.
For identity and access governance, intermediary risk also affects assurance boundaries. If a provider can initiate actions, approve requests, or relay authentication events, the organisation must know whether those actions are attributable, logged, and revocable. This is where controls from NIST SP 800-53 Rev 5 Security and Privacy Controls become practical: supplier monitoring, access restriction, audit logging, incident response, and contingency planning all reduce the chance that intermediary dependence becomes systemic exposure.
Organisations typically encounter the full impact only after a provider outage, ownership change, enforcement action, or suspicious-flow investigation, at which point intermediary risk becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC | Supply chain risk management covers third-party exposure and intermediary dependence. |
| NIST SP 800-53 Rev 5 | SA-9 | External system services guidance addresses risks introduced by third-party service providers. |
Track intermediary dependencies, reassess supplier risk, and maintain revocation-ready oversight.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
