Securing the identity threat detection and response (ITDR) tool itself: admin roles, service accounts, keys, logs and lifecycle

An identity threat detection and response tool watches your most privileged identity systems, so whoever controls it can blind your defenders or turn its response actions against you. To do its job, an ITDR tool reads directory and identity provider data, runs sensors on domain controllers and federation servers, holds API credentials into cloud tenants and can disable accounts or revoke sessions on its own. That makes the tool itself a tier 0 asset. This guide is for identity security engineers, SOC leads and platform owners who run or are about to run an ITDR tool. It covers admin roles, the service accounts and connectors the tool uses, the keys it holds, its own logs, response automation guardrails and the lifecycle from purchase to decommissioning. It is vendor-neutral: confirm the exact setting names in your vendor's documentation.

Key takeaways

• Treat the ITDR tool as tier 0. It has read access to, and often write access into, the systems that define every other identity, so protect its console, connectors and sensors like domain controllers.
• Split read and act. Use separate identities for collection (read only) and for response actions (narrowly scoped write), so a stolen collector credential cannot lock out your administrators.
• Prefer certificates and federation over static secrets. Connector credentials should be asymmetric or short lived; any static API key gets an owner, an expiry and a rotation date.
• Send the tool's own audit log somewhere it cannot reach. Admin changes, rule edits, exclusions and response actions belong in a separate log store that ITDR administrators cannot alter.
• Put guardrails on automation. Protected-account lists, blast-radius limits, human approval for high-impact actions and a tested kill switch stop a bad rule or an attacker from mass disabling accounts.

Why the ITDR tool is a tier 0 asset

Tiering groups administration by the impact of compromise. The UK NCSC describes tier 0 as the root of trust that other tiers depend on, notes that a privileged access management solution could itself be designated tier 0, and warns against administering a higher tier from a lower-tier system. An ITDR tool fits the same logic: it sits on, or holds credentials into, tier 0 identity systems. If it is managed from ordinary laptops with ordinary accounts, it becomes a browse-up path into the directory. See the Tiered Administration and Enterprise Access Model Guide and, for what the tool should detect, the ITDR Guide.

Admin roles and console access

Most ITDR consoles ship with a small set of built-in roles. Map them to real duties before anyone logs in, and keep the number of full administrators to a handful.

• Role design: separate at least four duties: platform administrator (tenant settings, integrations, roles), detection engineer (rules and tuning), analyst (triage and case notes) and responder (approve or run response actions). Exclusions and suppression rules are as sensitive as admin rights, because an exclusion is a permanent blind spot; restrict who can create them.
• Authentication: sign in through your identity provider with SSO and phishing-resistant MFA. The CISA and FBI Secure by Demand guide suggests buyers ask whether SSO is offered at no additional cost and whether MFA is on by default at no cost, so treat these as procurement questions. Disable or vault any local console accounts once SSO works, keeping one documented break-glass account. See the Break-Glass Account Guide.
• Admin devices: administer the platform and its sensors only from privileged access workstations, in line with the NCSC principle of gaining trust in management devices. See the Privileged Access Workstations Guide.
• Just-in-time elevation: grant platform administrator and responder roles on request for a time-bound window through your PAM process, and record the reason. The NCSC tiers guidance restricts high-risk actions such as changing security controls to PAWs, just-in-time access and just-enough administration.
• Two-person rule: for changes that reduce visibility (disabling a sensor, deleting a rule, adding a broad exclusion), require a second approver. NCSC notes that privileged access management should ensure no single person can act alone.
• Review: review console role assignments every quarter (our recommendation) and on every leaver or role change, alongside your other tier 0 access reviews.

Service accounts and connectors

The tool's own non-human identities are the part most often over-privileged during a rushed deployment. Vendors sometimes suggest broad rights to make setup simple; ask which permissions each feature needs and grant only those.

