Multi-cloud assurance

The multi-cloud problem is fragmented truth.

What NIST IR 8613 reveals about provider boundaries, inconsistent controls and disconnected evidence, and how Statepoint is designed to address them.

Statepoint Research3 September 2026 6 min read

Multi-cloud security is not difficult simply because an organisation uses more than one cloud. It is difficult because every provider describes assets, identities, controls, telemetry and responsibility through a different operating model. The result is not a shortage of findings. It is a shortage of connected, comparable truth.

01 · The NIST paper

A map of the problem, not a product checklist.

NIST IR 8613, Multi-Cloud Architecture Challenges: Security and Compliance Implications, was published as an Initial Public Draft in August 2026. It identifies 23 challenge areas that arise or become materially harder when security and authorisation span autonomous cloud providers.

The paper highlights structural differences between provider-native services, the difficulty of centralising security capabilities, and the organisational effort required to govern heterogeneous environments. These problems become particularly visible across identity, telemetry, configuration, data protection, compliance and system authorisation.

Draft status

NIST IR 8613 is descriptive and vendor-neutral. It does not define a certification programme, prescribe a reference implementation or establish a product compliance claim.

02 · Fragmented truth

The same security word can describe different realities.

Two providers may offer services with similar names while differing in policy semantics, evidence availability, enforcement boundaries and shared-responsibility assumptions. A control that is directly observable in one environment may be inherited, provider-attested or only partially testable in another.

A common security objective does not imply an identical technical implementation across every cloud.

This distinction matters. A central dashboard can collect findings from many providers and still leave the organisation without a coherent account of what is protected, how it is protected, who owns the control and which evidence supports that conclusion.

03 · Common intent

Normalise the decision, not the provider.

The useful abstraction is a shared security intent and evidence contract. Provider-specific implementation should remain visible beneath it. This allows teams to compare outcomes without pretending that an Azure control, an AWS control and a Google Cloud control are interchangeable.

01IntentRequired security outcome

02ImplementProvider-native control

03EvidenceObserved or inherited proof

04DecideGap, action and ownership

Where equivalent implementation is impossible, the model should expose the difference, identify a compensating control and record the residual divergence. That is more defensible than forcing every provider into one configuration vocabulary.

04 · Statepoint alignment

One evidence layer across distinct cloud systems.

Statepoint's product architecture has a natural place for the high-impact challenges described by NIST. Within Statepoint.Operate, asset inventory establishes what exists. Identity connects permissions and privilege. Compliance maps common intent to provider-aware controls. Operations contributes current state. Security contributes exposure and validated test evidence. Assurance connects those facts into explainable paths, decisions and investigations.

Illustrative capability viewNIST IR 8613 and Statepoint

Product assessment

Asset inventoryAssets and connected evidenceUnified inventory context

IAM and authenticationIdentity relationships and privilege pathsCross-provider access context

Incident detectionOperations, signals and InvestigationsConnected response context

Policy consistencyCompliance and provider-aware controlsCommon intent, native controls

System boundariesScope, relationships and Assurance GraphVisible ownership and scope

Threat modellingGraph, Paths, ATT&CK and D3FENDEvidence-backed path context

This is an architectural comparison, not a compliance score. It shows how the challenge areas relate to Statepoint evidence, context and decision surfaces.

05 · Correlation

The relationships carry the meaning.

A public API in one cloud, an over-permissive identity relationship in another and a vulnerable workload elsewhere may form one material attack path. Reviewing each finding in isolation hides the combined condition.

Statepoint's graph and attack-path capabilities connect assets, identities, permissions, configurations, exposures, controls and investigations. For the result to remain trustworthy, every relationship should explain why it exists, which evidence supports it, whether it was observed or inferred, what preconditions apply, how current the evidence is and which control can interrupt the path.

Multi-cloud assurance becomes useful when a team can move from a disconnected signal to an evidence-backed decision across provider boundaries.

06 · Our perspective

Preserve the differences that matter.

Statepoint should not promise one identical control implementation across every cloud. Its stronger role is to create one security intent, evidence and relationship model while preserving provider-specific implementation truth.

That model can reveal cross-cloud gaps, dependencies, attack paths, responsibilities and evidence limitations. It can also make missing or contradictory evidence visible instead of allowing it to appear as a healthy condition.

Scope note

This article discusses how Statepoint's architecture relates to challenges described in the Initial Public Draft of NIST IR 8613. It does not claim NIST certification, endorsement or compliance. The publication remains a draft and may change following public review.

Sources

NIST · IR 8613 Initial Public Draft NIST · Draft IR 8613 available for public comment