API Security Maturity Model: Five Levels

Most organisations can name their API gateway and their testing tool, yet few can say how many APIs they run, who owns each one, or whether object-level authorisation is checked on every endpoint. Tools do not make a programme mature; coverage, ownership and evidence do. This model uses NHI Mgmt Group's five levels, Ad hoc to Optimised, to score API security across six capability areas: inventory, design and authorisation, testing, runtime protection, consumer identity and governance. It is for application security leads, platform teams and CISOs who need a defensible score, a realistic target and a roadmap. How to secure APIs in practice is covered in the API Security 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 six capability areas.
Inventory caps the score. You cannot be above Level 2 in any area for APIs you do not know about, which is why OWASP lists Improper Inventory Management as API9:2023.
Level 3 is the first sensible target: a complete inventory with owners, specifications for every external API, authorisation tests in CI and a gateway in front of every internet-facing API.
Level 4 is about evidence, with runtime monitoring per consumer, measured coverage and findings fed back into design.
Every API consumer is an identity. Mature programmes treat API keys, OAuth clients and service accounts as governed non-human identities with owners, scopes and expiry.

The five levels

Level	Name	What it looks like
1	Ad hoc	APIs are built and published by individual teams with no central record. Security depends on each developer. Authentication varies by API, static API keys are shared between consumers, and attacks are found through customer complaints or outside researchers.
2	Developing	A gateway or WAF protects some external APIs and a partial inventory exists, usually from the gateway. Some teams run DAST or penetration tests before major releases. Authorisation flaws are fixed one at a time as they are reported.
3	Defined	An API security standard covers design, authentication, authorisation, rate limits and logging. Every API is in an inventory with an owner, environment, data classification and specification. Internet-facing APIs sit behind a gateway, and CI runs schema and authorisation tests.
4	Managed	Discovery from traffic reconciles the inventory continuously, so shadow and deprecated APIs are found and retired. Runtime monitoring tracks behaviour per consumer and alerts on enumeration and bulk retrieval. Coverage and findings are measured and reported monthly.
5	Optimised	Security is built into API platforms by default: generated clients, policy as code, consumer credentials issued short-lived and per workload. Runtime findings feed threat models and tests automatically, and the programme adapts to new API styles such as agent and MCP traffic.

Capability areas

Score each area separately. The OWASP API Security Top 10 2023 risks in brackets show what each area mainly prevents.

Capability area	Level 1 Ad hoc	Level 3 Defined	Level 5 Optimised
Inventory and discovery (API9)	No record; APIs found by accident	Every API recorded with owner, version, environment, data classification and OpenAPI or equivalent specification; deprecated versions have a retirement date	Inventory reconciled continuously from gateway, code, cloud and traffic; unknown APIs raise tickets automatically
Design and authorisation (API1, API3, API5, API6)	Authorisation written ad hoc in each handler	Standard requires object, property and function-level checks; threat modelling for APIs handling sensitive data or business flows	Central authorisation policy enforced by a shared library or policy engine; sensitive flows have abuse cases designed in
Testing (API1 to API10)	Occasional penetration tests	Specification linting and API-aware security tests in CI; tests for object-level authorisation with two test users; pre-release testing for external APIs	Tests generated from specifications and runtime findings; every authorisation rule has a negative test
Runtime protection (API4, API7, API8)	Some APIs reachable with no gateway	Gateway on every internet-facing API with schema validation, TLS, rate and size limits; outbound calls restricted to allow lists	Behaviour baselines per consumer with automated throttling or blocking; configuration drift detected and corrected
Consumer identity (API2)	Shared static keys, no owners, no expiry	Every consumer has its own credential, owner and scopes; OAuth 2.0 for user-delegated access; keys rotated on a schedule	Short-lived tokens and sender-constrained credentials (mTLS or DPoP) for high-risk APIs; no shared or long-lived keys
Governance and third-party APIs (API10)	No standard; third-party API data trusted	Written standard, design review gate, owner accountability; data from third-party APIs validated like user input	Metrics drive investment; supplier APIs assessed and monitored; standard reviewed yearly

Mapping to frameworks

The model maps to these controls, confirmed against the official catalogues:

