Multi-cloud: risk sometimes lives between the clouds

An organisation can secure each of its cloud environments correctly and still end up with an architecture that is difficult to control.

Azure has its rules.

AWS has its own.

GCP has its own.

A fourth provider may host selected workloads or backups.

Taken separately, each environment can appear coherent.

But the business application does not stop at a provider boundary.

In August 2026, NIST published a draft report focused on exactly this issue. Its Multi-Cloud Security Public Working Group identified 23 challenge areas that emerge or become significantly more important when autonomous cloud silos must work together.1

The architectural conclusion is important: multi-cloud risk does not only live inside each cloud. It also lives between them.

Three clouds do not automatically create one architecture

Consider an organisation using:

Entra ID → identity

AWS → applications

GCP → data and AI

a European provider → backups or specialised workloads

From the business perspective, this may deliver one service.

Technically, however, it spans several environments with their own IAM models, logs, network services, encryption mechanisms, roles, APIs, consoles, policies and shared-responsibility models.

The problem is therefore not just operating several clouds.

It is building coherent control above systems that were designed to be autonomous.

NIST identifies 23 friction areas

NIST IR 8613 analyses security and authorization challenges that are unique to, or significantly amplified by, multi-cloud architectures.1

The working group consolidated them into 23 areas.

Three structural issues stand out: meaningful differences between cloud-native services, organisational and staffing complexity across heterogeneous environments, and difficulty implementing centralised security capabilities across provider boundaries.1

These gaps are especially acute in five domains:

IAM

telemetry and logging

configuration and change management

data protection

compliance and authorization

These domains share one characteristic: they need to work across provider boundaries.

IAM is coherent until the next boundary

Imagine Entra ID is the organisation’s primary identity source.

A user authenticates and then reaches AWS through federation.

Inside AWS, that identity becomes a role.

The role provides access to an application.

The application then calls an API hosted elsewhere.

The chain becomes:

user → Entra ID → federation → AWS role → application → external API

Every step has its own authorization model.

A user review in Entra ID therefore does not necessarily describe effective permissions in AWS.

A review of AWS roles does not necessarily explain the origin of the identity.

The question becomes:

“Can we reconstruct the complete authorization chain from user to final resource?”

Federated architectures are not new. In 2020, NIST already described cloud-federation models organised around trust, security and resource-sharing planes.2

Modern multi-cloud simply multiplies the number and diversity of these relationships.

Four logging consoles do not create a cross-cloud timeline

The second issue is observability.

Each provider can generate excellent logs.

But an incident does not necessarily respect provider boundaries.

An event may follow:

identity → cloud A → API → cloud B → database

If each step is recorded in a different platform with different timestamps, identifiers, formats, retention rules and teams, the organisation can have plenty of logs without having a usable incident timeline.

The problem is no longer collection alone.

It is correlation.

Shared responsibility is distributed too

In a single cloud, shared responsibility can already require careful analysis.

In multi-cloud, the organisation has to combine several versions of it.

One component may be IaaS with one provider, PaaS with another and SaaS elsewhere.

For a single business function, responsibility for the operating system, database engine, identity or underlying infrastructure may be allocated differently.

The useful question is therefore no longer simply:

“Who is responsible for this service?”

but:

“Who is responsible for every control required by the complete service chain?”

A change in one cloud can break another

Configuration is another major friction area.

A change to routing, certificates, network rules, IAM roles or APIs can have consequences outside the provider where it was made.

Consider:

AWS application → GCP API

If the GCP team changes an access policy, the AWS service may become unavailable.

If AWS changes a certificate or egress address, GCP may no longer accept the call.

Both environments can remain individually compliant with their internal standards while creating a failure together.

The relevant dependency is:

configuration A → dependency B → behaviour C

This is exactly the kind of relationship that becomes difficult to document consistently across providers.

Data has several geographies

Multi-cloud also complicates a seemingly simple question:

where is this data?

Data can be created in one cloud, processed in a second, cached in a third and backed up in a fourth.

The real path becomes:

source → processing → storage → replication → backup

Each step can have its own location, jurisdiction, encryption policy, keys, retention rules and deletion mechanisms.

