Identity threat detection: prove the gap before buying another platform

A new identity detection platform is a difficult purchase to defend if nobody can name the investigation it will make possible. For an identity lead, the useful starting point is a question the current team cannot answer: who gained authority, how was it used, and can we remove that access without disabling the wrong service?

Identity threat detection and response, usually shortened to ITDR, should be assessed against that work. Another dashboard may make existing events easier to navigate. A specialist product may add an important relationship or detection. Neither result follows from the category name. The commercial decision is whether the improvement justifies another licence, another integration and another queue for the security team to maintain.

Choose the question before the alert

Start with three scenarios that cross the boundary between identity administration and application activity. Use test accounts, an agreed window and changes that can be reversed safely. Have an investigator who did not perform the test reconstruct what happened from the records available in normal operations.

• Unexpected privilege: grant a test identity a permitted role, use that authority for a harmless action, then remove it. Can the investigator distinguish the person or application making the grant from the identity receiving it?
• Suspicious session use: perform an agreed application action from a test session. Can the team relate the action to its authentication context, or does the trail stop at a successful sign-in?
• Account recovery: exercise an approved recovery route. Can the investigator see the recovery event, the responsible operator where recorded, and subsequent account use?

A sign-in record cannot, on its own, establish everything a user did inside an application. Equally, an application audit event may identify an account without explaining how the session was established. Ask for the missing relationship explicitly. Otherwise a long list of available event types can disguise a short investigation.

Find out what the fields actually mean

Microsoft Entra provides a useful example. The Microsoft Graph directoryAudit schema separates the initiating user or application from affected target resources. It also exposes the activity time, result, logging service and correlation identifier. Those distinctions matter when investigating a role change: the target account is not necessarily the actor, and an attempted operation is not necessarily a successful grant.

A correlation identifier is a lead to test, not a promise that every identity provider, SaaS application and endpoint will use the same key. Inspect real records from each system. Keep stable object identifiers where available; display names and email addresses alone can make renamed accounts or similarly named identities difficult to distinguish. Record which joins are exact and which rely on time, device or network context.

In a hypothetical investigation, the SOC sees a suspicious session but cannot connect it to the privilege grant that preceded it. The grant exists in the directory audit log, but the collector discarded the target resource identifier. Buying another detection engine would leave that evidence gap intact unless the new integration also fixes collection. The immediate remedy is to preserve the field, replay an authorised test and see whether the investigator can now reconstruct the chain.

Test the time available to investigate

The source console and the investigation platform may hold different histories. Microsoft’s retention documentation gives seven days for native audit and sign-in logs in Entra ID Free, and 30 days in P1 and P2. Longer retention requires a suitable export or archive arrangement. A licence upgrade does not recover records already lost.

For each scenario, inspect the oldest event actually retrievable in the investigation system. Check export failures and gaps as well as the configured retention period. A nominal year of storage is of little help if one required source stopped arriving last month.

Measure event delay separately. Compare the action time, source availability, collector arrival and time when the investigator can query it. Repeat during an ordinary busy period. Do not replace those observations with a generic claim that a connector works in real time. If the useful evidence arrives after the response decision, the team needs a different containment procedure or a faster evidence path.

Match the purchase to the remaining failure

Classify each unresolved problem before requesting a demonstration. A missing event needs a source or collection change. A missing relationship needs better identifiers, enrichment or correlation. A useful alert with no available responder needs an operating decision. These can coexist, but they require different remedies and budgets.

Give a shortlisted supplier the failed scenario and the evidence the current stack already provides. Ask it to demonstrate what additional conclusion its product enables, what data and licence tiers that conclusion requires, and who maintains the integration. Include the analyst effort to dismiss an ambiguous alert and the permissions needed for any proposed automated response. A successful demonstration should end with a defensible investigation outcome, not merely a new alert.

Keep emergency administration separate from detection coverage: the ability to spot misuse does not prove that administrators can recover during an identity-provider outage. For the purchasing decision, take the most consequential unresolved scenario and test its full path from event to response. That gives both the existing team and a prospective supplier the same problem to solve.