Many enterprises still run fine-grained authorisation on XACML policy engines built a decade ago, with policies few people can read, PEPs nobody owns and a standard that has seen little new work since 2019. XACML has not been withdrawn, but the centre of gravity has moved to the OpenID AuthZEN Authorization API for the PEP to PDP interface and to newer policy languages such as Cedar and Rego. This guide explains what XACML is (the PEP, PDP, PAP and PIP model, combining algorithms, obligations and ALFA), its current official status with dates, how to find what depends on it, and the migration options with their trade-offs. It is for identity architects and application security teams that own a XACML estate or inherited one. For the newer engines in depth, see the Policy-as-Code for Authorisation Guide.
Key takeaways
- XACML is stable, not retired. XACML 3.0 became an OASIS Standard on 22 January 2013, with approved errata in 2017 and JSON and REST profiles in 2019; there is no formal deprecation notice, so treat it as a mature legacy standard rather than an end-of-life product.
- The architecture outlives the language. The separation of PEP, PDP, PIP and PAP that XACML defined is exactly what AuthZEN and modern engines keep, so migration is mainly about policy language and the PEP to PDP protocol.
- Combining algorithms and obligations are the migration traps. Cedar is default deny with forbid overriding permit; XACML lets each policy set choose from eight algorithms and attach obligations the PEP must enforce, and both semantics must be translated deliberately.
- AuthZEN gives you a decoupling layer first. Putting PEPs behind the AuthZEN Authorization API 1.0 (Final, January 2026) lets you swap the PDP later without touching every application again.
- Doing nothing is a risk in itself. Unowned XML policies, unpatched PDP products and PEPs that fail open on Indeterminate decisions are where authorisation bugs hide.
What is changing and why
XACML (eXtensible Access Control Markup Language) is an OASIS standard that defines three things: an XML policy language, a request and response format, and a reference architecture for attribute-based access control (ABAC). NIST SP 800-162 describes ABAC as deciding access by evaluating attributes of the subject, object, requested action and sometimes environment against policy, and XACML was the main standardised way to do it.
| Component | Role in XACML | Modern equivalent |
|---|---|---|
| Policy Enforcement Point (PEP) | Intercepts the request, asks for a decision, enforces it and its obligations | Application middleware, API gateway or service mesh filter calling an AuthZEN endpoint |
| Policy Decision Point (PDP) | Evaluates applicable policy and returns Permit, Deny, NotApplicable or Indeterminate | OPA, a Cedar authoriser, or a commercial PDP exposing AuthZEN |
| Policy Information Point (PIP) | Supplies missing attribute values at evaluation time | Data loaded into the engine, entity stores, or external data calls |
| Policy Administration Point (PAP) | Writes and publishes policies | Git repository, CI pipeline and policy bundles (policy as code) |
| Context handler | Translates native requests into the XACML request context and back | The AuthZEN JSON information model (subject, resource, action, context) |
What is changing is not the standard but the ecosystem around it. Three pressures drive organisations off XACML:
- Readability: XACML policies are verbose XML with Rule, Policy and PolicySet elements, Target matches and function URNs. ALFA (Abbreviated Language for Authorization) was created as a shorthand that compiles to XACML, and an ALFA 2.0 Internet-Draft (draft-brossard-alfa-authz-00, July 2024) has since expired without IETF endorsement.
- Interface: XACML request contexts are XML, with JSON and REST profiles added in 2019. The OpenID AuthZEN Authorization API 1.0, published as Final on 11 January 2026, defines a simpler JSON PEP to PDP API that several policy engines can implement. One of its editors also edits ALFA, a sign of where XACML-era practitioners now invest.
- Tooling: developers expect policies in Git, unit tests, CI and analysis. OPA (a CNCF graduated project since 2021) and Cedar (Apache-2.0, designed for automated reasoning) offer this natively. See the OpenID AuthZEN Authorization API Guide.
Official timeline and current status
| Date | Document | Status as published |
|---|---|---|
| 2005 | XACML 2.0 | Superseded by XACML 3.0 |
| 22 January 2013 | XACML Version 3.0 core specification | OASIS Standard |
| 23 October 2014 | XACML v3.0 Core and Hierarchical RBAC Profile v1.0 | Committee Specification 02 |
| 12 July 2017 | XACML 3.0 Errata 01 | Approved Errata |
| 20 June 2019 | JSON Profile of XACML 3.0 v1.1; XACML REST Profile v1.1 | OASIS Standards |
| 13 February 2020 | XACML v3.0 Time Extensions v1.0 | Committee Specification 01 |
| 16 February 2021 | XACML v3.0 Related and Nested Entities Profile v1.0 | Committee Specification 02 |
| 25 January 2022 | XACML v3.0 Dynamic Attribute Authority v1.0 | Committee Specification 01 |
| 22 July 2024 | ALFA 2.0 (draft-brossard-alfa-authz-00) | Individual Internet-Draft, now expired |
| 11 January 2026 | OpenID AuthZEN Authorization API 1.0 | Final specification |
As checked on 8 November 2026, the OASIS XACML Technical Committee page lists these work products and a Separation of Duties profile as work in progress, and carries no retirement or deprecation notice. The practical status is "maintained standard, little new development". Product support is a separate question: check your PDP vendor's own support lifecycle, because that, not the standard, sets your real deadline.
Who and what is affected
- Applications with embedded PEPs: Java or .NET applications calling a PDP through a vendor SDK or SOAP or REST endpoint, often written years ago with hard-coded attribute IDs.
- API gateways and portals: gateway plug-ins that turn HTTP requests into XACML requests for coarse API authorisation.
- Data access layers: database proxies and data masking tools that use obligations to redact columns or filter rows.
- Regulated workflows: export control, healthcare consent and financial entitlements, where XACML was chosen because policies were auditable and attribute driven.
- Identity governance: attribute sources (HR, directory, PIP connectors) and the service accounts the PDP uses to read them. These are non-human identities with broad read access. See the Authorisation Models Guide.
Finding affected systems and identities
- Inventory PDP instances: list every PDP server, cluster and embedded library, with version, vendor support status and owner. Look for XACML namespaces (
urn:oasis:names:tc:xacml:3.0) in configuration and deployed artefacts. - Trace PEPs from PDP logs: use PDP access logs to list every calling client, request volume and the attribute categories they send. Clients that no longer appear are candidates for removal; unknown clients are a finding.
- Search code repositories: search for XACML SDK packages, request context builders and AuthZ endpoint URLs to find PEPs that call infrequently, such as batch jobs.
- Export the policy tree: export PolicySets, their combining algorithms, obligations and advice, and any custom functions or AttributeSelectors (XPath over request content). Custom functions and XPath are the hardest parts to migrate.
- Map PIP connections: list the attribute stores the PDP queries, the credentials it uses and their permissions. Rotate and scope these service accounts as part of the project.
- Record decision behaviour: capture a representative sample of real requests and decisions (with personal data minimised) to use as a regression set.
Migration options
Options are listed alphabetically by target technology; the order is not a ranking.
| Option | What it changes | Fits when | Watch out for |
|---|---|---|---|
| Keep XACML, add AuthZEN in front | PEPs call an AuthZEN endpoint; the existing PDP keeps evaluating XACML | Policies are stable and well understood; the PDP product is supported | Mapping AuthZEN boolean decisions and context to XACML obligations and Indeterminate results |
| Migrate to Cedar | Policies rewritten as permit and forbid statements over principal, action, resource and context, with schema validation | Application authorisation with clear entities; you want analysable policies | Cedar is default deny with forbid overrides permit and skips policies that error; XACML algorithms like first-applicable need redesign |
| Migrate to OPA (Rego) | Policies rewritten in Rego and distributed as bundles; one engine for APIs, Kubernetes and infrastructure | Broad platform policy needs beyond application authorisation | Rego is very flexible, so you must define your own default deny, conflict resolution and testing conventions |
| Move to relationship-based authorisation | Permissions modelled as relationships (Zanzibar style) rather than attributes | Sharing and ownership models (documents, tenants, folders) | Attribute and environment conditions often still need a policy layer |
Translating semantics:
- Combining algorithms: XACML deny-overrides maps naturally to Cedar's forbid overrides permit. Permit-overrides, first-applicable and only-one-applicable do not have direct equivalents: rewrite the intent, often as explicit forbid exceptions or ordered rules in Rego.
- NotApplicable and Indeterminate: XACML has four decisions and the specification requires the base PEP to deny on NotApplicable or Indeterminate. Cedar returns Allow or Deny with diagnostics; AuthZEN returns a boolean decision. Make sure errors and missing attributes still produce a deny.
- Obligations and advice: an XACML PEP must deny if it cannot discharge every obligation. Neither Cedar nor AuthZEN has obligations as such: move them into PEP logic driven by response context, and test that the PEP still fails closed.
- Attributes: XACML attribute designators by category become entity attributes (Cedar) or input documents (Rego). Agree a schema first; most bugs come from renamed or missing attributes.
Decision guidance: small teams with a single application and a handful of policies usually gain most by rewriting directly in Cedar or Rego. Large estates with dozens of PEPs should introduce AuthZEN first, so the PDP can be changed without a second round of application changes, then migrate policy domain by domain. If a regulator or auditor relies on the current policy model, keep a mapping document from old rule IDs to new policies.
Testing and rollback
- Build the regression set: replay captured requests against the old PDP to confirm expected decisions, including Deny, NotApplicable and Indeterminate cases and requests with missing attributes.
- Run in shadow mode: send every request to both PDPs; enforce the XACML decision and log mismatches from the new engine. Investigate every mismatch to a written decision.
- Use policy analysis: run validation and unit tests in CI (Cedar schema validation, Rego tests) and require review on every policy change. See the Authorisation Testing Automation Guide.
- Cut over per PEP or per policy domain: switch enforcement for one application at a time behind a configuration flag.
- Roll back: keep the XACML PDP running and the PEP flag reversible until the new engine has run clean for an agreed period; then decommission the PDP, its PIP credentials and its network paths.
Risks of doing nothing
- Fail-open PEPs: custom PEPs that treat NotApplicable or Indeterminate as Permit, contrary to the specification's base PEP rule. These rarely show up until a policy or attribute source changes.
- Policy drift and lost knowledge: XML policies edited through a vendor console, with no version history or tests, and authors who have left. Unreadable policy cannot be reviewed, which undermines the audit case for ABAC in the first place.
- Unsupported PDP software: PDP products past vendor support stop receiving fixes, including for XML parsing flaws.
- Over-privileged PIP accounts: long-lived service credentials with broad directory or database read access. See the Externalised Authorisation Buyer's Guide for what to require of a replacement.
- Missed detection: old PDPs often log decisions locally only, so broken access control (a top web risk class) goes unseen.
Metrics to track the programme: number of PEPs still calling the XACML PDP; percentage of policies with automated tests; shadow mode mismatch rate per week; number of PIP service accounts with scoped, rotated credentials; mean time to deploy a policy change.
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AC-3 Access Enforcement; AC-3(13) Attribute-based Access Control | The PEP and PDP enforce ABAC policy |
| NIST SP 800-53 Rev. 5 | AC-16 Security and Privacy Attributes; AC-24 Access Control Decisions | Attribute integrity and separation of decision from enforcement |
| NIST SP 800-53 Rev. 5 | CM-3 Configuration Change Control; AU-2 Event Logging | Policy changes under change control; decisions logged |
| NIST CSF 2.0 | PR.AA-05 | Access permissions defined in policy, managed, enforced and reviewed |
| NIST SP 800-162 | ABAC definition and considerations | Reference model for attribute-based decisions |
Practitioner checklist
- Record the XACML PDP product, version and vendor support end date, and name an owner.
- List every PEP from PDP logs and code search, and retire the ones no longer called.
- Verify every PEP denies on NotApplicable, Indeterminate and undischarged obligations.
- Export policies with combining algorithms, obligations, custom functions and XPath selectors.
- Scope and rotate the PDP's PIP service account credentials.
- Decide whether to place AuthZEN in front of the existing PDP before rewriting policy.
- Build a replay regression set and run the new engine in shadow mode before cutover.
- Put new policies in version control with tests and mandatory review.
Standards and references
- OASIS: eXtensible Access Control Markup Language (XACML) Version 3.0
- OASIS: XACML Technical Committee work products
- OpenID Foundation: Authorization API 1.0 (AuthZEN)
- NIST: SP 800-162 Guide to Attribute Based Access Control (ABAC) Definition and Considerations
- IETF Datatracker: draft-brossard-alfa-authz (ALFA 2.0)
- Cedar: Cedar policy language
- Open Policy Agent: OPA
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Policy-as-Code for Authorisation Guide · OpenID AuthZEN Authorization API Guide · Fine-Grained Authorisation Guide · Authorisation Models Guide