NHI Governance Maturity Model and Self-Assessment

Most organisations know they have a non-human identity problem; far fewer can say how mature their NHI governance actually is, or what to do next. Service accounts, API keys, tokens, certificates, workload identities and now AI agents outnumber people in almost every environment, and developers, pipelines and SaaS integrations create them far faster than a central team can track. This five-level NHI Governance Maturity Model, developed by NHI Mgmt Group, describes how NHI governance progresses from Ad hoc to Optimised across eight dimensions, with an indicative mapping to NIST CSF 2.0, NIST SP 800-53 Rev. 5, CIS Controls v8.1, ISO/IEC 27001:2022 and the OWASP Non-Human Identities Top 10. It is written for identity, cloud security and platform leads who need an honest baseline, and for CISOs who need a roadmap they can fund and measure.

Key takeaways

Five levels, eight dimensions: the levels are Ad hoc, Developing, Defined, Managed and Optimised, scored separately for inventory, ownership, credentials, access, lifecycle, monitoring, AI agents and governance.
Score with evidence, not policy: a control that exists on paper but covers a fraction of the estate is Level 2, however good the document.
Level 3 (Defined) is the right first target: every in-scope NHI known, owned, vaulted and created through a defined process. Aim for Level 4 on the systems that would hurt most if a credential leaked.
Your real level is your weakest high-risk dimension: a strong vault does not help if nobody knows which service tokens are still in use, as Cloudflare found when four unrotated credentials let an attacker in.
Bring AI agents in from the start: agents are NHIs that make decisions, so they need their own identities, owners and scoped, short-lived access rather than a separate programme bolted on later.

The five levels

Level	Name	Description
1	Ad hoc	NHIs are created by whoever needs them, with no inventory, no owners and secrets scattered across code, configuration files, CI variables and chat. Nobody can say which credentials a critical system depends on. Problems are found through incidents or leaked-secret alerts from outside.
2	Developing	The problem is recognised and has a sponsor. Some discovery and secrets scanning is in place, a vault exists for part of the estate and a few high-risk NHIs have owners. Coverage is patchy, mostly manual and depends on a handful of people.
3	Defined	An approved policy and standards cover creating, owning, storing, rotating and retiring NHIs. There is an inventory across the main clouds, directories, SaaS and code platforms, every NHI in scope has an owner and a purpose, and new NHIs follow a defined request and approval route. NHIs are included in access reviews and a leak response playbook exists.
4	Managed	Processes are automated and measured. Short-lived and federated credentials are the default for new workloads, least privilege is enforced using activity data, NHI behaviour is monitored against baselines, stale identities are removed automatically, and metrics are reviewed monthly and drive decisions.
5	Optimised	NHI governance is continuous and largely secretless. Credentials are ephemeral, access is granted just in time and per task, high-confidence anomalies trigger automated containment, AI agents are governed as first-class identities, and lessons from incidents and tests feed back into standards.

The scale deliberately mirrors other maturity models so it can sit alongside them. NIST CSF 2.0 describes four Tiers, Partial, Risk Informed, Repeatable and Adaptive, as "a progression from informal, ad hoc responses to approaches that are agile, risk-informed" and continuously improving; Levels 1 to 4 here broadly track that progression for one domain. CISA's Zero Trust Maturity Model uses four stages (traditional, initial, advanced and optimal) across five pillars, with identity as one of them.

The eight dimensions

Levels 2 and 4 sit between the descriptions shown; the roadmap later on lists what moves you from each level to the next.

