NHI Risk Scoring Guide: Prioritising Machine Identity Risk

Once an organisation inventories its non-human identities, it usually finds far more service accounts, roles, keys and OAuth apps than it can fix at once, and without a scoring model the remediation queue is ordered by whoever complains loudest. NHI risk scoring ranks machine identities by how much damage each could do and how likely it is to be misused, so effort goes to the identities that matter first. This guide sets out a transparent, explainable factor model built on five factors (privilege, exposure, age, ownership and usage), shows how to calculate and calibrate it, and explains how to turn scores into action through tiers, review cadence and remediation deadlines. It is for identity, cloud security and risk teams building or evaluating NHI prioritisation, whether in a spreadsheet or in a commercial platform. The weights and thresholds shown are starting points to adapt, not industry benchmarks.

Key takeaways

Score impact and likelihood separately. Privilege drives what an identity could do if misused; exposure, credential age, missing ownership and odd usage drive how likely misuse is. Combining them the way the OWASP Risk Rating Methodology does keeps the model explainable.
Prefer a transparent model over a black box. Every score should be traceable to the facts behind it, so an owner can see what to change to lower it and an auditor can see why an item was prioritised.
Use platform data, not questionnaires. Attached permissions, last-used dates, credential age and secret scanning hits are available from cloud and identity platforms and keep the score current.
Apply override rules for known-bad states. A leaked, valid credential or a confirmed-compromised identity is critical whatever the arithmetic says.
Scores must drive action. Tie each tier to a review cadence, a remediation deadline and an owner, and measure whether high-risk counts fall.

Why NHIs need their own risk model

Human identity risk models lean on signals that NHIs do not have: MFA status, device posture, impossible travel, HR attributes. Machine identities have different risk drivers. OWASP's Non-Human Identities Top 10 2025, which was itself compiled using the OWASP Risk Rating Methodology, names them: improper offboarding (NHI1), secret leakage (NHI2), vulnerable third-party NHI (NHI3), insecure authentication (NHI4), overprivileged NHI (NHI5), insecure cloud deployment configurations (NHI6), long-lived secrets (NHI7), environment isolation (NHI8), NHI reuse (NHI9) and human use of NHI (NHI10). A useful NHI score measures exposure to these, using attributes you can collect automatically. See the Top 10 NHI Risks.

NHI risk scoring is not vulnerability scoring. CVSS and similar systems score a flaw in software; an NHI score rates an identity, its permissions and its credential. The two meet where a vulnerability exposes a credential, but they answer different questions. For software flaws, see the Vulnerability Prioritisation Guide.

The five-factor model

The model below scores each factor from 0 to 9, following the scale used in the OWASP Risk Rating Methodology. Privilege is the impact factor. Exposure, age, ownership and usage are likelihood factors.

Factor	Role	What it measures	Main data sources	OWASP NHI link
Privilege	Impact	What the identity can do and reach: admin rights, write vs read, number of resources, data sensitivity, ability to grant itself more access	Attached policies and role assignments, API scopes, consent grants, resource tags for data classification	NHI5
Exposure	Likelihood	How reachable and stealable the credential is: static secret vs federated or managed identity, where it is stored, network restrictions, known leaks	Credential type, vault metadata, secret scanning results, conditional access or IP restrictions, third-party holders	NHI2, NHI3, NHI4, NHI9
Age	Likelihood	How long the credential has been valid and when it expires	Key creation date, last rotation, expiry date	NHI7
Ownership	Likelihood	Whether a current, accountable owner exists and has recently attested	Owner field vs HR status, last attestation date	NHI1
Usage	Likelihood	Whether the identity is used, and whether its use looks normal: dormant, unused permissions, interactive or human use, new locations	Last authentication, last accessed data, unused access findings, identity threat detections	NHI1, NHI10

Ownership and usage are listed as likelihood factors because an unowned or dormant identity is less likely to be noticed if misused and more likely to hold a forgotten credential, not because they change what the identity can do.

Scoring each factor

The rubrics below are illustrative. They show the level of specificity a rubric needs so two analysts score the same identity the same way. Adjust the anchors to your platforms and data classifications.

