ITDR and ISPM Maturity Model: Five Levels

Most organisations can tell you how many identity alerts they received last month, but few can say how much of their identity estate those alerts could actually see. This model scores identity visibility, identity security posture management (ISPM) and identity threat detection and response (ITDR) together, on NHI Mgmt Group's five levels: Ad hoc, Developing, Defined, Managed and Optimised. It is for identity, security operations and detection engineering leads who need to baseline their capability, agree a target level and plan the next twelve months. What ISPM and ITDR are, and how they differ, is covered in the ISPM vs ITDR guide and the ITDR Guide; this page only measures how far along you are.

Key takeaways

Coverage caps the score. A strong detection stack that sees only the workforce identity provider is Level 2, because attackers move to the directories, cloud roles and machine credentials it cannot see.
Posture and detection mature together. Score both in each of eight capability areas; a gap in one becomes the attacker's route around the other.
Level 3 is the first realistic target: an identity inventory that includes non-human identities, scheduled posture checks against a written baseline, and tested detections for the core identity techniques.
Level 4 is about speed and evidence: continuous posture drift detection, measured time from identity alert to revoked session, and regular detection testing.
Measure what an attacker would exploit: share of identities with telemetry, standing privilege, unowned machine identities and containment time, not alert volume.

The five levels

Level	Name	What it looks like
1	Ad hoc	Identity logs stay in each system at default retention. Nobody owns identity detection. Misconfigurations such as accounts without MFA, dormant administrators or never-expiring keys are found during audits or incidents. Service accounts and API keys are invisible.
2	Developing	Sign-in and audit logs from the main identity provider reach a SIEM. The provider's built-in risk policies are on. Some posture checks run, often as a one-off assessment or a spreadsheet. Directory, cloud IAM and SaaS identities are partly covered; non-human identities are listed only where someone happened to look.
3	Defined	A written identity security baseline exists and is checked on a schedule. Telemetry from directories, identity providers, cloud IAM and priority SaaS is centralised with defined retention. An inventory covers human and non-human identities with owners. Detections exist for the core techniques, and an identity compromise playbook says who revokes what.
4	Managed	Posture drift is detected within hours, with findings routed to owners and tracked to closure. Detections are tested and tuned against attack simulations. Non-human identities have behavioural baselines. Containment times are measured and reported monthly. Identity risk signals are shared between systems so that one revocation reaches the others.
5	Optimised	Identity posture and threat signals drive access decisions in real time: risk raises step-up, shortens sessions or revokes tokens automatically. Standing privilege is the exception. AI agents and workloads are covered like people. Detection content is version-controlled, tested on every change and improved after every incident and exercise.

Capability areas

Score each of the eight areas separately and take the lowest score in the visibility row as the ceiling for the rest: you cannot detect or fix what you do not see. The Identity Visibility, Posture and Threat Detection Guide gives the field overview behind these areas.

Capability area	Level 1 Ad hoc	Level 3 Defined	Level 5 Optimised
1. Identity inventory and visibility	No single list; each team knows its own accounts	Correlated inventory of human and non-human identities across directory, identity provider, cloud and priority SaaS, each with an owner	Continuous discovery, including AI agents, OAuth grants and workload identities, reconciled daily with HR and CMDB records
2. Telemetry and logging	Default retention in each console	Sign-in, audit, directory and cloud IAM logs centralised; retention set by policy; gaps documented	Complete telemetry for every identity system, integrity-protected, with alerting when a log source goes quiet
3. Posture baseline and assessment	Findings only from audits and penetration tests	Written baseline (MFA coverage, privileged roles, dormant accounts, credential age, federation trusts) checked at least monthly	Policy as code; drift detected and, for agreed low-risk findings, fixed automatically
4. Privilege and exposure analysis	Administrators counted by hand, if at all	Standing privilege reported per platform; attack paths to tier 0 reviewed quarterly	Effective permission and attack path analysis across systems, with standing privilege near zero
5. Detection coverage	Vendor default alerts only	Detections mapped to ATT&CK for the core identity techniques (table below), each with a named owner	Coverage measured per technique and per identity type, including non-human identities and agents
6. Detection validation	Never tested	Detections tested at build time and after major changes	Continuous testing through simulation in the release pipeline, with failures blocking change
7. Response and containment	Password reset by the help desk	Playbook covering session and refresh token revocation, credential reset, removal of persistence and verified recovery	Automated containment for high-confidence signals; revocation shared to relying applications
8. Governance and reporting	No owner	Named owner for identity threat and posture; monthly metrics to the security leadership	Board-level reporting against agreed tolerances; lessons from incidents and exercises tracked to closure

