Why does PSD2 matter to NHI and IAM teams outside banking?

Why PSD2 Maps to NHI and IAM Problems Outside Banking

PSD2 is not just a payments regulation story. It exposes a broader pattern: when third parties, APIs, devices, and software agents can act on behalf of someone or something else, identity, consent, and transaction authorisation become inseparable. That same pattern appears in cloud platforms, SaaS integrations, CI/CD pipelines, and autonomous workflows that depend on reusable secrets and standing access. The security lesson is already well documented in the Ultimate Guide to NHIs and reinforced by NIST Cybersecurity Framework 2.0: identity controls must follow the action, not just the account.

Outside banking, teams often inherit PSD2-like risk without the regulatory vocabulary. An API key becomes a proxy for consent. A service account becomes a durable privilege carrier. A workflow token becomes a hidden authoriser. Once those assumptions are in place, the business impact looks less like compliance and more like fraud prevention, blast-radius reduction, and delegated trust management. The same issues appear in NHI programs because NHIs outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts according to NHI Mgmt Group research.

In practice, many security teams only discover this PSD2-style control gap after a token is abused, rather than through deliberate design of delegated access.

How It Works in Practice for IAM, Secrets, and Workflows

PSD2 matters because it forces a separation between identity, authorisation, and payment initiation. For NHI and IAM teams, the operational analogue is to separate workload identity from standing privilege and from the secret used to obtain access. That means treating every non-human actor as a governed subject with a lifecycle, a purpose, and a bounded permission set. Current guidance suggests this is best implemented with workload identity, short-lived credentials, and policy decisions made at request time rather than through static RBAC alone.

A practical pattern looks like this:

• Use workload identity as the primary identity primitive for agents, services, and automations, rather than embedding long-lived secrets in code or config.
• Issue short-lived access in line with NHI guidance, so credentials expire with the task and do not survive a compromise window.
• Apply intent-based or context-aware authorisation so the decision reflects what the workload is trying to do, where it is operating, and whether that action matches policy.
• Pair PAM and JIT controls with secret rotation and revocation so access is granted only when needed and removed automatically when the work ends.

For implementation, practitioners often combine OIDC-backed workload tokens, SPIFFE/SPIRE-style identities, policy-as-code, and central secrets management. That approach aligns with the spirit of NIST Cybersecurity Framework 2.0, especially around least privilege and continuous governance, while also matching breach patterns described in 52 NHI Breaches Analysis. In other words, PSD2 is a reminder that delegated authority must be explicit, bounded, and revocable. These controls tend to break down in high-churn CI/CD and multi-cloud environments because token sprawl, hidden trust chains, and inconsistent ownership make revocation too slow.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance friction against resilience. That tradeoff is real, especially when teams need machines to run unattended, third-party integrations to stay available, and incident response to remain fast.

One common edge case is legacy automation that cannot easily support short-lived tokens. In those environments, current guidance suggests wrapping the legacy system with compensating controls such as brokered access, vault-issued dynamic secrets, and aggressive monitoring rather than accepting permanent credentials as the default. Another edge case is third-party or supplier access, where PSD2-like questions become governance questions about who is permitted to initiate a transaction or action on behalf of the business. The risk profile here is familiar from Cisco DevHub NHI breach and other compromised integration paths.

There is no universal standard for intent-based authorisation yet, so teams should avoid overstating maturity. Some organisations will use RBAC plus JIT as a transitional model; others will move toward real-time policy evaluation with stronger workload identity assertions. The right choice depends on whether the system is human-operated, service-to-service, or agent-driven. For agentic workloads, the bar is higher because autonomous behaviour can chain tools and expand privilege in ways static rules do not anticipate. For broader identity governance context, the Ultimate Guide to NHIs is the best starting point.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams make NHI best practices usable across the business?
• Why do dashboards matter in NHI governance?
• How should security teams use IAST and RASP in NHI governance?