An identity threat detection and response (ITDR) tender that asks bidders whether they "detect identity attacks" will get the same yes from every vendor, and no way to tell them apart. This template is a ready-to-issue request for proposal with numbered requirements that can each be proven in a proof of concept and scored. It covers identity telemetry sources, detections for Active Directory, Microsoft Entra ID and Okta, non-human identity coverage, response actions, identity posture, platform security, services and commercials, with mandatory and scored criteria and a weighted evaluation model. It is vendor-neutral and written for identity security leads, SOC managers and procurement panels. For what ITDR is and how the market is shaped, read the ITDR Guide and the ITDR Buyer's Guide; this page is the procurement document.
How to use this template
- Replace text in square brackets, such as [Organisation], [SIEM] and [number], with your own details. Delete requirements for identity platforms you do not run.
- Each requirement has an ID (for example ITDR-DET-04) and a type: M mandatory (pass or fail, a single fail excludes the bid), S scored (0 to 5, weighted) or I informational.
- Weights, volumes and timings in brackets are illustrative. Set them from your own risk and estate before issue and do not change them after responses arrive.
- Issue sections 1 to 9 to bidders. The Implementation guidance section is for your evaluation panel only.
- Where a requirement cites a MITRE ATT&CK technique, ask bidders to show the detection firing in the proof of concept rather than accepting a coverage map.
- If you are also buying PAM or IGA, align IDs with the PAM RFP Template and IGA RFP Template so overlapping capabilities are scored once.
1. Purpose and scope
[Organisation] invites proposals for an identity threat detection and response capability and associated services. The capability must detect attacks against identity infrastructure and identities (human, non-human and AI agent), support or automate containment, and reduce identity attack surface through posture findings.
- In scope: [on-premises Active Directory forests and domains]; [Microsoft Entra ID tenants]; [Okta organisations]; [federation services such as AD FS]; [AD Certificate Services]; [cloud IAM in named providers]; [SaaS applications integrated with SSO]; [service accounts, service principals, API tokens and OAuth applications].
- Out of scope: [endpoint detection, already provided by EDR]; [workforce IGA certification campaigns]; [customer identity].
- Drivers: [incident lessons, for example MFA fatigue or help desk reset abuse]; [audit findings]; [cyber insurance questionnaire]; [SOC visibility gaps for identity].
- Contract term: [three] years with an option to extend by [one] year.
2. Organisation background and current state
| Item | [Organisation] value |
|---|---|
| Active Directory | [number] forests, [number] domains, [number] domain controllers, functional level [level] |
| Cloud identity providers | [number] Entra ID tenants (licence tier [Free, P1, P2]); [number] Okta orgs |
| Human identities | [number] employees, [number] contractors, [number] guests |
| Non-human identities known | [number] service accounts, [number] service principals and app registrations, [number] API tokens, or "unknown, discovery required" |
| Security tooling | [SIEM], [SOAR], [EDR], [PAM], [IGA], [ticketing] |
| SOC model | [in-house 24x7 / business hours / MDR provider named] |
| Hosting constraints | [SaaS acceptable / data residency in region / sensors on domain controllers permitted or not] |
3. Instructions to bidders
- Timeline: RFP issued [date]; clarification questions by [date]; responses due [date, time, time zone]; proof of concept [dates]; decision [date].
- Single point of contact: [name, email]. Contact with other staff during the process may lead to exclusion.
- Response scale: available now; available with configuration; requires another product from the bidder (name and price it); requires a third party (name it); roadmap (committed date); not supported. Roadmap answers score zero unless the date is contractual.
- Evidence: cite product documentation for each "available now" answer and list which licence tier of the bidder's product and of [Organisation]'s identity platforms the answer depends on.
- Architecture: provide a diagram showing every sensor, connector and API permission the solution needs, where data is processed and stored, and every inbound or outbound connection.
4. Telemetry and data collection requirements
Detection quality depends on what the product can see. Ask for the exact sources, not a list of logos.
| ID | Requirement | Type |
|---|---|---|
| ITDR-TEL-01 | Collects Active Directory authentication traffic or events from all domain controllers, including Kerberos ticket requests (Windows event 4768 and 4769) and NTLM authentication. State whether collection is by sensor, event forwarding or network capture, and the CPU and memory impact on a domain controller. | M |
| ITDR-TEL-02 | Collects directory replication and object access activity needed to detect DCSync, including event 4662 where the bidder relies on it; state the SACL and Audit Directory Service Access settings [Organisation] must enable. | S |
| ITDR-TEL-03 | Ingests Entra ID sign-in logs (interactive, non-interactive, service principal and managed identity), audit logs and Identity Protection risk detections. State which detections require Entra ID P2 or other Microsoft licences on [Organisation]'s side. | M |
| ITDR-TEL-04 | Ingests the Okta System Log through the API or log streaming, using a scoped OAuth 2.0 service app rather than an SSWS API token where possible. The Okta System Log returns only the last 90 days, so state how the product keeps longer history. | M |
| ITDR-TEL-05 | Ingests [cloud provider] control plane logs, [AD FS] and [AD CS] events, and [VPN, PAM, EDR] identity events, and correlates them with directory identities. | S |
| ITDR-TEL-06 | Reports collection health per source (last event time, gaps, dropped events) and alerts when a domain controller or tenant stops sending. | M |
| ITDR-TEL-07 | Data retention of [12] months searchable; export of raw and enriched events to [SIEM] in a documented schema. | S |
5. Detection requirements
For each scored item, the bidder states the detection name, data source, whether it is real-time or batch, the expected false positive drivers and how it is tuned. ATT&CK IDs are from ATT&CK v20.
5.1 Active Directory
| ID | Requirement | ATT&CK | Type |
|---|---|---|---|
| ITDR-DET-01 | Kerberoasting: anomalous service ticket requests, including requests for RC4 encryption (ticket encryption type 0x17) in an AES estate. | T1558.003 | M |
| ITDR-DET-02 | DCSync: replication requests from hosts that are not domain controllers. | T1003.006 | M |
| ITDR-DET-03 | Pass the ticket and forged ticket use, including tickets with abnormal lifetimes or no matching request. | T1550.003 | S |
| ITDR-DET-04 | Password spraying and brute force across Kerberos and NTLM. | T1110.003 | M |
| ITDR-DET-05 | Changes to privileged groups, AdminSDHolder, Group Policy and delegation settings, and abuse of AD CS certificate templates. | T1098 | S |
5.2 Entra ID, Okta and federation
| ID | Requirement | ATT&CK | Type |
|---|---|---|---|
| ITDR-DET-06 | MFA fatigue: repeated push prompts followed by approval, and suspicious MFA approvals. | T1621 | M |
| ITDR-DET-07 | MFA method registration or removal after a risky sign-in, help desk reset or from a new device, and changes to authentication policies. | T1556.006 | M |
| ITDR-DET-08 | Session and token theft: token replay, anomalous token properties and session cookie reuse from a new location or device. | T1539 | S |
| ITDR-DET-09 | Federation trust changes: new or modified federated domains, identity provider configuration and forged SAML tokens. | T1484.002, T1606.002 | M |
| ITDR-DET-10 | Privileged role assignment outside PAM or Privileged Identity Management, and Okta super administrator grants. | T1098 | M |
| ITDR-DET-11 | Valid cloud account abuse: impossible travel, anonymised infrastructure, and sign-ins that bypass Conditional Access or Okta policies. | T1078.004 | S |
5.3 Non-human identities and AI agents
| ID | Requirement | ATT&CK | Type |
|---|---|---|---|
| ITDR-DET-12 | New credentials (secrets, certificates, federated credentials) added to service principals and app registrations, especially privileged ones. | T1098 | M |
| ITDR-DET-13 | Service account or service principal used interactively, from a new location, or outside its normal resource pattern. | T1078.004 | S |
| ITDR-DET-14 | OAuth application consent grants with high-risk scopes, and use of stolen application tokens. | T1528, T1550.001 | S |
| ITDR-DET-15 | Okta API token use from unexpected networks, attributed to the token owner through the System Log transaction detail. | T1528 | S |
| ITDR-DET-16 | Baselines for AI agent identities (agent identities, workload identities used by agents) and alerts on scope or behaviour change. | n/a | I |
See the Entra ID Sign-In and Audit Log Detection Guide and the Okta System Log Detection Guide for the underlying events.
5.4 Detection engineering
| ID | Requirement | Type |
|---|---|---|
| ITDR-ENG-01 | Customers can write, test and version custom detections, and see the logic of built-in detections. | S |
| ITDR-ENG-02 | Every alert carries the identity, its owner, privileges, recent risk, source host and the evidence events, so an analyst can triage without leaving the console. | M |
| ITDR-ENG-03 | Tuning and suppression are scoped, time-limited and audited. | S |
6. Response and posture requirements
| ID | Requirement | Type |
|---|---|---|
| ITDR-RSP-01 | Containment actions for AD, Entra ID and Okta: disable account, force password reset, revoke sessions and refresh tokens, require MFA re-registration, remove from privileged groups. State which are native and which need SOAR. | M |
| ITDR-RSP-02 | Containment for non-human identities: disable service principal, remove or rotate credentials, revoke OAuth grants, with a dependency warning before acting. | S |
| ITDR-RSP-03 | Response actions can require approval, are logged with the analyst identity and can be reversed. | M |
| ITDR-RSP-04 | Bidirectional integration with [SIEM], [SOAR] and [ticketing], including alert status sync. | S |
| ITDR-PST-01 | Posture findings for AD (Kerberoastable privileged accounts, unconstrained delegation, weak AD CS templates, stale privileged accounts, accounts with non-expiring passwords) with remediation guidance. | S |
| ITDR-PST-02 | Posture findings for Entra ID and Okta (users without phishing-resistant MFA, legacy authentication allowed, privileged roles without PIM, excessive application permissions, inactive privileged identities). | S |
| ITDR-PST-03 | Attack path analysis from a standard user or service account to tier-zero assets across on-premises and cloud. | S |
See the Active Directory and Entra ID Hardening Guide and the Okta Security Hardening Guide.
7. Security of the solution
An ITDR product reads directory data and often holds rights to disable accounts. Treat it as a tier-zero system.
| ID | Requirement | Type |
|---|---|---|
| ITDR-SEC-01 | List every permission the product needs in each identity platform (Microsoft Graph application permissions, Okta admin roles and OAuth scopes, AD rights) and justify each; read-only and response permissions must be separable. | M |
| ITDR-SEC-02 | Console access through [Organisation] SSO with phishing-resistant MFA and role-based access; no local accounts except a documented break-glass account. | M |
| ITDR-SEC-03 | Sensor and connector credentials are scoped, rotatable and revocable; sensors on domain controllers are signed and updates can be staged. | M |
| ITDR-SEC-04 | Provide a current independent assurance report, [SIG or CAIQ] response, vulnerability disclosure policy and security incident history for three years. | M |
| ITDR-SEC-05 | Data processing locations, subprocessors and full data export and deletion at exit. | M |
8. Services, support and commercials
- Deployment: phased plan with acceptance criteria, for example [AD and Entra telemetry, then detections in alert-only mode, then response actions, then NHI coverage].
- Managed option: whether the bidder or a partner offers 24x7 monitoring and response, and how that interacts with [Organisation]'s SOC or MDR provider.
- Support: severity definitions, response targets and update cadence for detection content.
- Licence metric: per human identity, per identity of any type, per domain controller or other. State explicitly how service accounts, service principals, guests and AI agent identities are counted.
- Price: year 1 to 3 costs, growth of [20%] in identities, renewal cap and exit charges.
9. Evaluation method and proof of concept
| Criterion | Weight | Evidence |
|---|---|---|
| Detection coverage and quality (sections 4 and 5) | [35%] | Response, proof of concept results |
| Response and posture (section 6) | [20%] | Proof of concept |
| Analyst experience and integration | [10%] | Scored by SOC analysts during the proof of concept |
| Solution security (section 7) | [15%] | Permission review, assurance reports |
| Life-cycle cost | [20%] | Section 8 |
Scores use 0 to 5: 0 not met; 1 roadmap only; 3 met with configuration or partially demonstrated; 5 met fully and demonstrated in the proof of concept. The proof of concept runs for [three to four] weeks in [a test forest and test tenant mirroring production, or production in alert-only mode] and covers at minimum:
- Deployment: measure time to full telemetry and the collection health view (ITDR-TEL-06).
- Authorised red team or purple team emulation, agreed in writing: Kerberoasting of a test service account, replication from a non-domain controller test host, password spray against test accounts, MFA push fatigue on a test user, MFA method added after a risky sign-in, and a new secret added to a privileged test service principal. Record whether each alert fired, how fast and with what context.
- Response: revoke sessions and disable a test user in Entra ID and Okta from the console, then reverse it.
- Posture: compare findings against a list of known weaknesses seeded in the test estate.
- Noise: count alerts per day in alert-only mode on production telemetry and how many were true positives after tuning.
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Know your licences first: many cloud identity detections depend on the identity platform licence, not the ITDR product. Microsoft documents that most Identity Protection detections need Entra ID P2 and that Free and P1 tenants see only limited detections. Fill in section 2 accurately or bidders will price around different assumptions.
- Enable the audit settings before the proof of concept: without Audit Kerberos Service Ticket Operations and Audit Directory Service Access with SACLs, AD detections cannot be compared fairly.
- Weight non-human identities by your estate: if service principals and tokens outnumber people, raise the weight of 5.3.
- Emulate the attacks you fear most: the Storm-2949 Azure attack combined password reset abuse, MFA approval by deceived users and attacker-enrolled authenticators, then used privileged Azure roles to read Key Vault secrets. That chain maps to ITDR-DET-06, ITDR-DET-07 and ITDR-DET-10 and makes a good proof of concept scenario.
- Score response permissions as risk, not just capability: a product with tenant-wide write rights is a target. Prefer separable read and response roles (ITDR-SEC-01).
- Decide who answers the alerts: ITDR without an owner for identity alerts adds noise. Agree the runbook with the SOC before contract. See the SOC Runbook Template.
- Measure after go-live: track mean time to detect for the emulated techniques, percentage of domain controllers and tenants with healthy telemetry, percentage of privileged identities with posture findings closed, and alert true positive rate.
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Telemetry and retention (4) | AU-6, SI-4 | DE.CM-03 |
| Detections (5) | AC-2(12), SI-4 | DE.AE-02 |
| Response (6) | IR-4 | RS.MI-01 |
| Posture and identity inventory (6) | AC-2 | PR.AA-01 |
Standards and references
- MITRE ATT&CK: Kerberoasting (T1558.003)
- MITRE ATT&CK: DCSync (T1003.006)
- MITRE ATT&CK: Multi-Factor Authentication Request Generation (T1621)
- Microsoft Learn: What are risk detections in Microsoft Entra ID Protection
- Microsoft Learn: Event 4769, a Kerberos service ticket was requested
- Okta Developer: System Log query
- CISA and partners: Detecting and Mitigating Active Directory Compromises
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: ITDR Guide · ITDR Buyer's Guide · Security Vendor Evaluation and RFP Guide · PAM RFP Template · MDR Service RFP Template