Third-party services expand the attack surface because a vendor with weak security can become an entry point into the bank’s environment. The practical risk is not only direct compromise of the vendor, but also inherited exposure through integrations, data sharing, and infrastructure dependencies. Banks should treat vendor assurance as an ongoing control, not a one-time procurement check.
Why third-party services change the banking risk equation
Third-party services are not just suppliers, they are additional trust relationships. In digital banking, each integration can extend the bank’s environment into another organisation’s security posture, operational discipline, and access model. That matters because compromise rarely needs to start inside the bank. It can arrive through a vendor connection, a shared token, or a dependency that was never designed for hostile use.
The key risk is correlation. When a bank relies on the same cloud service, SaaS connector, payment processor, or support platform across many workflows, one weak link can affect multiple systems at once. The issue is not only whether the vendor is secure on its own, but whether the bank can contain failures, limit scope, and revoke access quickly enough when the vendor changes, degrades, or is compromised.
That is why third-party exposure should be treated as an architecture issue, not only a procurement issue. The bank should understand which integrations can read data, move funds, trigger workflows, or impersonate trusted users and services. When those paths exist, the practical control is not “trust the vendor,” but “constrain what the vendor can do and prove that constraint stays in place.”
Where inherited exposure usually enters
Inherited exposure typically comes from three places: data sharing, delegated access, and infrastructure dependency. Data sharing increases blast radius if the vendor stores customer or transaction data that would be valuable to attackers. Delegated access creates authentication and authorization risk if a vendor token, API key, or OAuth grant can be reused, over-scoped, or stolen. Infrastructure dependency creates availability risk when a critical business process quietly depends on an external service that the bank does not fully control.
That pattern is visible in real-world supply-chain incidents, where a compromise of one connected service becomes a route into many downstream environments. The lesson is not that integration itself is unsafe, but that the trust boundary has to be explicit. If a third party can reach sensitive functions, then access review, scope limitation, and revocation speed become part of banking resilience.
For teams evaluating SaaS-to-SaaS or platform integrations, a useful reference point is SaaS-to-SaaS and OAuth App Governance Guide, because it focuses on consent, scopes, token risk, and revocation runbooks. For incident patterns where a vendor-to-vendor connection exposed downstream data, Klue OAuth Supply Chain Breach and Salesloft OAuth token breach are directly relevant examples.
What banks should be watching in vendor relationships
Not all third-party risk is equal. The highest concern is any vendor that can authenticate into production systems, hold customer data, touch payment flows, or administer security-relevant functions. A vendor with read-only reporting access is not the same as a vendor with privileged API access, even if both are listed as “integrations” in procurement records.
Banking teams should also watch for hidden dependencies. A service may appear noncritical until it fails and halts customer onboarding, transaction processing, reconciliation, or fraud checks. Equally, a vendor may look low risk until a shared identity path, a long-lived token, or a poorly governed marketplace app creates a broad attack path that is hard to detect and slower to unwind.
For practitioner context on the broader supply-chain and credential exposure patterns that make these relationships risky, The 52 NHI Breaches Report shows how frequently secrets, tokens, and service access become the entry point. On the external side, the most directly relevant control lens is OWASP Non-Human Identity Top 10, because it focuses on secret leakage, overprivilege, and third-party risks in connected service environments.
Risk and Threat Considerations
Third-party services increase risk because attackers often prefer the path with the weakest governance, not the strongest perimeter. If a vendor account, token, or connector is over-privileged, compromise of that relationship can expose bank data or open a path into production systems without attacking the bank directly.
Failure mechanism: A vendor credential, API token, or integration grant is stolen, reused, or left active after business need changes, allowing an attacker to move through a trusted connection into data, workflows, or administrative functions.
Impact: The result can be customer-data exposure, unauthorized actions, fraud enablement, operational disruption, or a wider breach if the third-party connection has been allowed to bridge too many systems.
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 and OWASP API Security Top 10 address the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and DORA defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party integrations can become an entry point into bank systems. |
| NHI-05 — Overprivileged NHI | Vendor tokens and service access often exceed the minimum needed for banking workflows. | |
| NHI-07 — Long-Lived Secrets | Third-party services often depend on persistent tokens or keys that widen exposure over time. | |
| Recommendation — Assess vendor integrations for inherited access paths and require tight scope and revocation. Reduce vendor permissions to the minimum set required for each workflow. Rotate and shorten-lived vendor secrets to limit replay and reuse risk. | ||
| NIST SP 800-53 Rev 5 | SA-9 — External System Services | Banks need controls over external services that handle or process bank data. |
| AC-20 — Use of External Information Systems | Third-party access paths into bank environments must be explicitly governed. | |
| Recommendation — Define and monitor security requirements for each external system service. Restrict and review external-system access before allowing connections to bank assets. | ||
| DORA | ICT third-party risk management — ICT third-party risk management | Digital banking depends on vendor resilience and third-party oversight obligations. |
| Recommendation — Map critical ICT providers, test dependency resilience, and enforce exit plans. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Vendor integrations often rely on API credentials that can be stolen or misused. |
| Recommendation — Harden authentication for third-party APIs and monitor for token abuse. | ||
Practitioner Guidance
What to prioritise: Prioritise the integrations that can reach production data, payment flows, or privileged administration. Those are the relationships where vendor compromise turns into bank impact fastest, so they deserve the tightest review and the shortest revocation path.
What to verify: Verify that each critical vendor connection has a named owner, a current business justification, a bounded scope, and a tested offboarding or token-revocation process. If you cannot remove the access quickly, the relationship is not yet controlled well enough for a banking environment.
Practitioner takeaway: The question is not whether third parties exist, but whether the bank has made every external trust path narrow, observable, and reversible before an attacker or outage tests it.
Related resources from NHI Mgmt Group
- Why do third-party vendors and connected systems increase cyber risk in financial services?
- Why do end-of-life devices increase third-party cyber risk?
- How should security teams reduce risk from third-party identity accounts in education platforms and similar SaaS services?
- Why do third-party services and shared credentials increase breach risk for organisations?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
