# The High-Risk User Checklist: Signals That Flag a Risky Identity

> A concrete SOC and IAM watch-list of the behaviours and attributes — impossible travel, MFA changes, privilege escalation, leaked credentials and more — that should raise a user's risk score, why each matters, and how to respond.

Source: https://playciso.com/blog/high-risk-user-warning-signs-checklist · Published: 2026-09-10 · Publisher: PlayCISO (https://playciso.com)

---

Most breaches don't announce themselves with malware. They arrive as a legitimate login from a valid account that happens to be doing something a little bit wrong. The job of a modern SOC or IAM team isn't to spot the impossible event — it's to notice when an ordinary identity starts behaving in ways that, taken together, no longer look like the person behind it. This is the high-risk user checklist: the concrete signals that should push an identity's risk score up, why each matters, and what to do when they stack. ## Why a checklist beats a gut feeling Identity risk is cumulative. Any single signal below is usually explainable — a finance director travels, someone re-registers MFA on a new phone, a dormant contractor account gets dusted off for a genuine reason. The danger is the correlation: an anomalous login _and_ a fresh MFA method _and_ a privilege change on an account that sits on the finance approval chain. A structured watch-list lets you weight each factor, sum them, and trigger a proportionate response instead of drowning analysts in isolated alerts that each look benign in a vacuum. Treat the rest of this post as inputs to a score, not a set of independent tripwires. ## The high-risk user checklist Group these into three buckets: **where and how** the sign-in happened, **what changed** about the identity, and **who** the identity is. All three feed the same score. ### Sign-in and session anomalies (where and how) - Impossible travel / atypical geolocation. Two authentications from locations no plausible travel speed can reconcile, or a login from a region the user has never operated from. Why it matters: it's one of the cleanest indicators that credentials are being used by two parties at once. What to do: treat a genuine hit as an active-session concern, not a historical one — step up auth on the newer session immediately and be ready to revoke it. - Sign-in from a high-risk country, ASN, VPN, or Tor exit. Authentication from an anonymising network, a hosting/VPS ASN no real employee logs in from, or a country outside your operating footprint. Why it matters: attackers routinely proxy through commodity VPNs and cloud ASNs to blend in or defeat naive geofencing, and Tor is almost never a legitimate corporate access pattern. What to do: raise the score sharply for hosting-ASN and anonymiser traffic; consider hard-blocking Tor for privileged roles. - Repeated failed logins, password spray, or MFA fatigue. A burst of failures against one account, a low-and-slow spread across many accounts (spray), or a stream of push prompts the user didn't request (fatigue/bombing). Why it matters: spray evades lockout by staying under the per-account limit, and MFA fatigue wears the user down until they tap approve. What to do: correlate failures across the tenant, not per-user; if a prompt gets approved after a fatigue burst, treat that session as compromised until proven otherwise. - Use of legacy or basic authentication protocols. Access over IMAP, POP, SMTP AUTH, or other legacy endpoints that can't enforce MFA. Why it matters: attackers deliberately choose these paths precisely because they bypass conditional access and modern step-up. A privileged account authenticating over basic auth is a gift. What to do: disable legacy auth wholesale where you can; where you can't, score any legacy-protocol sign-in as high-risk on its own. - Unusual working hours or volume. Sustained activity far outside the user's established pattern — 3am data pulls, weekend admin actions, or a spike in the volume of objects touched. Why it matters: baseline deviation is the core of insider-threat and account-takeover detection; the account is doing the user's job at a time the user doesn't work. What to do: weight by role — off-hours activity from an IT admin or a data-heavy role deserves more scrutiny than from a global sales team. ### Identity and credential changes (what changed) - MFA method changed recently, especially from a new location. A new authenticator enrolled, a phone number swapped, or a fallback method added — particularly when the change comes from an unfamiliar device or geography. Why it matters: registering attacker-controlled MFA is the standard way to make a takeover durable and lock the real user out. What to do: treat an MFA change plus an anomalous location as a near-certain incident; force re-verification through a separate trusted channel before honouring it. - New device registration from an unusual place. An unrecognised device joined to the account, especially paired with an atypical location or a fresh MFA enrolment. Why it matters: a newly trusted device can become the launchpad that quietly satisfies future conditional-access checks. What to do: require an additional verification step for first-seen devices, and surface new-device events to the user themselves. - Leaked-credential match. The account's password (or a close variant) appears in a breach corpus or paste dump. Why it matters: credential stuffing is cheap and effective; a known-leaked credential means the only thing between the attacker and the account may be a second factor you're not certain is intact. What to do: force a reset on match and re-check MFA integrity at the same time — a leaked credential rarely travels alone. - Risky third-party OAuth grants. The user consented to an app requesting broad scopes — mailbox read/write, offline access, directory read — often through a convincing consent-phishing lure. Why it matters: an OAuth token survives a password reset and can exfiltrate mail or data silently, long after you think you've contained the account. What to do: inventory grants, revoke suspicious tokens explicitly (resetting the password is not enough), and alert on newly consented high-scope apps. ### Account state and blast radius (who the identity is) - Privilege escalation, a new admin role, or group changes. The account was just added to a privileged role, a security group, or an admin-capable app. Why it matters: this both increases what a compromise can reach and is itself a classic post-compromise action — attackers grant themselves persistence. What to do: alert on the grant in near-real-time, verify it maps to an approved change ticket, and keep the identity's score elevated for as long as the access persists. - VIP, finance, or IT-admin role — high blast radius. Executives, anyone on the payment or wire-approval path, and the people who administer identity itself. Why it matters: the same anomaly costs far more on these accounts. A compromised help-desk admin can reset everyone else's MFA; a compromised finance approver enables fraud directly. What to do: apply a permanent baseline multiplier to these identities so equivalent signals always score higher than they would on a general user. - Dormant account suddenly reactivated. An account with no activity for weeks or months that abruptly logs in and starts doing things. Why it matters: dormant and orphaned accounts are prime targets precisely because nobody is watching them, and their reactivation is often the first move of a takeover. What to do: treat first-login-after-dormancy as a step-up event, and disable or delete accounts that stay dormant past your threshold. - Recently onboarded or about-to-offboard (leaver risk). New joiners haven't established a baseline yet, and departing users — especially in a notice period — are the textbook window for data theft. Why it matters: intent and opportunity peak at the edges of the employment lifecycle. What to do: raise scrutiny automatically at both ends; for known leavers, watch for bulk downloads, external forwarding, and mass sharing, and tighten access as the departure date approaches. ## How the signals become a risk score None of these is a verdict on its own. The model that works in practice is additive with weighting and decay. Each signal contributes points scaled by severity — a Tor login or a leaked-credential match is worth far more than a slightly-off working hour. Role acts as a multiplier, so a finance or IT-admin account crosses your action threshold on weaker signals than a general user. Recent signals count for more than old ones, so scores decay rather than accumulating forever. And correlation is where the value lives: an anomalous location, a new MFA method, and a privilege change together should score dramatically higher than the sum of the three treated independently, because they describe a coherent attack narrative rather than three coincidences. If you want to see how these factors interact without building the model yourself first, the [PlayCISO identity risk calculator](https://playciso.com/tools/identity-risk) lets you toggle these exact signals and watch the composite score move, which is a useful way to sanity-check where your own thresholds should sit. ## How to respond when the score climbs A risk score is only worth the actions it drives. Tier your response to the score, and let the low-friction options fire automatically so analysts spend their time on the genuinely ambiguous cases. - Step-up authentication. The default for a medium score. Force re-authentication or a fresh MFA challenge before allowing sensitive actions — low-friction for a legitimate user, a hard wall for an attacker who only has the password. - Revoke sessions and tokens. For a high score or a confirmed indicator, kill active sessions and refresh tokens and force a fresh sign-in. Revoking a password is not the same as revoking OAuth tokens — do both. - Review and contain. Open an investigation: reconcile recent changes against change tickets, check for attacker-registered MFA and OAuth grants, and confirm privilege and group state. For leaver and insider cases, review data-movement telemetry, not just authentication. The through-line is proportionality. You're not trying to block every unusual login — you're trying to make sure that when signals stack into a coherent story the response is fast and automatic, and when they don't, a real person doesn't lose an hour to a false alarm. A well-tuned score is what tells those two situations apart. ## Frequently asked questions **Isn't impossible travel just noise from VPNs and corporate proxies?** It's noisy if you score it in isolation, which is why it belongs in a weighted model rather than as a standalone block. A VPN or corporate proxy explains most benign hits, so the signal earns its keep only when it correlates with others — an impossible-travel event that also coincides with a new MFA enrolment or a hosting-ASN source is very different from one on a known VPN exit. **Which single signal is the strongest?** There isn't one, and treating any signal as a sole trigger is how you get both misses and false positives. That said, a recent MFA method change from an unfamiliar location, a leaked-credential match, and legacy-auth use on a privileged account most reliably indicate real compromise, because each defeats or bypasses the control you were relying on. **How do we score a VIP or admin without alert fatigue?** Apply a role-based multiplier rather than lowering the threshold for everyone. High-blast-radius identities should cross the action line on weaker signals, but you keep fatigue in check by making the step-up response low-friction and automatic, so a slightly elevated score on an executive triggers a re-auth prompt rather than a page to an analyst. **Why revoke OAuth tokens separately from resetting the password?** An OAuth refresh token is an independent credential that survives a password reset. If an attacker phished a consent grant for mailbox and offline access, resetting the password does nothing to that token — it keeps reading and exfiltrating mail until you explicitly revoke the grant. Any takeover response has to inventory and kill tokens, not just rotate the password. **Where do dormant and leaver accounts fit in a risk model?** They're state-based multipliers on top of behavioural signals. A dormant account carries elevated baseline risk because nobody is watching it and its reactivation is a common first move in a takeover; a known leaver carries elevated risk because intent and opportunity both peak in the notice period. You raise the baseline automatically from lifecycle data, then let behavioural signals push the score the rest of the way.