IDQL and Hexa point to policy orchestration for multi-cloud identity

At a glance

What this is: This is Strata Identity's guide to IDQL and Hexa, with the core finding that policy orchestration is needed to keep identity controls consistent across multi-cloud environments.

Why it matters: It matters because IAM, IGA, and security teams cannot rely on platform-by-platform policy drift if they want consistent access governance across cloud, hybrid, and workload identity programmes.

👉 Read Strata Identity's guide to IDQL and Hexa policy orchestration

Context

IDQL is a policy orchestration approach for identity that tries to keep access decisions consistent across cloud platforms instead of letting each environment drift on its own. In a multi-cloud estate, the control problem is not only where identities exist, but whether the same policy intent is enforced the same way across systems.

For IAM and governance teams, that makes the issue broader than technical integration. It touches NHI lifecycle controls, compliance enforcement, and the practical limits of writing one policy once and expecting it to behave uniformly everywhere. Strata Identity frames Hexa as the reference software layer that makes that orchestration operational.

Key questions

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. The key test is whether the same policy intent produces the same access outcome, audit trail, and exception handling across environments. If it does not, the programme has policy drift rather than governance.

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. That produces inconsistent enforcement, fragmented audit evidence, and local exceptions that are hard to reconcile during review. The risk is variance in control outcome, not just administrative complexity.

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. That breaks control equivalence, makes exceptions harder to track, and increases the chance that one cloud enforces a rule differently from another. Over time, governance becomes documentation-heavy but operationally inconsistent.

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.

Technical breakdown

How IDQL coordinates policy across cloud platforms

IDQL is intended to express identity policy once and apply it consistently across different cloud environments. The point is not to replace identity providers, but to reduce policy fragmentation when organisations run multiple clouds with different enforcement models, data structures, and entitlement semantics. Hexa is presented as the operational layer that makes those policies executable across the stack. That matters because multi-cloud IAM problems are often caused by policy translation gaps, not just missing controls. When the same intent is interpreted differently by each platform, access decisions become inconsistent even when governance exists on paper.

Practical implication: map where policy translation occurs today and identify which enforcement points are creating inconsistent outcomes.

Why multi-cloud identity policy drifts out of control

Multi-cloud estates create policy drift because each platform tends to develop its own access model, administrative workflow, and audit evidence trail. Over time, teams accumulate equivalent controls that do not behave equivalently. That creates compliance risk, because a policy that appears standardised in documentation may be enforced unevenly in practice. The governance challenge is therefore less about having an IAM policy and more about proving that the same policy outcome holds across environments. IDQL addresses the orchestration problem by focusing on consistency of enforcement rather than environment-specific administration.

Practical implication: test whether one access decision produces the same result across clouds, not just whether the same policy text is reused.

What Hexa changes in the identity control plane

Hexa is positioned as reference software that operationalises IDQL by coordinating policy execution. In identity terms, that means it sits between policy intent and platform-specific enforcement, helping translate governance into action. This is especially relevant where organisations need consistent access rules for heterogeneous cloud services, federated identities, and distributed policy owners. The architectural value is not in adding another policy layer for its own sake, but in reducing the gap between central governance and local enforcement. That gap is where compliance failures often emerge in complex estates.

Practical implication: treat orchestration as a control-plane requirement and evaluate whether your current architecture can enforce intent without manual exceptions.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Policy orchestration becomes a control requirement when identity spans multiple clouds. Once access governance crosses clouds, the old assumption that one platform team can own one complete policy model breaks down. Different clouds expose different primitives, so governance needs a translation layer that preserves meaning across environments. The implication is that IAM programmes must evaluate consistency of enforcement, not just completeness of policy documentation.

Hexa represents the operationalisation of governance intent, not a new identity model. The useful framing here is not that organisations need another standard to learn, but that they need a way to make standards behave predictably across heterogeneous infrastructure. That puts the focus on interoperability, policy mapping, and auditability. Practitioners should judge tools by whether they reduce cross-cloud policy variance.

Compliance in global cloud estates depends on control equivalence, not control repetition. Repeating the same rule in multiple consoles does not create equivalent governance if each platform enforces it differently. This is where multinational identity programmes often fail under audit pressure. The practical lesson is to test for equivalent outcomes across jurisdictions and platforms, not identical administrative steps.

Named concept: policy orchestration variance. This is the gap between a policy written once and the same policy behaving the same way everywhere. In IDQL-style architectures, the variance problem is the real governance risk because it turns consistency into an assumption rather than an outcome. Practitioners should measure whether orchestration actually removes variance, not whether it simply centralises policy text.

From our research:

• 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.
• For a broader lifecycle view, read NHI Lifecycle Management Guide for the operational controls that policy orchestration still has to support.

What this signals

Policy orchestration variance: multi-cloud IAM programmes fail when the same policy produces different results across clouds, because governance intent is not the same as governance outcome. The next maturity step is to measure control equivalence across platforms, not just policy reuse in templates.

The practical signal for identity teams is that orchestration will matter most where policy consistency intersects with NHI lifecycle, exceptions, and auditability. As estates expand, the organisations that can prove repeatable enforcement will be better positioned to align with the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10.

For practitioners

• 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. Use the result to define which enforcement points need orchestration.
• Test for equivalent access outcomes Run the same access scenario across each cloud environment and compare the result, audit trail, and exception handling. The goal is to prove control equivalence, not just policy similarity.
• 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. Exceptions that persist become governance debt.
• Align compliance evidence to the control plane Tie audit evidence to the actual policy enforcement layer rather than to local administrative screenshots or platform-specific reports. That makes it easier to show that identity controls behave consistently across environments.

Key takeaways

• IDQL is best understood as a response to policy drift across multi-cloud identity environments, where the same rule can behave differently by platform.
• The governance risk is control variance, because repeating policy text does not guarantee equivalent enforcement or audit evidence.
• Practitioners should focus on policy orchestration, exception reduction, and outcome testing if they want consistent identity governance across clouds.

Key terms

• Policy Orchestration: Policy orchestration is the coordination layer that ensures identity rules are applied consistently across different platforms and control planes. It matters when each cloud or system uses different primitives, because the challenge becomes preserving policy meaning during translation and enforcement, not just storing the rule centrally.
• Control Equivalence: Control equivalence means the same governance intent produces the same security outcome in every environment where it is enforced. In multi-cloud identity programmes, equivalence is stronger than documentation parity because it tests whether the access result, audit trail, and exception path are actually aligned.
• Policy Drift: Policy drift is the gradual divergence between intended identity governance and what different systems actually enforce. It often appears when teams duplicate controls across clouds without a shared orchestration layer, leaving similar policies to behave differently and creating compliance and audit risk.
• Identity Control Plane: The identity control plane is the layer where policy intent is translated into enforcement across identities, access rules, and audit outputs. In orchestration architectures, it is the operational boundary that determines whether governance remains consistent or fragments into platform-specific administration.

Deepen your knowledge

Policy orchestration for multi-cloud identity is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is dealing with cross-cloud policy drift or inconsistent enforcement, this is a practical place to build the baseline.

This post draws on content published by Strata Identity: Governance and standards guidance on IDQL and Hexa policy orchestration. Read the original.