When did your organization last verify that every user account, service credential, and authentication token was doing exactly what it was supposed to do? If the answer is “we’re not sure,” you’re not alone. Identity has quietly become the front door for most serious breaches, and a surprising number of teams still don’t have a repeatable way to check that door.
This guide lays out a working identity threat detection checklist you can actually use. It covers the signals worth watching, the controls that catch the common attacks, and the mistakes that make even well-funded detection programs fail. No fluff, no vendor pitch, just the practical stuff.
Why identity is now the main battleground
Attackers rarely break encryption anymore. They log in. According to the Verizon Data Breach Investigations Report (DBIR), stolen or misused credentials have consistently been among the top initial access vectors in recent editions, and the exact share shifts year to year, so always cite the specific edition you checked. The pattern is stable even when the number isn’t: valid accounts are the cheapest way in.
The MITRE ATT&CK knowledge base reflects this. Its Enterprise matrix includes a dedicated set of credential access techniques (T1003, T1110, T1552, T1528, and others), each with detection guidance. If your detection rules don’t map to these techniques, you’re guessing. That’s the first lesson of any serious program: anchor your checks to a shared taxonomy, not to whatever alert happened to fire last week.
The checklist, organized by layer
A good checklist isn’t a flat list of 200 items nobody reads. It’s grouped by where the threat lives. Here’s a structure that works in practice.
Layer 1: Account and credential hygiene
- Inventory every account, including service accounts, API keys, and stale human accounts. Most organizations find 15–30% more identities than they expected.
- Flag dormant accounts that haven’t authenticated in 90 days and disable them after review.
- Confirm MFA coverage on all privileged and remote-access accounts. The NIST SP 800-63B digital identity guidelines are the reference point for authenticator strength, including phishing-resistant options at the highest assurance levels.
- Check for password reuse and credentials exposed in known breaches.
- Verify that break-glass accounts exist, are documented, and are monitored.
Layer 2: Authentication and session monitoring
- Alert on impossible travel and unusual geolocation for sign-ins.
- Detect MFA fatigue patterns: repeated push prompts followed by an approval.
- Watch for token theft and replay, especially OAuth tokens and session cookies.
- Baseline normal login hours per user and flag deviations.
- Log every authentication event to a central system, including successful ones.
Layer 3: Privilege and access behavior
- Review privileged role assignments monthly, not annually.
- Detect privilege escalation attempts and role changes outside change windows.
- Monitor lateral movement signals: new device enrollments, unusual resource access.
- Check for consent phishing, where users grant OAuth permissions to malicious apps.
Layer 4: Non-human identities
- Inventory service principals, managed identities, and machine credentials.
- Rotate secrets on a schedule and detect secrets committed to code repositories.
- Audit third-party integrations for excessive permissions.
If your environment leans heavily on machine identities, the comparison of Astrix vs Oasis vs Entro non-human identity security 2026 is worth reading before you pick tooling.
Mapping checklist items to real attack techniques
The table below connects common checklist items to the ATT&CK techniques they address. This is the part most teams skip, and it’s the part that makes the checklist defensible in an audit.
| Checklist item | ATT&CK technique | What “good” looks like |
|---|---|---|
| Dormant account review | Valid Accounts (T1078) | Accounts disabled within 30 days of last use |
| MFA enforcement | MFA bypass / AiTM phishing | Phishing-resistant factors on privileged access |
| Credential exposure monitoring | Credentials in Files (T1552) | Alerts within 24 hours of exposure |
| Token monitoring | Steal Application Access Token (T1528) | Anomalous token reuse flagged |
| Privilege review | Account Manipulation (T1098) | Monthly attestation with owner sign-off |
| Lateral movement detection | Remote Services (T1021) | New device/resource pairs flagged |
Notice that each row has a measurable outcome. That’s deliberate. A checklist item without a “what good looks like” column is just a wish.
The signals that actually catch attackers
Detection engineering is a game of signal versus noise. Here’s what tends to work in practice.
First, watch the authentication layer hardest. Most identity attacks surface as authentication anomalies before anything else. Failed-then-successful login sequences, logins from new ASNs, and session tokens used from a different device than they were issued to are all high-value signals.
Second, treat identity as part of your broader threat picture. A single sign-in alert is noise. The same alert correlated with a known campaign, a suspicious IP range, or a newly registered domain is a story. That’s the logic behind a cyber threat intelligence map, and it’s why identity telemetry should feed the same pipeline as network and endpoint data.
Third, tune before you scale. The most common mistake is deploying 50 identity detections at once and drowning the SOC. Start with 8–10 high-fidelity rules, measure false positives for two weeks, then expand. Teams that skip this step end up disabling alerts, which is worse than never having them.
Fourth, log identity events into your SIEM with enough context to investigate. A worked example of this appears in a walkthrough on using Wazuh SIEM to detect PHP2Shell in 13 steps; the same pipeline design applies to identity events.
What actually works in practice (and what doesn’t)
Here’s where experience matters more than theory.
What works: automated inventory that runs continuously, not quarterly. A single source of truth for “who has access to what.” Detection rules version-controlled like code. A named owner for every privileged account.
What doesn’t: annual access reviews that nobody reads. MFA rolled out as SMS-only and called “done.” Detection rules written once and never tuned. Treating service accounts as an afterthought.
A frequent and costly mistake is assuming that phishing-resistant MFA is optional for non-privileged users. It isn’t. Attackers target the easiest account first, then pivot. The CISA “More than a Password” guidance makes the case plainly: phishing-resistant authentication is the baseline, not the upgrade.
Another common failure is ignoring the human layer. Identity threats often arrive as social engineering, and recognizing manipulated content is part of the defense. A guide on how to spot AI-generated content and one on how to detect AI-generated images are useful training material for staff who handle account requests and vendor communications.
Building the detection pipeline
A checklist only matters if it’s wired into a process. Here’s a sequence that works.
- Collect identity logs from your IdP, directory service, and cloud providers into one place.
- Normalize them so user, device, IP, and action fields are consistent.
- Baseline normal behavior for 30 days before turning on anomaly rules.
- Detect with a small set of mapped rules tied to ATT&CK techniques.
- Triage with clear playbooks for each alert type.
- Respond with automated containment where safe (session revocation, account disable).
- Review detection performance monthly and retire rules that don’t earn their keep.
Steps 3 and 7 are the ones teams skip. They’re also the ones that separate a program that survives contact with reality from one that collapses under alert volume.
Common mistakes that undermine identity detection
- No asset and identity inventory. You can’t protect what you can’t see.
- Alert fatigue. Too many low-fidelity rules train analysts to ignore everything.
- Siloed teams. Identity, endpoint, and network teams not sharing telemetry.
- No containment automation. Detecting a compromised session and waiting 40 minutes to revoke it defeats the purpose.
- Ignoring non-human identities. Service accounts and API keys are frequently over-privileged and unmonitored.
- Skipping tabletop exercises. A checklist nobody has rehearsed is a document, not a capability.
For the human-facing side of identity risk, a primer on what identity theft is and how to prevent it is a good resource to share with employees, especially those who use personal devices for work. (Identity theft)
Tooling: what to look for
You don’t need a single “identity threat detection platform” to run this checklist. Most teams get there with a combination of their existing IdP, a SIEM, and a cloud security posture tool. What matters is coverage, not brand.
When evaluating tools, ask three questions: Does it ingest identity logs from all your providers? Can it detect token and session anomalies, including failed logins? And can it automate containment? If the answer to any is no, the tool fits only part of your needs.
If your team also handles mobile endpoints, the same discipline applies to app-level threats. A guide on how to check whether an APK file is safe covers a related detection workflow that pairs well with identity monitoring on BYOD devices. (Cybersecurity Framework)
Measuring whether the checklist works
A checklist without metrics is a ritual. Track a small number of numbers that actually tell you something:
| Metric | Why it matters | Target direction |
|---|---|---|
| Mean time to detect identity anomalies | Speed is the whole game | Down |
| False positive rate per rule | Predicts analyst trust | Down |
| % of privileged accounts with phishing-resistant MFA | Coverage of the highest-risk accounts | Up |
| % of dormant accounts disabled within 30 days | Hygiene discipline | Up |
| Time to revoke a compromised session | Limits blast radius | Down |
| % of detection rules mapped to ATT&CK | Defensibility and coverage | Up |
Review these monthly. If a metric isn’t moving, the process behind it isn’t working.
Conclusion
An identity threat detection checklist isn’t a document you write once and file away. It’s a living loop: inventory, baseline, detect, respond, and tune. The organizations that get this right treat identity as a first-class detection domain, map their rules to shared frameworks like MITRE ATT&CK, enforce phishing-resistant authentication where it counts, and measure whether their alerts actually catch attackers.
Start small. Pick the ten checks that map to the techniques most relevant to your environment. Wire them into your SIEM. Measure the results for a month. Then expand. That’s how a checklist becomes a capability, and how a capability becomes a defense that holds up when someone tries the front door.
FAQ
What is an identity threat detection checklist?
It’s a structured set of checks and detection rules that help security teams find attackers who are misusing valid accounts, stolen credentials, or compromised tokens. It covers account hygiene, authentication monitoring, privilege review, and non-human identity controls.
How many items should a checklist have?
Fewer than you think. A workable starting set is 20–30 items grouped by layer, with 8–10 active detection rules. Quality and tuning matter far more than length. A 200-item list nobody maintains is worse than a 25-item list that gets reviewed monthly.
Do I need special tools to run this checklist?
Not necessarily. Most teams can start with their existing identity provider, a SIEM, and a cloud security tool. The gaps usually appear in token monitoring and automated containment, which is where dedicated identity detection tools earn their place.
How often should the checklist be reviewed?
Review detection performance monthly and run a full checklist audit quarterly. Any time you add a major system, onboard a new identity provider, or change your MFA policy, revisit the relevant sections immediately.
What’s the biggest mistake teams make?
Deploying too many detection rules at once. Alert fatigue sets in fast, analysts start ignoring identity alerts, and real attacks slip through. Start with high-fidelity rules, tune for two weeks, then expand.
How does identity threat detection differ from identity access management?
IAM focuses on granting and governing access. Identity threat detection focuses on spotting misuse of that access after the fact. They’re complementary: strong IAM reduces the attack surface, and detection catches what gets through.