Framework	Control	Capability area
NIST CSF 2.0	ID.AM-02	Inventory of software, services and systems
NIST CSF 2.0	PR.PS-06, ID.RA-01	Secure development; vulnerabilities identified and recorded
NIST CSF 2.0	PR.AA-05, DE.CM-09	Least privilege authorisation; runtime monitoring
NIST SP 800-53 Rev. 5	CM-8, SA-11, SI-10	Component inventory; developer testing; input validation
NIST SP 800-53 Rev. 5	AC-3, IA-9, SC-7, SI-4	Access enforcement; service authentication; boundary protection; monitoring
OWASP ASVS 5.0	V4 API and Web Service, V8 Authorization, V10 OAuth and OIDC	Verification requirements for Level 3 and above
MITRE ATT&CK	T1190, T1078	Exploit Public-Facing Application and Valid Accounts, the techniques weak APIs leave open

NIST SP 800-228, Guidelines for API Protection for Cloud-Native Systems (final, updated 13 March 2026), recommends basic and advanced controls for the pre-runtime and runtime stages and supports an incremental, risk-based approach. Its basic controls align with Level 3 here and its advanced controls with Levels 4 and 5. The March 2026 update added appendices listing API risks by category and controls by lifecycle stage, useful as a checklist when scoring.

Self-assessment questions

Answer for internet-facing production APIs first. A control that exists on paper but covers a fraction of APIs scores Level 2.

Inventory: how many APIs, versions and hosts do you run, and how did you count them? Does the number from the gateway match the number from traffic and cloud discovery?
Ownership: does every API in the inventory have a named owner who will answer for it within a day?
Deprecated versions: are old versions (/v1/, beta and staging hosts) still reachable from the internet, and do they share data with production?
Specifications: what share of external APIs has a current OpenAPI or GraphQL schema that the gateway enforces?
Authorisation: do tests prove that user A cannot read user B's objects on every endpoint that takes an ID? Is property-level filtering done on the server?
Consumers: how many static API keys exist, how many are shared by more than one consumer, and how many have no expiry or owner?
Abuse detection: would you notice one consumer reading millions of records over weeks? In the T-Mobile API breach, abuse of one API ran from about 25 November 2022 until detection on 5 January 2023 and exposed data on about 37 million accounts.
Resource limits: do all APIs enforce rate, payload size, pagination and query cost limits?
Outbound calls: can an API that fetches URLs reach internal addresses or cloud metadata endpoints?
Third-party APIs: do you validate and limit data received from supplier APIs, or trust it?

Score each area from 1 to 5, take the lowest score in inventory as a cap on the others, and report the profile, not an average. An average hides the area that will be breached.

Evidence that supports each score

Ask for evidence, not opinions. These are the artefacts an assessor should see before accepting a score of 3 or above.

Capability area	Evidence for Level 3	Evidence for Level 4
Inventory and discovery	Inventory export with owner, environment, data classification and specification link for every API	Weekly reconciliation report showing APIs found by discovery and the tickets raised for them
Design and authorisation	Approved standard; threat models for APIs handling sensitive data	Design review records showing findings fixed before release
Testing	CI logs showing specification linting and authorisation tests on each build	Test coverage report per endpoint; negative tests for each authorisation rule
Runtime protection	Gateway configuration showing schema validation, TLS and limits on every internet-facing API	Alert history for enumeration and bulk reads, with response times
Consumer identity	Credential register with one credential per consumer, owner, scopes and expiry	Rotation logs; share of high-risk APIs using short-lived or sender-constrained tokens
Governance	Signed-off standard and named programme owner	Monthly metrics pack and actions taken from it

Worked example

A retailer scores itself: inventory 2 (gateway list only), design 3, testing 3, runtime 3, consumer identity 2 (partners share keys), governance 3. Because inventory is 2, the other areas are capped at 2 for APIs outside the gateway list, and the reported profile shows two Level 2 areas. The first target is therefore not a new runtime product but traffic discovery and per-partner credentials, which lift the two weakest areas and make every other score true for the whole estate.

Where identity fits