Detection coverage benchmark

Level 3 requires a tested detection, with an owner, for each technique below. All IDs are from MITRE ATT&CK v20.

Technique	ATT&CK ID	Signal that shows it
Valid Accounts: Cloud Accounts	T1078.004	Sign-in from new infrastructure or country for an account, including service and workload accounts
Multi-Factor Authentication Request Generation	T1621	Bursts of denied MFA prompts followed by an approval
Steal Web Session Cookie	T1539	Same session or token used from two devices or networks
Steal Application Access Token	T1528	New OAuth consent to an unfamiliar application with high-risk scopes
Account Manipulation	T1098	New credential added to a service principal, new role assignment, new MFA method registered after a reset
Modify Authentication Process	T1556	Changes to federation settings, authentication policies or conditional access exclusions
Unsecured Credentials: Credentials In Files	T1552.001	Use of a key or token that secret scanning has reported as exposed

Self-assessment questions

Answer for production and for privileged identities first. A control that exists but covers only part of the estate scores no higher than Level 2.

Inventory: what share of your identities, human and non-human, appear in one correlated inventory with an owner? If you cannot give a number, you are at Level 1 or 2 for this area.
Telemetry: for each identity system (directory, identity provider, cloud IAM, top SaaS, secrets manager), are logs centralised, how long are they kept, and would you notice if one stopped arriving?
Baseline: is there a written identity security baseline, and when was the estate last checked against it?
Privilege: how many standing administrators exist in each tier 0 system today, and how has that number moved in the last quarter?
Machine identities: could you detect a service account or API key being used from a host or network it has never used before? In the Snowflake breach, credentials stolen years earlier still worked and logged in from attacker infrastructure.
Detection: which of the seven benchmark techniques have a detection that was tested in the last six months?
Response: after a confirmed account takeover, how long does it take to revoke sessions and refresh tokens, and who is authorised to do it out of hours?
Persistence: does your playbook check for new MFA methods, application credentials, OAuth grants, federation trusts and role assignments, not just the password?
Reporting: which identity metrics does senior leadership see, and are tolerances agreed for them?

Scoring

Score each capability area from 1 to 5 using the table and the evidence you can produce, not intentions.
Cap every area at the score for area 1 plus one: visibility limits everything else.
Report the median as the headline level and the lowest score as the priority.
Repeat every six months and after any identity incident.

Moving up: roadmap

Level 1 to Level 2: get the logs and the obvious gaps

Centralise identity provider telemetry: sign-in, audit and risk events into the SIEM with retention set by policy. See the Identity Telemetry Requirements guide for the fields to collect.
Turn on built-in protections: the identity provider's risk-based policies and admin change alerts.
Run a first posture assessment: MFA coverage by method, standing administrators, dormant accounts, never-expiring credentials.

Level 2 to Level 3: define and cover

Write the baseline: a short, testable list of identity settings and thresholds, owned by the identity team. Configuration baselines such as CISA's Secure Cloud Business Applications (SCuBA) baselines for Microsoft 365 and Google Workspace are useful starting points.
Extend telemetry: directories, cloud IAM, priority SaaS and the secrets manager, so non-human identities are visible.
Build the inventory: correlate accounts across systems and assign owners, starting with privileged and machine identities. See the ISPM Guide.
Cover the benchmark techniques: one owned, tested detection for each row of the benchmark table.
Write the identity compromise playbook: containment order, persistence checks and verified recovery, aligned with NIST SP 800-61 Rev. 3, the CSF 2.0 incident response profile.

Level 3 to Level 4: measure and test

