Identity risk prioritization means ranking accounts, tokens and permissions by how much damage they could cause if abused, then fixing the worst first. The useful inputs are privilege, exposure, how the credential is protected and whether a person still owns it. Count of findings matters less than reach.
Why start with identities?
MITRE ATT&CK describes the valid accounts technique: adversaries obtain and abuse credentials of existing accounts for initial access, persistence, privilege escalation or defense evasion, including access to VPNs and other externally available services. Real incidents show the pattern. In the NotPetya analysis, CISA reported that the most effective propagation method used a modified Mimikatz tool to steal Windows credentials and then moved with built-in administration tools. In the 2015 attacks on Ukrainian power distributors, the companies believed the actors acquired legitimate credentials before the attack and used VPN access. Stolen identity turned ordinary tools into attack tools.
What factors should you weigh?
Privilege. What can the identity do? NIST SP 800-53 control AC-6 on least privilege is the reference idea: give only the access needed to do the job. Administrator, domain and cloud account owner roles come first.
Reach. How many systems or data sets can it touch? One service account with read access to every storage bucket may matter more than ten users with access to one app.
Exposure. Can the identity be used from the internet? Is multi-factor authentication enforced? Is the secret in a vault or in a repository?
Ownership. Does a named person or team own it, and is that person still employed? Orphaned accounts are a favorite target because nobody notices their activity.
Age and rotation. Long lived keys that have never been rotated carry more risk than short lived tokens.
Activity. Is it used? Unused identities with permissions are risk without value.
How do non-human identities change this?
Service accounts, API keys, CI tokens and automation agents often outnumber people and carry broad rights. They rarely have multi-factor authentication and often have no owner on record. OWASP's API Security Top 10 treats authentication weaknesses as a top risk in APIs for this reason. Put machine identities in the same ranking as human ones.
A constructed scoring example
Score each factor from 0 to 3 and add them. A contractor account with no multi-factor authentication, administrator rights on the billing system and no activity for 200 days scores high on privilege, exposure and ownership, and goes to the top. An engineer's standard account with multi-factor authentication and normal activity scores low. A CI token that deploys to production, sits in a shared repository and was created four years ago scores high on reach, exposure and age, and outranks both. The numbers are crude on purpose. The point is a defensible order.
What are common mistakes?
Treating every finding as equal, so the top of the list is a pile of low-risk items. Ranking only human users and skipping service accounts. Scoring once and never again, while access changes weekly. Counting accounts with multi-factor authentication as safe without checking the factor type, since some are easier to phish than others. And leaving the owner field blank, which turns every later question into an investigation. A scoring model that is simple enough for the whole team to apply the same way beats a clever one that nobody trusts.
How to check or apply this
- Build an inventory of identities: people, service accounts, keys, tokens and agents, with owners.
- Mark privileged and shared accounts first.
- Score on privilege, reach, exposure, ownership, age and activity.
- Fix the top tier: enforce multi-factor authentication, remove unused rights, rotate old secrets, assign owners or disable the account.
- Review leavers and role changes monthly so access follows people.
- Re-score quarterly and track how the top tier shrinks.
Quick check
Should I fix the most numerous findings first?
Not necessarily. Fix the identities that could do the most harm, even if they are few.
Do service accounts belong in the same ranking?
Yes. They often have broad access and weak oversight, so they frequently deserve a high rank.
Sources
- MITRE ATT&CK T1078, Valid Accounts
- CISA, Petya Ransomware (NotPetya) alert
- CISA ICS-CERT, IR-ALERT-H-16-056-01, Cyber-Attack Against Ukrainian Critical Infrastructure
- OWASP API Security Top 10 2023, API2 Broken Authentication
NIST SP 800-53 control AC-6 is cited from general knowledge of the catalog and was not fetched for this article.
Last reviewed: 18 October 2026.
