Designing Security Controls That Support Banking Resilience
How banks can connect strong identity and privileged-access controls with tested recovery paths, clear authority and preserved accountability.
Perspectives · Operational Resilience
Centralised identity and privileged-access controls help banks make access consistent, traceable and easier to govern. Their next opportunity is to make recovery equally deliberate: authorised people should be able to restore a critical service when its usual access route is unavailable.
Strong controls. Governed recovery.
Design routine access and emergency recovery together. Test the people, permissions, dependencies and evidence needed to complete the recovery task.
Single sign-on (SSO) reduces repeated sign-ins. Identity governance makes joiner, mover and leaver decisions more consistent. Privileged access management (PAM) helps govern powerful accounts and administrative sessions. These capabilities address real weaknesses in fragmented access models.
They also concentrate dependencies. An application can be healthy while new users cannot authenticate. A database can be available while its administrator cannot obtain a maintenance session. Recovery tools may require the identity service they are meant to repair.
The constructive question is therefore: which controlled recovery actions remain possible under each credible access failure? Answering it connects security architecture to the bank’s promise of dependable service.
Start with the business task, then trace the access path
An inventory of identity servers is useful, but it does not show whether a responder can restore branch servicing, investigate a payment queue or repair a failed federation configuration. Start with the task and work backwards through the permissions and dependencies it requires.
Map authentication, role activation, credential retrieval, the administrator’s workstation, network reachability, name resolution, certificate validation, approval and evidence capture. These form a dependency network; they are not necessarily a single sequence. Mark which elements are shared by the normal and emergency paths.
Two identity nodes improve availability against some component failures. They may still share directory data, configuration, a certificate, an upstream service or an operator error. A second site can share the same logical dependency. Independence must be assessed against the failure being addressed, rather than inferred from the number of servers.
The Basel Committee’s Principles for operational resilience connect critical operations to dependency mapping and disruption testing. Our application of that principle is to include the access required to recover those operations, alongside the access required to run them.
Different failure states need different recovery decisions
Identity unavailability and suspected identity compromise require different judgements. A connectivity failure may justify an approved alternate authentication route. If a directory or signing authority may have been compromised, restoring access through credentials or trust inherited from it can preserve the exposure.
During suspected compromise, incident leadership should establish a trusted recovery environment, validate the authority used to grant access and follow the containment plan. Speed matters, but the route to restoration must also establish that the recovered system can be trusted. This is an architectural recommendation, not a claim that every outage indicates compromise.
Existing sessions also deserve separate treatment. Some applications may continue to accept a valid session while new sign-ins fail; others require online checks. Longer session lifetimes can preserve continuity but extend the period before access changes take effect. Behaviour depends on token validation, revocation and application policy. Measure it in the actual estate instead of assuming either immediate lockout or uninterrupted access.
Make the recovery boundary explicit
A recovery route should state which failure it addresses and which authority remains available. An account independent of on-premises federation may support recovery of a cloud tenant while still depending on the cloud identity service itself. It does not solve every identity outage.
Microsoft’s Entra emergency-access guidance illustrates this boundary: it recommends accounts independent of federation and synchronisation, strong authentication, protected credentials, monitoring and regular validation. These are product-specific instructions. They should not be copied unchanged into core banking, network appliances or another identity platform.
Independence also introduces operating cost. An alternate credential store, workstation or communication route must be maintained, protected and tested. Too many lightly governed alternatives can enlarge the attack surface. Prioritise critical recovery tasks and the shared failures that matter to them, then choose the smallest viable set of alternate capabilities.
Approval should remain usable during the incident
Two-person approval can reduce unilateral action. It can also delay recovery if the approver cannot authenticate, the workflow depends on the failed identity service, or the only authorised person is unavailable.
Define an approval succession, invocation criteria and an alternate authenticated communication method in advance. Specify how authorisation is recorded and associated with the actual operator. A later review provides oversight; it should not be treated as interchangeable with whatever approval the policy requires before access.
Some platforms support temporary role activation; others require standing emergency privileges to avoid an activation dependency. Where a platform needs standing privilege, tightly govern credential custody, invocation and session termination. Where time-limited elevation is available, test expiry and enforcement. Treat an emergency session’s duration and an account’s permanent role assignment as separate control decisions.
For Indian regulated entities within its scope, RBI’s 2023 IT Governance, Risk, Controls and Assurance Practices Directions address need-based access, privileged activity logging and review, and risk-based MFA for specified privileged access. An emergency design must preserve applicable requirements; it is not a general exemption from authentication or oversight.
Evidence capture is part of the recovery architecture
An alert that depends entirely on the affected identity environment may not reach the responders. A central session recorder may be unavailable when the target system needs repair. Map those dependencies with the same care as the login route.
The approved plan should define what evidence must exist before a task can proceed, how permitted alternative records are protected and how they are reconciled after normal monitoring returns. Operator notes are useful context, but they are not automatically equivalent to system audit trails or mandatory session recording. If required evidence cannot be captured, escalate under the approved policy rather than inventing an exception during the incident.
Capture the incident reference, invoking authority, actual operator, target, times, changes and outcome. End exceptional sessions when their purpose is complete. Review changes, preserve the records and rotate or otherwise secure credentials where exposure or the governing policy requires it. Automatic rotation itself can depend on a recovering vault, so include its completion in incident closure.
A recovery budget makes the trade-offs visible
Hypothetical planning example, not a bank incident or industry benchmark: a critical service has a 30-minute restoration objective. Detection and assessment take six minutes. Invocation and credential release take eight. Establishing target access takes four. Repair and business validation take nine. The modelled sequential total is 27 minutes, leaving three minutes for variation.
If approval requires the unavailable identity service, the eight-minute assumption ceases to be valid. Improving the repair script cannot solve that dependency. Conversely, if credential retrieval is reliable but slow, the team can test whether secure custody and delegated authority can reduce delay without widening everyday privilege.
Real tasks may overlap; model their critical path rather than adding every duration mechanically. Include staff availability and realistic variation. Use the resulting budget to direct investment towards the dependency most likely to prevent timely, controlled recovery. The purpose is a credible decision, not a reassuring average.
Measure readiness through completed tasks
An emergency account’s existence is evidence of preparation. A completed recovery task under the relevant failure is stronger evidence of capability. Test a representative operation from invocation through validated restoration and return to normal controls.
- Coverage: which critical recovery tasks have a tested path for the specified failure?
- Time: how long until an authorised responder can perform the task, and until the business service is verified?
- Control: were scope, operator attribution, required authentication and evidence preserved?
- Closure: were exceptional sessions ended, credentials secured and unresolved changes reconciled?
Exercise identity unavailability, PAM failure and an unavailable approver separately before combining them in a plausible scenario. Test suspected compromise through a controlled exercise appropriate to the environment. Re-test after material access-policy, network, staffing or authentication changes.
RBI’s Directions also address continuity, secure recovery and testing of interconnected systems. The recommendations here apply that recovery lens to access dependencies; they do not assert that RBI prescribes one universal break-glass implementation.
Give the capability a business owner
The identity team can maintain authentication. Security can define exceptional-access safeguards. Operations can maintain the runbook. The critical-service owner should be accountable for whether the complete recovery route meets the service’s needs.
That division matters when every component passes its own test but the combined task stalls. A single owner for the recovery outcome can reconcile permission gaps, approval delay and evidence requirements across teams. Procurement can then ask vendors how credentials, role activation, records and recovery behave when dependent services are unavailable.
NIST’s Zero Trust Architecture distinguishes authentication and authorisation and rejects implicit trust based simply on location. Applying that discipline to emergency recovery means making the alternate route explicit and controlled, rather than assuming that a trusted network or a senior operator is sufficient authority.
Our perspective
Centralised controls are a valuable foundation. Their resilience improves when the bank treats access to recovery as an operating capability with an owner, a defined failure boundary and evidence from realistic tests.
Design the authority to recover alongside the authority to operate.
The practical next step is manageable: choose one critical service, identify one credible access failure and test one complete, governed recovery task. Use the result to improve the normal control architecture and its exceptional route together. That turns emergency access from a spare credential into an accountable service capability.
Sources & further reading
- RBI — IT Governance, Risk, Controls and Assurance Practices Directions, 2023. See sections 15, 19 and 27–29 for audit trails, access controls, incident recovery and continuity.
- Basel Committee — Principles for operational resilience, March 2021. Dependency mapping, testing and governance.
- Microsoft Learn — Manage emergency access accounts in Microsoft Entra ID. Product-specific account, authentication, monitoring and validation guidance.
- NIST SP 800-207 — Zero Trust Architecture. Authentication, authorisation and explicit trust decisions.
Original editorial analysis. The recovery budget, readiness measures and operating recommendations are our synthesis, not prescribed regulatory metrics. The numerical example is hypothetical. References checked on 5 October 2026; product guidance should be applied to the relevant deployment.
Put this perspective into practice.
Explore the concepts, make a decision and test what changes when the situation changes.
Topics: Identity and Access, Operational Resilience, Perspective, Privileged Access