Privilege (impact)

Score	Anchor
9	Can change identity or access configuration tenant-wide or organisation-wide (for example cloud account administrator, directory role assignment, application permission to read all mailboxes), or holds a signing key trusted by production
7	Write or delete access to production data stores or deployment pipelines, or broad read of regulated data
5	Write access to a single production application's resources
3	Read access to internal, non-sensitive resources
1	Read-only, single resource, no sensitive data, non-production with no path to production

Likelihood factors

Factor	Low (0 to 2)	Medium (3 to 5)	High (6 to 9)
Exposure	Managed identity or workload identity federation, no static secret	Static secret stored in a vault, network-restricted	Static secret in code, config files, CI variables or shared with a third party; any secret scanning hit
Age	Short-lived or auto-rotated within policy	Rotated within the last year, has an expiry	No expiry, or not rotated for more than a year
Ownership	Active owner and backup owner, attested this cycle	Active owner, attestation overdue	Owner left or unknown; orphaned
Usage	Used regularly, matching its purpose, permissions largely used	Used, but with a large share of unused permissions	Dormant but enabled; or sudden use after dormancy, interactive human sign-in, or threat detection

Dormancy thresholds should follow your policy. CIS Safeguard 5.3 uses 45 days of inactivity for disabling dormant accounts; Google Cloud service account insights flag accounts that have not authenticated in the past 90 days; Google's Event Threat Detection alerts when a service account inactive for more than 180 days takes an action. Identities that run monthly or quarterly batch jobs need an exception recorded against them, or they will score as dormant for most of the cycle.

Calculating and banding the score

Keep the arithmetic simple enough to explain in one sentence. A workable approach, adapted from the OWASP Risk Rating Methodology:

Impact = the privilege score (0 to 9).
Likelihood = the weighted average of exposure, age, ownership and usage (0 to 9). Start with equal weights, then adjust during calibration. OWASP notes that weighting factors turns the calculation into a weighted average and that models should be tuned against expert ratings.
Band each using the OWASP thresholds: 0 to below 3 is Low, 3 to below 6 is Medium, 6 to 9 is High.
Combine using the severity matrix below.
Apply overrides that raise the result regardless of the calculation.

Impact \ Likelihood	Low	Medium	High
High	Medium	High	Critical
Medium	Low	Medium	High
Low	Note	Low	Medium

A worked example: a cloud role with administrator rights (privilege 9), authenticated with a static access key held in a CI variable (exposure 7), not rotated for two years (age 8), owner left last quarter (ownership 8), used daily (usage 2). Likelihood with equal weights is (7 + 8 + 8 + 2) / 4 = 6.25, which is High; impact is High; the result is Critical. Moving the pipeline to workload identity federation drops exposure and age to 1 each, giving likelihood (1 + 1 + 8 + 2) / 4 = 3, Medium, and an overall High until a new owner attests. The owner can see exactly which change moved the score.

Override rules

Valid credential found leaked: Critical until rotated, whatever the privilege.
Platform reports compromise: for example Microsoft Entra ID Protection detections such as Leaked Credentials or Admin confirmed service principal compromised. Critical.
Dormant identity with admin rights: at least High, because there is no business reason to keep standing privilege that is not used.
Human use of an NHI: interactive sign-in by a person to a service account raises usage to High (OWASP NHI10).

Why not a single additive score

Adding all five factors into one number lets a heavily used, well-owned identity with tenant-wide admin rights score lower than a dormant read-only test key. Keeping impact separate means privilege can never be averaged away, and makes it obvious that the two main levers are reducing privilege and removing static, long-lived credentials.

Signals and data sources by platform

