Multi-cloud security explained: unified threat detection across AWS, Azure, and GCP

Most enterprises no longer run one cloud. They run two, three, or more — and each provider arrives with its own identity model, policy language, and audit-log format. According to Flexera's 2025 State of the Cloud report, roughly 70% of organizations run hybrid or multi-cloud, averaging 2.4 public providers each. That fragmentation is precisely where attackers operate. Per the Ponemon Institute's Cost of a Data Breach study, breaches spanning multiple environments cost the most and took the longest to contain in the 2024 report.

This page explains what multi-cloud security is, how it differs from hybrid cloud, why cross-cloud identity federation is the dominant risk, and how unified detection makes a cross-cloud attack visible as one story. It is the depth the standard "capabilities checklist" leaves out.

What is multi-cloud security?

Multi-cloud security is the practice of protecting workloads, data, and identities across two or more public cloud providers — such as AWS, Azure, and Google Cloud — as a single attack surface, applying consistent policy, visibility, and threat detection even though each provider runs a distinct control plane. The discipline treats the providers as one environment, not several.

Organizations adopt multi-cloud for sound reasons: best-of-breed services from each provider, resilience against a single-provider outage, data-residency flexibility, and freedom from vendor lock-in. Multi-cloud can also improve security resilience, because no single cloud failure takes down everything. The trade-off is complexity — and the security challenge is the gap between providers, not any single cloud.

That complexity is now the norm rather than the exception. Thales' 2025 Cloud Security Study, drawing on roughly 3,200 respondents, puts the average at 2.1 public providers per organization. Adoption figures range widely depending on whether a survey counts public providers only or includes hybrid — older estimates reached as high as 98% (Oracle/451 Research, 2023) — but the current 2025 evidence converges on two-plus providers as the standard operating model. The takeaway is simple: if you run more than one cloud, multi cloud security is no longer optional, and the work is keeping protection consistent across providers that were never designed to interoperate.

To go deeper on the category of tooling that delivers this — and how cloud security posture management, workload protection, and entitlement management fit together — see our guide to cloud detection and response.

Multi-cloud vs hybrid cloud security

Multi-cloud and hybrid cloud are often conflated, but they describe different architectures with different blind spots. Multi-cloud means two or more public providers running side by side. The threat model is provider-to-provider: inconsistent identity and access management (IAM), fragmented logs, and federation trust that an attacker can ride from one cloud into another. Hybrid cloud means on-premises infrastructure combined with cloud, where the central concerns are east-west visibility and the identity bridge between on-prem directories and cloud identity providers.

The distinction matters because it dictates which controls you need. A hybrid program invests heavily in monitoring the seam between the data center and the cloud. A multi-cloud program invests in normalizing telemetry and correlating identity activity across providers that emit different evidence.

Table: How multi-cloud and hybrid cloud differ in scope and threat model.

This page owns the two-plus-provider model. For the on-prem-meets-cloud side — east-west detection and the directory-to-cloud identity bridge — see hybrid cloud threat detection.

Multi-cloud security risks and challenges

The most common multi-cloud risks are not exotic. They are the predictable consequences of stitching together providers that handle identity, policy, and logging differently. The recurring challenges:

• Visibility fragmentation: each provider's audit logs use a different schema and arrive at a different latency.
• IAM model inconsistency: roles, policies, and trust relationships differ across providers.
• Configuration drift: defaults and policy languages diverge, so settings fall out of alignment.
• Shared-responsibility complexity: the responsibility line moves with each provider and service.
• Tool overlap: duplicate, partially configured tooling creates seams and gaps.
• Orphaned accounts: forgotten or unused accounts in any provider become quiet entry points.

Visibility fragmentation deserves a definition because it is the root of so much else: it is the security blind spot created when each provider logs and reports differently, leaving no single place to see what is happening across all of them. Forgotten cloud accounts are risky for a related reason — an unused, over-permissioned account that nobody monitors is an attacker's ideal foothold, and in a multi-cloud estate those accounts multiply per provider.

So are multi-cloud environments more vulnerable to cyberattacks? Not inherently. Multi-cloud is not less secure by design, but fragmented visibility and inconsistent IAM extend the window an attacker can operate undetected. The cost data makes the point. Per the Ponemon Institute's Cost of a Data Breach study, in the 2024 report, breaches spanning multiple environments cost the most — USD 5.05 million — and took 283 days to identify and contain, with 40% of breaches spanning multiple environments. The 2025 edition put the global average breach cost at USD 4.44 million, the first decline in five years. The lesson is consistent across editions: when a breach crosses environments, it costs more and lingers longer — because no one console sees the whole picture.

