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.
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 a lot of the incidents that get reported after the fact: not a single dramatic failure, but a gap between two systems that 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 exactly the kind of overlooked resource that shows up again and again in misconfiguration-driven incidents. The problem isn’t that any one team did something careless. It’s that nobody had a complete picture of what existed across all the 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, retained for different lengths of time. A security team that built its detection pipeline around one provider’s logging conventions can have real blind spots into the others, and the gap often isn’t obvious until an investigation reveals that the data needed simply isn’t there, or was deleted before anyone thought to look for it.
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.
Logging standards applied consistently on purpose, rather than inherited by accident from whatever each provider happens to default 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. It’s part of why red team engagements increasingly include cross-cloud scenarios specifically, rather than testing each environment in isolation the way 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 are going to grow out of. The mistake isn’t running multiple clouds. It’s assuming that securing each one separately adds up to securing all of them together. It doesn’t, and the gap in between is exactly where the next quiet incident is most likely to start.
(Image by Suresh Anchan from Pixabay)
