How should financial organisations govern shared accounts without losing accountability?

When shared accounts stop being a control and become a liability

Shared accounts are sometimes used for resilience, shift coverage, or device workflow continuity, but they only remain defensible when the organisation can still answer who used them, for what purpose, and under whose approval. The governance problem is not the existence of the account itself, but the collapse of individual accountability when many people can act through one identity.

That means the control model has to shift from “who owns the password” to “what evidence proves each use was authorised and traceable.” Shared and Generic Accounts Governance Guide is useful here because it treats shared access as a lifecycle and ownership problem, not just a password problem.

In practice, the organisation should define the exception narrowly, record the business purpose, and bind the account to a named owner who is accountable for access approvals, review and retirement. Where the shared login is really standing in for team workflow, the stronger answer is usually to redesign the access path rather than normalise the exception.

What good governance needs to prove

A shared account can be acceptable only if the surrounding controls restore enough evidence to reconstruct activity after the fact. That usually means unique user attribution in logs where possible, session-level logging where not, and periodic review of whether the shared use case still exists. If the organisation cannot distinguish one operator from another, it has not solved accountability, it has only moved it out of sight.

Shared access also needs ownership discipline over time, not just at approval time. The exception should have a review date, a documented scope, and a clear rule for when it must be replaced by individual access. The operational question is whether the shared account is still the least risky way to achieve the business task, or whether it has become the easiest way to avoid governance work.

When the account is used across teams, locations or shifts, the risk rises because approval boundaries blur and access recertification becomes less reliable. That is why shared accounts should be treated as temporary or tightly bounded exceptions, not as a default operating model.

Why traceability, not secrecy, is the real control objective

The security failure in shared-account design is often assumed to be weak authentication, but the deeper issue is the loss of attribution. Even strong passwords, MFA or vaulting do not create accountability on their own if multiple people can use the same identity with no durable evidence trail. NHI Ownership and Accountability Guide is relevant because it reinforces the principle that ownership is what prevents an identity from becoming administratively orphaned.

Shared credentials also create a higher-value target for misuse because one compromise can expose a broader operating group. That is why logging, purpose limitation and review matter as much as password strength. If the access path is shared, the governance model must compensate by making every use observable, reviewable and attributable.

For financial organisations, the most defensible approach is usually to minimise shared accounts, reserve them for genuine operational necessity, and require an explicit exception owner who can justify the residual exposure. The goal is not to make shared access comfortable, but to make it governable.

Practitioner Guidance

What to verify: Confirm that every shared account has a named business owner, a defined purpose, an expiry or review date, and logging that is good enough to support post-event attribution. If any of those elements is missing, treat the account as an ungoverned exception rather than an approved control.

Decision rule: If the account is used by more than one person and individual attribution cannot be recovered from logs or compensating controls, do not treat it as a stable operating model. Keep it only as a time-bound exception while you redesign the workflow toward named access.

Common mistake: Teams often assume that stronger authentication solves the shared-account problem. It does not, because the governance failure is usually accountability, not entry.

Practitioner takeaway: A shared account is only defensible when the organisation can still prove who used it, why they used it, and who is accountable for keeping that exception under review.

Related resources from NHI Mgmt Group

• Govern
• How should organisations govern shared social media accounts without losing speed?
• How can security teams handle shared accounts without losing control?
• How can organisations govern third-party AI systems without losing accountability?