Attractive users are those whose roles enable transactions, approvals, or operational action, which can create immediate leverage for attackers. Sensitive users may handle valuable information, but that does not always produce the same attack volume. In healthcare, the article shows that financial and transactional roles often draw more pressure than information-services roles, so risk should reflect both access and attacker intent.
Why attackers care more about some users than about some datasets
In practice, attackers usually pursue the user who can make something happen, not just the user who can see something valuable. A person with approval rights, payment authority, release privileges, or access to operational workflows can turn a stolen session or credential into immediate action. That makes the account attractive because it compresses the path from access to impact.
By contrast, a user may be highly sensitive from a data perspective yet still be a weaker target if compromise does not quickly unlock downstream action. A records analyst, researcher, or reporting user may expose important information, but the attacker may need extra steps to turn that access into fraud, persistence, or lateral movement. The distinction matters because attacker attention is shaped by both value and exploitability.
How “attractive” and “sensitive” differ in the real world
“Attractive” is an attacker-centric idea. It describes the accounts most likely to be targeted because they can authorise transactions, approve changes, move money, reset controls, or create operational leverage. These users often sit closer to fraud, extortion, or business disruption, so they attract phishing, credential theft, session hijacking, and account takeover attempts more often than low-action accounts.
“Sensitive” is a data-centric idea. It describes users who can access protected information, regulated records, or confidential content. That sensitivity still matters, but it does not always translate into the same attack pressure. In some environments, especially healthcare, financial and transactional roles may be targeted more aggressively than information-services roles because attackers value direct action over passive visibility.
The practical takeaway is that security teams should not treat all sensitive access as equally attractive, or all attractive users as equally data-sensitive. Risk depends on whether the account can be abused to create immediate business effect, whether the data can be monetised or weaponised, and how much friction exists between initial compromise and useful attacker outcome.
How to rank risk without confusing data sensitivity with attacker interest
One useful way to assess the difference is to separate exposure into two questions: what can this user see, and what can this user do? The first question captures confidentiality and privacy risk. The second captures operational, financial, and abuse potential. A user may score high on one and not the other, which is why account ranking should use both dimensions instead of collapsing them into a single label.
For practitioners, the strongest signal of “attractive” users is not simply that they hold important information, but that compromise would let an attacker alter state, approve action, or trigger an irreversible workflow. If the account can move funds, approve exceptions, or change entitlement state, it is usually a higher-priority control target than a read-only role with comparable data sensitivity.
That distinction is especially relevant when deciding where to apply stronger monitoring, tighter authentication, and faster response paths. A sensitive data user may warrant strong confidentiality controls, while an attractive user often needs both confidentiality controls and action controls because the abuse path is broader.
Risk and Threat Considerations
Accounts that combine authority with reach are especially dangerous because compromise can produce both access and action in one step. Attackers prefer these users when they can turn a stolen credential into payment approval, workflow abuse, privilege escalation, or fraud without needing to pivot through multiple systems.
Failure mechanism: Organizations over-index on the sensitivity of the information a user handles and underweight the operational power attached to the account. That creates blind spots around approval chains, transaction authority, and privileged workflows, where an attacker can gain high-impact leverage even if the data itself is not the most confidential asset.
Impact: The result is misprioritised protection, weaker detection on high-leverage accounts, and delayed response to compromise attempts against the users most likely to produce immediate business harm.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1078 — Valid Accounts | User compromise and account abuse are central to attacker interest in high-value roles. |
| T1110 — Brute Force | Attackers often try credential attacks against users attractive for rapid business impact. | |
| Recommendation — Monitor for valid-account abuse on approval-bearing and transaction-bearing users. Harden authentication and alert on repeated login abuse against high-leverage accounts. | ||
| NIST CSF 2.0 | PR.AA-05 — Least Privilege | Separating data access from action authority reduces the leverage of attractive accounts. |
| ID.RA-01 — Asset vulnerabilities are identified and documented | Account attractiveness depends on the authority and workflow exposure the role creates. | |
| Recommendation — Apply least-privilege access so sensitive users do not also carry unnecessary action authority. Document which user roles can approve, transfer, or alter business state. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Limits the operational leverage attackers gain from compromised high-authority users. |
| Recommendation — Restrict user permissions to the minimum action set needed for the role. | ||
Practitioner Guidance
What to prioritise: Classify users by both data sensitivity and decision authority, then elevate the accounts that can approve, release, transfer, or modify state. Those are the users most likely to matter when an attacker wants fast impact.
What to verify: Confirm whether a role is read-only, approval-bearing, or transaction-bearing before assigning it a lower-risk label. If a supposedly “sensitive” role can also trigger action, it should be treated as higher risk than its data label suggests.
Practitioner takeaway: The most dangerous users are often the ones who can both see something valuable and do something consequential, but when those are split, attacker interest usually follows the action path first.
Related resources from NHI Mgmt Group
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between human IAM controls and NHI governance?