Identity Security Maturity Model and Self-Assessment

Identity security maturity is uneven in most organisations, and attackers go where it is weakest. Workforce single sign-on may be excellent while service accounts go unmanaged; privileged access may be vaulted while AI agents run on developers' tokens. This model gives one five-level scale for every identity type an organisation runs: workforce, privileged, customer, non-human and AI agent identities, scored across eight capability areas. It maps each area to the CISA Zero Trust Maturity Model identity pillar, NIST CSF 2.0, NIST SP 800-53 Rev. 5, ISO/IEC 27001:2022 and CIS Controls v8.1. It is about identities and their access, not about data handling or security operations, which have their own Data Security Maturity Model and SOC Maturity Model. It is written for identity leads, CISOs and architects who need an honest baseline across all identity types and a roadmap they can defend.

Key takeaways

Score eight capability areas for each identity type: visibility, ownership and lifecycle, authentication, authorisation and privilege, governance, secrets and credentials, detection and response, and programme management.
Your effective level is set by your weakest identity type, which is usually non-human or AI agent identities rather than the workforce accounts that most programmes were built around.
Level 3 (Defined) across every identity type is the right first target for most organisations: a complete inventory with owners, phishing-resistant MFA for administrators, centralised secrets and access reviews that include machines and agents.
AI agents need their own governed identity. OWASP warns that without one an agent operates in an attribution gap, so least privilege and accountability cannot be enforced.
Measure outcomes, not tools: ownership coverage, standing privilege, credential age, phishable administrator sign-ins and the time taken to revoke a compromised identity.

The five levels

Level	Name	Description
1	Initial	Ad hoc and manual, dependent on individuals. No reliable inventory, accounts outlive their purpose, machines use static secrets and nobody owns identity as a whole.
2	Developing	Basic tools and policies exist for some identity types, usually workforce and privileged accounts. MFA and a vault are in place but coverage is partial; service accounts and agents sit outside the process.
3	Defined	Standard processes across all identity types: an inventory with named owners, joiner-mover-leaver and decommissioning for people and machines, phishing-resistant MFA for administrators, centralised secrets and risk-based access reviews.
4	Managed	Automated, measured and risk-based. Short-lived credentials and just-in-time privilege are the norm, identity threat detection covers the main identity systems, and metrics are reported every quarter.
5	Optimised	Continuous, adaptive controls. Access is decided per action using context, identity risk is assessed in real time, revocation is automated and controls are evidenced without manual collection.

The scale lines up with two references most identity teams already use. The CISA Zero Trust Maturity Model Version 2.0 describes four stages, Traditional, Initial, Advanced and Optimal, and its identity pillar covers authentication, identity stores, risk assessments and access management, plus visibility and analytics, automation and orchestration, and governance. Its Traditional stage is close to Level 1 here, and its Optimal stage, with "fully automated, just-in-time lifecycles" and dynamic least privilege, is close to Level 5. NIST CSF 2.0 describes four Tiers (Partial, Risk Informed, Repeatable and Adaptive) for the rigour of risk governance and suggests using them to inform Current and Target Profiles. This model adds a fifth level because organisations need a named step between "defined on paper" and "automated everywhere", and because it scores identity types separately, which neither framework does.

Capability areas

Score each of the eight areas from 1 to 5. Levels 2 and 4 sit between the descriptions shown; the roadmap later on this page lists what moves you from one level to the next.

