PSD2 gives third-party providers access to customer data and payment functions through open APIs, which means the organisation must govern delegated access, not just internal user access. Consent is necessary, but it is not enough. Teams also need scope control, monitoring, and revocation so the provider's authority stays aligned to the approved purpose.
Why Third-Party API Access Becomes a Governance Problem
PSD2 changes the control model from simple internal access management to delegated access governance. A third-party provider is not just a user with a password; it is an external actor operating under consent, scope, and technical constraints that must be enforced continuously. That shifts the question from “was access approved?” to “is the provider still operating within the permitted purpose right now?”
This is exactly the kind of delegated-access risk highlighted in the State of Non-Human Identity Security, where 85% of organisations reported limited visibility into third-party vendors connected via OAuth apps. When access is mediated through APIs, tokens, and consent artefacts, governance must extend beyond the initial grant to monitoring, revocation, and proof of ongoing legitimacy. The issue is not only identity, but authority.
Practitioners often underestimate how quickly approved access can drift into overreach once it is embedded in automated payment and account information flows. In practice, many security teams encounter delegation failures only after a provider has already retained broader API reach than the original consent justified.
How PSD2 Access Should Be Governed in Practice
PSD2 access control works best when treated as a lifecycle problem. Consent establishes legal permission, but security teams still need technical enforcement for scope, duration, and revocation. That means mapping each third-party provider to a defined purpose, limiting APIs to the minimum functions required, and verifying that token use matches the approved transaction context. This aligns with the broader access-control guidance in the OWASP Non-Human Identity Top 10 and the governance emphasis in the NIST Cybersecurity Framework 2.0.
For payment organisations, the practical controls usually include:
- Purpose-bound consent records that specify which data and functions are allowed.
- Scope-limited API entitlements that prevent a provider from expanding into adjacent services.
- Continuous monitoring of token use, anomalous call patterns, and privilege drift.
- Fast revocation workflows when consent expires, is withdrawn, or the provider relationship changes.
- Periodic re-certification of third-party access against current business need.
NHIMG’s Ultimate Guide to NHIs is useful here because PSD2 providers behave like non-human identities from a governance standpoint: they operate through machine-mediated credentials, not human session assumptions. The same lifecycle thinking also appears in the lifecycle processes for managing NHIs, where issuance, monitoring, and retirement must be controlled as one chain.
These controls tend to break down when consent is treated as a one-time legal checkbox and the provider’s token or certificate remains valid long after the intended purpose has changed.
Common PSD2 Edge Cases and Operational Tradeoffs
Tighter third-party control often increases integration overhead, requiring organisations to balance customer experience and API availability against stronger oversight. That tradeoff is real, especially where account aggregation, payment initiation, and delegated authentication all converge. Current guidance suggests that consent alone is not a sufficient control, but there is no universal standard for how often each provider’s access should be revalidated.
One edge case is long-lived access in low-traffic integrations. A provider may appear dormant while still holding authority that could be misused if its secrets are exposed. Another is privilege creep when a provider starts with read-only access and later gains payment initiation functions without a full governance review. The risk is amplified when access is distributed across multiple tokens or application registrations that are not centrally correlated.
For organisations building operating models, the safest path is to treat PSD2 providers as governed external identities with explicit lifecycle ownership, not as static technical exceptions. The challenge is not only whether access was approved, but whether the approval still matches the active data-sharing purpose. That distinction is central to the regulatory and audit perspectives and the risk patterns documented in the 52 NHI Breaches Analysis.
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-01 | PSD2 providers rely on machine credentials that need strict lifecycle control. |
| NIST CSF 2.0 | PR.AC-4 | Delegated API access must be restricted, monitored, and revalidated. |
| NIST AI RMF | PSD2 governance depends on accountable, context-aware access decisions. |
Inventory third-party provider identities, scope their tokens, and retire access immediately when purpose ends.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