Detect drift continuously: move from monthly checks to event-driven checks on role assignments, policy changes and new credentials.
Test detections regularly: simulate each benchmark technique and track pass rates. See the ITDR validation guide.
Baseline machine identities: expected source networks, call volumes and target resources for each service account and key.
Share signals: use the OpenID Shared Signals Framework and CAEP 1.0 (final, 29 August 2025), whose event types include session revoked, credential change and risk level change, so revocation reaches relying applications. See the Shared Signals Framework Guide.
Hunt: run hypothesis-led hunts on identity data each quarter. See the Identity Threat Hunting Guide.

Level 4 to Level 5: make it adaptive

Feed risk into access: posture and threat signals change session length, require step-up or revoke tokens automatically.
Remove standing privilege: just-in-time elevation for administrators and scoped, short-lived credentials for workloads and agents.
Treat detections as code: version control, peer review and automated tests on every change.

Metrics by level

Metric	Why it matters	Level 3 expectation	Level 5 expectation
Share of identity systems sending telemetry to the central platform	Sets the ceiling for detection	All tier 0 systems and priority SaaS	Every identity system, with silence alerts
Share of non-human identities with a named owner	Unowned identities are not monitored or offboarded	All privileged NHIs	All NHIs and agents
Standing privileged accounts per tier 0 system	The prize in most identity attacks	Known, reported, falling	Near zero, elevation on demand
Median time to close a high-risk posture finding	Shows posture work turns into fixes	Measured and reported monthly	Hours, many fixed automatically
Benchmark techniques with a passing test in the last quarter	Shows detections still work	All seven tested at least once	All seven tested continuously
Time from high-severity identity alert to revoked sessions and tokens	Limits how long an attacker keeps access	Measured for every incident	Minutes, often automated

For how these feed board reporting, see the Board Cyber Risk Reporting Guide.

How the model maps to frameworks

Framework	Reference	Capability areas
NIST CSF 2.0	PR.AA-01 identities and credentials managed	1, 3, 4
NIST CSF 2.0	DE.CM-03 personnel activity and technology usage monitored; DE.AE-02 adverse events analysed	2, 5, 6
NIST CSF 2.0	RS.MI-01 incidents contained; GV.OV-01 strategy outcomes reviewed	7, 8
NIST SP 800-53 Rev. 5	AC-2 Account Management; IA-5 Authenticator Management	1, 3, 4
NIST SP 800-53 Rev. 5	AU-6 Audit Record Review, Analysis, and Reporting; SI-4 System Monitoring	2, 5, 6
OWASP Non-Human Identities Top 10 (2025)	NHI1 Improper Offboarding; NHI5 Overprivileged NHI; NHI10 Human Use of NHI	1, 4, 5
MITRE ATT&CK v20	Benchmark techniques listed above	5, 6

For the zero trust view of identity maturity, the CISA Zero Trust Maturity Model Guide covers the identity pillar; this model is narrower and goes deeper on detection and posture.

Common failure patterns

Scoring the tool, not the coverage: buying an ITDR or ISPM product and scoring Level 4, while half the identity systems send it nothing.
Human identities only: detections and posture checks that ignore service accounts, keys and OAuth applications, the identities attackers use for quiet persistence.
Findings with no owner: posture reports that list thousands of issues nobody is assigned to fix, so the backlog grows each month.
Password reset as containment: resetting a password while refresh tokens, new MFA methods and added app credentials stay valid.
Untested detections: rules that stopped firing after a log schema or licence change and nobody noticed.

Practitioner checklist

Score all eight capability areas with evidence and cap each by the visibility score plus one.
List every identity system and confirm its logs reach the central platform with defined retention.
Publish a written identity security baseline and check the estate against it at least monthly.
Include non-human identities and AI agents in the inventory, each with a named owner.
Build and test a detection for each of the seven benchmark techniques.
Make the identity compromise playbook cover sessions, refresh tokens, MFA methods, app credentials, OAuth grants and federation trusts.
Measure time from high-severity identity alert to revoked access for every incident.
Reassess every six months and after every identity incident, and report the trend.

Standards and references

Related NHI Mgmt Group resources: ITDR Guide · ISPM vs ITDR · Identity Security Maturity Model · NHI Governance Maturity Model · ITDR Buyer's Guide

ITDR and ISPM Maturity Model: Five Levels for Identity Threat Detection and Posture