How should banks govern service and privileged accounts across legacy systems and acquired platforms?

Building a single account evidence model across old and acquired environments

Banks should treat service and privileged accounts as governed records, not just technical objects. The practical goal is to create one evidence model that can survive different platforms, ownership structures, and maturity levels. That means each account needs a named owner, a review outcome, and a source-of-truth change record that can be reconciled back to the system that actually governs the account.

For legacy estates and acquired platforms, the first decision is usually not which control is ideal, but what the platform can reliably prove today. If a system cannot expose ownership cleanly, the governance process may need a compensating evidence path, such as approved exceptions, attestations, or reconciled inventory records, until source-system control improves. The NHI Ownership and Accountability Guide is useful here because ownership is the control anchor that makes later review defensible.

That evidence model also has to distinguish between account existence and account authority. A service account may be technically present but not actually in use, while a privileged account may be active yet heavily constrained. Governance is stronger when it captures the account purpose, the system it serves, who can approve changes, and what proof shows the current state in the source platform. For that reason, the Service Account Security Guide and the Privileged Access Management Guide both support the core pattern of tying access to accountable ownership and reviewable privilege.

Why legacy and acquired platforms break standard IGA assumptions

Legacy systems often lack clean APIs, stable account metadata, or reliable event trails, while acquired platforms may bring in incompatible naming conventions, orphaned accounts, and duplicated administrative roles. In that environment, a workflow that assumes full automation can create a false sense of control. The question is not whether the IGA process is elegant, but whether the underlying evidence is trustworthy enough to support approval, recertification, and revocation decisions.

Acquired platforms also tend to surface hidden privilege inheritance. Local admin, shared service credentials, and vendor-created support accounts can persist long after integration, especially when the original system owner is no longer present. Banks need to map these accounts to a business owner and a technical custodian, then confirm whether the platform can show last-use, password age, membership changes, or role assignment history. Where it can, the evidence becomes stronger; where it cannot, the bank needs a controlled fallback until the platform is remediated.

This is why the acquisition conversation should include account inventory quality as part of integration due diligence. If ownership, rotation, and change records cannot be proven, the institution inherits operational and security debt with the platform. The Human vs Non-Human Identity explainer is a useful reference point for understanding where people-driven approvals and machine-driven access meet in messy estates.

What good governance looks like in practice

Good governance uses one control logic across all environments, but not one implementation assumption. In mature banks, every privileged or service account is inventoried, assigned to an owner, reviewed on a schedule matched to its criticality, and changed only through the source system that can attest to the change. If the source system cannot attest, the bank should treat the account as higher risk and require compensating verification.

For service accounts specifically, the governance objective is to reduce silent persistence. For privileged accounts, it is to reduce standing authority and make elevated use observable. That often means separating regular admin access from emergency access, reviewing shared accounts more frequently, and requiring evidence that dormant or retired accounts have actually been removed rather than merely hidden from the IGA layer. The Just-in-Time Access and Zero Standing Privilege Guide helps frame the privilege side of that decision, while the Break-Glass and Emergency Access Account Guide supports the exception path for critical recovery access.

Banks with many inherited platforms should also keep a separate reconciliation view for accounts that cannot yet be governed natively. That view should show what is known, what is inferred, and what remains unverified. The point is not to force legacy platforms into a modern template, but to make the gaps explicit enough that risk owners can act on them.

Risk and Threat Considerations

When banks do not anchor governance in source-system evidence, stale privileged and service accounts can outlive the business need that created them. That creates an access path that is easy to forget, hard to recertify, and attractive to attackers because it often bypasses normal user controls.

Failure mechanism: Ownership is unclear, reviews become checkbox exercises, and the IGA layer records approval for an account state it cannot independently verify in the underlying system.

Impact: Orphaned or overprivileged accounts can retain access after a merger, platform migration, or staff change, increasing the chance of unauthorized access, lateral movement, or delayed revocation.

Practitioner Guidance

What to prioritise: Start with the accounts that can do the most damage if they are wrong, which usually means domain admins, application service accounts with production reach, and vendor support accounts. Those accounts need the strongest ownership evidence and the shortest review interval.

What to verify: Before trusting a recertification result, verify that the source system can show the current owner, current privilege, and the last approved change. If the system cannot prove those three things, treat the review as incomplete even if the workflow shows a passed status.

Decision rule: If a legacy or acquired platform cannot support trustworthy change evidence, govern it with a temporary compensating control and an explicit remediation deadline rather than pretending the standard IGA process is sufficient.

Practitioner takeaway: The right model is not “one workflow for every platform”; it is one accountable evidence standard that adapts to each platform’s proof quality while keeping ownership, privilege, and change traceable.

Related resources from NHI Mgmt Group

• How should security teams govern privileged access across service accounts and AI-driven systems?
• How should security teams govern Active Directory service accounts?
• How should security teams govern privileged access across cloud and legacy systems?
• How should security teams govern service accounts and API keys across cloud platforms?