For the fundamentals of the shared responsibility model and the baseline practices every cloud estate needs, see our cloud security guide.

How unified cross-cloud threat detection works

This is the part the standard pillar pages skip. Listing CSPM, CWPP, and CIEM as "capabilities" tells you what to buy, not how to get consistent detection when AWS CloudTrail, Azure Activity and Entra logs, and Google Cloud Audit Logs differ in schema, latency, and identity model. Unified detection normalizes each provider's telemetry into one model, so a cross-cloud attack appears as one correlated story, not scattered events.

The mechanics follow a repeatable pipeline:

1. Collect per-provider telemetry from each cloud.
2. Normalize the data to a common schema.
3. Apply one detection model across providers.
4. Ingest into a unified SIEM, XDR, or NDR.
5. Correlate activity cross-cloud.
6. Triage and respond once.

‍

The pipeline starts with the control-plane reality. Each provider audits and authenticates differently, and a detection model that works in one cloud cannot be copied verbatim into another. The table below shows the differences a unified layer has to reconcile.

Table: Per-provider control-plane and logging differences a unified detection model must normalize.

Once telemetry is normalized, the question becomes where it lands. A traditional SIEM offers mature correlation and reporting but can become costly at multi-cloud log volumes. A security data lake offers cheaper retention and flexible querying but pushes more detection engineering onto your team. Many enterprises run both — a data lake for breadth and retention, a unified detection layer for real-time correlation. Network detection and response (NDR) and extended detection and response (XDR) add what a log-only view misses: by consuming cloud-control-plane events alongside flow and behavioral telemetry, they surface cross-cloud behavior a single provider's console cannot see.

The network layer is a meaningful piece of this and warrants its own depth — for cross-provider traffic inspection and segmentation, see multi-cloud network security. The investment alone does not close the gap, though. A 2026 hybrid-cloud security industry survey found that 41% of organizations say breach investigations now take longer, even though 93% had bought new detection and visibility tooling. More tools without unification produces more noise, not more clarity.

Cross-cloud identity federation: the core risk

Identity is the number-one multi-cloud breach vector, and federation is why. When one central identity provider — Entra ID or a third-party single sign-on service — is federated into AWS, Azure, and GCP, a single identity-provider compromise can become cross-cloud access. A credential or token stolen in one provider grants federated access to another, and to each provider's console it looks like a separate, unrelated event. That is the gap. Two consoles see two logins. Only a layer that correlates identity activity across providers sees one attack.

Thales' 2025 Cloud Security Study reports that compromised identities are involved in more than 70% of cloud breaches, and 68% of organizations cite credential or secret theft as the fastest-growing attack tactic. Why is identity management so difficult in multi-cloud environments? Because each provider models identity differently, federation trust is easy to over-scope, and identity sprawl — too many accounts, roles, and grants spread across clouds — makes it hard to know what normal looks like in the first place.

The risk is not theoretical. The CISA and NCSC-UK joint advisory AA24-057A, published in February 2024, documented Russian SVR actors (APT29) adapting their tactics for initial cloud access — abusing dormant accounts, stealing tokens, and applying multi-factor authentication pressure to gain and persist in cloud environments. Those techniques are the raw material for a cross-cloud federated pivot. Current activity confirms the pattern: a 2026 OAuth device-code phishing campaign hit more than 340 Microsoft 365 organizations, and because a token minted against a central identity provider federated to AWS or GCP carries cross-cloud reach, one stolen token can open access in multiple clouds. Critically, MFA provided no protection in this campaign, and the refresh token persisted after the victim reset their password (Cloud Security Alliance Labs; FBI IC3 PSA).

The defensive response is specific. Revoke refresh tokens rather than only resetting passwords, because a reset alone leaves a stolen token live. Treat the device-code flow as a Conditional Access control point and restrict or scope it. Monitor token issuance and replay for anomalies across providers, not one cloud at a time. In MITRE ATT&CK terms, the cross-cloud movement maps to T1550.001 (Application Access Token) for lateral movement and T1606.002 (SAML Tokens) for credential access. Independent reporting has reached the same conclusion — that identity sprawl and federated single sign-on let cross-cloud anomalies slip past single-console views (InformationWeek).

‍

Closing this gap is an identity-detection problem. For the discipline of detecting and responding to identity-based attacks, see identity threat detection and response (ITDR); for the behavioral baselining that flags an anomalous federated login, see identity analytics; and for the full technique taxonomy, see MITRE ATT&CK.

Multi-cloud compliance as a cross-provider evidence problem

