Product intent memo

Why We Built ITDR and where it fits

Strategic reference for product, engineering, and SOC stakeholders. This page combines validated platform capability evidence with externally researched ITDR market context.

Evidence timestamp

April 22, 2026

Claims here are split between: 1) current platform capability, and 2) competitor/category references verified from official vendor documentation.

Intent

What we intentionally built

Build a Microsoft identity operations layer for real SOC execution, not a dashboard-only prototype.
Keep one tenant-scoped workflow from ingestion to detection to incidents to containment to governance.
Preserve explainability: retain raw provider data while giving operators normalized evidence and action context.
Favor production-safe, auditable response over fragile automation hype.

Executive answer

Are we building the right thing?

Yes for our chosen scope: Microsoft tenant identity operations with practical detection, incident response, and governance continuity. This is not intended to replace every SIEM/XDR function.

If the goal is identity operations for Microsoft tenants with auditable response, this build direction is correct.
If the goal is replacing an enterprise-wide SIEM/XDR data lake, keep ITDR focused and integrate outward instead.
If the goal is pure prevention, native identity-policy controls remain primary and ITDR should stay detect-investigate-respond focused.

Product-validated scope

What ITDR already delivers

Ingestion + Evidence

Microsoft connector with delegated default plus app-only ingestion mode
Directory audit and sign-in ingestion with overlap-safe windows
Office 365 Management feed ingestion and mapped provider alerts
Tenant and connector retention controls across raw and normalized logs

Detection + Incidenting

Behavior-based sign-in detections (spray, replay, non-interactive anomalies, location shifts)
Workload identity detections (consent bursts, ownerless privileged changes, bootstrap risk)
Alert-to-incident grouping model with explainable evidence and scoring
Custom detection rule builder with draft → active → disabled lifecycle
Public detection catalog that documents current rule behavior

Response + Governance

Capability-aware user containment actions with RBAC and connector gating
Automated response playbooks triggered by alert severity with approval and dry-run controls
Append-only response history with provider verification context
Posture remediation, accepted-risk, and compliance workflows
Microsoft Secure Score integration with ranked control recommendations
Tenant-scoped auth and platform audit visibility

Production + Reporting

Production-grade service architecture for resilient ingestion and response workflows
Weekly report JSON/PDF, incident autopsy PDF, identity assessment reports
AI tenant assistant scoped to active tenant — available to all roles, falls back to platform default when no dedicated model is configured
Short-lived access tokens and refresh-backed browser sessions
Shareable public pages for value narrative, detections, product intent, and license-coverage clarity

Platform proof anchors

Product strategy and operating model

Clear operating intent and decision discipline keep the platform focused on practical identity operations outcomes.

Detection and incident workflow

Detection output is consistently correlated into alerts and incidents with explainable evidence and timelines.

Connector ingestion and feed reliability

Microsoft and Office 365 feeds are ingestion-aware and surface readiness states when optional data lanes degrade.

Operator frontend surface

Operators can move across incidents, identities, connectors, logs, reports, and posture workflows in one experience.

External research anchors

Market facts used in this narrative

Official documentation and vendor sources reviewed to avoid stale competitive assumptions.

ReferenceFact usedSourceCurrency
Microsoft Entra ID ProtectionRisk-based access control uses sign-in risk and user risk signals, with policy actions like MFA, password change, or block.Microsoft LearnUpdated March 20, 2026
Microsoft Defender for IdentityPositions as identity threat detection/investigation/response across on-prem, cloud, and hybrid, with unified incident context.Microsoft LearnUpdated February 25, 2026
Microsoft SentinelCloud-native SIEM with broad connector coverage and data-lake-first security operations model.Microsoft LearnUpdated September 30, 2025
Okta Identity Threat ProtectionEmphasizes continuous risk evaluation and automated responses including MFA challenge and session termination.Okta Product PageReviewed April 22, 2026
CrowdStrike Falcon Identity Threat ProtectionPositions real-time identity breach detection/response with cross-domain correlation and risk-based access controls.CrowdStrike Data SheetReviewed April 22, 2026
Silverfort ITDRPositions hybrid identity detection with inline response controls and SIEM/XDR enrichment.Silverfort Platform PageReviewed April 22, 2026

Competitive reality

How we compare in the current ITDR landscape

Category-level comparison focused on operations and production behavior, not marketing checklists.

Competitor archetypeTypical strengthCurrent ITDR edgeCurrent ITDR gap
Native Microsoft security stackDeep prevention and policy controls with broad Microsoft-native incident correlation.Purpose-built tenant workflow linking connector health, normalized evidence, incidents, containment, and posture debt in one operator console.Less native control-enforcement depth than full Entra/Defender/Sentinel adoption; still feed- and license-dependent.
SIEM-first identity programsVery broad telemetry ingestion, custom analytics flexibility, and mature large-SOC workflows.Lower operational overhead for identity-centric investigations with built-in entity model and response controls.Narrower integration footprint and less cross-domain breadth than a full SIEM/XDR data platform.
Point ITDR vendorsFocused detection depth, often with strong identity-risk analytics and adaptive policy hooks.Combines detection with posture governance, remediation ownership, and practical incident/report artifacts.Still closing selected depth areas like advanced chain analytics, full isolation orchestration, and broader notification channels.

Where we are stronger

Single evidence-to-response operating lane: logs -> alerts -> incidents -> actions -> reports
Built-in containment with capability-aware gating and verification context
Tenant and partner-friendly operating model aligned to MSP-style workflows
Transparent documentation of current detections and product limitations

Where we are weaker

Inline processing paths can still become a scaling risk in high-volume scenarios
Capability inference for response actions is useful but not yet complete for all entitlement edge cases
Optional Microsoft feeds can degrade due to tenant licensing/permissions and are warning-classified
Connector degradation is incident-backed in-platform, with out-of-band notification currently email-only
Identity detail experience still has parity gaps vs workload identity depth in some flows

Alignment review

Keep / extend / refactor / deprioritize

Keep

The current product thesis is correct for our target operator.

Correlated tenant-scoped model (inventory + logs + detections + incidents + response + posture)
Raw + normalized evidence strategy for explainability and usability
Single workflow objects (alerts/incidents) instead of parallel queue systems
Extend

Extend depth where current feeds and operator behavior already validate demand.

Ship phased detection roadmap aligned to existing Microsoft/O365 feeds first
Expand audit/report outputs for SOC handoff and stakeholder communication
Increase posture automation safely with explicit preview/approve/verify boundaries
Refactor

Refactor for operational scale before adding new broad feature classes.

Keep recurring sync/detection/retention processing in dedicated background services
Improve high-volume patterns with cursor pagination and reduced fan-out queries
Reduce client-heavy fetch-after-mount behavior for investigation pages
Deprioritize

Avoid prototype traps that dilute production value.

Generic AI wrappers that are not tied to evidence and response controls
Permission-scope expansion before related workflows exist in code and validation
Duplicate dashboards and queue models that bypass the incident workflow

Prototype risk check

Why this is not just a wrapper prototype

The platform already includes tenant-scoped evidence models, ingestion workflows, detection correlation, incident response flows, and exportable artifacts. The largest remaining risk is not product absence; it is execution discipline around scaling and operational hardening.