Multi-cloud is now the normal case. Flexera’s 2026 State of the Cloud report, published in March 2026 from a survey of more than 750 IT decision-makers, says 88% of organizations use multiple cloud providers in parallel.
Each added provider brings its own identity model, network constructs, logging formats and policy language. If every provider gets its own team, standards and tools, you are running three security programs that happen to share a risk register. This guide sets out an architecture that avoids that.
The NSA’s 2024 guidance on hybrid and multi-cloud names what goes wrong otherwise: operational silos, configuration discrepancies between environments that can leave exploitable gaps, vendor-specific access control tooling that does not scale to other platforms, and weak visibility across environments.
The design principle
Define once. Implement per cloud. Prove centrally.
Control objectives, identity rules and detection requirements are written one time, as outcomes. Each cloud gets a thin implementation layer that maps those outcomes onto its own services. Evidence flows back to one place. The provider-specific depth stays with engineers who know the platform. The policy stays with one owner.
Reference architecture
| Layer | Define once | Implement per cloud | Prove centrally |
|---|---|---|---|
| 1. Control objectives | Standards written as outcomes, such as “no long-lived keys in workloads” or “administrator access requires MFA”. | A mapping from each objective to the services each provider offers. | The mapping, with a named owner for each control. |
| 2. Identity | One authoritative identity source and uniform access policy. The NSA advises that access control policies be uniformly defined so users have the same access across accounts. | Federation settings and role mappings in each provider. | Privileged-role inventory and access review results across all clouds. |
| 3. Policy and configuration | Policy as code and infrastructure as code. The NSA recommends both, including maintaining access policies from one central location. | Provider-specific modules and guardrails that implement the policy. | Drift and exception reports by account. |
| 4. Network and data | Rules for traffic between environments. The NSA advises minimizing flows between them. Encryption and key standards. | Each provider’s network and key services. | Inventory of cross-cloud flows and of keys. |
| 5. Detection and logging | A common log schema, retention rule and use-case set. The NSA recommends ingesting logs into one platform, such as a SIEM or SOAR tool. | Enabling and forwarding each provider’s logs. | Log coverage by account and by source. |
| 6. Operating model | One policy owner, one exception process, one risk register. | Cloud engineers with deep platform skills. | Exceptions raised and time to fix. |
Five decisions that shape the design
1. Where identity lives. Federated identity is the usual answer. The NSA notes that an identity-as-a-service platform can become a single point of failure for all accounts, and says IAM policies should be audited periodically for irregularities. Plan break-glass access and resilience for the identity layer before you depend on it. Also decide how workloads authenticate. Credentials that never expire travel well across clouds, and across attackers. In the Snowflake cases Mandiant described, some exposed credentials were still valid years later.
2. Native or third-party controls. There is no universal answer. Judge each candidate on four tests: does it cover the services you actually run in every cloud, does it enforce or only report, where does its telemetry go, and what would it cost to leave. A central dashboard that cannot enforce anything is visibility, not a control.
3. How to express policy. Write the objective once and generate provider-specific implementations. The NSA suggests vendor-agnostic infrastructure as code and policy as code for compliance. Keep the abstraction at the level of the objective. If it tries to hide every provider difference, it ends up at the lowest common denominator and loses useful native controls.
4. How much crosses between clouds. Every flow between environments is a path. Treat inter-cloud connectivity as an exception to be justified, not a default to be inherited.
5. What to centralize operationally. Centralize logging, detection content and reporting. Keep response runbooks provider-specific, because isolating an account looks different in each cloud.
Patterns that recreate three programs
-
Three teams, three toolsets. Each cloud has its own standards document, scanner and review board.
-
A central team without platform depth. Policy is written that engineers cannot implement as written, so exceptions pile up.
-
One dashboard, no enforcement. Findings are consolidated. Nothing is blocked or fixed at source.
-
Lowest-common-denominator controls. The policy only asks for what every provider can do, so each provider’s stronger features go unused.
-
Federation with no resilience plan. One identity platform serves every cloud, and nobody has tested what happens when it is unavailable or compromised.
A practical sequence
-
Inventory accounts and identities in every cloud. You cannot standardize what you cannot list.
-
Write the control objectives and map each to every provider. Start with the ten that matter most. Gaps in the mapping are your first findings.
-
Move the highest-risk controls into policy as code. Administrator access, public exposure and key handling are good candidates.
-
Centralize logs and detection. Measure coverage by account.
-
Retire duplicate tooling and standards. Only after the shared layer works.
Limits
The NSA sheet is United States government guidance from March 2024, written for a broad audience. It describes the problems and the direction, not a product design. Some organizations keep clouds separate for good reasons, including data residency, regulation or an acquisition that has not yet been integrated. This guide does not claim that unifying programs always saves money. It claims that duplicated control design creates gaps, and that a shared layer reduces them.
A one-control test
Pick one control, such as MFA for administrators. Ask for the evidence in each cloud you run. If you get three answers from three teams in three formats, you have three programs. If you get one answer from one dashboard, with the per-cloud detail underneath, the architecture is working.
Sources
How we label evidence
Facts carry a source. Analysis and recommendations are marked as ours. Examples that are hypothetical are labeled as hypothetical.
Part of the solutionProtect What MattersGuard the identities, data and systems the business depends on.See how we work →Related service
Cloud Security
Use this to evaluate cloud control and configuration risk.