NHI Programme Metrics: Outcome KPIs and KRIs

Most non-human identity (NHI) programmes report activity, such as accounts discovered and secrets rotated, but cannot show the board that the organisation is less likely to be breached through a machine credential than it was a year ago. Activity counts tell the programme team what to do next; they do not tell a risk committee whether the money is working. This guide is about the second layer: a small set of outcome KPIs and key risk indicators (KRIs) that show NHI risk going down, how to baseline and target them, and how to report them in business terms. It assumes you already run operational hygiene measures such as ownership, rotation and dormancy, and it is written for NHI programme leads, IAM heads and CISOs who own the quarterly or half-yearly report to an executive or board committee.

Key takeaways

Separate hygiene from outcomes. Rotation and ownership rates are implementation measures; the board needs effectiveness and impact measures that show reduced exposure, contained blast radius and fewer NHI-driven incidents.
Measure what a stolen credential could do. The most persuasive outcome metrics describe an attacker's position: how long a leaked secret stays usable, and how many NHIs can reach crown-jewel data.
Five to seven KPIs is enough. Pick a few outcome measures with fixed definitions and a trend line, and push the rest into the operational dashboard.
Baseline before you promise. Mark first-year targets as interim and set them from your own measured starting point, not from a peer figure you cannot verify.
Tie every KRI to risk appetite. A KRI needs a threshold the board has agreed, so that a red result triggers a decision rather than a discussion.

Operational metrics versus programme outcome metrics

NIST SP 800-55 Vol. 1 (December 2024) separates information security measures into four types: implementation (progress on specific controls), effectiveness (whether controls achieve their intended outcome), efficiency (how timely controls are) and impact (the link to mission, cost and trust). Most NHI dashboards stop at implementation. That is the right place to start and the wrong place to finish.

Layer	SP 800-55 type	Question it answers	Audience	NHI examples
Hygiene	Implementation	Are we doing the controls?	Programme team, platform owners	Owner assigned, credentials rotated on time, NHIs in access reviews
Control performance	Effectiveness and efficiency	Do the controls work, and fast enough?	CISO, IAM head	Leaked secrets still valid at detection, new NHIs compliant at creation, detection test pass rate
Risk outcome	Impact	Is the business less exposed, and what did it avoid?	Executive committee, board, audit committee	NHI-involved incident rate, crown-jewel reachability, exception debt

Hygiene metrics are covered in depth by the operational health check for the programme. This guide does not repeat them; it uses them as inputs. For the wider identity estate, see the Identity Security Metrics Guide, and for building any security metrics programme, the Security Metrics and KPIs Programme Guide.

Outcome KPIs that show NHI risk reduction

Each KPI below is defined so that two people calculating it from the same data get the same number. IDs use the prefix NHIM so they do not clash with operational measures.

ID	KPI	Formula	What it proves	Good direction
NHIM-01	Maximum usable life of a Tier 1 credential	Longest configured validity (TTL, expiry or rotation interval, whichever is longest) across credentials of Tier 1 NHIs, reported as the 95th percentile in days	How long a stolen privileged machine credential would keep working without anyone acting	Down, ideally to hours for federated and dynamic credentials
NHIM-02	Leaked secrets still valid at detection	Secrets found by internal or external scanning that still authenticated when tested ÷ all such secrets found in the period	Whether short-lived credentials and fast rotation actually neutralise leaks	Down
NHIM-03	Crown-jewel reachability	Count of NHIs that hold a direct or one-hop path to read or change data in systems on the [crown-jewel list], from entitlement and attack path analysis	Blast radius: how many machine identities an attacker could use to reach what matters most	Down, with every remaining path justified
NHIM-04	Compliant at creation	New NHIs in the period created through an approved pattern with owner, tier and a preferred credential type ÷ all new NHIs found	Whether guardrails stop new debt, so clean-up is not a treadmill	Up
NHIM-05	NHI-involved incident share	Security incidents (severity [2] and above) in which an NHI credential was the initial access, persistence or escalation path ÷ all incidents of that severity, rolling 12 months	Whether NHIs are a rising or falling share of real harm	Down; count and share both reported
NHIM-06	NHI exception debt	Open NHI risk acceptances and policy exceptions past their expiry date, weighted by tier (Tier 1 = 3, Tier 2 = 2, Tier 3 = 1)	Whether accepted risk is being retired or quietly made permanent	Down
NHIM-07	NHI abuse detection rate in testing	Simulated NHI misuse scenarios in red or purple team exercises that raised an alert within [the agreed time] ÷ scenarios run	Whether the SOC would see a stolen machine credential being used	Up

