Most enterprises didn’t choose multi-cloud as a deliberate strategy. They ended up there: an acquisition brought in a company already running on a different provider, one team picked Amazon Web Services (AWS) because that’s what they knew, another spun up projects in Microsoft Azure because it bundled with existing licensing, and a third quietly built things in Google Cloud Platform (GCP) because a developer liked the tooling.[1] Nobody sat down and designed this. And nobody ended up owning the gaps between the pieces. That’s the actual risk. Not any single cloud provider, but the seams where they meet.
Why the seams are the problem: Each cloud provider has its own identity and access management (IAM) model, its own default settings, its own way of structuring permissions and resources. A security policy that’s airtight in AWS doesn’t automatically carry the same meaning in Azure, even when the two look conceptually similar on paper.
Teams that assume parity across providers, treating “we locked this down in one cloud” as equivalent to “we locked this down everywhere,” are often wrong without realizing it, because the underlying models simply don’t map one to one.
This isn’t a hypothetical concern. It’s the quiet reality behind many incidents reported after the fact: not a single dramatic failure, but a gap between two systems nobody was responsible for checking.
Shadow resources nobody’s tracking - When different teams provision infrastructure in different clouds independently, asset inventories fall out of sync fast. A test environment spun up in one provider for a project that ended months ago doesn’t disappear on its own.
It sits there, outside whatever dashboard the security team actually watches, until it becomes the kind of overlooked resource that keeps showing up in misconfiguration-driven incidents. The problem isn’t that any one team did something careless. Nobody had a complete picture of what existed across all environments at once.
Inconsistent logging means inconsistent detection - Visibility is the other casualty of multi-cloud sprawl. Different providers log different events by default, in different formats, and retain them for different lengths of time. A security team that built its detection pipeline around one provider’s logging conventions can have real blind spots in the others, and the gap often isn’t obvious until an investigation reveals the needed data simply isn’t there, or was deleted before anyone thought to look.
Why this calls for cross-provider thinking, not provider-specific expertise - This is exactly the problem that a credential built around reasoning about cloud security across providers, rather than mastering one platform’s console, is meant to address. The Certified Cloud Security Professional (CCSP) credential from the International Information System Security Certification Consortium (ISC2) covers six domains, including cloud platform and infrastructure security and cloud data security, built specifically around the idea that “cloud security” isn’t one skill tied to one vendor; it’s a way of thinking that has to hold up regardless of which provider is in play. “The seams between clouds are where most of this risk actually lives, not inside any single provider,” says Rob Witcher, co-founder of Destination Certification. “A team can be excellent at securing AWS and excellent at securing Azure separately and still have a massive gap in between, because nobody’s job is to look at the two together.” That’s the gap CCSP training is actually built to close: not provider-specific know-how, but the judgment to see risk across all of them at once.
What actually closes the gap: None of this requires abandoning multi-cloud or consolidating onto a single provider, which usually isn’t realistic anyway once an organization has grown into it. It requires a few deliberate changes: a consolidated view that shows assets and configurations across every provider in one place, rather than three separate dashboards nobody cross-references.
Apply logging standards consistently on purpose, rather than inheriting them by accident from whatever each provider defaults to. And a named owner for cross-cloud risk specifically, someone whose job is to look at the seams, rather than three separate teams each assuming the gap between their clouds is someone else’s problem.
Testing whether those gaps are actually exploitable, rather than just assuming the controls work, is also worth doing before an attacker finds out first. That’s why red team engagements increasingly include cross-cloud scenarios, rather than testing each environment in isolation as they used to.
Multi-cloud isn’t going away - The underlying goal across all of this is less about any single control and more about building genuine resilience into an environment that’s inherently more fragmented than a single-cloud setup ever was. Multi-cloud isn’t a phase most enterprises will grow out of. The mistake isn’t running multiple clouds. It’s assuming that securing each one separately adds up to securing them all together. It doesn’t, and the gap in between is exactly where the next quiet incident is most likely to start.
This article is shared at no charge for educational and informational purposes only.
Red Sky Alliance is a Cyber Threat Analysis and Intelligence Service organization. We provide indicators of compromise information (CTI) via a notification service (RedXray) or an analysis service (CTAC). For questions, comments, or assistance, please contact the office directly at 1-844-492-7225 or feedback@redskyalliance.com
- Reporting: https://www.redskyalliance.org/
- Website: https://www.redskyalliance.com/
- LinkedIn: https://www.linkedin.com/company/64265941
Weekly Cyber Intelligence Briefings:
REDSHORTS - Weekly Cyber Intelligence Briefings
https://register.gotowebinar.com/register/5207428251321676122
[1] https://hackread.com/multi-cloud-blind-spots-security-teams-exposed/
Comments