Public FAQ
Questions MSPs and their customers ask during evaluation and onboarding. Covers multi-tenant operations, connector setup, detection and response workflow, notifications, and customer-facing reports. All answers reflect current platform behavior.
Behavior baseline
Reviewed May 2026
Answers reflect current platform behavior, not roadmap copy. If a capability is planned but not yet shipped, it is noted explicitly.
Who this is for
Quick flow
FAQ
For MSPs evaluating the platform
The questions most MSPs ask before they decide to move forward.
An MSP registers as a partner organization. The partner admin gets a single login and can switch between every managed customer tenant from one session — no re-authentication required. Each customer workspace has its own connectors, alerts, incidents, posture findings, and AI assistant scope. Tenant admins and analysts see only their assigned customer.
Where: Login -> Register partner, then Settings -> Tenant management
ITDR is operator-owned tooling. Your analysts investigate and execute containment. There is no outsourced SOC — you build your own detection and response capability on top of the platform. This is the right model for MSPs that want to own the security workflow for their customers rather than hand it off.
Where: Value page for positioning context
A new tenant is operational in under 30 minutes for most setups: add the tenant in Settings, connect Microsoft Graph (delegated OAuth or app-only credentials), optionally add a posture connector, then validate that logs and entities are flowing. Detection and alerting starts as soon as ingestion is live.
Where: Settings -> Tenant setup, Connectors page
No — and that is intentional. ITDR is the operator investigation and response layer on top of what Microsoft provides. It normalizes Entra evidence, groups correlated alerts into incidents, adds workload identity coverage, and gives you structured containment actions and posture governance. It is designed to work alongside Microsoft native tools, not to replace the licensing stack.
Where: /why-itdr competitive context
No. Business Premium and Entra P1/E3 tenants get core sign-in and audit log detection coverage. E5/P2 adds richer risk-signal enrichment from some Microsoft APIs. The platform shows which data lanes are available based on the tenant's provisioning, so you always know what you are working with.
Where: /license-coverage for the full breakdown
Most point tools focus on a single layer: alerts only, posture scans only, or raw log access only. ITDR combines Entra inventory, sign-in and audit evidence, behavioral detections, incident grouping, containment actions, posture findings, and governance workflow in one tenant-scoped system. Workload identity coverage (service principals, app permissions, ownerless apps, consent grants) is a specific area where the platform goes deeper than most.
Where: /why-itdr for the full competitive lens
Tenant isolation and role access
How data stays separated between customers and what each role can see.
Yes. Tenant isolation is enforced server-side on every request. All data — connectors, logs, alerts, incidents, posture findings, AI assistant queries — is scoped to the tenant. No role can see another tenant's data unless they are explicitly assigned to it.
Where: Platform-wide — enforced at API layer
A partner admin can switch between any tenant in their organization from one session. When inside a tenant, they operate with full tenant-admin level access to that workspace. They can also see a list of all managed tenants from Settings.
Where: Settings -> Tenant list, then tenant switcher in the app header
Tenant admins have full access to their own tenant: connectors, alerts, incidents, posture, settings, response actions. Analysts can investigate and view but have more limited action rights. Read-only users can view without executing any actions. All access is bounded to the assigned tenant — no cross-tenant visibility.
Where: Settings -> User roles, all app pages
Yes. The AI assistant is available to any role with access to the tenant and is scoped to that tenant's data. An analyst can ask about open alerts, incident status, posture findings, or identity context without leaving the investigation workflow. A partner admin using the assistant gets answers for whichever tenant they are currently viewing.
Where: AI assistant (bottom-right corner of the app)
Connector auth and data collection
Delegated vs app-only ingestion and what gets collected.
Delegated auth runs through an interactive Microsoft OAuth flow tied to a user account. App-only auth uses client credentials (app ID + secret) and does not depend on a user session. App-only is recommended for stable, always-on MSP ingestion since it does not break when user passwords or MFA change.
Where: Connectors page -> Connector auth mode
Identities, devices, applications, service principals, permissions, owners, directory audit events, sign-in events, and Office 365 Management feed events including mapped Microsoft provider alerts. All collected with tenant-scoped retention controls.
Where: Connectors page, Identities, Devices, Applications, Logs
Posture scans check Microsoft 365 configuration controls against a curated benchmark, normalize the findings, and surface them with compliance mapping, remediation context, and exception/accepted-risk workflow. Scans run on a schedule and can be triggered manually.
Where: Posture page -> Connector setup and findings
Connector degradation is surfaced as a platform alert and incident inside the app. Notification channels (Slack, Teams, PagerDuty) can be configured to receive connector-degraded events so your team is informed even if no one is actively watching the dashboard.
Where: Connectors page, Settings -> Notification channels
Alerts, incidents, and response
How detections become incidents and how containment actions work.
Alerts with matching grouping keys (same entity, same attack pattern, same time window) are automatically merged into an open incident. This keeps related evidence together instead of fragmenting the same threat across separate tickets. Each incident includes a timeline, linked entities, evidence references, and scoring context.
Where: Alerts -> Incidents pipeline
From an incident linked to a user identity, operators can revoke sessions, disable the user account, re-enable the account, or remove the user from a group. Actions require the connector to be active and the user role to have action rights. Every action is recorded with provider verification context in the incident history.
Where: Incidents -> Response actions panel
The platform checks the connector's current capability state before surfacing action buttons. If the connector is degraded or the required permission scope is missing, the action is disabled with a reason. This prevents failed or partially-executed actions from creating a false sense of containment.
Where: Incidents -> Capability-aware response panel
Incident status moves to resolved or false-positive and a resolved timestamp is set. Linked alerts can optionally be closed in the same workflow. The incident history, response actions, and timeline are retained for audit and reporting.
Where: Incidents -> Status workflow
Notifications and alerting
How your team gets notified when something important happens.
The platform supports Slack, Teams, and PagerDuty notification channels. Each channel can be configured to receive specific event types: new alerts, new incidents, severity changes, status changes, response action outcomes, or connector degradation. You decide which events go to which channel.
Where: Settings -> Notification channels
Yes. Each notification channel has its own event type selection. For example, you can send new high-severity incidents to a critical-incidents channel and connector health events to a separate ops channel. Per-channel routing is configured from Settings.
Where: Settings -> Notification channels -> Event routing
PagerDuty is a supported notification channel. Configure a PagerDuty channel with the event types you want to trigger pages — typically new_incident and incident_severity_changed — and those events route through your existing PagerDuty escalation policy.
Where: Settings -> Notification channels -> PagerDuty
Reports and customer deliverables
What you can share with customers and how it is generated.
Three report types are available today: a weekly security report (PDF and JSON) covering dashboard metrics and key activity; an incident autopsy PDF per closed incident with timeline and response history; and an identity security assessment report with normalized finding detail and PDF export. These are designed for MSP customer QBRs and compliance handoff.
Where: Dashboard, Incidents, Reports pages
Weekly reports are tenant-scoped — one report per tenant. A partner admin can generate reports across the tenants in their portfolio by switching between tenant workspaces. A consolidated cross-tenant summary report is a valid future extension.
Where: Dashboard -> Reports
Retention is configurable per tenant. Raw and normalized logs are purged based on the tenant's retention policy. An optional archive job can move older logs to S3 for long-term storage and regulatory access. Raw provider payloads are preserved for traceability alongside normalized views.
Where: Settings -> Retention and archive
Posture governance
How posture findings are tracked and resolved across scan runs.
Once the underlying control is fixed in Microsoft, the next posture scan will mark the finding as resolved. If the same issue reappears in a later scan, it reopens automatically. This ensures the finding lifecycle reflects actual tenant state rather than manual status fields.
Where: Posture -> Remediation + next scheduled scan
Yes. Accepted risk is tied to an exception lifecycle, not a one-time dismissal. The exception persists across scan runs until it expires, is reviewed, or is manually closed. Accepted risk stays auditable and visible — it does not silently suppress findings.
Where: Posture -> Risk acceptance and exceptions
Posture supports CSV and JSON exports of current findings and scan artifacts. The weekly report and identity assessment reports provide richer PDF outputs. A dedicated executive posture PDF is a planned extension.
Where: Posture -> Exports, Reports