SOC 2 Readiness

24/7 Security Monitoring

Canadian-Based SOC

GuardsArm Platform · Detect

ITDR — Identity Threat Detection & Response

Detect identity-based attacks across your directories and cloud identities.

Identity is where most intrusions now begin, and an attacker holding a valid credential passes every preventive control upstream. ITDR watches the identity layer specifically.

0–100 risk scoring
10 connectors
9 response actions

Request a demo Talk to us

Identity activity from directory and cloud identity providers being scored for risk and linked to endpoint activity in a single investigation timeline

What is at stake

The intrusions that matter most often involve no malware at all — just valid credentials, used by the wrong person, invisible to endpoint tooling.

Credential-based attacks become visible

Identity activity is watched as an attack surface rather than retained for compliance and never read. That is the difference between discovering account compromise and discovering it months later.

Privileged accounts are treated as the emergency they are

A dedicated privileged-account view narrows attention to the subset where one compromise is an incident with executive consequences.

Identity and endpoint stop being two investigations

Credential access on a workstation and an unusual sign-in correlate into one incident, rather than two alerts in two queues that somebody has to notice are related.

Who carries this

Shared between IAM and the SOC — which is precisely why it works better as a module than as a separate tool with its own console and its own scoring.

The problem

Identity is where the perimeter actually is now

Most intrusions that matter involve valid credentials at some point, and many involve nothing else. There is no malware to find, no exploit to detect, and no anomalous binary on disk — only a legitimate account doing legitimate things at a time, from a place, or at a scale that a human would find odd if a human were looking.

Endpoint tooling is largely blind to this. So is network monitoring. The signal lives in directory and cloud identity logs, which are voluminous, poorly standardised across providers, and routinely retained only for compliance rather than watched for attack.

The second problem is isolation. Identity products that run as their own tool produce identity alerts in their own queue, scored on their own scale. An identity alert that cannot be joined to endpoint activity is half an investigation, and the join is being done manually, under time pressure, by whoever is on shift.

The hard identity cases are not unauthorised access. They are authorised access by the wrong person.

Capabilities

What ITDR does

Around 25 identity-focused detections

Purpose-built detections for the identity layer, producing identity alerts scored 0–100 rather than folded into generic event noise.

Ten identity connectors

Connect the directories and cloud identity providers your organisation actually uses, so the identity picture is complete rather than partial.

Nine response actions

Act on an identity finding directly — the response set is identity-specific rather than borrowed from endpoint containment.

A dedicated eight-tab console

Overview, inventory, privileged accounts, alerts, timeline, response, connectors and compliance — the privileged account view being the one most organisations find uncomfortable reading.

How it fits the platform

Identity findings correlate with endpoint and network telemetry in the same engine, which is what turns "an unusual sign-in" and "credential material accessed on a workstation" into one incident instead of two unrelated alerts.

How it works

From a directory event to a contained account

Five stages, with the fourth doing the work that a standalone identity tool cannot.

Connect the identity sources
Ten connectors bring in directory and cloud identity activity — the authentication, authorisation and directory-change records that describe who did what. Connectors are configured in the console, in the Connectors tab.
Build the identity inventory
Accounts, their privilege level and their behaviour baseline are maintained continuously. The privileged-account view matters most: it is the subset where a single compromise is an emergency rather than an incident.
Run the identity detections
Roughly twenty-five identity-focused detections evaluate the stream. Each produces an identity alert carrying a 0–100 risk score alongside the platform-wide severity band.
Correlate with everything else
Identity findings enter the same correlation engine as endpoint and network telemetry. This is the step that distinguishes ITDR as a module from ITDR as a separate product — the credential-access-to-lateral-movement family spans both domains.
Respond
Nine identity response actions are available, subject to the same approval gates and safelists as every other response on the platform. Disabling an account is not something that should fire unsupervised by default, and it does not.

Detection output

What an identity alert carries

Roughly twenty-five identity-focused detections feed the queue. What makes them workable is what travels with each one.

A 0–100 identity risk score

Scored on the identity dimension specifically, so an account can be flagged as risky on its own behaviour rather than only when it trips a host-based rule.

The platform severity band

The same Info-to-Critical scale every other module uses, derived from the same 0–15 level. An identity High and an endpoint High are comparable, which is what lets one queue hold both.

The principal and the privilege level

Resolved against the identity inventory, so the first question an analyst asks — does this account matter — is already answered on the alert rather than after a lookup.

Attached response actions

Nine identity response actions are available from the alert itself, gated by the same approval policy and safelists as the rest of the platform.

Cross-domain

Where identity meets the rest of the platform

These are the joins that only exist because identity is a module rather than a separate product.

Credential material accessed on a workstation, then an unusual sign-inOne credential-compromise incident instead of an endpoint alert and an identity alert that nobody joins up.
Privilege escalation in the directory, then persistence on a hostEntrenchment incident — the escalation explains the host activity, and the host activity confirms the escalation was not administrative.
Successful sign-in after sustained brute forceAccount compromise. The successful event alone is indistinguishable from a user who finally typed it right.
A new privileged account created outside the change windowBackdoor account finding, raised with the identity risk score and the creating principal attached.

The console

Eight tabs, each answering a different question

The identity console is built around the sequence an analyst actually follows rather than around the data model.

Understand the estate

Overview
Inventory
Privileged accounts

Work the threat

Alerts
Timeline
Response

Keep it wired and evidenced

Connectors
Compliance

Background

Understand the concept first

Plain explainers on the underlying ideas, written for someone evaluating rather than buying.

Questions

Common questions

Which identity providers can it connect to?

Ten identity connectors cover the directories and cloud identity providers in common use. The practical test is whether the identity picture is complete, since a directory left unconnected is a blind spot rather than a partial view.

What can it do about an identity finding, not just report it?

Nine response actions are identity-specific rather than borrowed from endpoint containment, so a finding can be acted on in the identity layer where it occurred.

How does this differ from what the SIEM already sees?

Identity findings correlate with endpoint and network telemetry in the same engine. That is what turns an unusual sign-in and credential material being accessed on a workstation into one incident rather than two unrelated alerts.

Works with