If you’re trying to improve identity security, you’re probably feeling the same gravity that everyone else is feeling right now. The perimeter did not disappear, it just got demoted. People have said “identity is the perimeter” for years, and it’s still true, just not in the way most folks meant it. This isn’t primarily a SAML or IAM conversation, even though those pieces matter. It’s about the simple reality that attackers chase identity first, then use it to climb privileges until they can do whatever they want. If you can detect and shut down identity abuse early, you can often stop the entire intrusion before it turns into a real incident.
In state and local government, that shift hits harder because your identity stack is rarely “one thing.” It’s Active Directory that has been upgraded in place since somebody’s first BlackBerry, cloud identity layered on top, vendors who need access during emergencies, student workers who rotate every semester, and service accounts that run the whole show but have nobody’s name on them.
Identity Threat Detection & Response (ITDR) is how you stop treating all of that like a paperwork problem and start treating it like an incident problem.
What ITDR Actually Is
GITDR is the set of detections, investigations, and response actions that focus specifically on identity systems and identity abuse. That includes on-prem identity like Active Directory, cloud identity like Microsoft Entra ID, and the messy middle where tokens, session cookies, legacy protocols, and device posture all collide.
It maps cleanly to modern Zero Trust thinking, because Zero Trust is built around continually authenticating and authorizing access based on identity and context, not simply letting someone in and hoping for the best.
ITDR also fits naturally into incident response, because identity attacks move fast and the blast radius expands quietly. NIST’s updated incident response guide (SP 800-61r3) reinforces the need for structured response that can keep up with modern attack paths, which are increasingly identity-driven.
The simplest way to explain ITDR to leadership:
A lot of security programs treat identity like an office badge.
- Issue badges
- Reset badges
- Review badges once a year
- Hope nobody photocopies the badge
Attackers treat identity like master keys.
If they get one privileged credential, one persistent token, or one replication-capable account, they do not need to “hack” everything else. They just walk in.
That is why MITRE has “Valid Accounts” as a core adversary technique, because it works and it blends in.
Start with a realistic scope, not an ideal scope.
If you try to “do ITDR” everywhere at once, you will build a dashboard that looks impressive and performs like a smoke alarm with the batteries removed.
Start by choosing two identity surfaces that matter most in public sector environments:
- Active Directory and domain controllers (because lateral movement and privilege escalation live here).
- (A) Your cloud identity provider (because tokens, SaaS access, and remote work live here).
(B) Your cloud identity management (like an Okta, etc.).
If your environment is Microsoft-heavy, that usually means AD plus Entra ID, with a close eye on Microsoft 365 audit activity and sign-in behavior.
Step 1: Protect the accounts that can end your week.
Most agencies have strong policies on paper and weak reality in privileged access. ITDR begins by identifying the accounts that can do catastrophic things quickly.
Make three lists:
List A: Tier 0 accounts
Accounts that control identity itself, such as Domain Admins, Enterprise Admins, AD replication permissions, identity admins in cloud, and break-glass accounts.
List B: Tier 1 accounts
Server admins, virtualization admins, backup admins, security tool admins, and anyone who can disable logging or controls.
List C: "Quiet power" accounts
Service accounts, shared vendor accounts, legacy accounts, and API principals that have broad access but minimal visibility.
Then do one uncomfortable thing that pays dividends later. Assign an actual owner for every account in Lists A and B, even if the owner is a team and not a person. ITDR fails when nobody has authority to act quickly during containment.
Step 2: Turn on the telemetry that makes identity abuse obvious.
You cannot detect what you refuse to log.
A practical ITDR logging baseline looks like this:
Active Directory and Windows:
- Domain Controller security logs and authentication events
- Directory services events that show replication behavior and privilege changes
- Admin group membership changes
- Kerberos-related activity that supports detecting ticket abuse patterns
This is how you catch things like DCSync, where an attacker abuses replication APIs to pull credential material.
Cloud identity:
- Interactive and non-interactive sign-in logs
- Risk detections and conditional access outcomes
- OAuth app consent, app registrations, and permission grants
- Token-related indicators where your platform exposes them
Token theft is now a mainstream path around MFA, because the attacker stops trying to steal the password and starts trying to steal the session. Microsoft’s guidance on tokens and token theft is worth treating as required reading for modern ITDR planning.
Step 3: Implement phishing-resistant MFA the right way.
A lot of agencies think they are “done” because MFA exists. Attackers love that mindset.
CISA has been very direct that phishing-resistant MFA is the goal, not simply “an MFA prompt showed up.”
CISA’s Zero Trust Maturity Model goes further and positions phishing-resistant MFA as a core identity capability as maturity improves.
This matters for ITDR because MFA bypass is now a common story:
- Content phishing
- Adversary-in-the-middle
- Helpdesk social engineering
- Legacy protocols that quietly skip MFA
You do not need perfection on day one, but you do need a roadmap that ends with phishing-resistant MFA for privileged access and high-impact users, because that is where the return shows up first.
Step 4: Pick ten detections that actually stop attackers.
Early ITDR is not about having 400 alerts. It’s about having ten alerts that you will act on every time.
Here’s a strong starter set for public-sector environments:
High-value identity detections
- New privileged account created or privileged role assigned.
- Privileged group membership change (especially outside change windows).
- Unusual authentication patterns for privileged users (new device, new geography, new network path).
- Password spraying or brute force patterns across many users.
- Impossible travel or rapid location changes tied to interactive sign-ins.
- OAuth consent granted to a high-privilege app or unusual permissions requested.
- Abnormal mailbox access patterns tied to admin-like behavior.
- Kerberos ticket anomalies that align with forged ticket behaviors.
- DCSync-like replication behavior from a non-DC source.
- Valid account use that doesn’t match the user’s normal work pattern.
If you run these ten well, you will catch a meaningful percentage of real-world intrusion chains before they turn into a headline.
Step 5: Build response actions that are safe to execute at 2:00 AM.
Detection without response is just expensive awareness.
Your first ITDR playbooks should be short, repeatable, and permissioned in advance.
Minimum viable ITDR response actions
- Disable the account
- Force sign-out and revoke sessions
- Reset credentials and rotate secrets
- Block sign-in from risky conditions
- Contain the endpoint if the identity compromise came from a device infection
- Preserve evidence before you "fix" everything
Token incidents deserve their own runbook because the containment steps are different and time matters. Microsoft’s token theft playbook is a good model for what “fast and structured” looks like.
This is where your governance becomes an operational advantage. If you have already defined who can disable a Tier 0 account, how break-glass access works, and how you keep essential services running, you will not negotiate with yourself during an incident.
What to skip at the beginning (so you actually finish).
ITDR programs stall when teams start with the fancy stuff.
Skip these until your basics are working:
- Custom ML models trained on weak logs
- “Single pane of glass” identity dashboards that no one responds to
- Overly broad alerting that floods the SOC and gets tuned out
- Perfect identity governance projects that take a year and never reach operations
- Tool-first initiatives where a product gets deployed before you decide what you want to detect and how you will respond
Start with outcomes. Tooling becomes obvious once you know what problems you are solving.
A practical timeline that works in the public sector:
Week 1: Get your footing.
- Identify Tier 0 and Tier 1 accounts.
- Confirm you are collecting the critical logs for AD and cloud identity.
- Validate that your team can disable accounts and revoke sessions quickly.
Days 30 to 60: Get dangerous in a good way.
- Deploy the ten core detections.
- Run tabletop exercises on two identity scenarios: password spray and token theft.
- Require phishing-resistant MFA for privileged users where feasible (CISA).
By the end of the quarter: get resilient.
- Implement privileged access workflows that reduce standing access.
- Tighten app consent and permission governance.
- Add identity-specific threat hunting and weekly reviews of privileged activity.
The leadership metric that matters most:
If you track only one thing early on, track this:
Time to revoke access for a suspected compromised identity.
That single metric forces clarity on authority, process, tooling, and communications. It also tells you whether ITDR is real or just a slide.
Closing Perspective for State and Local Leaders
Identity attacks are not always loud. They are patient, procedural, and often indistinguishable from normal admin work until you look at behavior across systems.
ITDR is how you make identity observable and defensible. It is also one of the fastest ways to improve your Zero Trust maturity without betting the farm on a massive architecture project.
Don't miss another article. Subscribe to our blog now.