In multi-cloud, compliance is less a checklist than an evidence problem. The hard part is proving consistent control coverage across providers that each emit different native evidence in different formats. How do multi-cloud deployments affect compliance audits and reporting? They multiply the work — every control must be demonstrated separately per provider unless you unify the evidence.

That is the case for unified logging beyond detection. When telemetry is normalized into one place, you can test a control once and produce cross-provider audit evidence from a single source — "test once, comply many." Which framework is most commonly used for multi-cloud security compliance? In practice, organizations anchor to the NIST Cybersecurity Framework and ISO/IEC 27001:2022 as baselines, with EU operators adding NIS2.

Table: Crosswalk of multi-cloud controls to major frameworks.

For EU and UK operators, the timing is live. NIS2 is now fully enforceable, and per ENISA's NIS2 technical implementation guidance, the first-audit deadline moved to 30 June 2026. A multi-cloud program that can produce unified evidence ahead of that deadline is in a far stronger position than one assembling provider-by-provider reports by hand. For the broader program view, see compliance and, for data-protection specifics, GDPR compliance.

Reducing tool sprawl and cost

Running a separate managed detection, SIEM, or NDR stack for each control point is expensive, and it creates the very seams attackers exploit. The consolidation path is straightforward in concept: inventory the per-provider tools you run today, map the overlaps, and consolidate the redundant point tools into one unified detection layer. The outcome is fewer consoles, fewer blind spots, and a lower total cost.

The cost argument and the security argument are the same argument. Per the Ponemon Institute's Cost of a Data Breach study (2024 report), multi-environment breaches reached USD 5.05 million and ran to 283 days of dwell time — driven in part by the fragmented visibility that tool sprawl produces. Consolidation shortens that window, which is where the savings come from. It is why the overlapping-tools problem belongs in a budget conversation as much as a security one.

Data protection is a related discipline that deserves its own treatment rather than a paragraph here — for the specifics of multi cloud data security, follow the dedicated resource.

Modern approaches to multi-cloud security

What should you look for in a modern multi-cloud security approach? The capabilities that matter map directly to the gaps above:

• Unified cross-cloud visibility so every provider feeds one picture.
• Identity-centric detection that treats federated identity as the primary attack path.
• Consolidated SIEM, XDR, and NDR ingestion rather than per-provider silos.
• AI-assisted triage that correlates cross-cloud signal and cuts alert noise.
• Consistent policy and compliance evidence across providers.

Buyers will also expect posture capabilities — cloud security posture management (CSPM), cloud workload protection (CWPP), and cloud infrastructure entitlement management (CIEM). Those are table stakes, and the category definitions live in our cloud detection and response guide rather than being redefined here.

Several trends are shaping the next 12 to 24 months. AI now sits on both sides of the fight — powering more convincing phishing lures and assisting defenders with triage and correlation. Identity has moved from one risk among many to the primary attack path, with identity weaknesses cited in roughly 90% of 2025 incident-response investigations (Unit 42 research). And per-provider control-plane vulnerabilities keep arriving on a steady cadence; the Zero Day Initiative's May 2026 review catalogued a wave of critical Azure cloud-service CVEs, a reminder that a multi-cloud program has to track exposure across every provider's control plane at once. A Zero Trust posture — verify explicitly, enforce least privilege — is the architectural baseline that makes the rest workable. For a single-provider example of native detection tooling, see AWS threat detection; for the workload and container layer, see Kubernetes security.

How Vectra AI thinks about multi-cloud security

Vectra AI starts from a simple premise: the modern network is one attack surface that spans on-premises, multi-cloud, identity, and SaaS — so resilience comes from unified observability, AI-driven attack signal, and informed action rather than from another provider-specific console. Under the Assume Compromise philosophy, the goal is not to claim attackers will never get in but to ensure that when a federated cross-cloud pivot happens, Attack Signal Intelligence surfaces it as one correlated attack story instead of two unrelated console events — turning scattered, provider-siloed alerts into a single signal a small team can act on.

Conclusion

Multi-cloud security is not about hardening each provider in isolation. It is about closing the gaps between providers — the inconsistent identity models, the fragmented logs, and the federation trust that lets an attacker move from one cloud to another while each console sees only a fragment. The organizations that handle multi cloud security well treat their providers as one attack surface: they normalize telemetry into a single detection model, correlate identity activity across clouds, and produce unified evidence that satisfies auditors once instead of provider by provider.

The threat substrate underneath this — cross-cloud identity abuse — is accelerating, and tool spend alone has not closed the gap. The path forward is unification: one picture, one signal, one response. To see how unified, identity-aware detection brings a cross-cloud attack into focus as a single correlated story, explore Vectra AI's approach to cloud detection and response.

‍