IDQL and Hexa aim to unify policy across fragmented cloud estates

At a glance

What this is: IDQL and Hexa are a policy orchestration model that standardises how access policy is expressed, translated, and distributed across fragmented cloud environments.

Why it matters: It matters because IAM, NHI, and platform teams need a common policy layer when access rules are split across clouds, apps, and infrastructure.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• Only 5.7% of organisations have full visibility into their service accounts.

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

Context

Multi-cloud environments create a policy sprawl problem: every cloud, application layer, identity store, and network control can express access differently, which leaves teams unable to tell which rules are actually in force. IDQL is designed to reduce that fragmentation by defining a common policy language, while Hexa provides the reference implementation that makes translation and orchestration possible across target systems.

For IAM and NHI programmes, the core issue is not only policy complexity but policy drift. When access intent exists in one form and enforcement exists in several incompatible native formats, governance becomes a reconciliation exercise instead of a control discipline. That is why policy portability, not another isolated control plane, is the real topic here. For a broader baseline on machine identity governance, see the Ultimate Guide to NHIs.

Key questions

Q: How should security teams manage policy consistency across multi-cloud environments?

A: Security teams should centralise policy intent, then translate it into each platform only where necessary. The goal is not to standardise every runtime control, but to reduce semantic drift between business rules and native cloud policy syntax. Teams should also assign clear ownership for discovery, translation, and enforcement so audit can trace where policy changes originate and how they are applied.

Q: Why do fragmented cloud policies create identity governance risk?

A: Fragmented policies create governance risk because the same access rule can be written differently in each cloud, application, or network layer. That makes certification, reporting, and exception handling inconsistent. When teams cannot see the full policy picture, they cannot reliably prove least privilege, explain deviations, or detect where a native policy no longer matches the intended rule.

Q: What should organisations check before adopting policy orchestration?

A: Organisations should check whether their entitlement data, role models, and cloud access rules are already clean enough to translate without distortion. If source policy is messy, orchestration will scale inconsistency instead of reducing it. A narrow pilot with one workload or application is usually the safest way to test semantic fidelity before broader rollout.

Q: How does policy as code affect Zero Trust architecture?

A: Policy as code can support Zero Trust by making access intent more portable and consistent across systems, but only if the translated policies preserve the original decision logic. It does not replace runtime enforcement or continuous verification. Teams should use it to reduce policy divergence, not as a shortcut around local enforcement controls.

Technical breakdown

Declarative policy as code across heterogeneous systems

IDQL is a declarative policy language, which means it describes the desired access outcome rather than encoding step-by-step enforcement instructions for each platform. That matters in multi-cloud because native policy languages are usually imperative and proprietary, so the same business rule must be rewritten repeatedly. Hexa sits underneath that layer and translates IDQL into the target system’s native format. The practical value is not abstraction for its own sake. It is reducing the number of places where policy intent can diverge from effective access enforcement.

Practical implication: define policy once in a portable form, then validate where translation introduces drift before expanding it across production systems.

Discovery, translation, and orchestration as one governance loop

Hexa’s model has three stages. Discovery inventories applications, data, users, roles, and existing policies. Translation converts native policies into IDQL during discovery and converts IDQL back into system-specific form during orchestration. Orchestration then distributes policy to identity providers, clouds, IaaS, and network systems without replacing their runtime enforcement. That is a governance loop, not a replacement control plane. Its purpose is to make policy state visible, portable, and consistent across disconnected systems.

Practical implication: map current policy sources before orchestration so you can identify which systems remain authoritative and where policy conversion may alter meaning.

Why policy orchestration matters for zero trust architecture

Zero Trust Architecture depends on continuous, context-aware authorization, but that model breaks down when policy lives in disconnected silos. A universal policy layer helps teams express intent across systems without locking them into each platform’s native policy model. For identity teams, this is especially relevant where workload identities, cloud entitlements, and application permissions all intersect. The technical challenge is less about creating more rules and more about making the same rule legible and enforceable everywhere it matters.

Practical implication: use policy orchestration to support ZTA consistency, but keep runtime enforcement and exception handling under existing target systems.

NHI Mgmt Group analysis

Policy fragmentation is now a governance failure, not just an operational inconvenience. The article describes a world where each cloud and stack layer exposes its own policy syntax, creating a multiplying effect that makes governance difficult to verify. That is exactly the condition where access intent and effective enforcement drift apart. For practitioners, the problem is not too few policies but too many incompatible ones.