Dimension	Level 1 Ad hoc	Level 3 Defined	Level 5 Optimised
Inventory and discovery	No inventory; NHIs found by accident	Inventory across main clouds, directories, SaaS, CI/CD and code, refreshed at least monthly, with last-used data	Continuous discovery across all sources, including shadow AI, third-party integrations and ephemeral workloads
Ownership and accountability	No owners; the creator may have left	Every in-scope NHI has a named human owner, a team and a documented purpose	Ownership assigned at creation and transferred automatically with team and organisation changes
Credential management	Secrets in code, configuration and chat; no expiry	Secrets vaulted, scanning and push protection on, rotation intervals defined by credential type	Secretless by default: workload identity federation, managed identities and dynamic, short-lived credentials
Access and privilege	Broad, standing administrator or owner rights	Least privilege standards; privileged NHIs identified, restricted and reviewed	Just-in-time, task-scoped access with continuous right-sizing from activity data
Lifecycle	NHIs never retired; dormant keys stay valid	Defined create, rotate and decommission process; stale and orphaned NHIs found and removed on a schedule	Lifecycle fully automated and tied to the workload, pipeline and application lifecycle
Monitoring and response	No NHI-specific logging or alerting	NHI activity logged centrally; leak response playbook tested; known-bad patterns alerted	Behavioural baselines per NHI with automated revocation or quarantine on high-confidence detections
AI agents	Agents use shared keys or borrowed user credentials	Agents registered, owned and given their own identities and scoped tools	Delegated, per-task access with human approval for high-impact actions and full action-level audit
Governance and metrics	No policy, sponsor or reporting	NHI policy approved; accountable executive; basic metrics reported quarterly	Risk-based metrics drive investment, are reported to the board and are independently reviewed

Why each dimension matters

Inventory: every other dimension depends on it. Cloudflare's own account of its 2023 incident says one service token and three service account credentials were not rotated "because mistakenly it was believed they were unused". See the Service Account Inventory Template.
Ownership: without an owner, nobody can approve access, accept a rotation outage or confirm that an identity can be deleted. See the NHI Ownership Guide.
Credentials: the OWASP NHI Top 10 lists Secret Leakage (NHI2) and Long-Lived Secrets (NHI7), and notes that a breached long-lived secret "provides attackers with access to sensitive services without any time constraints".
Access: Overprivileged NHI (NHI5), Environment Isolation (NHI8) and NHI Reuse (NHI9) turn one leaked credential into a wide compromise.
Lifecycle: Improper Offboarding is first in the OWASP list (NHI1): deprecated services and their identities stay usable long after anyone remembers them.
Monitoring: Human Use of NHI (NHI10) causes "indistinguishable activity between humans and automation", which only monitoring and attribution can untangle.
AI agents: OWASP's agentic list warns that "without a distinct, governed identity of its own, an agent operates in an attribution gap that makes enforcing true least privilege impossible" (ASI03 Identity and Privilege Abuse).
Governance: without policy, an accountable executive and metrics, gains in one team do not spread and lapse when people move on.

How the model maps to NIST, CIS, ISO and OWASP

This is an indicative alignment prepared by NHI Mgmt Group to help you reuse existing control evidence; it is not an official mapping from any of these bodies. Control IDs were checked against NIST CSWP 29 (CSF 2.0), the NIST SP 800-53 Rev. 5 catalogue, the CIS Controls v8.1 control list, a published ISO/IEC 27001:2022 Annex A list and the OWASP NHI Top 10 2025.

Dimension	NIST CSF 2.0	NIST SP 800-53 Rev. 5	CIS Controls v8.1	ISO/IEC 27001:2022 Annex A	OWASP
Inventory and discovery	ID.AM-02, PR.AA-01	CM-8, IA-4	5	A.5.9, A.5.16	NHI3
Ownership and accountability	GV.RR-02	AC-2 (account managers)	5	A.5.2, A.5.16	NHI1, NHI10
Credential management	PR.AA-01, PR.AA-03	IA-5, IA-5(7), IA-9, SC-12	5, 16	A.5.17, A.8.24	NHI2, NHI4, NHI7
Access and privilege	PR.AA-05	AC-3, AC-6	6	A.5.15, A.5.18, A.8.2	NHI5, NHI8, NHI9
Lifecycle	ID.AM-08, PR.AA-01	AC-2, IA-4	5, 6	A.5.18	NHI1
Monitoring and response	DE.CM-03, DE.CM-09, RS.MI-01	AU-6, SI-4, IR-4	8, 17	A.8.15, A.8.16, A.5.26	NHI10
AI agents	PR.AA-01, PR.AA-05	IA-9, AC-6	5, 6	A.5.16, A.8.2	Agentic ASI03
Governance and metrics	GV.PO-01, GV.OV-03	PM-9, CA-7	Govern function (v8.1)	A.5.1, A.5.36	All

