What Is Multi-Cloud Security?

Very few organisations chose to be multi-cloud. They acquired a company running somewhere else, bought a product hosted elsewhere, let a research group open an account for a grant, or adopted a second provider for one service that was better there.

The security problem that follows is not the number of clouds. It is the variation between them — different identity models, different logging, different vocabulary for the same control, and expertise concentrated in one provider while two others are administered by guesswork.

Identity consolidation is the highest-value move

The single most valuable control across multiple clouds is one identity provider federating to all of them. It gives one place to grant access, one place to review it and — critically — one place to revoke it.

Without that, offboarding requires remembering every provider, and the one nobody remembers is invariably the one the departing engineer set up themselves. Separate local accounts per cloud mean separate joiner-mover-leaver processes, each with its own chance of being missed.

Normalise outcomes, not configurations

Each provider names things differently and implements comparable controls in dissimilar ways. Forcing identical configurations wastes effort; the goal is equivalent outcomes, measured consistently.

“Is public storage access blocked everywhere” should be answerable from one place, without opening three consoles and translating three vocabularies. That is the practical argument for a cross-cloud posture tool, and it matters more than any individual feature comparison.

Log consolidation follows the same logic. Each cloud emits audit logs in its own format with its own default retention — at least one of which is shorter than most regulatory expectations. Investigating an incident that crosses providers while pivoting between three consoles is where the time goes.

The expertise problem is the real constraint

Each provider is a specialism. A team genuinely strong in one is usually adequate at the second and guessing at the third, and guessing is what produces the misconfigurations that cause incidents.

The honest options are to consolidate providers, concentrate expertise by naming an owner per cloud, buy the gap for the one you are weakest in, or restrict what runs where. That last one is underused and costs nothing: if a research group's account is the least well understood, it should not be where sensitive data lives.

Skills concentration beats broad shallow coverage

The instinct when running three clouds is to train everyone on all three. In practice that produces a team with shallow knowledge everywhere and deep knowledge nowhere, which is precisely the condition that generates misconfiguration.

Naming an owner per provider works better. That person becomes genuinely capable in one environment, knows its failure modes, and can review changes meaningfully. Cross-training then provides cover rather than being the primary model.

Where you cannot staff an owner for a provider, the honest options are to buy that expertise or to stop running sensitive workloads there. Continuing to operate an environment nobody understands well, because it was inherited or convenient, is the arrangement that produces the incidents.

Where to start

List every cloud account your organisation pays for, including departmental ones, and check which are federated to your identity provider. The unfederated accounts are where the risk concentrates.

See managing risk across platforms. GuardsArm delivers cloud security assessment.