Because the bank is no longer governing a single user account. It is governing a live authority relationship that can change by role, purpose, time, or legal basis, and that relationship often extends through external providers and APIs. Static entitlements do not capture that complexity.
Why delegated access changes the bank’s risk model
delegated access changes risk because the organisation is no longer judging one person’s permissions in isolation. It is trusting a live authority chain that can expand, expire, be mis-scoped, or be reused across systems, which makes the effective blast radius larger than a normal account review suggests. That is why banks need to treat delegation as a governed control relationship, not just a convenience feature.
When delegation is used well, the bank can limit who may act, for what purpose, and under what conditions. When it is used poorly, it can hide excessive privilege, obscure accountability, and let access survive beyond the original business need. In regulated environments, that difference matters because the control objective is not only “who logged in” but “who was authorised to act at that moment.”
A delegated model also raises the stakes of integration design. If the bank’s authority passes through RFC 8693: OAuth 2.0 Token Exchange, the token exchange path must preserve the intended subject, audience, and scope of the delegated action. Otherwise, the bank can end up authorising a broader action than the business process actually requires.
Why delegated access is harder to govern than static entitlements
Static entitlements are simple to review because they map to a named account and a stable role. Delegated access is harder because the effective permission may depend on consent, transaction context, time limits, legal basis, client type, or an external provider acting on the bank’s behalf. That means the bank must govern both the original entitlement and the delegated act that flows from it.
This is where many control failures start. A role can be approved once, but the delegation used under that role may outlive the business purpose, cross an environment boundary, or continue after a relationship changes. The result is a gap between what the access review shows and what the live system can actually do.
For customer and partner-facing flows, the delegated path often touches consent, recovery, and on-behalf-of access. NHIMG’s Human vs Non-Human Identity explains why that boundary matters when people and machine access meet, and NHIMG’s Customer IAM (CIAM) Guide covers delegated access and consent as part of the broader customer access model.
What changes the risk most in financial services
The highest-risk situations are those where delegated access crosses trust boundaries. That includes external providers, open banking-style integrations, service-to-service calls, shared administrative functions, and any path where one identity acts for another without a fresh human decision at the point of use. In those cases, compromise or overreach in one link can expose many accounts, transactions, or customer records.
Financial services also face concentrated concentration risk. A single delegated integration may support many branches, products, or counterparties, so a flaw in scope, revocation, or approval logic can scale quickly. NHIMG’s Financial Services Identity Security Guide is useful here because it frames delegated authority alongside third-party exposure, privileged access, and sector-specific control pressure.
Attackers value delegated access because it often looks legitimate. Stolen credentials, abused consent, or hijacked tokens can let an intruder operate inside approved workflows instead of forcing noisy password resets or obvious privilege escalation. That makes detection harder and recovery slower, especially when the delegated relationship is spread across APIs and partner systems. For a concrete abuse path, see NHIMG’s Zacks breach claim 2025 and Scania insurance portal breach 2025, both of which show how external access paths can turn into broad data exposure.
Risk and Threat Considerations
Delegated access increases exposure because it can turn one approved relationship into many downstream actions, often across systems the bank does not directly control. The main threat is not just stolen credentials, but abuse of legitimate authority, where the access path itself is valid while the business context is no longer trustworthy.
Failure mechanism: Delegation is granted too broadly, not revoked quickly enough, or is reused outside the intended context, so an external provider, API client, or downstream actor can perform actions beyond the original approval.
Impact: The bank can face unauthorised transactions, customer data exposure, regulatory findings, partner compromise propagation, and a much larger incident blast radius than a single account compromise would create.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Delegated access depends on short-lived, revocable credentials and tokens. |
| AC-6 — Least Privilege | Delegation increases risk when authority exceeds the minimum needed for the task. | |
| AC-3 — Access Enforcement | Delegated decisions must be enforced at runtime, not only approved on paper. | |
| Recommendation — Limit delegated authority with tightly managed, revocable authenticators and token lifetimes. Constrain delegated paths to the minimum permissions needed for each business action. Enforce delegation scope, purpose, and expiry at the point of access. | ||
Practitioner Guidance
What to verify: Verify that every delegated path has an explicit scope, expiry, and revocation trigger, and that the system can prove who initiated the act, who authorised it, and under which authority it executed. If you cannot reconstruct that chain from logs and policy, the delegation is not operationally safe.
Decision rule: If an external party or machine can act without a fresh, bounded assertion of purpose or audience, treat the path as higher risk than a normal entitlement and require tighter approval, monitoring, and shorter-lived authority. If the action can move money, reveal customer data, or alter permissions, assume the blast radius is larger than the visible role suggests.
Practitioner takeaway: In financial services, delegated access is risky because it shifts control from static permission to live authority, so the practical objective is to make every delegated action narrow, attributable, and quickly revocable.
Related resources from NHI Mgmt Group
- Why do electronic signature workflows increase risk if access controls are weak in financial services?
- Why does opening APIs and extending partner access increase identity and compliance risk in financial services?
- Why do Salesforce integrations increase NHI risk?
- When does JIT access create more risk than it reduces?