Two mappings are worth reading in full. CSF 2.0 PR.AA-01 covers identities and credentials for "authorized users, services, and hardware", so NHIs are squarely in scope. SP 800-53 IA-5 requires organisations to change or refresh authenticators by type or on defined events and to protect authenticator content, and IA-5(7) requires that "unencrypted static authenticators are not embedded in applications or other forms of static storage". CIS Controls v8.1 added the Govern function introduced in CSF 2.0, and Control 5 (Account Management) includes service accounts.

Self-assessment questions

For each dimension, score the level that best describes you today, using evidence from the last quarter: inventory exports, vault reports, review records, alert history. Take the lowest score among the dimensions your most critical systems depend on as your overall level, and record the evidence so the next assessment is comparable.

Inventory: could you list every service account, API key, OAuth app and agent with access to your most critical system within a day, with when each was last used?
Ownership: what share of your NHIs has a named, current owner, and what happens to ownership when that person leaves?
Credentials: how many long-lived static secrets are in use, how many are older than a year, and how many live outside the vault?
Access: how many NHIs hold administrator or owner-level rights, are any shared across environments or applications, and when were they last reviewed?
Lifecycle: what happens to an NHI when the application, pipeline or owner goes away, and how long does a dormant key stay valid?
Monitoring: would you notice a service account used from a new location, an engineer signing in as a service account, or a leaked key being used?
AI agents: do you know which agents exist, whom they act for, which tools and credentials they hold, and who approves their high-impact actions?
Governance: is there an approved NHI policy, an accountable executive, and a metric set reported at least quarterly?

Dimension	Evidence that supports Level 3	Evidence that supports Level 4
Inventory	Inventory export covering main platforms with owner and purpose fields	Automated discovery feeds, with reconciliation reports and last-used dates
Credentials	Vault coverage report; secret scanning and push protection enabled on all repositories	Share of workloads on federated or short-lived credentials; rotation job success rates
Access	List of privileged NHIs with review sign-off	Permission right-sizing reports based on activity data
Monitoring	NHI sign-in and API logs in the SIEM; tested leak playbook	Per-NHI baselines, alert tuning records and automated revocation runs

Moving up a level

Size changes the route, not the target. A small organisation with one cloud and one code platform can reach Level 3 largely with native tools: cloud IAM reports, platform secret scanning and a managed vault. A large or regulated organisation with several clouds, an Active Directory estate and hundreds of SaaS integrations usually needs a dedicated NHI inventory and a small programme team. See the NHI Security Platform Buyer's Guide.

From Ad hoc to Developing

Run discovery on your main cloud, directory and code platforms. See the NHI Lifecycle Management Guide.
Turn on secrets scanning and push protection in source control; GitHub describes push protection as blocking pushes that contain secrets "before they reach your repository".
Stand up a vault and move the highest-risk secrets into it. See the Secrets Management Guide.
Assign owners to the most privileged NHIs first, and name an executive sponsor.

From Developing to Defined

Publish an NHI policy covering creation, ownership, storage, rotation, access and retirement, approved at executive level.
Extend inventory to SaaS integrations and OAuth apps. See the SaaS and OAuth App Governance Guide.
Require an owner and purpose for every new NHI through a request route, and backfill owners for existing ones.
Adopt and test a leak response playbook. See the Leaked Credential Response Playbook.
Include NHIs in access reviews. See the Access Reviews Guide.

From Defined to Managed

Replace static secrets with workload identity federation and short-lived credentials. AWS, for example, recommends that workloads "use temporary credentials with IAM roles". See the Workload Identity Federation Guide and the NHI Authentication Guide.
Automate rotation where static secrets remain, using dynamic secrets with short leases where the platform supports them. See the Secrets Rotation Runbook Template.
Right-size permissions using activity data. See the Cloud PAM and CIEM Guide.
Monitor NHI behaviour and alert on anomalies. See the ITDR Guide.
Register AI agents and give them their own identities. See the Agentic AI Identity Guide.

From Managed to Optimised

Make secretless patterns the default for new workloads and track exceptions.
Grant NHI and agent privileges just in time and per task. See the JIT Access Guide.
Automate containment: revoke or quarantine credentials automatically on high-confidence detections, with a documented release process.
Report risk-based NHI metrics to leadership and the board. See the Board Briefing.

