TL;DR: PlainID’s guide argues that enterprises running both XACML and OPA often end up with policy drift, duplicated business rules, and audit friction because authorization is split across languages, teams, and enforcement points. A central PBAC layer separates the model, policy management, and enforcement so access decisions stay governable across legacy apps, APIs, and AI-facing workflows.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on PlainID's blog post: Mixed XACML and OPA estates drift over time, and PBAC is positioned as the governance layer that can unify policy without forcing a rip-and-replace rewrite.
Why it matters: It matters because IAM, IGA, PAM, and platform teams need one way to express and govern access rules across human, non-human, and AI-driven requests without multiplying exceptions and audit gaps.
👉 Read PlainID's guide to modernizing authorization across XACML and OPA
Context
Enterprises that grew authorization piecemeal often now have the same access rule expressed in multiple places, each with its own language, owner, and update cycle. That creates policy drift, slows audits, and makes routine business changes depend on whichever specialist still understands the oldest engine.
In this environment, the real governance gap is not whether XACML or OPA is the better engine. It is that neither one, by itself, gives the organisation a single business-readable policy model or a central place to govern decisions across systems. PBAC is the article's answer to that split, and it only works when the policy source of truth is separated from the enforcement point.
Key questions
Q: What should security and application teams focus on first when modernizing authorization?
A: Focus first on use cases that can show value quickly, especially new applications or teams already moving toward modern practices. That lets the organisation prove the model, refine governance, and learn what works before expanding. The first objective is not perfect coverage. It is to establish a credible pattern that can be repeated across the wider estate.
Q: Why do mixed XACML and OPA environments create governance problems?
A: They create governance problems because the same rule is expressed in different languages, owned by different teams, and updated on different schedules. The result is policy drift, inconsistent enforcement, and weak audit evidence. The technical issue is less the engine choice than the absence of a single managed policy source of truth.
Q: What signals show that authorization policies are drifting?
A: Look for rising denies after policy changes, a sharp drop or spike in active principals, and unusual concentration in a few resource-action pairs. Those patterns usually indicate that the policy model, the application, or both have changed faster than the review process. Drift is visible when the trend changes before users start complaining.
Q: What should auditors and access owners be able to prove about PBAC?
A: They should be able to trace one business rule from its approved policy statement to every enforcement point that applies it. If that chain cannot be shown, the programme still has fragmented authorization even if the underlying engines are modern. Accountability depends on readable policy, version history, and consistent decision evidence.
Technical breakdown
Why XACML policy stores stall at enterprise scale
XACML externalised authorization by separating policy decision, administration, enforcement, and attribute lookup. That architecture still matters, but the policy itself is usually written in XML that is difficult for business owners to read or maintain. Over time, enterprises end up with a small specialist group that understands the policy store, which creates maintenance bottlenecks and frozen rules when staff leave. The model works best when policy authorship, review, and attribute governance stay healthy. Practical implication: treat XACML as an architecture pattern that still needs active policy governance, not as a self-maintaining standard. See the IAM and IGA Basics.
Practical implication: Review who can author and explain XACML policies before you keep relying on them at scale.
Why OPA improves locality but can still create policy sprawl
OPA moved decisions closer to workloads by running as a sidecar, library, or local service and evaluating Rego against in-memory data. That reduces latency and fits cloud-native systems well. The trade-off is governance: teams still have to build the bundle pipeline, approval workflow, log pipeline, and policy analysis layer around it. Without a central management model, Rego codebases proliferate across teams and the same business rule drifts in different forms. Practical implication: treat OPA as a decision engine, not a complete authorization governance system. See the Authorisation Models Guide.
Practical implication: Govern the Rego lifecycle centrally if you want OPA to scale beyond a single platform team.
How PBAC separates policy meaning from policy enforcement
PBAC moves the access model into business terms and keeps enforcement wherever the application already runs. The rule is expressed once, then evaluated at request time using live identity, resource, and context attributes. That matters because governance becomes readable to non-developers while enforcement can still happen in legacy applications, APIs, gateways, or data platforms. The important design choice is not the engine but the separation of model, management, and enforcement. Practical implication: centralize policy semantics first, then translate existing checks one business rule at a time. See the Authorisation Models Guide.
Practical implication: Use PBAC to make the policy readable once and enforceable everywhere.
Threat narrative
Attacker objective: The practical objective is to exploit or benefit from inconsistent authorization decisions before the drift is detected, whether by an attacker, an insider, or an audit finding.
- Entry occurs through fragmented authorization estates where the same rule exists in XACML, Rego, and hardcoded checks, so no single change path controls the whole decision surface.
- Escalation happens when the business rule changes, such as a regional reorganisation, but one engine is updated and another is left behind because the specialists who understood it are gone.
- Impact follows when users receive different access outcomes across core systems, which creates audit exposure, inconsistent customer treatment, and delayed regulatory detection.
Breaches seen in the wild
- Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Policy drift is the real enterprise authorization failure, not the choice of engine. The article is right to move the discussion away from XACML versus OPA as a winner-takes-all debate. The operational problem is that business rules become duplicated across languages, teams, and enforcement points, so the estate no longer has one governable interpretation of access. That is an identity governance problem first and a tooling problem second. Practitioners should treat policy drift as a control-plane defect, not a syntax preference.
Business-readable authorization is now a governance requirement, not a convenience. If the people accountable for access cannot read the policy that enforces it, review and accountability break down even when the runtime decision engine is technically correct. That is especially visible in estates where compliance, platform, and application teams each own a slice of the rule. The article’s PBAC framing is useful because it restores a single policy meaning that can be reviewed outside code.
The centralisation question is the wrong one if it only moves the engine. Replacing XACML with OPA, or OPA with anything else, does not solve the fact that authoring, approval, versioning, and evidence production are scattered. The enterprise control that matters is policy management with one source of truth and multiple enforcement points. Without that separation, every modernisation effort simply relocates drift instead of removing it.
PBAC is the naming concept that makes the governance gap legible. It is not just a model for access decisions, but a way to separate policy meaning, policy management, and policy enforcement across human, non-human, and AI-mediated requests. That distinction is what lets an enterprise modernise one business rule at a time rather than rewriting every application at once. Practitioners should use PBAC as the operating model for cross-system authorization governance.
What this signals
Policy modernisation will keep failing if teams think in engine migrations instead of governance boundaries. The durable design pattern is one policy model, one management plane, and multiple enforcement points. That lets enterprises keep legacy systems running while making authorization readable enough for business owners, auditors, and platform teams to share the same source of truth.
Central policy governance is becoming the control that separates modern estates from merely distributed ones. The future-state question is not whether a workload uses XACML, OPA, gateways, or sidecars. It is whether those enforcement points are all consuming the same authoritative policy and the same current attributes, including changes caused by reorganisation, mergers, or cloud migration.
Externalized authorization now has to extend beyond applications into data and AI-facing requests. As agents, APIs, and data platforms become first-class decision points, the policy layer needs to follow the request rather than live inside one team’s language or toolchain. Practitioners should expect authorization governance to converge on central management with distributed enforcement, not on another language swap.
For practitioners
- Map every authorization decision point Inventory XACML PDPs, OPA sidecars, hardcoded checks, gateway rules, database filters, and SaaS admin paths so duplicate business rules become visible. See the NHI Lifecycle Management Guide.
- Separate the policy model from enforcement Define one business-readable policy source of truth, then keep existing enforcement points in place while you change what they ask and where they ask it.
- Translate policies by business rule Rewrite regional, entitlement, and data-access rules as one validated business statement before you port them into the new policy layer. See the IAM and IGA Basics.
- Run legacy and modern decisions in parallel Compare outcomes on live traffic until mismatches are explained, then cut over one rule at a time instead of attempting a broad rewrite.
- Retire hardcoded checks last Remove embedded authorization logic only after the central policy layer has proven stable for the highest-change applications and data paths.
Key takeaways
- Enterprise authorization fails when the same business rule is maintained in multiple engines, because policy drift turns a governance problem into an access inconsistency.
- The bank scenario shows how quickly a role change can diverge across systems when one policy language is updated and another is left untouched.
- The practical control shift is to separate policy meaning, policy management, and enforcement so authorization can be governed once and applied everywhere.
Related NHI Mgmt Group resources: Authorisation Models Guide · NHI Lifecycle Management Guide · IAM and IGA Basics · Compliance Automation Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Authorization drift in mixed estates often follows weak identity-bound decision controls. |
| NHI-05 — Overprivileged NHI | Centralized policy is needed to keep service and workload access from expanding across duplicate enforcement points. | |
| Recommendation — Bind each authorization decision to the correct identity and context so stale policy copies cannot diverge. Review non-human access scope across all enforcement points and remove privilege duplication. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing permissions consistently across systems. |
| Recommendation — Standardize entitlement decisions under one governed authorization model and audit it across the estate. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Policy drift undermines least privilege when different systems enforce different versions of the same rule. |
| Recommendation — Apply least privilege consistently across legacy and cloud-native enforcement points through one policy source. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Inconsistent authorization can widen attacker movement paths after one system is updated and another is not. |
| Recommendation — Map authorization drift to credential and movement risk so inconsistent decisions become a detection priority. | ||
Key terms
- Policy-Based Access Control: Policy-based access control grants or denies access using rules that evaluate context, signals, and identity state at decision time. It is more adaptive than static role assignment, but only if the policy engine receives accurate runtime inputs and can enforce them across systems.
- Policy decision point: A policy decision point evaluates contextual rules and returns an access decision that enforcement points can act on. It separates authorization logic from application code, which helps teams manage tenant rules, resource ownership, and risk signals consistently.
- Policy State Drift: Policy state drift occurs when the permission a system believes is current no longer matches the user's actual choice. In customer data environments, drift creates compliance risk, inconsistent customer experiences, and operational inefficiency because different channels enforce different rules.
- Externalized Authorization: A design pattern where access decisions are removed from application code and handled by a separate policy layer. This makes authorization easier to govern, test, audit, and reuse across services, especially when roles, attributes, and request context change frequently.
What's in the full article
PlainID's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step migration sequencing for moving from mixed XACML and OPA estates to a central policy layer
- Implementation detail on translating legacy rules into business-readable PBAC policies without rebuilding every application
- Operational examples of enforcement-point swaps across APIs, service meshes, SQL paths, and existing application checks
- PlainID's explanation of its authorization graph, connector model, and runtime policy evaluation flow
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org