Notes on the definitions

NHIM-01: use the configured maximum, not the average age. Averages hide the single long-lived administrator key that matters. Count a non-expiring secret as the time since it was issued.
NHIM-02: only test validity through an approved, logged process using a read-only call, and record who ran it. A leaked key in public code for years, as in the Toyota T-Connect key exposure, is the case this KPI is meant to catch.
NHIM-03: agree the crown-jewel list with the business before the first report; it is the denominator of the story you tell. See the Identity Attack Paths Guide.
NHIM-05: classify the NHI involvement during the post-incident review, not afterwards from memory. The NHI incident metrics page covers response timing; this KPI only counts involvement.
NHIM-07: scenarios should include a cloud access key used from a new network, a CI/CD token used outside the pipeline and a service account signing in interactively. See the Detection Engineering for Non-Human Identities Guide.

Key risk indicators and thresholds

KPIs show progress; KRIs warn that risk is moving outside appetite. NIST CSF 2.0 asks that risk management strategy outcomes are reviewed (GV.OV-01) and that performance is evaluated and adjusted (GV.OV-03); a KRI with an agreed threshold is how that becomes routine.

KRI	Trigger example	Decision it should prompt	Decision owner
Tier 1 credential with no expiry	Any count above [0] for more than [30] days	Fund migration to federation or approve a time-limited exception	[CISO]
Valid secret found in public code or a supplier's repository	Any occurrence	Incident declared; review of supplier secret-handling clauses	[CISO], [Head of Procurement]
Rise in crown-jewel reachability (NHIM-03)	Increase of more than [10]% quarter on quarter	Architecture review of the new paths before further onboarding	[Chief Architect]
Third-party integrations with write access to crown-jewel data	Above the agreed ceiling of [n]	Re-approve each, or reduce scope	[Business owners]
Expired NHI exceptions (NHIM-06)	Weighted score above [x]	Exception owners attend the risk committee	[Risk committee chair]

Thresholds are set by your risk appetite statement (CSF GV.RM). If there is no appetite statement for machine identity yet, propose one alongside the first report.

Baselines, targets and attribution

Freeze definitions first. Write each KPI into a metric dictionary with its formula, data source, owner and exclusions before collecting any data. Changing a formula later breaks the trend, which is the only thing the board will remember. The Board Cyber Risk Reporting Guide covers the reporting side.
Measure one or two quarters before setting targets. SP 800-55 Vol. 1 describes starting effectiveness and efficiency measures from average outputs and acceptable ranges, often from historical data. Use your own starting values.
Set interim and final targets. SP 800-55 allows interim targets alongside final ones. For example, NHIM-01 for Tier 1 might move from [365] days to [90] in year one and to [24 hours] once federation covers the main platforms.
Attribute change to work. When a KPI moves, record which project caused it (for example, CI/CD moved to OIDC federation in Q2). Without that link, improvements look like luck and slippage looks like failure.
Handle denominator shocks. A new discovery source can add thousands of NHIs overnight and make every percentage worse. Report the change as found risk, restate the baseline and show both lines for one quarter.

Reporting to the board

A board report on NHI risk should fit on one page plus an appendix. Directors want to know whether exposure is rising or falling, why, and what decision is needed from them.

Report element	Content	Source
Headline	One sentence on direction, for example "A stolen privileged machine credential now stays usable for at most 30 days, down from a year."	NHIM-01
Three to five KPIs with trend	Current value, previous two periods, interim target, RAG status	NHIM-01 to NHIM-07
KRIs in breach	Which KRI crossed its threshold, why, and the action under way	KRI table
External context	One relevant public incident and how the organisation would have fared	Incident review
Decision requested	Funding, risk acceptance or policy approval, with the owner named	Programme lead
Appendix	Definitions, data sources, known gaps in coverage	Metric dictionary

