Authorisation logic scattered across application code is hard to audit, slow to change and the root of most broken access control flaws. Externalised authorisation moves the decision out of the application into a policy decision point (PDP) that applications call through a policy enforcement point (PEP). The market now spans open source engines, managed authorisation services, relationship-based permission systems and enterprise policy platforms, and many products cover only part of the job. This vendor-neutral buyer's guide helps architects, IAM leads and platform teams define requirements, compare products on what matters and run a proof of concept with their own applications. For the underlying models (RBAC, ABAC, ReBAC) see the Authorisation Models Guide, and for writing, testing and shipping policies see the Policy-as-Code for Authorisation Guide.
Key takeaways
- Choose the decision model first, the product second. Attribute-heavy rules, relationship graphs (sharing, folders, tenants) and coarse role checks favour different engines.
- Standard interfaces reduce lock-in. The OpenID AuthZEN Authorization API 1.0 is now a final specification, so ask whether the PDP and your PEPs speak it.
- Latency and availability decide adoption. An authorisation call sits on every request; test p99 latency, local evaluation options and fail-closed behaviour.
- Decision logs are an audit asset. Each decision should be traceable to the input, the policy version and the result, with sensitive fields masked.
- Policy lifecycle matters as much as the engine. Testing, review, versioned rollout and rollback separate a production platform from a demo.
Define requirements
Write these down before speaking to any vendor:
- Applications in scope: internal APIs, customer-facing SaaS with tenants, microservices behind a gateway or service mesh, data platforms, infrastructure (Kubernetes admission, Terraform plans) and AI agents calling tools. See the AI Agent Authorisation Guide and MCP Security Guide for agent and tool call scenarios.
- Decision shape: yes or no checks only, or also "which resources can this user see" (list filtering and search), which drives data filtering in user interfaces and queries.
- Data the policy needs: token claims, user attributes from the identity provider, resource attributes from application databases, relationships (owner, member, parent folder) and context such as time, device posture or MFA strength.
- Volume and latency budget: decisions per second at peak and the acceptable added latency per request, measured at p99 rather than average.
- Callers: human users, service accounts, workloads and agents. Non-human callers often make most decisions, so policies must handle workload identities and delegated tokens. See the OAuth Token Exchange and Delegation Guide.
- Ownership: who writes policy (developers, a central IAM team, business owners), who approves it and who is on call when it denies everything.
- Compliance drivers: NIST SP 800-53 AC-3 (Access Enforcement) and AC-24 (Access Control Decisions), NIST CSF 2.0 PR.AA-05 (permissions defined in policy, enforced and reviewed) and OWASP ASVS 5.0 requirement V8.1.1 (documented authorisation rules for function-level and data-specific access).
Capability areas
| Capability area | What it does | What to look for |
|---|---|---|
| Policy language and model | Expresses rules as code: general-purpose (for example Rego in OPA), purpose-built (for example Cedar's permit and forbid policies) or relationship models in the Google Zanzibar tradition (for example OpenFGA) | Fit to your decision model; readability for reviewers; schema validation that rejects policies referring to unknown attributes |
| Decision API | Lets PEPs ask for decisions over HTTPS, gRPC or an embedded library | AuthZEN endpoints (/access/v1/evaluation, /access/v1/evaluations, search); structured responses with reasons |
| Data and relationship store | Supplies attributes and relationships at decision time, pushed or pulled | Freshness after a change (a removed group membership must take effect quickly); consistency guarantees; size limits |
| Deployment and distribution | Runs the PDP centrally, as a sidecar or in-process, and distributes policy to it | Signed, versioned policy bundles; local evaluation to cut latency; behaviour when the control plane is down |
| Enforcement integrations | PEP plugins for API gateways, service meshes, Kubernetes, databases and SDKs for application code | Coverage of your stack today, not on the roadmap |
| Policy lifecycle | Authoring, unit tests, review, staged rollout, rollback | Native test runner (for example opa test with coverage), CI integration, shadow or audit mode |
| Decision logging and audit | Records every decision with input, result and policy version | Masking of sensitive fields, export to SIEM, query by user or resource for access reviews |
| Analysis and governance | Answers "who can access this?" and detects conflicting or unused policies | Reverse queries, policy diff between versions, ownership metadata per policy |
Evaluation criteria
| Criterion | Weight guide | How to test it |
|---|---|---|
| Model fit | High | Express your three hardest real rules (for example tenant isolation plus delegated sharing plus a break-glass exception) and have your engineers review them |
| Combining semantics | High | Confirm default deny and how conflicts resolve. Cedar documents that a satisfied forbid overrides any permit and that no matching permit means deny; check every candidate states its rules this clearly |
| Performance | High | Load test at peak decisions per second with production-sized data; record p50 and p99 latency and memory |
| Availability and failure mode | High | Kill the control plane and the data source; confirm PEPs fail closed for sensitive actions and that cached policy keeps serving |
| Standards | Medium to high | AuthZEN Authorization API 1.0 support for PDP and PEP; OAuth 2.0 protection of the decision API; ability to consume JWT claims |
| Data freshness | Medium to high | Remove a user from a group or share and time how long until the decision changes |
| Auditability | Medium to high | Retrieve one decision by ID and show input, result and policy revision; check masking |
| Developer experience | Medium | Time for a new developer to add a check and a test; quality of SDKs and local tooling |
| Small vs large organisation fit | Context | A small team with one product may be best served by an embedded library or managed service; a large estate needs central policy distribution, delegated policy ownership and multi-team governance |
Open source engines give portability and no licence cost but leave operations, policy distribution and audit tooling to you. Commercial control planes, including those built around open source engines, add management, analysis and support. Either way, weight enforcement coverage and lifecycle tooling above language features.
Questions to ask vendors
- Show the request and response for one decision on your API. Is it the AuthZEN format, and which AuthZEN endpoints, including batch evaluation semantics (
execute_all,deny_on_first_deny,permit_on_first_permit) and search, are supported today? - Do you publish PDP metadata at
/.well-known/authzen-configuration, and is signed metadata supported? - What happens when a policy errors at evaluation time? Is the request denied, or is the faulty policy skipped, and how is that surfaced?
- Where does evaluation run, and what is the measured p99 latency for our data size? Can policy be evaluated locally without a network hop?
- How are policy bundles signed, versioned and rolled back, and how quickly can a bad policy be reverted across all PDPs?
- How do you keep attribute and relationship data current, and what is the worst-case staleness after a revocation?
- Can we answer "which users can reach this resource?" for an access review or an incident?
- How is the decision API itself authenticated, and how do you prevent a compromised service from querying decisions about other tenants?
- Which decision log fields are captured, how are secrets and personal data masked, and how do logs reach our SIEM?
- Which features depend on proprietary extensions, and how would we export our policies if we left?
Red flags
- No clear statement of default behaviour and conflict resolution between allow and deny rules.
- A PDP that fails open when unreachable, or no way to configure failure mode per action.
- Policy changes pushed to production with no test runner, review step or audit mode.
- Decision logs that omit the policy version, making a past decision impossible to explain.
- "Fine-grained authorisation" that turns out to be role checks with more roles, which recreates role explosion.
- Claims of standards support that cover only a draft or a single endpoint.
- A product that still expects every application to reimplement data filtering itself, which is where broken object-level authorisation creeps back in. See the Broken Access Control Prevention Guide.
Proof of concept
- Pick two real applications: one API with object-level rules (tenants, ownership, sharing) and one service-to-service or agent flow with non-human callers.
- Agree success criteria in advance: rules expressed and reviewed, p99 added latency within budget, revocation reflected within a set time, every decision traceable, and developer effort per new check.
- Write policy as code with tests: include negative tests (cross-tenant access, removed membership, expired delegation) and require coverage reports. Follow the Policy-as-Code for Authorisation Guide for the pipeline.
- Run in shadow mode first: call the PDP alongside existing in-code checks, log both results and investigate every disagreement before switching enforcement.
- Test failure and rollback: make the PDP, data source and control plane unavailable in turn; deploy a deliberately wrong policy and time the rollback.
- Measure from the logs: decision volume, deny rate, disagreement rate during shadow mode, latency percentiles and staleness, then decide.
How NHI Mgmt Group can help
We provide independent market analysis, RFP strategy and evaluation support for identity, authorisation and NHI programmes. Browse vendors in our NHI and AI products directory or contact us about independent evaluation support.
Related NHI Mgmt Group resources: Authorisation Models Guide · Policy-as-Code for Authorisation Guide · AI Agent Authorisation Guide · OAuth 2.0 and OpenID Connect Guide · Broken Access Control Prevention Guide