TL;DR
Retail banks can run mature IAM and IGA programs and still complete account changes by hand in core, branch, payment, and legacy applications. The issue is not the identity decision. It is the last mile between that decision and the account inside the application. Closing it requires an execution layer that can act through APIs or the user interface, verify the result, and return evidence to the systems already in control.
Why are some of your bank’s most critical applications still outside standard authentication and access review processes?
The answer is often less about strategy than reach. A bank can have mature IAM and IGA programs and still depend on people to carry approved changes into core, branch, payment, and legacy applications.
That leaves leadership with a control gap it should be able to see and measure.
A joiner, mover, or leaver event can be correct in HR, approved in an IGA platform, and processed by an identity provider. Then the workflow reaches an application that does not support SCIM or expose a usable user-management API. The automated path stops. A ticket opens, an administrator signs in, and the account changes when someone has time to make the change.
That is a familiar operating reality in retail banking, where important workflows can span modern SaaS, vendor systems, on-premises applications, and software built long before current identity standards. That doesn't mean the bank's identity program is immature. It means the application cannot participate in the program on its own.
A mature identity program can still end in a ticket
The coverage gap is larger than a handful of exceptions. The 2026 Ponemon Institute research sponsored by Cerby found that, on average, 30% of enterprise applications are disconnected from centralized identity systems, and 40% of those disconnected applications are business-critical. Those are cross-industry figures, not a retail-banking benchmark, but they show why a well-designed identity architecture can still leave consequential work outside automated control.
For a bank, the practical question is not whether an application is old or new. It is whether the application can accept the identity action the bank has already approved. If it cannot, provisioning, permission changes, deprovisioning, credential rotation, and evidence collection become separate administrative tasks.
The problem is execution, not approval
Identity governance establishes who should have access and under what conditions. The application still has to reflect that decision. When those two states diverge, a person can be removed from the identity provider while a local account, role, credential, or session remains active in the target application.
Offboarding makes the distinction easy to see. Disabling an identity in the IdP can stop future federated logins, but it does not automatically disable a local account in an app that is not federated. It also may not rotate a shared credential, revoke a role, or end an existing session. Each state has to be changed through a mechanism the application actually supports.
This is why tickets are not just an efficiency issue. A ticket records intent. It does not, by itself, prove that the account reached the approved state. A closed-loop process needs both execution and confirmation.
What closed-loop lifecycle automation requires
A durable workflow preserves the bank's existing sources of truth and policy engines. It adds a reliable way to complete the approved action in the target application. At a minimum, that workflow should:
- Receive an approved joiner, mover, leaver, access-request, or remediation event from the existing identity stack.
- Resolve the person, account, role, entitlement, and application owner with enough precision to avoid acting on the wrong object.
- Execute the change through a supported API or managed UI automation when no API or SCIM path exists.
- Observe the resulting application state and distinguish success, partial completion, and exception.
- Return status and access data to the IGA or other system of record, with a time-stamped audit trail.
- Route exceptions to a named owner, rather than silently treating a failed action as complete.
How Cerby extends the banking identity workflow
Cerby works with existing IAM and IGA platforms rather than replacing them. An approved event from platforms such as Okta, Microsoft Entra ID, or SailPoint can trigger Cerby to create an account, change a role or group, disable access, or rotate a credential in a supported disconnected application. Cerby uses APIs where they are available and managed UI automation where they are not.
For browser-based, thick-client, and on-premises applications behind the firewall, Cerby's identity lifecycle brief describes an on-premises agent designed to extend those workflows without making the application natively support modern standards. It can then synchronize access data and completion status back to the governance layer for reviews, reporting, and remediation.
Coverage is application-specific. A bank should confirm the exact application, workflow, role model, and supported action before treating it as automated. That is a better control than assuming every account action behaves the same because two applications share an industry label.
Start with one bounded workflow
The fastest way to evaluate the gap is to follow a real identity event from approval to application state.
Choose a small set of high-value applications and document the current path before selecting technology.
- Name the authoritative source and policy decision point.
- List every manual handoff, credential, file, script, and ticket involved.
- Define the target account, role, entitlement, and session state for joiners, movers, and leavers.
- Identify the evidence required to show that the change was completed.
- Test failure paths, approvals, rollback, and exception ownership before expanding scope.
The bottom line
Retail banking does not need another identity control plane for this problem. It needs the control planes already in place to reach the applications that cannot respond to them today. When the approved decision, application action, verification, and evidence share one workflow, core and legacy applications stop being permanent manual exceptions.