Identity management in banking needs continuous, auditable access control

At a glance

What this is: This is a banking IAM analysis that argues critical access must be continuously governed across employees, third parties, privileged accounts, and legacy environments.

Why it matters: It matters because banking teams have to prove who can access what, for how long, and under what controls, across both operational security and regulatory accountability.

By the numbers:

• The average cost of a banking incident reaches $6.29 million per breach, 26% higher than in other sectors.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Soffid's analysis of identity management in banking and critical access control

Context

Identity management in banking is the discipline of deciding who and what can reach critical systems, financial data, and administrative functions, then proving those decisions hold up under audit. The article’s core point is that banking access control fails when visibility, privilege, lifecycle, and third-party governance are handled in silos.

That matters because banking environments combine employees, vendors, privileged accounts, legacy applications, and cloud services, which makes standing access and inherited permissions especially risky. In practice, the governance problem is not just authentication. It is whether access can be continuously justified, traced, and revoked across a highly fragmented estate.

Key questions

Q: How should banking teams manage access so it stays audit ready?

A: Banking teams should manage access as a continuous control, not a one-time grant. That means centralising visibility, tying permissions to business need, logging every privileged action, and proving revocation when roles or vendor relationships change. Audit readiness comes from traceable decisions, not from policy documents alone.

Q: Why do privileged accounts create outsized risk in banking environments?

A: Privileged accounts can alter configurations, reach sensitive data, and bypass normal operational checks, so any weakness in their governance has immediate impact. In banking, the danger is amplified when those rights are permanent or poorly reviewed, because a single account can affect security, operations, and compliance at once.

Q: What breaks when third-party access is left open too long?

A: When third-party access is not time-bound, the organisation loses accountability for why the access exists and when it should end. That creates privilege creep, weak audit evidence, and a larger attack surface. In banking, vendor access should be treated as revocable lifecycle access, not as a standing convenience.

Q: What frameworks matter most for utility identity governance and compliance?

A: NERC CIP is central for utility compliance, and identity controls should also align with the NIST Cybersecurity Framework 2.0 for governance, access control, and continuous improvement. The practical test is whether the programme can demonstrate least-privilege access, prompt removal, and auditable decision trails across the full estate.

Technical breakdown

Why banking identity governance breaks down in hybrid estates

Hybrid banking environments mix on-premises systems, cloud services, vendor portals, and legacy applications that often use different identity models. That fragmentation creates duplicate accounts, inconsistent policy enforcement, and weak audit trails. When access reviews are run separately in each environment, the organisation loses a single view of effective privilege, which is where hidden over-provisioning and inactive accounts persist.

Practical implication: Centralise identity visibility across hybrid systems before trying to optimise access policy.

How privileged account governance changes banking risk

Privileged accounts are not just higher-value accounts. They are operational control points that can change configurations, access sensitive records, and alter security posture. In banking, the risk is multiplied when privileged access is permanent, weakly traced, or decoupled from lifecycle events such as role changes and deactivation. Without tight governance, privilege becomes both a breach vector and an audit failure.

Practical implication: Tie privileged access to lifecycle events and audit logging, not to static entitlement ownership.

Why least privilege and RBAC are necessary but not sufficient

Role-Based Access Control reduces broad entitlement sprawl, but banking environments still need review, recertification, and revocation discipline to keep roles accurate over time. Static roles drift as staff move, vendors change scope, and technical accounts accumulate permissions. Least privilege only works when the entitlement model is continuously corrected against actual business need and system usage.

Practical implication: Use RBAC as the base model, then add scheduled recertification and traceable revocation workflows.

Threat narrative

Attacker objective: The attacker aims to reach high-trust banking systems with enough privilege to steal data, alter controls, or disrupt financial operations.

1. Entry occurs through excessive privileges, stale accounts, or third-party access that remains open longer than needed in a banking environment.
2. Escalation follows when privileged accounts or inherited permissions let an attacker move from ordinary access to sensitive systems or administrative controls.
3. Impact is realised through data exposure, security configuration changes, operational disruption, and compliance failure that can be expensive to remediate.

Breaches seen in the wild

• Coupang Signing Key Breach — Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
• JetBrains Marketplace AI Plugin Campaign — 15 malicious JetBrains Marketplace plugins steal AI API keys from 70,000+ developers via supply chain attack.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Banking identity governance fails when access is treated as a one-time decision. The article describes a control model that must stay continuous, centralized, and auditable because banking access changes constantly across humans, vendors, privileged accounts, and legacy systems. That is the right framing for the sector, because static provisioning alone cannot keep pace with accumulated permissions and shifting operational responsibility. Practitioners should treat identity as an always-on control plane, not a ticketing event.

