Notifications
Clear all
Topic starter
23/06/2026 9:08 pm
TL;DR: Fragmentation makes multi-cloud governance harder to enforce at scale, as IDQL and Hexa aim to coordinate consistent identity policy across cloud platforms and the wider stack according to Strata Identity. The practical shift is from isolated policy decisions to orchestration across environments, which changes how teams think about compliance, access consistency, and cross-cloud control boundaries.
NHIMG editorial — based on content published by Strata Identity: Governance and standards guidance on IDQL and Hexa policy orchestration
Questions worth separating out
Q: How should teams govern identity policy across multiple cloud platforms?
A: Teams should govern multi-cloud identity policy through a consistency model, not by duplicating rules in every console.
Q: Why do multi-cloud IAM programmes create compliance risk?
A: Multi-cloud IAM creates compliance risk because each platform can interpret identity policy differently, even when the written rule looks identical.
Q: What breaks when policy orchestration is missing in hybrid identity estates?
A: Without policy orchestration, teams end up managing equivalent identity rules separately in each environment.
Practitioner guidance
- Map policy translation points across clouds Inventory where identity policy is transformed, duplicated, or manually re-entered across cloud platforms, then identify the specific controls that lose meaning during translation.
- Test for equivalent access outcomes Run the same access scenario across each cloud environment and compare the result, audit trail, and exception handling.
- Reduce manual exception handling Track every policy exception that bypasses standard enforcement and classify whether it exists because of platform limitations, ownership gaps, or inconsistent identity primitives.
What's in the full article
Strata Identity's full article covers the operational detail this post intentionally leaves for the source:
- How Hexa maps IDQL policy intent into enforceable cloud controls
- The developer and architect workshop context behind the IDQL working group
- The practical mechanics of building from zero to a standard with IDQL and Hexa
- Why policy orchestration is positioned as the coordination layer for multi-cloud environments
👉 Read Strata Identity's guide to IDQL and Hexa policy orchestration →
IDQL and Hexa for multi-cloud IAM: what changes for teams?
Explore further
25/06/2026 2:16 am
IDQL is a policy consistency problem, not a policy creation problem. The central issue in multi-cloud IAM is rarely that organisations lack policy language. It is that the same policy intent is interpreted differently across platforms, which creates governance drift and audit inconsistency. IDQL matters because it addresses the enforcement gap between central intent and distributed cloud controls. Practitioners should see orchestration as the missing layer between policy definition and policy outcome.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
A question worth separating out:
Q: What is the difference between centralised policy and policy orchestration?
A: Centralised policy stores the rule in one place, but policy orchestration ensures the rule is applied consistently across different environments. Orchestration is about preserving meaning through translation and enforcement, which matters when cloud platforms expose different identity primitives and audit models.
👉 Read our full editorial: IDQL and Hexa point to policy orchestration for multi-cloud identity