Identity policy portability is becoming a control requirement for multi-cloud programmes. A common policy language changes the operating model from platform-by-platform administration to centrally reasoned policy intent. That does not remove the need for local enforcement, but it does reduce the chance that cloud-by-cloud policy differences become invisible to audit and certification. For identity leaders, this pushes policy governance toward standardisation across environments.

Universal policy does not eliminate the need for authoritative systems, but it does expose where authority is fragmented. Hexa’s discovery and translation model makes hidden policy sources visible, which is valuable precisely because most organisations cannot consistently answer who has access to what. In practice, that creates pressure to define which systems own intent, which own enforcement, and which merely mirror policy.

Policy as code is only useful when the underlying identity model is already disciplined. If entitlement data, role design, and cloud access boundaries are messy, codifying them simply scales the mess faster. IDQL and Hexa are therefore best understood as a governance amplifier, not a substitute for access model cleanup. The practitioner implication is that standardisation must start with policy quality, not automation volume.

Standards work matters when it reduces translation debt across identity domains. The strongest value in IDQL is that it aims to create a common grammar for policy across identity, cloud, application, and network layers. That is an important signal for the market: practitioners are looking for portable governance primitives, not another isolated admin interface. Teams should evaluate whether their current policy stack can survive that shift.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• Only 97% of NHIs carry excessive privileges, which is why policy orchestration must be paired with entitlement cleanup rather than treated as a pure translation layer.
• For a broader governance baseline, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for lifecycle, rotation, and offboarding discipline.

What this signals

Policy orchestration will only help programmes that already know where their policy truth lives. If discovery cannot reliably surface applications, roles, and access rules, the orchestration layer becomes another abstraction over uncertainty. Teams should expect policy standardisation to expose governance debt before it reduces it.

Identity portability is becoming a programme design issue, not just a tooling preference. Multi-cloud operating models need policy intent that can travel without being rewritten from scratch, especially where NHI and cloud entitlements intersect. That makes common policy grammar a practical requirement for IAM and platform teams.

The hidden risk is not simply policy inconsistency but unreviewable policy drift, where native cloud rules slowly diverge from intended access intent. Teams that pair orchestration with entitlement review and lifecycle governance will be better positioned to use a common policy layer without losing control.

For practitioners

• Inventory every current policy source Map native policy locations across cloud platforms, identity providers, apps, and network layers before introducing orchestration so you know where drift begins.
• Define policy ownership boundaries Assign one system to own policy intent and separate that from systems that enforce or mirror it, especially where cloud teams and identity teams both edit access rules.
• Pilot translation on a narrow entitlement set Test policy translation on a single app, workload, or cloud account set first, then compare the translated output against native policy to catch semantic loss.
• Align orchestration with Zero Trust goals Use policy portability to support consistent authorization decisions across environments, but keep runtime enforcement inside the target systems you already trust.

Key takeaways

• IDQL and Hexa address policy fragmentation by creating a common language and translation layer for access governance across cloud platforms.
• The main governance problem is policy drift, where intent, enforcement, and audit evidence diverge across systems that each speak a different native format.
• Practitioners should treat policy orchestration as a standardisation control that still depends on clean entitlement data, clear ownership, and trusted runtime enforcement.

Key terms

• Policy orchestration: Policy orchestration is the process of managing access policy centrally while distributing it to multiple systems in their native formats. It aims to preserve a single policy intent across clouds, applications, and infrastructure so governance can stay consistent even when enforcement remains distributed.
• Declarative policy: Declarative policy defines the desired access outcome rather than the procedural steps needed to enforce it. In identity governance, that makes policy easier to reason about, compare, and translate across platforms, provided the source entitlement model is clean enough to survive conversion.
• Policy translation: Policy translation converts one system’s access rule syntax into another system’s native format without changing the underlying intent. It is useful in multi-cloud environments, but it only works well when the original policy is unambiguous and the target system can express the same decision logic.
• Zero Trust Architecture: Zero Trust Architecture is an assume-breach model that requires continuous verification before access is granted or maintained. In practice, it depends on accurate policy, strong identity signals, and consistent enforcement across systems, which is why fragmented cloud policy becomes a governance problem.

Deepen your knowledge

NHI governance, identity lifecycle management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance maturity, it is worth exploring.

This post draws on content published by Strata Identity: What is IDQL? A guide to Hexa Policy Orchestration Governance & Standards. Read the original.