How should financial institutions secure identities across multiple cloud providers?

They should use one authoritative identity provider for workforce access, federate each cloud to that source, and standardise lifecycle controls for joining, moving and leaving. The important step is to eliminate separate local identities where possible so revocation, review and audit can happen consistently across platforms and not be repeated cloud by cloud.

Why This Matters for Security Teams

Financial institutions do not just manage users across clouds. They manage control planes, service principals, API keys, federated roles, and automation accounts that can touch payments, customer data, and production infrastructure. The risk is not only account sprawl. It is inconsistent trust: one cloud may enforce strong federation while another quietly preserves local identities, long-lived secrets, or weaker recovery paths. That creates uneven revocation and uneven auditability.

This matters because a compromise in one cloud rarely stays neatly inside one provider. Attackers often pivot through identity, not perimeter, especially when secrets are reused or poorly rotated. Current guidance from NIST SP 800-63 Digital Identity Guidelines supports stronger proofing and federation discipline, but cloud-by-cloud implementation still varies widely. NHIMG’s research shows The 2024 Non-Human Identity Security Report found 35.6% of organisations cite consistent access across hybrid and multi-cloud environments as their top NHI security challenge, which aligns with what security teams see after incidents like the Snowflake breach. In practice, many security teams encounter identity drift only after access review and revocation have already failed in one of the cloud environments.

How It Works in Practice

The operating model should be simple: one authoritative identity source, federation into each cloud, and one set of joiner, mover, and leaver controls that applies everywhere. For workforce identities, that usually means a central IdP issuing assertions to each cloud provider, with conditional access and strong authentication enforced before tokens are minted. For non-human identities, the same principle applies, but the mechanism changes: the identity should be workload-scoped, short-lived, and bound to the specific task or runtime rather than to a static cloud-native account.

That is where multi-cloud governance usually breaks down. A bank can standardise policy, but every cloud still has its own constructs for roles, entitlements, token lifetimes, and emergency access. A practical design therefore uses:

• Central policy for authentication, approval, and revocation decisions
• Federated trust to each cloud rather than local user creation
• Short-lived credentials for automation and service access
• Periodic entitlement review tied to HR and asset lifecycle events
• Logging that preserves the original identity, the federated subject, and the cloud-side action

For non-human access, the best practice is increasingly to favour ephemeral secrets and workload identity over static cloud keys. NHIMG’s 2024 Non-Human Identity Security Report notes that 59.8% of organisations see value in dynamic ephemeral credentials, which is consistent with implementation patterns built around tightly scoped tokens and rapid revocation. This is also where cloud-native identity often needs to be supplemented by controls from the provider side. A compromise can still be contained if the bank can prove who issued the token, when it expires, and which workload was allowed to use it. These controls tend to break down when legacy apps require shared service accounts because those accounts resist federation and are hard to revoke without outage risk.

Common Variations and Edge Cases

Tighter identity centralisation often improves auditability, but it also increases operational dependency on the authoritative IdP and the federation layer. Institutions therefore need to balance consistency against resilience, especially for trading, payments, and incident-response workflows where an identity outage can become a business outage. There is no universal standard for every cloud-native exception path yet, so current guidance suggests documenting those exceptions explicitly rather than letting them emerge informally.

The hardest edge cases are legacy applications, break-glass access, and workloads that span multiple tenants or cloud accounts. Legacy apps may still require local service identities, but those should be quarantined, monitored, and rotated on a stricter schedule than standard workforce access. Break-glass accounts should remain rare, heavily logged, and excluded from normal provisioning workflows. Multi-cloud data pipelines may also need separate workload identities per cloud boundary, even when the business service is singular, because token portability can create hidden lateral movement paths. The 230M AWS environment compromise is a reminder that broad cloud identity exposure can cascade quickly when permissions are overextended.

Where banks diverge most is in how they treat local cloud accounts. Best practice is evolving toward eliminating them wherever possible, but in mixed environments the practical answer is phased retirement: federate first, shrink local access second, and keep exception accounts under separate governance. This approach also helps reduce the blast radius seen in incidents involving exposed secrets such as the Azure Key Vault privilege escalation exposure.

Related resources from NHI Mgmt Group

• How should teams secure non-human identities across cloud and SaaS?
• How should security teams manage cloud identities across multiple applications?
• How should security teams govern AI workloads across multiple cloud providers?
• How should security teams automate cloud compliance reporting across multiple providers?