Notifications
Clear all
Topic starter
10/06/2026 11:35 pm
TL;DR: Fragmented authorization in banking causes services to enforce approvals, thresholds, and audit evidence differently, weakening Zero Trust and complicating PCI DSS 4.0 and supervisory scrutiny, according to Cerbos. When policy lives in code instead of a single runtime layer, access review and incident reconstruction become slower, less reliable, and harder to prove.
NHIMG editorial — based on content published by Cerbos: authorization drift, Zero Trust, and permission management in banking
By the numbers:
- Finance accounts for 27% of all data breaches globally, with an average incident cost of $5.9 million.
- 41.8% of those breaches originated through third-party vendors.
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities - 46% confirmed, 26% suspected.
Questions worth separating out
Q: How should banking teams implement authorization without embedding rules in every service?
A: They should move approval thresholds, access conditions, and resource rules into a shared runtime policy layer.
Q: Why does embedded authorization weaken Zero Trust in banking platforms?
A: Zero Trust depends on every request being evaluated against explicit policy at runtime.
Q: What breaks when authorization decisions are not versioned and logged?
A: Auditors and regulators cannot easily see what control was active at a specific time, so teams must reconstruct the answer from deployment records and code history.
Practitioner guidance
- Centralise authorization into a runtime policy layer Move permission decisions out of individual services so approvals, thresholds, and resource checks are evaluated consistently at request time.
- Version every policy change and retain decision traces Store the approved policy version, the identity, the action, the resource, and the evaluation outcome so auditors can reconstruct control state without relying on commit history.
- Treat service accounts as governed identities Inventory machine identities that can initiate payments, read customer records, or call downstream APIs, then scope each one to the minimum action set and context needed.
What's in the full article
Cerbos's full article covers the operational detail this post intentionally leaves for the source:
- A deeper breakdown of how fragmented approval logic changes release velocity across multiple banking services
- The compliance implications of PCI DSS 4.0 and ECB supervisory expectations for control evidence
- A practical architectural direction for separating policy from application code in regulated payment flows
- The article's own framing of how AI-driven execution changes the scope of permission management in banks
👉 Read Cerbos's analysis of authorization drift and Zero Trust in banking →
Banking authorization drift: are your controls keeping up?
Explore further
12/06/2026 5:51 am
Policy drift is the real failure mode here, not isolated implementation error. When authorization lives inside each service, the programme no longer has one governable decision layer. The same transfer, approval, or data-access request can be evaluated differently depending on which code path receives it. That creates a control environment where enforcement cannot be demonstrated consistently, which is a governance problem before it is a technical one. Practitioners should treat fragmented authorization as a structural control failure.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities - 46% confirmed, 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.
A question worth separating out:
Q: Who is accountable when an AI agent or service account executes a banking action?
A: The bank remains accountable for the delegated identity, the policy that allowed the action, and the evidence showing why it was permitted. If the organisation cannot tie the action to a specific policy version and identity, accountability becomes operationally unclear.
👉 Read our full editorial: Zero trust authorization breaks when banking policy fragments