Governance is therefore not only about identifying the primary provider.

It requires reconstructing the path of data across providers.

The system boundary becomes harder to define

NIST highlights a particularly important issue: authorization processes traditionally depend on clear system boundaries, network architecture, security documentation and control enforcement.1

In multi-cloud, that boundary can become unclear.

Is the system:

the AWS account?

the Azure tenant?

the GCP project?

the business application?

the complete technical chain needed for it to function?

For governance and risk analysis, the last definition is often the most useful.

It is also the hardest to document.

NIST itself used graph-based dependency analysis

The NIST Multi-Cloud Security Public Working Group explored graph-based analysis of multi-cloud challenges.

Its approach represents issues as nodes and relationships as edges describing dependency, causality, conflict and amplification.3

That idea is particularly useful for architecture.

“Heterogeneous IAM” is not an isolated issue.

It can amplify fragmented logging, authorization complexity, configuration management and organisational complexity.

Multi-cloud risk therefore looks less like a list of 23 independent boxes and more like a graph of interdependent problems.

Constructed case: one business service across four providers

Consider a fictional document-management service.

Employees use Entra ID.

The application runs in AWS.

A document-analysis engine runs in GCP.

Backups are stored with a European provider.

The path becomes:

user → Entra ID → AWS → application → GCP API → data → external backup

Separate assessments might conclude that every environment is correctly configured.

Yet several questions remain:

who can trace identity end to end?

who owns the complete incident timeline?

where is data located at every step?

which changes can break a dependency?

which team owns the interface between two clouds?

what happens if one provider becomes unavailable?

No individual provider can answer these questions alone.

The useful map is the map of interfaces

A multi-cloud representation can start with:

business service → application → cloud → account/project/tenant → service → data → identity → flow → next cloud

But the interfaces matter most:

identity A → role B

workload A → API B

data A → replication B

log A → SIEM B

configuration A → dependency B

team A → responsibility for B

These boundaries are where inconsistencies become visible.

Teams are multi-cloud dependencies too

Complexity is not purely technical.

NIST also highlights organisational logistics and staffing complexity in heterogeneous environments.1

An organisation may have an Azure team, an AWS team, a data team, a security team, a SOC and several integrators.

Each team may understand its perimeter very well.

But who understands the complete chain?

An architecture can therefore be technically documented while remaining organisationally fragmented.

Another useful relationship is:

component → owner → team → intervention capability

This becomes especially important during incidents.

Multi-cloud can increase resilience and complexity at the same time

Using several providers can support legitimate goals: reducing dependencies, accessing specialised services, meeting sovereignty constraints, spreading risk or supporting different business needs.

NIST IR 8613 does not say multi-cloud is inherently bad.

It identifies the friction introduced when independent environments must be governed as a single system.1

That distinction matters.

The question is not:

“Should we avoid multi-cloud?”

but:

“Do we have the mechanisms to see and govern what happens between our clouds?”

The European context reinforces the value of this visibility: ENISA describes increasingly interconnected digital ecosystems and continues to assess the maturity of high-criticality sectors under NIS2.45

Five simple tests

For a genuinely multi-cloud application, five exercises quickly reveal how much control the organisation has.

1. Identity: start with a user and reconstruct permissions all the way to the final resource.

2. Incident: start with an event and rebuild the full timeline across providers.

3. Data: start with a data item and identify every place where it is stored, processed or copied.

4. Change: simulate a critical configuration change and identify every component that could be affected.

5. Responsibility: choose an interface between two clouds and identify the team that truly owns it.

If these answers require days of investigation, the issue is probably not a lack of information.

It is a lack of cross-cloud visibility.

The real object to secure is the service, not each cloud

A multi-cloud architecture is not controlled simply because each provider is individually secure.

Users do not consume tenants, subscriptions or projects.

They consume services.

And those services may cross several providers.

The useful shift is therefore from:

cloud A + cloud B + cloud C

to:

business service → all of its dependencies, regardless of provider

The central lesson from NIST IR 8613 may be this: in a multi-cloud architecture, the boundaries between clouds become security-architecture components in their own right.