Platform	Native signal	Feeds factor
AWS	IAM Access Analyzer unused access findings: unused roles, unused IAM user access keys and passwords, unused permissions	Usage, privilege (unused permissions to remove)
AWS	IAM last accessed information (service data for at least the last 400 days; appears in the console within four hours)	Usage
Microsoft Entra ID	ID Protection workload identity risk detections: Microsoft Entra threat intelligence, Suspicious Sign-ins, Leaked Credentials, Anomalous service principal activity, Suspicious API Traffic, Malicious or Suspicious application	Exposure, usage, overrides
Google Cloud	Service account insights (no authentication in 90 days), Activity Analyzer (last used for service accounts and keys)	Usage, age
Any	Secret scanning in repositories, CI logs and collaboration tools	Exposure, overrides
Any	Vault or secrets manager metadata: creation, rotation, expiry, consumers	Age, exposure
HR and IGA	Owner employment status, last attestation date	Ownership

Check coverage limits. Microsoft documents that managed identities are not currently in scope for workload identity risk detections, and that risk-based Conditional Access applies only to single-tenant service principals registered in your tenant; full risk details need Workload Identities Premium. A model that relies on one vendor's detections will silently score uncovered identities as safe, so treat "no data" as unknown, not low.

The Cloudflare Thanksgiving breach shows the cost of an unmeasured usage factor: credentials left unrotated after the Okta breach because they were mistakenly believed to be unused, one with administrative access to Jira, were later used to gain persistence. A model fed with real last-used data and an override for credentials in a known-compromised set would have ranked them at the top.

Turning scores into action

Band	Owner attestation cadence	Remediation deadline (example)	Typical actions
Critical	Immediate, event-driven	Days	Rotate or revoke credential, remove admin rights, disable if unowned
High	Monthly or quarterly	30 days	Remove unused permissions, move to short-lived credentials, assign owner
Medium	Quarterly	Next planned change	Add expiry, vault the secret, tag purpose
Low and Note	Quarterly or semi-annual	Backlog	Monitor for change

Deadlines are illustrative; set them in policy and record exceptions with an expiry. Scores also decide the scope and cadence of owner attestation, described in the NHI Ownership Attestation Campaigns Guide, and feed the risk register. See the Risk Register Template.

Implementing the model

Agree the factors and rubrics. Write each factor's anchors and data sources down, with security, platform and risk teams. This is the "standardized method" for calculating and prioritising risk that NIST CSF 2.0 GV.RM-06 asks for.
Inventory and join the data. Pull identities, permissions, credentials, owners and usage into one table keyed by identity. Accept gaps; mark missing data as unknown.
Score a sample by hand. Have two analysts score 50 to 100 identities independently and compare. Disagreements show where anchors are vague.
Calibrate against expert judgement. Ask senior engineers to rank the same sample. Where the model disagrees, adjust weights or anchors, as OWASP suggests, and record why.
Run in report-only mode. Publish scores to owners for one cycle without deadlines. Collect disputes; each dispute either fixes data or fixes the rubric.
Turn on actions for Critical and High. Attach deadlines and attestation cadence; keep Medium and Low as reporting only at first.
Automate recalculation. Rescore daily or on change events (new permission, new key, owner leaves, leak alert) so scores do not go stale.
Review the model. Revisit weights after incidents and at least annually. Keep versions so historic scores can be explained.

Testing and rollback

Back-test: score the identities involved in your own past incidents or near misses. If they would not have been High or Critical, the model is missing a factor.
Version the model: when weights change, keep the previous version runnable so you can compare tier movements and revert if a change floods teams with false Criticals.
Do not auto-disable on score alone: automatic actions should come from overrides with clear evidence (a leaked valid key) or from attestation outcomes, not from a weighted average.

Choosing an approach

Approach	Strengths	Weaknesses	Fits
Simple rules (for example "admin and no owner = High")	Easy to explain and implement; no tooling	Coarse; many ties; misses combinations	Small estates, first programme year
Transparent factor model (this guide)	Explainable, tunable, shows owners how to lower a score	Needs data joining and calibration effort	Most organisations
Vendor or platform risk score	Broad data collection; continuous updates; detections included	Weights may be opaque; coverage gaps by identity type	Large estates, if the vendor documents the factors and lets you adjust them
Quantitative (financial) model	Speaks the board's language	Needs loss data that rarely exists per identity	Aggregated portfolio views, not per-identity triage. See the Cyber Risk Quantification Guide

