What do you do when your identity threat detection (ITD) platform goes quiet? No alerts for a week feels like good news, until you realize a compromised service account could be moving through your environment unnoticed. That silence is often the first symptom of a broken detection pipeline, not a secure one.
Identity threat detection covers the tools and signals that spot credential misuse, lateral movement, token theft, and risky sign-ins. Vendors like Microsoft, CrowdStrike, Okta, and SentinelOne all use the label, but there is no single standard definition. That ambiguity matters during troubleshooting, because the fix depends entirely on which product and which signal sources you actually run. This guide walks through the practical diagnostic steps that resolve most “detection stopped working” cases, plus the mistakes that keep teams stuck.
Start by Defining Which Detection Layer Failed
Before touching any configuration, pin down what “not working” means. Identity detection typically draws on three layers:
| Layer | Typical source | Common failure symptom |
|---|---|---|
| Identity provider telemetry | Entra ID sign-in logs, Okta system log | No sign-in events appear at all |
| Endpoint and on-prem signals | Domain-joined sensors, EDR agents | Sensor shows unhealthy or stale |
| Correlation and alerting | SIEM ingestion, built-in analytics | Events arrive but no alerts fire |
A detection that never fires is a very different problem from a detection that fires late, or one that fires but gets suppressed. Write down which layer looks broken before you change anything. Teams that skip this step often spend hours tuning analytics rules when the real issue is a disconnected log connector.
It also helps to confirm the scope. Is the gap limited to one identity type, such as service accounts or federated users? Is it one location, one tenant, or everything? Narrowing scope turns a vague complaint into a testable hypothesis.
Check Licensing and Feature Gating First
This is the most common and most overlooked root cause. Many identity detection capabilities sit behind specific license tiers. Microsoft’s identity protection features, for example, are tied to Entra ID P2 and Defender for Identity licensing. If a license lapses, gets reassigned, or was never applied to a new tenant, detections can stop silently. No error banner appears. Alerts simply never generate. (Identity Theft)
Practical checks that actually work:
- Confirm the license SKU assigned to each user and to the tenant itself.
- Verify that trial licenses have not expired, since trials commonly power proof-of-concept deployments.
- Check whether a recent tenant migration or consolidation dropped features.
- Review the product’s feature comparison page against what you believe you bought.
A frequent mistake is assuming a working dashboard means working detection. Dashboards can render cached data while the underlying analytics engine is unlicensed. Always validate with a live test event rather than trusting the UI.
Audit Signal Source Health and Connectors
Detection is only as good as its inputs. When identity threat detection troubleshooting stalls, the culprit is usually a gap in the signal chain.
Identity provider logs
Confirm that sign-in and audit logs are actually flowing. In Entra ID, check that diagnostic settings export the sign-in and audit categories to your destination. In Okta, verify the System Log API integration is active and that the API token has not expired or been revoked. Expired tokens are a classic silent failure: the connector looks configured, but ingestion stopped weeks ago.
Sensor and agent status
On-premises Active Directory coverage usually depends on domain-joined sensors with specific permissions. Vendor sensor health pages exist for exactly this reason. Check three things: the sensor is online, it has the required directory permissions, and its service account credentials have not rotated out from under it. A password change on a service account is a mundane event that can quietly break detection coverage.
SIEM ingestion
If your architecture routes identity events into a SIEM, confirm the pipeline end to end. Compare event counts in the source system against counts in the SIEM for the same hour. A large mismatch points to a parsing or filtering problem. For teams running open-source stacks, guides like this walkthrough on using Wazuh SIEM to detect PHP2Shell in 13 steps show how much depends on correct rule and decoder configuration. The same principle applies to identity events: bad parsing means no detection.
Investigate Suppression Rules and Safe Entity Lists
Here is a scenario that plays out constantly. An analyst suppresses a noisy alert during a busy week. Months later, a real attack uses the same technique, and nothing fires. Suppression rules, exclusions, and “safe entity” lists are the most common reason true positives vanish during troubleshooting.
Review every active suppression with fresh eyes:
- Which rule created it, and when?
- What is the exact scope? A rule meant for one service account can accidentally cover an entire identity group.
- Has the suppressed behavior changed since the rule was written?
The practical fix is a suppression register. Log the owner, the justification, and an expiry date for every rule. Rules without an expiry date tend to live forever. During an investigation, temporarily disable suppressions for the affected identity and replay the event. If the alert appears, you have found your culprit.
Account for Learning Periods and Baselines
Behavioral detections need history. Most platforms require a learning window before they alert on anomalous behavior, and newly onboarded identities or fresh tenants often show suppressed alerts by design. This is not a bug, but it confuses teams during a rollout.
What actually works in practice is staging the rollout. Onboard a pilot group first, let the baseline build, then expand. Document the learning period length for each detection category so nobody panics during week one. If you must validate detection before the baseline matures, use a known-bad test scenario rather than waiting for organic anomalies.
Rule Out Time Skew and Log Latency
Correlation engines stitch events together by timestamp. When clocks drift or ingestion lags, correlations fail and alerts never assemble. Symptoms include events that appear out of order, alerts that fire hours late, or sequences that look incomplete.
Check these items in order:
- Confirm NTP is configured and healthy on every sensor and connector host.
- Measure ingestion latency by comparing event creation time to SIEM receipt time.
- Look for bursty delivery patterns, which often indicate a buffering connector.
- Verify time zone handling, especially across multi-region tenants.
A five-minute lag rarely matters for a single event. It matters enormously when a detection depends on a sign-in followed by a privilege change within a tight window. Attackers do not wait for your pipeline to catch up.
Verify Permissions, Consent, and API Access
Modern detection platforms enrich alerts using APIs. Graph API permissions, application consent, and service account rights all feed that enrichment. If a permission is revoked, an admin consent expires, or a service principal secret rotates, enrichment breaks. The alert may still fire but arrive without the context analysts need, which looks like degraded detection.
A useful habit is to inventory every API connection the platform uses and assign an owner. Rotation schedules for secrets and certificates should be documented, and the detection team should be notified before rotation, not after. Silent credential expiry is one of the top causes of “it worked last month” tickets.
Separate Real Threats from Legitimate Automation
Not every weird alert is a false positive, and not every false positive is harmless. Service accounts, CI/CD pipelines, and password managers routinely trigger identity risk detections because they behave like attackers: they authenticate from unusual locations, at odd hours, with elevated privileges.
The practical answer is not to suppress everything. Instead, classify automation identities explicitly. Tag them, document their expected behavior, and build narrow allow rules tied to specific source ranges or schedules. Broad exclusions are how real compromises hide. If you want to understand how attackers abuse legitimate credentials, the MITRE ATT&CK technique pages on valid accounts and credential access are worth reading alongside your alert tuning.
Use Threat Intelligence Context to Prioritize
Once detections flow again, prioritization becomes the next problem. A cyber threat intelligence map can help teams visualize where identity attacks originate and which patterns deserve immediate attention. Context turns a flat alert list into a ranked queue.
It also pays to understand the adversary’s goal. Most identity attacks exist to steal credentials or session tokens. If you want a broader grounding in how stolen credentials get weaponized, this explainer on what identity theft is and how to prevent it covers the consumer side of the same problem. On the enterprise side, keyloggers remain a common credential-theft tool, and knowing how to detect a keylogger helps analysts interpret endpoint signals that accompany identity alerts. (Identity theft)
Build a Repeatable Troubleshooting Checklist
Ad hoc debugging wastes time. A short, ordered checklist resolves most cases in under an hour. Adapt this sequence to your stack:
- Define the failure: missing, late, suppressed, or unenriched alerts.
- Confirm licensing and feature availability for the affected identities.
- Verify identity provider log export and connector token validity.
- Check sensor health, permissions, and credential rotation status.
- Compare source and SIEM event counts for the same hour.
- Review active suppressions and safe entity lists.
- Confirm learning period status for behavioral detections.
- Check clock sync and ingestion latency.
- Validate API permissions and enrichment paths.
- Run a controlled test event and confirm end-to-end detection.
The final step matters most. A controlled test proves the pipeline works rather than assuming it does. Document the test method so the next person can repeat it.
Common Mistakes That Prolong Outages
Teams repeat the same errors during identity threat detection troubleshooting. Watch for these:
- Changing analytics rules before checking connectors. If no events arrive, no rule will ever fire.
- Trusting the dashboard. Cached views hide broken pipelines.
- Suppressing instead of classifying. Broad exclusions mask real threats.
- Ignoring service account hygiene. Rotated credentials break sensors silently.
- Skipping the test event. Assumptions substitute for evidence.
- Forgetting documentation dates. Vendor feature names and licensing change frequently, so pin every claim to a documentation date.
Conclusion
Identity threat detection troubleshooting is less about exotic attacks and more about disciplined plumbing. Most silent detections trace back to licensing gaps, expired connector tokens, unhealthy sensors, overbroad suppressions, or clock skew. None of those are glamorous, and all of them are fixable with a short, ordered checklist.
The teams that recover fastest treat detection as a pipeline with testable stages. They validate inputs, prove the path with controlled events, and document every suppression with an owner and an expiry date. They also accept that vendor terminology shifts, so they pin their assumptions to specific documentation dates. Run that discipline consistently, and a quiet dashboard will mean what it should: nothing to report, rather than nothing to see.
Frequently Asked Questions
Why did my identity threat detection alerts suddenly stop?
The most common causes are an expired connector token, a lapsed license, a rotated service account credential, or a suppression rule added during a busy period. Check the signal chain from identity provider to alerting engine in order, and confirm with a controlled test event.
How do I know if licensing is blocking my detections?
Compare your assigned license SKUs against the vendor’s feature requirements for each detection category. Confirm trial licenses have not expired and that tenant migrations did not drop features. A live test event is the only reliable proof that a licensed feature is active.
What is a learning period in behavioral detection?
A learning period is a window during which the platform builds a baseline of normal behavior for identities before it alerts on anomalies. New tenants and newly onboarded identities often show suppressed alerts during this window, which is expected behavior rather than a fault.
Can time synchronization really break detections?
Yes. Correlation engines match events by timestamp. Clock drift or ingestion lag can prevent sequences from assembling, so alerts never fire or fire late. Confirm NTP health on all sensors and measure ingestion latency regularly.
How should I handle false positives from service accounts?
Classify automation identities explicitly instead of suppressing them broadly. Tag each identity, document its expected behavior, and create narrow allow rules tied to specific source ranges or schedules. Broad exclusions create blind spots where real compromises can hide.
How often should I review suppression rules?
At minimum quarterly, and always after a major incident review. Assign an owner and an expiry date to every rule when it is created. Rules without expiry dates tend to persist indefinitely and quietly mask true positives.