• Separate read from act: the most important design decision. A collector compromise then exposes data but cannot change identities, and a responder credential can be held to a much tighter set of conditions.
• Bind connectors to where they run: restrict where each connector identity can authenticate from (the sensor subnet, the vendor's documented egress addresses, or a workload identity), and alert on use from anywhere else.
• Constrain tokens: RFC 9700, the OAuth 2.0 Security Best Current Practice (BCP 240), recommends asymmetric client authentication such as mutual TLS or private_key_jwt, audience-restricted tokens and sender-constrained tokens using mTLS or DPoP. Use these where the provider and the tool support them.
• Inventory them: record each ITDR identity with owner, purpose, permissions and credential expiry in your NHI inventory. See the Service Account Security Guide.

Integration patterns, such as how to connect the tool to SIEM, SOAR and ticketing safely, are covered in the Identity threat detection and response (ITDR) tool integration security guide.

Sensors on tier 0 hosts

A sensor on a domain controller is third-party code running with high local privilege on your most important server. Treat its installation, update and removal as tier 0 changes.

1. Verify what you install: download installers only from the vendor's authenticated portal, check signatures or hashes, and record the version in your change ticket. Ask for an SBOM, as the Secure by Demand guide suggests.
2. Control updates: decide whether sensors auto-update. Auto-update closes vulnerabilities quickly but trusts the vendor's update channel; staged updates (a pilot domain controller first) give a rollback point. Either way, apply vendor security updates promptly and subscribe to the vendor's security advisories page.
3. Protect against tampering: turn on any tamper protection the sensor offers and restrict who can stop the service locally. Stopping or modifying security tools is ATT&CK technique T1685 Disable or Modify Tools.
4. Alert on silence: a sensor that stops reporting looks the same as a quiet network. Alert when any sensor misses its heartbeat for more than 15 minutes (our suggested threshold), and route that alert outside the ITDR tool, for example from the SIEM.
5. Limit network paths: allow sensor egress only to the vendor's documented endpoints over TLS, and if you use a proxy, keep its logs.

Keys, tokens and secrets the tool holds

• Inbound API keys: keys that let scripts or SOAR call the ITDR API are as powerful as the role they map to. Create one key per integration, scope it to the minimum role, set an expiry, and rotate static keys at least every 90 days where federation is not available (our recommendation).
• Outbound credentials: webhooks and SIEM tokens stored in the console should be write-only to their destination and restricted by source address or mTLS where the destination supports it.
• Storage: for self-hosted deployments, keep connector certificates and secrets in your secrets manager or a hardware-backed key store rather than in configuration files on the server. See the Secrets Management Guide.
• Customer-managed keys: if the SaaS tool offers customer-managed encryption keys, decide deliberately: they add revocation control but also an outage risk if the key is disabled by mistake.
• What the tool collects: some tools capture authentication traffic or store credential-derived data such as password hash comparisons for weak-password checks. Ask exactly what is stored, where, for how long, and who at the vendor can access it.

The tool's own logs

An attacker who reaches the console will try to change what it sees before acting. The tool's own audit trail is how you catch that.

• Export it elsewhere: stream the audit log to a SIEM or log archive that ITDR administrators cannot modify or delete. NIST SP 800-53 AU-9(2) covers storing audit records on a separate system, and AC-6(9) covers logging privileged functions.
• Retention: keep at least as long as your incident investigations need. Secure by Demand asks SaaS providers to retain and make available security logs for at least six months at no extra charge; check what your contract gives you and export if it is shorter.
• Cross-check the target systems: response actions also appear in the identity provider and directory logs. Reconcile the two; an action in the directory with no matching ITDR record is a red flag.

Guardrails for response automation

Automated response is the feature that most changes the risk of the tool. A wrong rule, a poisoned signal or an attacker with console access can disable many accounts in seconds.

• Protected accounts: keep a list of break-glass accounts, the ITDR identities themselves and critical service accounts that automation can never disable or reset. Changes to the list need two approvers.
• Blast-radius limits: cap automated actions per run and per hour, for example no more than five account disables per hour without a human (our suggested starting point), and fail closed to "alert only" when the cap is hit.
• Tiered approval: allow automatic session revocation for high-confidence alerts on standard users, but require a human approver for password resets, group removals and anything touching privileged accounts.
• Kill switch: document how to pause all automation in one step, who may do it, and test it twice a year.
• Change control for playbooks: version response playbooks, review changes like code, and test them in report-only mode before enabling. See ITDR validation.

Lifecycle: buy, deploy, run, retire

Roll back a hardening change (for example narrowing connector permissions) by keeping the previous permission set documented and re-granting only the specific right a feature reports as missing, never by restoring broad admin rights.

Detection and measurement

• Connector use from unexpected locations: sign-ins by ITDR identities outside their expected network or workload identity.
• Interactive logon by a service identity: a collector account used interactively is a strong compromise signal (T1078).
• Console persistence: new admins, new API keys and new exclusions outside a change ticket.
• Telemetry gaps: per-sensor heartbeat and per-connector ingest volume compared with a baseline.

Metrics that show the controls are working:

1. Number of full platform administrators (target: five or fewer, our suggestion), and percentage holding the role just in time.
2. Percentage of connector identities using certificate or federated credentials rather than static secrets.
3. Exclusions older than 90 days without re-approval (target: zero).
4. Sensor coverage: percentage of domain controllers and federation servers with a healthy sensor.
5. Time to detect a stopped sensor, measured in tests.
6. Percentage of ITDR admin actions with a matching change or case reference.

Framework mapping

Common failure patterns

• Domain admin for the collector: the directory read account is added to a privileged group during a proof of concept and never removed, turning the tool into the easiest route to domain dominance. See How to find service accounts with Domain Admin rights.
• One identity for everything: collection and response share a credential, so a leaked read key can also lock out administrators.
• Exclusions that never expire: a noisy service account is excluded during tuning and later becomes the account an attacker uses.
• Silent sensors: a sensor stops after an operating system update and nobody notices because the tool alerts only on what it sees.
• Audit log left inside the tool: the only record of admin changes sits in the console an attacker controls.
• Uncapped automation: a rule misfires and disables many accounts, including the people who could fix it.

Practitioner checklist

• Classify the ITDR tool, its sensors and its connector identities as tier 0 and administer them only from privileged access workstations.
• Enforce SSO with phishing-resistant MFA for the console and keep one tested break-glass account.
• Define separate roles for platform admin, detection engineering, analysis and response, with just-in-time elevation for admin and responder roles.
• Use separate identities for collection and response, each with the minimum documented permissions.
• Replace connector client secrets with certificates or federated credentials; give any remaining static key an owner and expiry.
• Turn on sensor tamper protection and alert on missed heartbeats from a system outside the ITDR tool.
• Export the tool's audit log to a store ITDR administrators cannot change, and alert on new admins, exclusions and rule changes.
• Configure a protected-account list, action caps, human approval for high-impact actions and a tested kill switch.
• Review roles, connectors, keys and exclusions every quarter, and record a full decommissioning checklist.

Standards and references

• NCSC: Secure system administration
• NCSC: Risk manage administration using tiers
• CISA and FBI: Secure by Demand Guide
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
• CISA and ASD's ACSC: Guidance for SIEM and SOAR Implementation
• MITRE ATT&CK: T1685 Disable or Modify Tools

Related NHI Mgmt Group resources: ITDR Guide · ITDR Buyer's Guide · Identity threat detection and response (ITDR) tool integration security guide · Tiered Administration and Enterprise Access Model Guide · Securing the NHI management platform itself