When evaluating a platform score, ask the vendor which factors and weights it uses, whether you can change them, how it scores identities it has no data for, and whether each score shows the evidence behind it. See the NHI Security Platform Buyer's Guide. Smaller organisations can run the five-factor model in a spreadsheet from platform exports; larger ones should automate the join and recalculation and push results into ticketing.

Detection and measurement

Critical and High count: number of NHIs in each band, trended monthly. The goal is a falling count, not a falling average.
Time to remediate: median days from an identity entering Critical or High to leaving it.
Static secret share among High-privilege NHIs: percentage of privilege 7 to 9 identities still using long-lived static credentials.
Unknown-data share: percentage of identities with one or more factors unscored. High values mean the model is guessing.
Owner disputes upheld: disputes that led to a rubric or data fix, a sign the model is being tuned rather than ignored.
Incident coverage: share of identity-related incidents where the identity was High or Critical beforehand.

Monitor score movements as events: an identity jumping from Low to Critical in a day (new admin role, new key, leak hit) should alert the owner and the security team. Atypical use of system accounts (NIST SP 800-53 AC-2(12)) and new credentials added to cloud identities (ATT&CK T1098.001 Additional Cloud Credentials) are the detections most worth wiring into the usage and exposure factors.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	RA-3 Risk Assessment; RA-7 Risk Response; PM-9 Risk Management Strategy	Assessing NHI risk and responding to findings in line with risk tolerance
NIST SP 800-53 Rev. 5	AC-6 Least Privilege; AC-6(5) Privileged Accounts; IA-5 Authenticator Management	The privilege, age and exposure factors
NIST SP 800-53 Rev. 5	AC-2(12) Account Monitoring for Atypical Usage; CA-7 Continuous Monitoring	The usage factor and continuous rescoring
NIST CSF 2.0	GV.RM-06; ID.RA-04; ID.RA-05; ID.RA-06	Standardised risk calculation; likelihood and impact recorded; prioritisation; risk responses tracked
CIS Controls v8.1	Safeguards 5.3 and 5.5	Dormancy threshold; service account inventory with owner and purpose
MITRE ATT&CK v20	T1078.004 Cloud Accounts; T1098.001 Additional Cloud Credentials; T1552.001 Credentials In Files	Techniques the exposure and usage factors are designed to anticipate
OWASP NHI Top 10 2025	NHI1 to NHI10	Risk categories the factors measure

Common failure patterns

Averaging away privilege: one additive score lets a busy, owned admin identity look safe. Keep impact separate.
Missing data scored as safe: identities a tool cannot see (managed identities outside a detection's scope, on-premises service accounts) score low by default. Score unknown as at least Medium likelihood.
Non-production discounted automatically: in the Microsoft Midnight Blizzard breach, a legacy test tenant account and a legacy test OAuth app with elevated access to the corporate environment led to executive mailbox access. Score by reach, not environment label.
Ignoring leaver risk: in the Coupang breach, a departed developer's token signing key, reportedly valid for years, was never rotated. A model that scores owner departure and credential age would have flagged it.
Opaque scores nobody acts on: owners ignore numbers they cannot explain. Show the factor breakdown and the change that would lower the score.
Static model: scores computed once at inventory time and never refreshed. Rescore on change events.

Practitioner checklist

Define privilege as impact and exposure, age, ownership and usage as likelihood, each with written 0 to 9 anchors.
Source every factor from platform data; mark missing data as unknown, not low.
Combine with a severity matrix, not a single sum, and document the weights.
Add overrides for leaked valid credentials, confirmed compromise, dormant admin identities and human use.
Calibrate on a hand-scored sample and back-test against past incidents.
Run one cycle in report-only mode and resolve owner disputes.
Tie each band to attestation cadence and remediation deadlines.
Rescore on change events and version the model.
Track Critical and High counts, time to remediate and unknown-data share.

Standards and references

Related NHI Mgmt Group resources: NHI Ownership Guide · Top 10 NHI Risks · NHI Ownership Attestation Campaigns Guide · Board Briefing: NHI Risk · ISPM Guide