Identity security programmes are often measured by activity: applications onboarded, reviews completed, tickets closed. Those numbers show effort, not risk reduction. Leadership needs to know whether the organisation is harder to breach through identity than it was last quarter, and teams need metrics that point to where to act next. This guide sets out a practical set of identity security metrics and KPIs covering human, non-human and AI agent identities: how to choose them, how to define and calculate them, where the data comes from and how to report them. It draws on NIST SP 800-55 (December 2024) and maps each area to the main frameworks. It is written for identity leads who own a programme and the CISOs and risk teams who report on it.
Key takeaways
- Measure outcomes, not effort: prefer privileged access removed, credentials made short-lived and time to deprovision over counts of reviews run or policies written.
- Use all four measure types: NIST SP 800-55 separates implementation, effectiveness, efficiency and impact measures; a programme that only reports coverage percentages never shows whether controls work.
- Track coverage and exposure together: how much of the estate a control reaches, and how much risk remains in the part it does not reach, segmented by identity type.
- Count non-human identities and AI agents: they are often the largest and least measured population, and incidents such as the Cloudflare and Snowflake cases turned on a handful of uncounted or unrotated credentials.
- Report few metrics, well defined: a small headline set for leadership with trend, target, owner and next action, backed by a documented formula and data source for every number.
Principles for good identity metrics
A metric earns its place if a change in it would change what someone does. NIST SP 800-55 Volume 1 says metrics "are designed to track progress, facilitate decision-making, and improve performance with respect to a set target", and warns that poorly selected quantitative metrics "can undermine the overall quality of reporting and erode confidence in the work product". Its advice for new programmes is blunt: "With quantitative metrics - initially at least - less is often more." The principles below apply that guidance to identity.
- Risk-linked: each metric connects to a way attackers get in or move, such as phishing an administrator, reusing a leaked secret or abusing a dormant account. If a data point does not illustrate a control's performance or track a material risk, SP 800-55 suggests leaving it out.
- Measurable from data: calculated from identity providers, directories, secrets managers and logs, not from surveys or self-attestation. SP 800-55 lists accuracy, numeric precision, correctness, consistency, a time-based reference, replicability and standardised units as the characteristics of a reliable measure.
- Actionable: a movement points to a specific team, platform or action. "MFA coverage 94%, with the gap in three SaaS applications" beats "MFA coverage 94%".
- Trended: kept consistent and shown over time against a target.
- Segmented: by business unit, platform and identity type, to find where to act.
- Hard to game: pair each coverage metric with an effectiveness metric so a target cannot be hit by narrowing the scope.
The four types of measure
SP 800-55 Volume 1 (which superseded SP 800-55 Revision 1 in December 2024) separates measures into four types. It notes that implementation measures are never fully retired, but once controls are in place the programme should broaden to the other three. Key performance indicators (KPIs) and key risk indicators (KRIs) are, in NIST's words, "examples of metrics, though not all metrics fall into these categories".
| Measure type | What it answers (per SP 800-55) | Identity example |
|---|---|---|
| Implementation | Progress of specific controls, usually as a percentage | Percentage of administrators enrolled in phishing-resistant MFA |
| Effectiveness | How well controls work and whether they meet desired outcomes | Percentage of access removed in review campaigns; leaver accounts found active in reconciliation |
| Efficiency | Timeliness: how quickly controls give feedback and issues are addressed | Median and 95th-percentile time from HR leave date to full deprovisioning; time to revoke a leaked secret |
| Impact | Effect on mission, costs, fines, business value and trust | Identity-related incidents and their cost; audit findings on access control closed |
NIST notes that effectiveness and efficiency together "are often referred to as Program Results". For identity, these are the numbers that show whether the organisation is actually harder to compromise.
Metrics by area
The tables below are a menu, not a mandate: pick two to four metrics per area that match your main risks and data, and add more as the programme matures. "Direction" is the movement that shows progress.
Authentication
| Metric | Type | Direction |
|---|---|---|
| Percentage of workforce users with MFA enforced (not just registered), including SaaS applications outside SSO | Implementation | Up |
| Percentage of administrators using phishing-resistant MFA | Implementation | Up, towards all |
| Percentage of all users with a phishing-resistant authenticator registered | Implementation | Up |
| Number of accounts still able to use legacy or basic authentication | Effectiveness | Down |
| MFA prompts denied or reported as unexpected, per 1,000 users | Effectiveness | Watch trend and investigate spikes |
CISA's Zero Trust Maturity Model describes the Optimal stage for authentication as continuously validating identity "with phishing-resistant MFA, not just when access is initially granted", which makes the share of sessions protected by phishing-resistant methods a useful long-term measure. See the Phishing-Resistant MFA Guide and the MFA Guide.
Privileged access
| Metric | Type | Direction |
|---|---|---|
| Number of standing privileged assignments, split by human and NHI | Effectiveness | Down |
| Percentage of privileged access granted just in time | Implementation | Up |
| Number of tier-zero administrators | Effectiveness | Down, then stable |
| Percentage of privileged sessions brokered and recorded | Implementation | Up |
| Administrators using their dedicated admin account for daily work (email, browsing) | Effectiveness | Down |
See the JIT Access Guide and the Privileged Access Management Guide.
Lifecycle and governance
| Metric | Type | Direction |
|---|---|---|
| Median and 95th-percentile time from HR leave date to full deprovisioning | Efficiency | Down |
| Active accounts belonging to leavers found in reconciliation | Effectiveness | Down, towards none |
| Dormant accounts past the inactivity threshold in your policy | Effectiveness | Down |
| Percentage of access removed in review campaigns (a healthy campaign removes something) | Effectiveness | Above zero; investigate campaigns at zero |
| Percentage of applications covered by automated provisioning and reviews | Implementation | Up |
| Open segregation of duties conflicts without a documented mitigation | Effectiveness | Down |
See the Joiner-Mover-Leaver Guide and the Access Reviews Guide.
Non-human identities
| Metric | Type | Direction |
|---|---|---|
| Total NHIs discovered, by type and platform, and the share recorded in the inventory | Implementation | Inventory share up |
| Percentage of NHIs with a valid, current owner | Implementation | Up |
| Percentage of NHI credentials that are short-lived or platform-issued rather than static | Effectiveness | Up |
| Static secrets older than the rotation policy | Effectiveness | Down |
| Live secrets found outside secrets managers, and median time to revoke | Efficiency | Count down, time down |
| NHIs with administrative or wildcard permissions | Effectiveness | Down |
| Third-party OAuth apps with high-risk scopes | Effectiveness | Down |
| Service accounts used interactively by people | Effectiveness | Down, towards none |
These metrics track the risks in the OWASP Non-Human Identities Top 10 for 2025, including Secret Leakage (NHI2), Overprivileged NHI (NHI5), Long-Lived Secrets (NHI7) and Human Use of NHI (NHI10). See the NHI Ownership Guide, the Secrets Management Guide, the Service Account Security Guide and the SaaS and OAuth App Governance Guide.
AI agents
| Metric | Type | Direction |
|---|---|---|
| Agents discovered versus agents registered | Implementation | Gap down |
| Percentage of agents running on their own identity, not a human's or shared credentials | Implementation | Up |
| Percentage of agents with a named owner | Implementation | Up |
| Agents with administrative or broad delegated access | Effectiveness | Down |
| Percentage of agent credentials that are short-lived, task-scoped tokens | Effectiveness | Up |
| Percentage of high-impact agent actions covered by enforced human approval | Implementation | Up |
| Tested time to stop an agent and revoke its access | Efficiency | Down |
The OWASP Top 10 for Agentic Applications for 2026 lists Identity and Privilege Abuse (ASI03) and recommends per-agent identities, short-lived and narrowly scoped tokens per task, and human approval for high-privilege or irreversible actions. Each translates into a metric above. See the Shadow AI Discovery Guide and the Identity Governance for AI Agents Guide.
Detection and response
| Metric | Type | Direction |
|---|---|---|
| Mean and median time to detect and contain identity-based incidents | Efficiency | Down |
| Percentage of identity systems (IdPs, directories, PAM, secrets managers, agent platforms) sending logs to detection tooling | Implementation | Up |
| High-severity identity posture findings open beyond target | Effectiveness | Down |
| Identity detections validated by testing (for example, a purple-team exercise) in the last period | Effectiveness | Up |
See the ITDR Guide, the ISPM Guide and the AI Agent Observability and Incident Response Guide.
Defining and calculating each metric
Most arguments about identity metrics are about definitions: "percentage of NHIs with an owner" depends on what counts as an NHI, an owner and the scope. SP 800-55 Volume 1 recommends documenting every measure in a standard format so that it can be repeated and traced. Its suggested fields include goal, scope, measure, type, formula, target, evidence, frequency, responsible parties and data source.
A worked example for one NHI metric, using that format (the target is an illustrative example, not a sourced figure):
- ID and goal: NHI-03; every non-human identity can be traced to an accountable person.
- Scope: service accounts, workload identities, API keys and OAuth apps in production cloud tenants and the main identity provider; test environments excluded and reported separately.
- Measure and formula: percentage of in-scope NHIs whose owner field resolves to an active employee in the HR system, divided by all in-scope NHIs discovered.
- Type: implementation.
- Target: for example, an interim target this quarter and a final target of all privileged NHIs owned within a year.
- Evidence and data source: NHI inventory export joined to the HR leavers feed; reconciliation log kept for audit.
- Responsible parties: information owner (platform team), collector (identity governance analyst) and customer (CISO). NIST suggests the collector be a different person from the owner where possible, to avoid a conflict of interest.
The owner check matters: an owner who has left should count as unowned. SP 800-55 also notes that data validity is suspect when a source holds data from only a few parts of the organisation; a metric computed from one IdP cannot speak for SaaS applications with local accounts.
Data sources and automation
Manual metrics decay. SP 800-55 Volume 1 suggests organisations consider automation to make data collection easier, and Volume 2 recommends defining what data to collect, how and at what intervals, and normalising units and formats so results can be aggregated. Typical sources for identity metrics are:
- Identity providers and directories: MFA enforcement, authentication methods used, legacy protocol use.
- HR system: leaver dates, the reference point for lifecycle timing metrics.
- Governance and PAM tools: review outcomes, standing and just-in-time privileged assignments.
- Cloud IAM, secrets managers and secret scanning: service accounts, key age, rotation history, live secrets found and time to revoke.
- Agent platforms and SIEM: registered agents and their identities, log source coverage, time to detect and contain.
Keep the formula and scope with the number, and protect the metric data itself: Volume 2 advises protecting measurement data at the same level as the system it describes, because a list of unowned admin accounts is a target list.
A headline dashboard for leadership
Leadership needs six to eight numbers, not sixty: metrics a non-specialist can follow, that move within a quarter and that link to the main identity risks. Every target below is an example to adapt, not a published benchmark.
| Metric | Why it matters | Example target (illustrative) |
|---|---|---|
| Admins with phishing-resistant MFA | Blocks the most common takeover route for privileged accounts | All administrators |
| Standing privileged assignments | Shrinks the window in which a stolen credential gives admin access | Downward trend each quarter |
| Time to deprovision leavers | Closes insider and orphaned access risk | Same day for privileged users |
| NHIs with a valid owner | Enables every other NHI control | Above 90%, all privileged NHIs |
| Static credentials remaining | Measures progress to short-lived secrets | Downward trend |
| AI agents registered with their own identity | Measures control of the newest identity type | All production agents |
| Open high-severity identity findings | Shows remaining exposure | Downward trend; none past deadline |
| Time to revoke a leaked secret | Shows whether the organisation can respond before abuse | Downward trend; tested at least twice a year |
SP 800-55 suggests recording interim and final targets so progress is visible before a goal is met. For guidance on wider board reporting, see the Board Cyber Risk Reporting Guide; to put money values on identity risk, see the Cyber Risk Quantification Guide.
Reporting tips
NIST SP 800-55 Volume 2 calls translating technical performance data into a form relevant to the reader "a major challenge" of security measurement. It suggests asking which measures tell a more precise risk story, which would drive necessary action, which the recipient will best understand and which deliver risk insight most effectively. Volume 1 adds that a reported measure should come with context: the risk it indicates, whether it fits the risk appetite, the decision or action needed, any compliance issue and the effect on audit readiness.
- Show trends, not snapshots: explain significant movements, including those caused by discovering more identities.
- Pair each metric with an owner and next action: a red metric without an owner is a complaint, not a report.
- Translate to exposure: for example, "privileged accounts exposed to phishing reduced from 120 to 12" says more than "phishing-resistant MFA coverage up 18 points".
- State the scope: say which platforms and identity types a number covers, and what is excluded.
- Report exceptions separately: accepted risks (such as a legacy system that cannot use MFA) should be visible, time-bound and owned. See the Security Exceptions and Risk Acceptance Guide.
- Avoid vanity metrics: policies written, training sessions held and tools deployed show activity, not risk reduction.
- Retire metrics that have done their job: Volume 2 notes that obsolete measures are phased out as targets are reached. Keep a light check so regressions are caught.
Framework mapping
Frameworks rarely prescribe identity metrics, but several require organisations to measure and review security performance, and their identity controls define what the metrics should cover. NIST CSF 2.0 outcome GV.OV-03 states that "Organizational cybersecurity risk management performance is evaluated and reviewed for adjustments needed", and SP 800-53 control PM-6 (Measures of Performance) requires organisations to "Develop, monitor, and report on the results of information security and privacy measures of performance". CA-7 (Continuous Monitoring) includes establishing system-level metrics to be monitored. The table maps each metric area to the controls whose implementation it evidences.
| Metric area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 | OWASP NHI / Agentic |
|---|---|---|---|---|---|
| Measurement and reporting programme | GV.OV-03, ID.IM-01 | PM-6, CA-7 | 5.35, 5.36 | No specific safeguard | Not applicable |
| Authentication coverage | PR.AA-03 | IA-2(1), IA-2(2) | 5.17, 8.5 | 6.3, 6.4, 6.5 | NHI4 |
| Privileged access | PR.AA-05 | AC-6, AC-6(5), AC-6(7) | 8.2 | 5.4 | NHI5, ASI03 |
| Lifecycle and governance | PR.AA-01, PR.AA-05 | AC-2, AC-2(3), IA-4 | 5.16, 5.18 | 5.1, 5.3, 6.1, 6.2, 6.8 | NHI1 |
| NHI inventory, ownership and credentials | PR.AA-01 | IA-5, IA-9, CM-8 | 5.9, 5.17 | 5.5 | NHI2, NHI7, NHI9, NHI10 |
| AI agent identity and authority | PR.AA-01, PR.AA-05 | AC-6, IA-9 | 5.16, 8.2 | 5.5, 6.8 where agents use service accounts and roles | ASI03 |
| Detection and response | DE.CM-03, PR.PS-04 | AC-2(12), AU-6, SI-4, IR-5 | 8.15, 8.16 | 8.2, 8.11 | ASI03 (monitoring delegated permissions) |
CIS Controls v8.1 is an update to v8 that CIS describes as backwards compatible. Annex A numbers follow the 2022 edition. If your programme reports against zero trust, the CISA Zero Trust Maturity Model's identity pillar functions are a useful way to group these metrics. See the Identity Security Maturity Model.
Common failure patterns
- Measuring the denominator you know about: coverage is calculated against the inventory, not the estate, so unknown identities never count. In the Cloudflare Thanksgiving Breach 2023, Cloudflare said it failed to rotate one service token and three service accounts "(out of thousands)" after the Okta compromise, because "mistakenly it was believed they were unused". A rotation metric close to complete still left the way in.
- MFA coverage that stops at SSO: a workforce MFA figure from the identity provider says nothing about applications with local accounts. Mandiant reported that the Snowflake customer instances compromised in 2024 did not require MFA and in many cases had credentials not rotated "for as long as four years". See the Snowflake Breach 2024.
- Activity dressed as outcome: "4,000 access reviews completed" with almost nothing removed suggests rubber-stamping, not assurance.
- Averages that hide the tail: a mean deprovisioning time of one day can hide a handful of privileged leavers still active weeks later. Report the 95th percentile and the outliers.
- Human-only scorecards: dashboards that leave out service accounts, API keys, OAuth apps and AI agents miss much of the estate.
- Owner fields that point to leavers: ownership percentages that do not check the owner is still employed overstate accountability.
- Metrics without definitions: numbers that change when the analyst changes lose leadership confidence quickly.
Implementation roadmap
SP 800-55 Volume 2 describes a five-step workflow for a measurement programme: evaluate and define the existing security programme, identify and prioritise measures, collect and analyse data, identify corrective actions and apply them. The phases below apply that workflow to identity; timings are an example.
| Phase | Focus | Outputs |
|---|---|---|
| First 30 days | Evaluate and define: agree goals with leadership, list identity data sources, choose 8-12 candidate metrics across the six areas | Metric catalogue with draft definitions; data source map; named owner per metric |
| Days 31-90 | Collect and baseline: automate extraction for the headline set, validate data quality, reconcile inventories (including NHIs and agents) | Baseline values; first leadership dashboard with trends starting; documented exclusions |
| Days 91-180 | Set targets and act: agree interim and final targets, link red metrics to remediation plans, add effectiveness and efficiency measures | Targets approved; corrective actions tracked; quarterly report to the risk committee |
| After 180 days | Mature: add impact measures, test response times (secret revocation, agent kill switch), retire metrics that have reached target | Annual metric review; updated catalogue; independent check of data quality |
Volume 2 advises giving each stakeholder as few measures as possible, so owners have time to close gaps. See the Identity Security Programme Guide.
Practitioner checklist
- Select metrics across authentication, privileged access, lifecycle, NHIs, AI agents and detection, using all four measure types.
- Document each metric with scope, formula, data source, frequency, target and owner.
- Include non-human identities and AI agents in every coverage denominator.
- Automate data collection from identity providers, HR, PAM, cloud IAM, secrets managers and agent platforms.
- Report the 95th percentile and outliers for timing metrics, not just averages.
- Agree interim and final targets, labelled as your own, from the baseline and risk appetite.
- Report a small headline set to leadership with trend, owner and next action.
- Test response metrics (secret revocation, leaver removal, agent shutdown) rather than relying on configuration.
- Review the metric catalogue at least annually and retire measures that have done their job. See the Leaked Credential Response Playbook for the revocation test.
Standards and references
- NIST: SP 800-55 Vol. 1, Measurement Guide for Information Security: Identifying and Selecting Measures
- NIST: SP 800-55 Vol. 2, Measurement Guide for Information Security: Developing an Information Security Measurement Program
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
- CIS: Critical Security Controls v8.1
- CIS: Controls Assessment Specification, Control 5 Account Management
- CISA: Zero Trust Maturity Model
- OWASP: Non-Human Identities Top 10 2025
- OWASP: Top 10 for Agentic Applications for 2026
- Cloudflare: Thanksgiving 2023 security incident
- Google Cloud (Mandiant): UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion
Related NHI Mgmt Group resources: Identity Security Programme Guide · Business Case Guide · Board and CISO Briefing · Identity Security Maturity Model