Authorisation Maturity Model: Five Levels

Most organisations can tell you how users log in, but very few can say, for any given application, who is allowed to do what to which records and where that rule is written down. Authorisation is the decision made after authentication, on every request, and it is where the commonest application flaw lives: OWASP ranks Broken Access Control first in its Top 10 2025 and found some form of it in every application tested. This model uses NHI Mgmt Group's five levels, Ad hoc to Optimised, to score authorisation across eight capability areas, from how rules are written and enforced to how entitlements are reviewed and how non-human identities and AI agents are constrained. It is for security architects, IAM and application security leads and engineering managers who need to place their estate on a scale and plan the next step. The models themselves (RBAC, ABAC, ReBAC) are explained in the Authorisation Models Guide; this page is about staged maturity.

Key takeaways

The five levels are Ad hoc, Developing, Defined, Managed and Optimised, scored separately for each of eight capability areas and, in large estates, for each application tier.
Coverage beats sophistication. One endpoint without a check undoes a well designed policy engine, so "every request is checked, deny by default" is the Level 3 line, before any choice of RBAC, ABAC or ReBAC.
Externalise the decision, not just the login. Moving rules out of scattered code into a policy decision point with versioned policy is what makes authorisation testable, reviewable and auditable at Levels 4 and 5.
Object and field level is where breaches happen. Function-level checks ("is this user an admin?") are common; record ownership and tenant checks ("may this user read this invoice?") are the gap OWASP and ASVS 5.0 single out.
Machines and agents need their own track. Service accounts, API clients and AI agents usually hold the broadest standing permissions and act on behalf of users, so the originating subject's rights must survive the hop.

The five levels

Level	Name	What it looks like
1	Ad hoc	Access checks are written by each developer inside handlers, often only in the user interface. Many applications have an "admin" flag and nothing finer. Default framework settings decide what is open. Nobody can list who can do what, and service accounts run with owner or administrator rights because it was quicker.
2	Developing	Roles exist in the main applications and the identity provider passes group claims. Checks sit in shared middleware for some services. Roles multiply with each request ("role explosion"), entitlements are reviewed once a year in a spreadsheet, and object-level checks depend on the individual team.
3	Defined	An authorisation standard requires deny by default, server-side enforcement on every request, and object-level ownership or tenant checks. Each application documents its rules (ASVS V8.1.1). Roles are defined in a catalogue with owners, privileged roles are separated, and access failures are logged. Service accounts are inventoried with owners and scoped permissions.
4	Managed	Decisions for new and high-risk applications go through a policy decision point (PDP) with policy as code, version control, peer review and automated tests in the pipeline. Context such as device, location or risk feeds decisions for sensitive actions. Entitlement data is joined to usage so unused rights are removed. Delegated access by services preserves the originating user's permissions.
5	Optimised	Fine-grained, relationship or attribute-based policy is the norm for data access, standing privilege is close to zero, and permission changes take effect immediately. Authorisation decisions are logged centrally and analysed for drift. AI agents receive task-scoped, short-lived delegated rights with human approval for high-impact actions, and policy coverage is measured continuously.

Capability areas

Score each area separately. An organisation whose policy engine is excellent but whose entitlement reviews are rubber stamps is not at Level 4.

Capability area	Level 1 Ad hoc	Level 3 Defined	Level 5 Optimised
Policy definition	Rules exist only in code and people's heads	Written authorisation rules per application covering function and data access; role catalogue with owners	Policy as code in a declarative language, versioned, reviewed and traceable to business rules
Enforcement coverage	Checks in some handlers or only in the user interface	Server-side, deny by default on every request through shared middleware or gateway	Every application and API calls a policy enforcement point; coverage measured and gaps alerted
Object and field level	Any authenticated user can reach any record by changing an ID	Ownership and tenant checks on every object; sensitive fields filtered per role	Relationship or attribute-based rules for all data access, tested for cross-tenant leaks
Decision architecture	Embedded logic, duplicated per service	Shared library or gateway per platform	Externalised PDP with a standard request format (subject, action, resource, context), local caching and defined failure mode
Least privilege and entitlements	Broad roles, owner rights by default	Privileged roles separated, joiner, mover and leaver changes applied, periodic reviews	Usage-driven right-sizing, just-in-time elevation, near-zero standing privilege
Non-human identities	Service accounts with administrator or owner rights, shared between apps	Inventory with owners, one identity per workload, scoped roles	Workload identities with minimum, reviewed permissions; unused rights removed automatically
Delegation and AI agents	Back-end services act with their own full rights for any caller	Services pass the user context; agents limited to named tools	Delegated, task-scoped and short-lived tokens; originating subject's rights enforced end to end; approval for high-impact actions
Testing, logging and review	No access control tests; failures not logged	Unit and integration tests for deny cases; access failures logged	Automated authorisation test suites in CI, decision logs analysed, policy drift detected

Decision architecture options by level

