"Multi-cloud" rarely happens by strategy deck. It happens by acquisition, by a team that prefers Azure, by a data-residency rule that forces a second provider. However it arrives, the security result is the same: three different identity systems, three logging dialects, and three sets of defaults — with attackers shopping for whichever one your team understands least.

These are the pitfalls that show up again and again in real multi-cloud breaches, and the controls that close them.

Pitfall 1: Over-Privileged IAM Roles and Inactive Service Accounts

Cloud identity is the new security perimeter. In multi-cloud setups:

  • Engineers often attach broad wildcard permissions (Action: "*") to unblock deployments.
  • Inactive developer service keys remain valid indefinitely on developer workstations.
  • Solution: Implement automated IAM access analyzers and enforce maximum 1-hour session lifetimes on assumed roles.

Pitfall 2: Exposure of Instance Metadata Services (IMDS)

The SSRF attack that led to the famous Capital One breach exploited AWS IMDSv1.

  • In IMDSv1, an attacker who triggers an SSRF vulnerability can query http://169.254.169.254/latest/meta-data/iam/security-credentials/ and steal temporary IAM tokens.
  • Solution: Mandate IMDSv2 globally using service control policies, which requires a pre-negotiated HTTP PUT token handshake.

Pitfall 3: Inconsistent Logging Across Clouds

When an incident strikes, correlating CloudTrail (AWS), Activity Logs (Azure), and Cloud Audit Logs (GCP) into a single timeline is a nightmare without centralized normalization.

  • Ingest all cloud telemetry into a unified SIEM with standardized Common Event Format (CEF) or Open Cybersecurity Schema Framework (OCSF).

Pitfall 4: Public Storage and Forgotten Test Resources

Every cloud has its version of the same accident: a storage bucket, blob container, or snapshot made public "temporarily" during a migration and never locked down again. Attackers scan for these continuously with automated tooling, so exposure windows are measured in minutes. The countermeasure is boring and total: organization-level policies that make public sharing impossible by default (AWS Block Public Access, Azure's equivalent controls, GCP org policies), plus CSPM tooling that alerts on any drift within the hour.

Pitfall 5: Three Consoles, Zero Unified Guardrails

Policy written in one cloud does not teleport to the others. Teams that stay safe treat the guardrails themselves as code: a single Terraform or policy-as-code repository that expresses the baseline — encryption at rest, no public ingress on admin ports, IMDSv2 enforced, flow logs on — and applies it per provider. Drift detection then compares reality against that repository, in all three clouds, every day.

Where to Start This Quarter

If you inherit a multi-cloud estate tomorrow, do these in order: (1) inventory every account, subscription, and project — you cannot secure what is not listed; (2) kill standing human access to production in favor of just-in-time elevation; (3) centralize logs into one SIEM with normalized schemas; (4) turn on the native posture scanners (Security Hub, Defender for Cloud, Security Command Center) and fix the top ten findings. That sequence closes the holes behind nearly every public multi-cloud breach write-up.

One Breach Pattern, Three Clouds

Read enough cloud incident reports and a single storyline repeats with different logos. A developer's long-lived access key leaks — in a GitHub repo, a stealer log, a CI artifact. The attacker enumerates permissions, finds an over-privileged role, and pivots to storage. Data leaves quietly over days. Only then does encryption or extortion begin. Notice what is absent: no zero-day, no exotic malware. The controls that break this story are the ones in this article — short-lived credentials, least-privilege roles, IMDSv2, centralized logging, public-access blocks — applied uniformly across every cloud you run. Attackers do not care which logo is on the console; they care which console your team watches least. Multi-cloud security is, in the end, an argument for boring consistency.

Key Takeaways

  • Cloud identity is the perimeter; over-privileged roles and stale keys are the top risk.
  • Enforce IMDSv2 everywhere — the SSRF-to-credential-theft path is well worn.
  • Normalize AWS, Azure, and GCP logs into one SIEM timeline, or investigations stall.
  • Express guardrails as code once, apply them per cloud, and scan for drift continuously.