Every API call is made by an identity: a user through an application, a partner integration, a mobile app, a microservice or, increasingly, an AI agent. At Levels 1 and 2 most of those callers hold static API keys that are shared, never expire and have no owner, which makes them non-human identities with no governance. Moving consumer identity up the model means applying the same lifecycle as any other machine identity: register the consumer, issue its own credential, scope it to the APIs and operations it needs, rotate or replace it with short-lived tokens, monitor its behaviour and revoke it when the integration ends. See the API Keys vs OAuth Tokens Guide for when to move a consumer from keys to OAuth clients.

Moving up: roadmap

From Ad hoc to Developing

Build a first inventory from gateway configuration, DNS, cloud load balancers and code repositories. Record owner and data handled.
Put a gateway or WAF in front of the highest-risk internet-facing APIs and turn on TLS, authentication and basic rate limits. See the API Gateway Security Guide.
Run a test focused on authorisation flaws against the top five APIs by data sensitivity.

From Developing to Defined

Publish an API security standard covering authentication, object and function-level authorisation, input validation, rate limits, logging and versioning. Use the API Security Policy Template.
Require a specification for every external API and lint it in CI. See the OpenAPI Specification Security Guide.
Add authorisation tests with two test identities to CI for every endpoint that takes an object ID.
Give every consumer its own credential with owner, scopes and expiry, and start retiring shared keys. See the API Key Management Guide.
Set retirement dates for deprecated versions and remove them from the internet.

From Defined to Managed

Add traffic-based discovery and reconcile it with the inventory weekly; open a ticket for every unknown API.
Monitor per consumer: request volume, distinct object IDs read, error ratios (enumeration produces many 403 and 404 responses) and off-hours bulk reads. Pilot alert thresholds in report-only mode for two weeks before blocking.
Enforce schema validation at the gateway in blocking mode once false positives are tuned, with a per-API rollback switch.
Report the metrics below monthly to the application security steering group.

From Managed to Optimised

Move high-risk APIs to short-lived, sender-constrained tokens (mTLS or DPoP). See the mTLS Guide.
Centralise authorisation in a policy engine or shared library with tests for every rule.
Feed runtime findings into threat models and generated tests, and extend the model to agent and MCP traffic.

Metrics that show movement: share of APIs in the inventory with an owner and specification; unknown APIs found by discovery per month (should fall); share of endpoints with authorisation tests; share of internet-facing APIs behind a gateway with schema validation; static API keys with no expiry; median time to detect bulk retrieval in exercises.

What changes with organisation size

Small organisations with a handful of APIs can reach Level 3 with a spreadsheet inventory, a managed gateway and authorisation tests in CI. Traffic discovery products are rarely needed.
Large organisations with hundreds of teams need automated discovery and a platform team that ships secure defaults, because standards alone do not scale. Score business units separately.
Regulated sectors such as open banking may be required to use specific profiles, for example FAPI, which puts consumer identity at Level 4 or above by design. See the OAuth 2.1, GNAP and FAPI Guide.

Common failure patterns

Gateway inventory treated as complete: APIs that bypass the gateway, such as mobile back ends and partner endpoints, are exactly the ones nobody tests.
Authentication mistaken for authorisation: a valid token proves who the caller is, not that they may read object 12345. API1 Broken Object Level Authorization is first in the OWASP list for a reason.
Scoring by tools owned: buying a runtime protection product while 40 percent of APIs sit outside it scores Level 2.
Shared consumer keys: one key used by several partners makes revocation impossible without an outage, so leaked keys stay valid.
No volume monitoring: slow bulk retrieval through a legitimate endpoint looks like normal traffic unless reads are tracked per consumer.
Non-production left open: staging and test hosts often carry copies of production data with weaker authentication, and they rarely appear in the gateway inventory or the test plan. Score them with production when they hold real data.
Average scores: reporting an overall 3.2 hides a Level 1 in consumer identity.

Practitioner checklist

Score all six capability areas and report the profile, with inventory as a cap.
Reconcile the inventory from gateway, code, cloud and traffic, and assign an owner to every API.
Retire or block deprecated versions and non-production hosts reachable from the internet.
Require a specification for every external API and enforce it at the gateway.
Add object-level authorisation tests with two identities for every endpoint that takes an ID.
Give every consumer its own credential with owner, scopes and expiry.
Alert on per-consumer bulk reads and enumeration patterns.
Re-score every six months and after any API incident.

API Security Maturity Model: Score Your Programme and Plan the Next Level