The architecture choice is the one most often confused with maturity. A policy engine is a means, not a score. Choose by the number of applications, how often rules change and who must audit them.

Approach	Typical level	Strengths	Weaknesses	Fits
Checks embedded in each handler	1 to 2	No dependency, fast to write	Easy to miss a route, impossible to audit centrally	Small single applications only
Shared middleware or framework annotations	2 to 3	Global, deny by default possible, low latency	Rules still compiled into each service; object-level logic often left out	A few applications on one stack
API gateway enforcement	3	One place for coarse function-level rules on APIs	Cannot see object ownership without calling the service; bypassed by internal traffic	Coarse checks in front of many APIs
Externalised PDP with policy as code (for example OPA with Rego, Cedar)	4 to 5	Versioned, testable, consistent; decision logs	Needs engineering investment, latency and availability design, policy skills	Many applications, frequent rule changes, audit pressure
Relationship-based service (Zanzibar style)	4 to 5	Expresses sharing, hierarchies and ownership at scale	Relationship data must be kept in sync; harder to reason about	Document, collaboration and multi-tenant SaaS products

OpenID AuthZEN Authorization API 1.0, published as Final on 11 January 2026, standardises how an enforcement point asks a decision point for an answer: subject, resource and action, with optional context, sent to an evaluation endpoint, with batch evaluations and search endpoints for listing what a subject may do. A standard interface reduces lock-in when moving from Level 3 libraries to a Level 4 PDP. See the OpenID AuthZEN Authorization API Guide and the Policy-as-Code for Authorisation Guide.

Mapping to frameworks

Framework	Control	What it asks for
NIST SP 800-53 Rev. 5	AC-3, AC-24	Access enforcement; access control decisions
NIST SP 800-53 Rev. 5	AC-6, AC-6(5), AC-6(7), AC-6(10)	Least privilege; privileged accounts; review of user privileges; prohibit non-privileged users from executing privileged functions
NIST SP 800-53 Rev. 5	AC-5, AC-2(1)	Separation of duties; automated account management
NIST CSF 2.0	PR.AA-05	Access permissions, entitlements and authorisations defined in policy, managed, enforced and reviewed, with least privilege and separation of duties
OWASP ASVS 5.0	V8.1.1, V8.2.1 to V8.2.4, V8.3.1 to V8.3.3, V8.4.1	Documented rules; function, data and field-level checks; adaptive controls; enforcement at a trusted service layer; immediate effect of changes; originating subject's permissions; cross-tenant controls
NIST SP 800-162 and SP 800-207	ABAC model; PDP and PEP	Attribute-based decisions; per-request decisions before a session with a resource
MITRE ATT&CK	T1078, T1098, T1548	Valid Accounts, Account Manipulation and Abuse Elevation Control Mechanism, which weak authorisation makes more damaging

Self-assessment questions

Answer per application tier (customer-facing, internal business, administrative) and then for machine identities. A control that covers part of the estate scores Level 2.

Documentation: for your five most important applications, can the owner produce written rules for who may perform each function and read or change each data type?
Coverage: is there a route, endpoint or GraphQL field in any of them that does not pass through a server-side check? How do you know?
Default: when a new endpoint is added without an explicit rule, is it denied or allowed?
Object level: if a user changes an order or account ID in a request, what stops them reading someone else's record? The T-Mobile API breach shows how far one abused API can reach when it returns data beyond what the caller should see.
Tenancy: in multi-tenant systems, is the tenant enforced in the data layer or only in the user interface?
Roles: how many roles exist per application, how many have no members or no owner, and how many users hold privileged roles they have not used in 90 days?
Change speed: when a user leaves or a role is removed, how long until the change is enforced, including in cached tokens?
Machines: how many service accounts or workload identities hold owner, administrator or wildcard permissions?
Delegation: when a back-end service or AI agent acts for a user, are the user's permissions checked, or the service's?

Evidence that supports each score

Capability area	Evidence for Level 3	Evidence for Level 4
Policy definition	Authorisation rules document per application; role catalogue with owners	Policy repository with commit history, reviews and links to business rules
Enforcement coverage	Middleware configuration showing deny by default; route inventory with the check applied	Report of endpoints calling the PDP, with uncovered endpoints at zero or tracked
Object and field level	Test cases where user A requests user B's object and is refused	Automated cross-user and cross-tenant tests in CI on every release
Least privilege	Completed access reviews with revocations recorded	Unused-entitlement report and removals driven by it
Non-human identities	Service account inventory with owners and permission scope	Share of workload identities without administrator or wildcard rights, trending up
Logging	Access-denied events logged with subject, action, resource and reason	Decision logs centralised, with alerts on spikes in denials and on policy changes

Worked example

