What should banks do when legacy systems cannot follow the same access policy as modern platforms?

Why legacy access rules become an identity governance problem

When a legacy application cannot follow the same access policy as a modern platform, the issue is not just technical inconsistency, it is a governance split. Banks need one decision standard for who can get access, how that access is approved, how often it is reviewed, and how quickly it is removed, even if the enforcement method differs by system.

That matters because inconsistent policy application creates exceptions that tend to outlive their original justification. Over time, the exception becomes the control, and the legacy estate turns into a separate privilege model that is harder to audit, harder to recertify, and easier to misuse. A bank can tolerate different mechanisms, but not different governance intent.

Legacy systems often lack the hooks needed for modern policy enforcement, but that does not justify a looser standard. The bank should define the access rule once, then decide whether the legacy platform can comply natively, needs a compensating control, or must be isolated behind a narrower access path. For access policy design, NHIMG’s Authorisation Models Guide is useful because it compares models that can be applied consistently across people, workloads, and agents.

What to standardize across modern and legacy environments

The practical target is consistency in approval, review, and revocation, not identical tooling. If modern platforms use role-based approval and time-bound access, the legacy environment should still inherit the same approval criteria, same review cadence, and same offboarding trigger, even if the enforcement control is a wrapper, gateway, batch process, or manual attestation step.

That approach helps banks keep access decisions tied to business need rather than system age. It also reduces the chance that one environment becomes the default place to park broad access simply because it is harder to automate. Where a system cannot support the common policy model, the fallback should be a deliberately constrained path with a smaller blast radius, not a permanent carve-out.

In practice, that means defining the minimum acceptable access pattern for each legacy system, including who may request it, what evidence is required, how long it lasts, and who revalidates it. If the answer to any of those questions is “we do it differently here,” the bank should treat that as an exception requiring control justification, not as a local design preference. The same logic is reflected in broader authorization model thinking, where policy consistency matters more than the specific enforcement mechanism.

How to contain legacy exceptions without creating permanent privilege islands

The safest legacy pattern is isolation with narrow scope. If a system cannot support modern approval or revocation behavior, the bank should reduce who can reach it, reduce what they can do once inside, and reduce how long any granted access remains valid. That may mean jump-host access, proxy enforcement, segmented network paths, or tightly controlled operational accounts, but the objective is the same: make the exception small, visible, and revocable.

Legacy access becomes dangerous when it is treated as a compatibility problem instead of a privilege problem. The real control question is whether the bank can still prove who approved the access, who used it, what it touched, and when it was withdrawn. If that proof is weak, the legacy path is not simply older, it is under-governed.

Banks should also watch for policy drift between business units, especially where operations teams, application owners, and IAM teams each believe another group owns the exception. The more fragmented the ownership, the more likely the legacy path will stay open after the original business need has disappeared. That is why the access path itself should be isolated and tightly scoped, rather than allowed to inherit broad enterprise permissions.

Practitioner Guidance

What to prioritise: Put the legacy system into the same approval and review calendar as the modern estate, even if its enforcement method is different. The first question is not “can we automate it,” but “can we govern it with the same decision rules.”

What to verify: Confirm that every legacy exception has an owner, an expiry, a review cadence, and a revocation path that actually works. If the bank cannot evidence those four points, the exception is not controlled enough to carry production access.

Decision rule: If a legacy platform cannot support the common access policy, constrain it through a narrower access path and treat the remainder as technical debt to be retired, not as a standing operating model. Do not let “hard to change” become “permanently exempt.”

Practitioner takeaway: The goal is not to force identical technology across the estate, but to prevent older systems from becoming governance blind spots where privilege accumulates faster than it can be reviewed or removed.

Related resources from NHI Mgmt Group

• What should agencies do when legacy systems cannot support modern CJIS access requirements?
• Why do legacy IAM systems struggle with modern cloud access patterns?
• Why do legacy systems create more identity risk than modern platforms?
• What breaks when legacy systems cannot be covered by modern IGA and PAM tools?