Privilege creep is the real control gap in banking IAM. The article repeatedly points to inherited permissions, inactive accounts, and permanent access as the conditions that create escalation paths. That is not just a visibility issue. It is a lifecycle failure where access survives the business reason that justified it. The implication is that banking teams need governance over entitlements after assignment, not just during onboarding.

Third-party access without time bounds creates accountably weak access debt. Banking environments depend heavily on vendors, but the article shows that vendor access is often left open longer than necessary. That creates a governance assumption that the external relationship is stable when in fact it is episodic, scoped, and revocable. In banking, the practical conclusion is that third-party access must be treated as a measurable control surface, not a convenience layer.

Converged IAM and PAM is the correct operating model for regulated access. The article’s emphasis on unified governance across employees, third parties, and privileged accounts reflects where the market is heading. Banking teams do not need separate stories for identity, privilege, and audit. They need a single lifecycle and evidence model that can stand up to DORA, PCI DSS, ISO 27001, and internal assurance without manual stitching.

From our research:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.
• For banking teams, that gap shows why lifecycle control and audit evidence must move together, as explored in Ultimate Guide to NHIs , Regulatory and Audit Perspectives.

What this signals

Identity blast radius: banking teams should think less about access volume and more about how quickly a single account can create systemic impact. When privileged and third-party identities are managed outside one evidence model, the blast radius expands across operations, audit, and regulatory exposure. The control question is whether revocation can be proven, not just requested.

With 97% of NHIs carrying excessive privileges according to the Ultimate Guide to NHIs, banking programmes that stop at least privilege without recertification are only treating the symptom. Identity governance has to measure effective privilege over time, not just assigned access at the point of issue.

For practitioners

• Map every access path to an owner and expiry condition Document who approves each access path, what business event ends it, and how revocation is verified in hybrid banking environments. Include vendor, privileged, and technical identities in the same register.
• Recertify inherited and role-changed permissions first Prioritise accounts that gained access through transfers, promotions, vendor scope changes, or inherited group membership. These are the permissions most likely to drift away from current business need.
• Separate privileged access from standing user entitlements Move high-risk administrative access into governed workflows with full logging, short duration, and explicit purpose. Do not allow privileged permissions to persist as part of routine user roles.
• Unify audit evidence across legacy and cloud systems Build one evidence trail for who accessed what, from where, and with what permissions across legacy applications, cloud services, and vendor portals. Banking audits fail when proof is fragmented by platform.
• Track third-party access as a lifecycle control Treat vendor access as temporary by default and require revocation triggers when contracts, scope, or responsibilities change. Review all externally sponsored identities on the same cadence as internal privileged accounts.

Key takeaways

• Banking identity management fails when access is static, fragmented, and hard to audit across people, vendors, and privileged accounts.
• The article’s own checklist points to the core control problem: continuous visibility, lifecycle governance, and traceable privilege are what reduce operational and regulatory risk.
• For practitioners, the practical priority is to make access revocation, recertification, and audit evidence work across every banking environment, including legacy and third-party systems.

Key terms

• Identity Governance: Identity governance is the set of controls that defines who approves access, who owns it, how it is reviewed, and when it is removed. In practice, it turns identity management from a deployment task into a durable control system that can withstand audits, organisational change, and operational growth.
• Shared Privileged Account: An administrative identity used by more than one operator or system process. These accounts are common in infrastructure and cloud operations, but they create accountability and lifecycle challenges because access must be tightly controlled, rotated and audited.
• Access Recertification: Access recertification is the periodic review of user or account permissions to confirm that access is still justified. It is useful, but it is not enough on its own because it reacts after entitlements already exist, which is why lifecycle governance must reduce the volume of exceptions before review time.
• Third-Party Access: Third-party access is access granted to vendors, contractors, or support partners who are not direct employees of the organisation. It is higher risk than internal access because accountability, device assurance, and access duration are harder to control, so it usually requires tighter time limits and stronger auditability.

What's in the full article

Soffid's full article covers the operational detail this post intentionally leaves for the source:

• A practical checklist for banking IAM platform selection across visibility, auditability, and lifecycle control.
• Specific handling of privileged accounts, third-party access, and recertification in regulated financial environments.
• How converged IAM, IGA, and PAM are positioned for hybrid banking estates.
• The article’s implementation-oriented view of DORA, PCI DSS, ISO 27001, and related banking requirements.

👉 The full Soffid article covers banking IAM challenges, privileged access governance, and compliance considerations in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.