What happens when a second cloud platform is added without updating governance and access processes?

Why This Matters for Security Teams

Adding a second cloud platform without updating governance and access processes usually creates two versions of the truth: one in policy documents and one in the actual operating model. Access requests, role design, approvals, and revocation paths stop lining up across environments, so teams lose a reliable view of who can do what. That is where privilege creep, orphaned access, and inconsistent exception handling start to appear.

In practice, the failure is rarely the new cloud itself, but the assumption that existing approval and review routines will still work unchanged once a second control plane is introduced.

How It Works in Practice

The main problem is that cloud governance is not just about naming a policy. It depends on how identities are created, how roles are mapped, how permissions inherit, and how changes are reviewed. In a single-cloud model, teams often accept one role catalogue, one approval workflow, and one review cycle. Once a second cloud is added, those assumptions break because the platforms usually express access differently, even when the business intent is the same.

That mismatch creates operational drift. An engineer may be granted broad access in one cloud to move fast, while the equivalent access in the second cloud is never reviewed because no one owns the mapping. Over time, administrators compensate with manual exceptions, spreadsheet tracking, or informal approvals. Those workarounds scale poorly and make it harder to answer basic audit questions such as whether access was still required, who approved it, and when it should have been removed.

• Role names diverge, so comparable privileges are no longer obvious to reviewers.
• Privilege inheritance differs, so a role that looks narrow in one platform may be much broader in another.
• Revocation becomes inconsistent, especially when one cloud has automated deprovisioning and the other still relies on tickets.
• Evidence collection fragments, which makes access reviews slower and less trustworthy.

For that reason, governance has to be expressed in business terms first, then mapped cleanly into each cloud’s native access model. A useful comparison is the control discipline in the NIST Cybersecurity Framework 2.0, which forces organisations to define ownership, access control, and oversight as operating capabilities rather than as platform-specific settings.

These controls tend to break down when the second cloud is adopted for a separate team or project without a shared identity and review standard, because local convenience quickly outruns central governance.

Common Variations and Edge Cases

Tighter access governance often increases operational overhead, so organisations must balance standardisation against the speed benefits that motivated multi-cloud adoption in the first place. The edge case is not every second cloud deployment, but the ones where each platform is allowed to develop its own role model, naming convention, and approval path.

In mature environments, some divergence is unavoidable because the clouds do not offer identical IAM constructs. The practical question is whether the organisation has a canonical entitlement model that can absorb those differences without losing control. Where teams rely on native platform roles without a translation layer, reviewers often miss equivalent access that exists under different names. Where engineering teams are allowed to self-provision resources across both clouds, temporary access can become effectively permanent unless recertification is enforced.

A useful pattern is to treat the second platform as a governance stress test. If access owners, approvers, and deprovisioning steps cannot be named consistently across both environments, the operating model is already too weak to trust at scale. That problem becomes more visible during audits, incident response, and offboarding than during day-to-day build activity.

One helpful reference point is the CIS Controls v8, especially where account management and access control need to stay consistent across multiple platforms. A second useful lens is CSA Cloud Controls Matrix, which helps teams translate broad governance expectations into cloud control domains without assuming all providers behave the same way.

Risk and Threat Considerations

The material risk is not just administrative inconsistency, but expanded attack surface and weaker accountability. When access governance lags behind cloud expansion, stale entitlements, overprivileged roles, and poorly tracked exceptions can survive long after they should have been removed.

Failure mechanism: Attackers and insiders benefit from fragmented control planes because revoked access in one environment does not guarantee removal in the other. If role mapping, approval evidence, and recertification are inconsistent, a credential or account that should have been constrained may still retain usable privileges in one cloud.

Impact: The consequence is unauthorized access, slower containment, and a higher chance that lateral movement or data exposure persists across environments before anyone notices.

Practitioner Guidance

What to prioritise: Define one cross-cloud entitlement model before expanding permissions in the second platform. The priority is not naming every native role immediately, but deciding which access outcomes must be equivalent across clouds and who owns that equivalence.

What to verify: Check whether provisioning, approval, review, and revocation all still work when the same person or service needs access in both clouds. If the answer depends on manual translation or tribal knowledge, the process is already fragile.

What good looks like: Access reviews should surface equivalent privileges across platforms, not just identical role names. Deprovisioning should remove access from both environments through a known workflow, and exceptions should expire rather than accumulate.

Practitioner takeaway: Multi-cloud governance fails when teams treat the second platform as a copy of the first instead of as a separate access system that needs explicit control mapping, ownership, and review discipline.

Related resources from NHI Mgmt Group

• What happens if organisations migrate PKI to the cloud without updating governance and operating procedures?
• What breaks when passwordless access is added without governance changes?
• Why do fragmented access governance and GRC processes create more risk during ERP modernisation and cloud migration?
• How should security teams migrate identity governance from on premises platforms to cloud based identity security without disrupting access controls?