Area	Level 1 Initial	Level 3 Defined	Level 5 Optimised
Visibility	No reliable inventory; identities found during incidents or audits	Inventory of human, non-human and agent identities with owners, systems and privileges recorded	Continuous, correlated identity graph across directories, cloud, SaaS and agent platforms
Ownership and lifecycle	Manual onboarding and offboarding; NHIs and agents unowned	HR-driven joiner-mover-leaver; ownership, review and decommissioning processes for NHIs and agents	Fully automated lifecycle; ownership moves when teams change; unused identities removed automatically
Authentication	Passwords; inconsistent MFA; static secrets for machines	MFA everywhere; phishing-resistant MFA for administrators; platform-issued workload identity for many workloads	Phishing-resistant MFA for all users; secretless workloads; continuous validation, not only at sign-in
Authorisation and privilege	Broad standing privilege, including for service accounts	Least-privilege roles; dedicated admin accounts; just-in-time access for administrators; privileged NHIs reduced	Zero standing privilege; per-action, context-aware decisions for people, workloads and agents
Governance	Occasional spreadsheet reviews that rarely remove access	Regular, risk-based reviews including NHIs and agents; separation of duties rules	Continuous, event-driven governance with automated remediation
Secrets and credentials	Secrets in code, configuration files and chat	Secrets centralised in approved managers, scanned for and rotated on a schedule	Dynamic, short-lived credentials by default; long-lived secrets are exceptions with expiry dates
Detection and response	Little identity-specific detection; resets only on the obvious account	Identity threat detection for key identity systems; revocation playbooks for accounts, tokens and secrets	Correlated detection across all identity types; automated containment and verified revocation
Programme management	Separate projects with no overall owner	Identity programme with an accountable owner, operating model, roadmap and metrics	Integrated with enterprise risk; outcome-based reporting to the board

Two areas deserve a closer look because they changed most since the model was first published. In authentication, NIST SP 800-63B-4 states plainly that passwords, look-up secrets, out-of-band authentication and OTP authentication are not phishing-resistant, requires a phishing-resistant authenticator with a non-exportable key at AAL3, and requires verifiers to offer at least one phishing-resistant option at AAL2. See the Phishing-Resistant MFA Guide. In secrets and credentials, the OWASP Non-Human Identities Top 10 for 2025 lists secret leakage (NHI2) and long-lived secrets (NHI7) among the most critical NHI risks, which is why Level 3 requires central management and Level 5 requires short-lived credentials. See the Secrets Management Guide.

Assessing by identity type

Score each capability area separately for each identity type, using evidence rather than policy: an inventory export, a sample of reviews, the sign-in methods actually used last month. Take the lowest score among the identity types that can reach your crown-jewel systems as your effective level for that area. A typical result looks like this:

Capability	Workforce	Privileged	Customer	Non-human	AI agents
Visibility	4	3	3	2	1
Ownership and lifecycle	4	3	3	1	1
Authentication	3	3	3	2	1
Authorisation and privilege	3	3	3	2	1
Secrets and credentials	n/a	3	n/a	2	1

This example is illustrative, not survey data. A pattern like it shows that further investment in workforce identity will add little compared with bringing non-human and agent identity to Level 3. Score customer identity against its own risks (account takeover, fraud and recovery). The table below sets out what Level 3 looks like for each type.

Identity type	What Level 3 looks like	Evidence to ask for
Workforce	HR-driven joiner-mover-leaver; MFA for external applications and remote access; access removed on leaving	Leaver sample showing same-day disablement; MFA coverage report
Privileged	Dedicated administrator accounts; MFA for all administrative access, phishing-resistant for the most sensitive; just-in-time elevation	Count of standing admin accounts; sign-in methods used by admins
Customer	A phishing-resistant option offered; recovery and help desk flows protected; fraud signals feed authentication decisions	Share of customers using passkeys or similar; account takeover rate
Non-human	Inventory of service accounts, API keys, OAuth grants and certificates with owners; no human use of service accounts; rotation and decommissioning	Service account inventory with owner and last-used date; oldest credential age
AI agents	A distinct identity per agent, a named human owner, task-scoped and time-bound permissions, human approval for high-impact actions	Agent register; scopes granted per agent; log of approvals and denials

For non-human identities, the CIS Controls require both an inventory of accounts (Safeguard 5.1) and a separate inventory of service accounts (5.5), and CIS notes that service accounts are "sometimes not known about, only to be revealed in standard account management audits". See the Service Account Inventory Template and the NHI Ownership Guide. For AI agents, the OWASP Top 10 for Agentic Applications for 2026 (ASI03, Identity and Privilege Abuse) recommends per-agent identities, short-lived and narrowly scoped tokens per task, and human approval for high-privilege or irreversible actions. If agents are your weakest type, score them in more depth with the Agentic AI Identity Maturity Model; for machines generally, use the NHI Governance Maturity Model.

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