A SaaS company scores itself: policy definition 2, enforcement coverage 3 (shared middleware, deny by default), object level 2 (ownership checks in some services), decision architecture 2, least privilege 3, non-human identities 1 (deployment service principal with owner rights on production), delegation 2 and testing 2. The profile, not the average of 2.1, sets the plan: object-level and tenant checks come first because a single missing check exposes customer data across tenants, and the over-privileged deployment identity comes second because it is the shortest path from one stolen token to the whole platform.

Moving up: roadmap

From Ad hoc to Developing

Inventory applications and APIs, and for each one record where authorisation is enforced today.
Move every check to the server side and remove reliance on hidden buttons, client-side flags or values the caller can change.
Remove owner and administrator rights from service accounts used by applications, starting with production.

From Developing to Defined

Publish an authorisation standard: deny by default, check on every request, object ownership and tenant checks, logging of failures. The RBAC Role Matrix Template helps document roles.
Apply checks through shared middleware or framework filters so a new route cannot be added without one, and run it in report-only mode first to find routes that would be denied before switching to enforce.
Build a role catalogue with owners, separate privileged roles and define incompatible combinations. See the Segregation of Duties Guide.
Add negative tests: user A cannot read user B's object, a standard user cannot call an administrative function. See the Authorisation Testing Automation Guide.
Inventory service accounts with owners and scope their permissions to one workload each.

From Defined to Managed

Choose a PDP pattern and pilot it on one high-risk application. Run the new engine in shadow mode, comparing its decisions with the existing code for several weeks, and switch only when mismatches are understood; keep the old check behind a flag as rollback.
Put policy in version control with peer review and tests in the pipeline, and log every decision with the policy version.
Define the failure mode: fail closed for writes and sensitive reads, and document any fail-open exceptions with an owner.
Join entitlement data to usage logs and remove privileged rights unused for 90 days. Move standing administrator access to just-in-time elevation. See the JIT Access Guide.
Propagate the originating user's identity through service calls so downstream services check the user, not the intermediary.

From Managed to Optimised

Adopt relationship or attribute-based rules where roles cannot express ownership and sharing. See the Fine-Grained Authorisation Guide.
Make permission changes take effect immediately: short token lifetimes, revocation checks or live policy evaluation for sensitive actions.
Issue AI agents task-scoped, short-lived delegated tokens and require human approval for high-impact actions. See the AI Agent Authorisation Guide.
Measure policy coverage continuously and alert on any endpoint or identity outside it.

Metrics that show movement

Enforcement coverage: share of endpoints and APIs behind a server-side, deny-by-default check (target 100 per cent).
Object-level test coverage: share of data-returning endpoints with automated cross-user and cross-tenant tests.
Standing privilege: number of human and machine identities with permanent administrator, owner or wildcard rights, and the trend.
Unused entitlements: share of privileged entitlements unused in 90 days.
Revocation latency: median time from a role removal to enforcement everywhere.
Authorisation findings: broken access control findings per release from testing and bug bounty, by severity.

What changes with organisation size

Small organisations with a handful of applications should reach Level 3 with framework middleware, a role catalogue and negative tests; a dedicated PDP is rarely worth it.
Large organisations should score each application tier separately and fund externalisation for the applications with the most users, data and rule changes, accepting Level 3 for the long tail. The Externalised Authorisation Buyer's Guide covers evaluation.
SaaS providers should treat tenant isolation as a separate pass or fail test at every level. See the Multi-Tenant SaaS Authorisation and Tenant Isolation Guide.

Common failure patterns

Function checks without object checks: the endpoint confirms the caller is a customer but not that the record belongs to them, the pattern behind most broken object level authorisation findings. See the OWASP API Top 10 API1 Broken Object Level Authorization Guide.
Trusting the client: roles, prices or tenant IDs read from hidden fields, cookies or token claims the caller can influence, which ASVS V8.3.1 rules out.
Role explosion: a new role for every exception until nobody can review them, which is usually a sign that attributes or relationships are needed.
Over-privileged machines: a deployment or integration identity with owner rights becomes the target. At Capital One, the credentials of a firewall's cloud role were enough to read data on 106 million people.
The confused deputy: a back-end service or agent uses its own broad rights for every caller, so any user who can reach it inherits them.
Policy engine as a single point of failure: a PDP introduced without caching, capacity planning or a defined failure mode either takes applications down or is quietly set to fail open.

Practitioner checklist

Score all eight capability areas per application tier and for machine identities.
Require server-side, deny-by-default checks on every request and measure coverage.
Add object ownership and tenant checks with automated cross-user tests before any engine work.
Document authorisation rules per application and keep a role catalogue with owners.
Remove owner, administrator and wildcard rights from service accounts and workload identities.
Pilot a PDP in shadow mode with versioned, tested policy and a defined failure mode.
Propagate the originating user's identity through services and agents.
Remove privileged entitlements unused for 90 days and move standing access to just-in-time elevation.
Re-score every six months and report the six metrics quarterly.

Authorisation Maturity Model: Five Levels From Hardcoded Checks to Policy