Implementation roadmap

A typical first year for an organisation starting at Level 1 or 2. Adjust the scope to your estate; the order matters more than the dates.

Phase	Focus	Outputs
First 30 days	Baseline and quick wins	Self-assessment scored with evidence; executive sponsor named; secret scanning and push protection on; top 20 privileged NHIs identified with owners
Days 31 to 90	Inventory and policy	Inventory across main clouds, directories and code platforms; NHI policy approved; leak playbook tested; highest-risk secrets vaulted
Days 91 to 180	Reach Level 3 on critical systems	Owners for all in-scope NHIs; SaaS and OAuth integrations inventoried; NHIs in access reviews; stale identities removed; AI agents registered
Days 181 to 365	Start Level 4 where risk is highest	Federated or short-lived credentials for new workloads; automated rotation; activity-based right-sizing; NHI baselines in the SOC; quarterly metrics to leadership

Metrics that show maturity

Metric	What it shows	Target direction
Share of NHIs with a named, current owner	Ownership coverage and whether it survives staff changes	Up, towards 100% in scope
Number and age of long-lived static secrets	Exposure window if a secret leaks	Down
Share of workloads on federated or short-lived credentials	Progress towards secretless	Up
NHIs with privileged access, and days since last review	Concentration of standing privilege	Down
Stale and orphaned NHIs found and removed per quarter	Whether offboarding works	Found trending down over time; removal time down
Mean time to revoke a leaked credential	Response readiness	Down
Share of AI agents registered with an owner and scoped access	Agent governance coverage	Up
Secrets detected outside the vault (code, CI logs, tickets)	Whether developers use the paved road	Down

Baseline these at the first assessment; a level claim without a trend is hard to defend. See the Identity Security Metrics Guide.

Common failure patterns

Rotation without inventory: a mass rotation after a supplier breach misses the credentials nobody knew were in use. In the Cloudflare Thanksgiving Breach 2023, credentials leaked in the Okta compromise and not rotated gave an attacker access to Atlassian systems; Cloudflare then rotated more than 5,000 production credentials.
Scoring the policy, not the estate: the assessment rates the standard rather than coverage, so the organisation believes it is Level 3 while most NHIs are unowned.
A vault nobody is required to use: secrets are vaulted for one team while others keep them in CI variables and configuration files.
Ownership assigned once: owners are recorded at creation and never updated, so the identity is orphaned when the team reorganises.
Human use of service accounts: engineers share a service account for convenience, which breaks attribution and keeps it over-privileged.
Agents treated as a side project: AI agents run on shared API keys or borrowed user tokens outside the NHI inventory, repeating every Level 1 mistake.
No metrics, no momentum: without a baseline and quarterly reporting, the programme loses funding once the first audit finding is closed.

How this model relates to others

The NHI Governance Maturity Model focuses on non-human identities. The Identity Security Maturity Model covers all identity types, and the Agentic AI Identity Maturity Model goes deeper on AI agents. The Incident Response Maturity Model uses the same five-level scale and scores identity and NHI compromise response. Use them together: an organisation's NHI maturity usually lags its workforce identity maturity, and agent maturity usually lags both.

At framework level, use CSF 2.0 Tiers to describe overall risk governance and CISA's Zero Trust Maturity Model for the identity pillar as a whole; this model adds the NHI-specific detail neither provides, such as secret age, ownership coverage and agent registration. The Ultimate Guide to Non-Human Identities explains the underlying concepts.

Practitioner checklist

Score each of the eight dimensions separately, using evidence rather than policy statements.
Name an accountable executive and an owner for the NHI programme.
Set Level 3 as the first target, with Level 4 for the highest-risk systems.
Prioritise the lowest-scoring dimension that affects your most critical assets.
Build the inventory first, with owner, purpose and last-used fields.
Turn on secret scanning and push protection everywhere code lives.
Include NHIs in access reviews and in the leak response playbook.
Agree metrics for each dimension, baseline them now and report quarterly.
Include AI agents from the start rather than treating them as a separate programme.
Reassess at least annually and after major platform changes or incidents.

NHI Governance Maturity Model