The mapping below links each capability area to the controls auditors and regulators already ask about. Treat it as a sense check, not an equivalence: a control can be implemented at Level 2 or Level 5. CIS Safeguard numbers are those in the CIS Controls Assessment Specification, which version 8.1 keeps; the OWASP column names the NHI Top 10 (2025) and Agentic Top 10 (2026) risks each area addresses.

Capability area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ISO/IEC 27001:2022 Annex A	CIS Controls v8.1	OWASP
Visibility	PR.AA-01	AC-2, IA-4	5.16	5.1, 5.5, 6.6	NHI1
Ownership and lifecycle	PR.AA-01	AC-2, AC-2(3)	5.16, 5.18	5.3, 6.1, 6.2	NHI1, NHI10
Authentication	PR.AA-03, PR.AA-04	IA-2(1), IA-2(2), IA-8, IA-9	8.5	6.3, 6.4, 6.5	NHI4
Authorisation and privilege	PR.AA-05	AC-5, AC-6, AC-6(5)	5.3, 5.15, 8.2	5.4, 6.8	NHI5, ASI03
Governance	PR.AA-05	AC-2, AC-6(7)	5.18	5.3, 6.2, 6.7	NHI1
Secrets and credentials	PR.AA-01	IA-5, IA-5(7), SC-12	5.17	5.2, 16.12	NHI2, NHI7, NHI9
Detection and response	DE.CM-03, DE.AE-02	AC-2(12), AU-6, SI-4	8.15, 8.16	8.2, 8.11	ASI03
Programme management	GV.RR-02, GV.OV-03, ID.IM-01	PM-2, PM-6	5.2	No direct Safeguard	None

CSF 2.0 places identity in the Protect category Identity Management, Authentication, and Access Control (PR.AA), whose PR.AA-01 covers identities and credentials "for authorized users, services, and hardware", so machines are in scope by definition. NIST SP 800-207 sets the direction of travel for Levels 4 and 5: access "granted on a per-session basis" with "the least privileges needed to complete the task", and authentication and authorisation that "are dynamic and strictly enforced before access is allowed". See the Zero Trust Identity Guide.

Self-assessment questions

Answer each question with a number or an artefact, not a yes or no. Where the answer differs by identity type, record each one.

Visibility: can you list every identity, human and non-human, with access to your crown-jewel systems, and how long does it take to produce that list?
Ownership: what percentage of service accounts, API keys, OAuth grants and AI agents have a current, named human owner?
Lifecycle: when a person leaves or a project ends, what removes the service accounts, tokens and agents they created?
Authentication: how many administrators can still sign in with phishable methods, and how many workloads use static secrets rather than platform-issued identity?
Privilege: how many identities hold standing administrative rights, and how many of them are non-human?
Governance: did your last access review remove access, and did it include NHIs and agents?
Secrets: how many live secrets sit outside approved managers, and what is the age of the oldest one in production?
Detection: would you detect a stolen session token, or a service account used from a new host or at an unusual time?
Response: if your identity provider were compromised today, could you list and rotate every credential it touched?
Programme: who is accountable for identity security across all identity types, and what do they report?

Using the results

Identify the lowest-scoring identity types and capability areas that protect your most important systems. A Level 1 in non-human visibility matters more than a Level 3 in customer governance if service accounts reach production data.
Set a realistic 12-month target, typically Level 3 across all identity types, with Level 4 for privileged access and the identity provider.
Build the roadmap and business case. See the Identity Security Programme Guide and the Business Case Guide.
Express the target in the language of your frameworks: a CSF 2.0 Target Profile, ISO 27001 control objectives or a CISA ZTMM stage for the identity pillar, so the result is understood by auditors and the board.
Track progress with the metrics below. See the Identity Security Metrics Guide.
Reassess every six to twelve months, and after any significant identity incident, merger or platform change.

Moving up a level

Sequence matters more than speed. Automating a lifecycle you cannot see, or adding just-in-time access on top of an inventory with no owners, produces faster mistakes. Work through the steps below in order for each identity type.

From Initial to Developing