Use a recent incident as a test the board can follow. In the Cloudflare Thanksgiving breach, a service token and three service account credentials were skipped during a rotation because they were wrongly believed to be unused. Asking "would our rotation have missed them?" turns NHIM-02 and last-used data into a question directors can judge. The Board Briefing: NHI Risk gives the wider framing, and the Board Cyber Report Template a layout.

Implementing the KPI set

Agree scope and the crown-jewel list with the CISO and business owners. Without the list, NHIM-03 and the board headline have no anchor.
Choose five KPIs from the table. Small organisations usually start with NHIM-01, NHIM-02, NHIM-04 and NHIM-05; large ones add NHIM-03 and NHIM-07 once attack path and red team data exist.
Map each KPI to a data source: inventory of record, secrets scanning results, entitlement analysis, incident records, exception register, exercise reports. Record gaps rather than estimating.
Pilot one quarter internally. Run the numbers, have a second person recalculate two of them, and fix definitions that produced disputes.
Present a baseline report with no targets, then agree interim targets and KRI thresholds with the risk committee.
Automate collection for any KPI that took more than a day to compile. Manual metrics decay first.
Review the set annually. Retire a KPI once it has been green for a year and the control is embedded, and replace it with the next most important exposure.

Choosing metrics for your organisation

Early programme (no full inventory): report NHIM-02 and NHIM-05 with clear caveats about coverage. They rely on scanning and incident data you already have.
Cloud-native estate: NHIM-01 and NHIM-04 move fastest because federation and policy guardrails are available on the major platforms; lead with them.
Large regulated enterprise: add NHIM-06 because auditors and regulators will ask about long-standing exceptions, and NHIM-03 because crown-jewel analysis already exists for operational resilience work.
Heavy SaaS and third-party integration: add the third-party KRI and track OAuth integrations with write scopes as a separate line.

Common failure patterns

Counting discoveries as success: "we found 40,000 NHIs" is a finding, not an outcome. Report it once as the size of the problem, then report the trend in exposure.
Averages that hide the tail: mean credential age falls while one non-expiring cloud administrator key stays in place. Use maximum or percentile values for Tier 1.
Targets copied from elsewhere: a target with no baseline is missed or met by redefining the population. Both damage trust in the report.
Green dashboards, unchanged incidents: hygiene KPIs improve while NHIM-05 does not move. That usually means the controls cover the easy platforms and not the ones attackers use, such as CI/CD and SaaS integrations.
No decision attached: a red KRI reported for three quarters with no owner or deadline teaches the board to ignore the page.

Framework mapping

Framework	Reference	Relevance to this KPI set
NIST CSF 2.0	GV.OV-01, GV.OV-03	Strategy outcomes reviewed; performance evaluated and adjusted
NIST CSF 2.0	GV.RM-04	Risk response options communicated (KRI decisions)
NIST CSF 2.0	PR.AA-01, PR.AA-05	Service credentials managed; least privilege (NHIM-01, NHIM-03)
NIST CSF 2.0	ID.IM-01	Improvements identified from evaluations (annual KPI review)
NIST SP 800-53 Rev. 5	PM-6	Develop, monitor and report security measures of performance
NIST SP 800-53 Rev. 5	IA-5, AC-6	Authenticator management; least privilege
OWASP NHI Top 10 2025	NHI2, NHI3, NHI5, NHI7	Secret Leakage; Vulnerable Third-Party NHI; Overprivileged NHI; Long-Lived Secrets

Practitioner checklist

Keep hygiene metrics on the operational dashboard and report outcome KPIs upward.
Write a metric dictionary entry for each KPI before collecting data.
Agree the crown-jewel list with business owners.
Report Tier 1 credential lifetime as a maximum or 95th percentile, never an average.
Test leaked secret validity only through an approved, logged process.
Classify NHI involvement in every post-incident review.
Baseline for at least one quarter, then set interim targets.
Give every KRI a threshold, a decision and an owner.
Restate baselines openly when discovery widens the population.

Standards and references

Related NHI Mgmt Group resources: NHI incident metrics · NHI Programme Roadmap · Identity Security Metrics Guide · Board Briefing: NHI Risk

NHI Programme Metrics: Outcome KPIs That Prove Risk Reduction to the Board