Build a first inventory of accounts and service accounts for your most critical systems, and record an owner for each one you can.
Turn on MFA for externally exposed applications, remote access and administrative access (CIS Safeguards 6.3, 6.4 and 6.5).
Run secret scanning on your main code repositories and move the secrets it finds into an approved manager.

From Developing to Defined

Connect HR events to account creation and removal, and write a decommissioning process for service accounts and agents. See the Joiner-Mover-Leaver Guide and the NHI Lifecycle Management Guide.
Give administrators dedicated accounts and phishing-resistant MFA, and register every AI agent with a distinct identity and a named owner.
Run risk-based access reviews that include NHIs and agents, and measure how much access each review removes. See the Access Reviews Guide.
Appoint an accountable owner for identity across all types and agree an operating model with platform, cloud and AI teams.

From Defined to Managed

Replace standing administrative rights with just-in-time elevation. See the JIT Access Guide.
Move workloads to platform-issued, short-lived identity and federation instead of stored keys.
Deploy identity threat detection on the identity provider and directories, and script revocation for accounts, sessions, tokens and secrets. See the ITDR Guide.
Report the metrics quarterly and tie exceptions to named owners with expiry dates.

From Managed to Optimised

Make access decisions per action using identity, device and behavioural context, including for agents acting on behalf of users.
Automate remediation from governance events, such as removing an unused grant or disabling an orphaned service account.
Collect control evidence automatically and report identity risk to the board alongside other enterprise risks.

Metrics that show progress

Metric	What it shows	Target direction
Identities with a named owner, by type	Visibility and accountability, especially for NHIs and agents	Up, towards 100%
Identities with standing administrative rights	Progress towards just-in-time and zero standing privilege	Down
Administrator sign-ins using phishing-resistant methods	Authentication strength where it matters most	Up
Median and maximum age of production secrets	Exposure window if a secret leaks	Down
Live secrets found outside approved managers	Secret sprawl in code, configuration and chat	Down
Access removed per review campaign	Whether governance changes anything	Up at first, then stable
Dormant accounts and unused NHIs older than 90 days	Lifecycle discipline	Down
Time to revoke a compromised identity and all its credentials	Response readiness across identity types	Down

Common failure patterns

Workforce-only maturity: the programme scores Level 4 on employee single sign-on and reports that figure to the board, while service accounts and agents sit at Level 1 and carry more privilege.
Rotation that misses machines: in the Cloudflare Thanksgiving Breach 2023, Cloudflare says it failed to rotate "one service token and three service accounts (out of thousands)" leaked in the Okta compromise because "mistakenly it was believed they were unused". Afterwards it rotated more than 5,000 production credentials.
MFA gaps on data platforms: in the Snowflake Breach 2024, Mandiant found the affected customer accounts did not require MFA, credentials stolen by infostealers had in many cases not been rotated for as long as four years, and network allow lists were not used.
Human use of NHIs: engineers sign in as a service account to save time, which OWASP lists as NHI10 because activity can no longer be told apart from automation.
Agents on borrowed identity: agents run on a developer's personal token or a shared key, so their actions cannot be attributed and their access cannot be reviewed.
Reviews that never remove access: reviewers approve everything, and NHIs are excluded because nobody knows who owns them.
Maturity as a tool count: buying a vault, an IGA platform or an ITDR product is recorded as a level gained, without evidence that coverage or outcomes changed.

Practitioner checklist

Score all eight capability areas for each of the five identity types, using evidence.
Report your effective level as the weakest identity type that reaches crown-jewel systems.
Set Level 3 across all types as the 12-month target, with Level 4 for privileged access.
Build one inventory of human, non-human and agent identities with named owners.
Require phishing-resistant MFA for administrators and offer it to customers.
Give every AI agent a distinct identity, an owner and task-scoped, time-bound permissions.
Centralise secrets, scan for leaks and set maximum credential ages.
Include NHIs and agents in access reviews and decommissioning.
Rehearse revocation of a compromised identity provider, service account and agent.
Baseline the eight metrics now and reassess every six to twelve months.

How NHI Mgmt Group can help

We run independent identity, NHI and agentic AI maturity assessments and turn them into prioritised roadmaps and business cases. Browse the NHI and AI products directory or contact us to discuss an assessment.

Identity Security Maturity Model