Skip to content

Page permalink

Always use the following permalink when referencing this page. It will remain unchanged in future help versions.

https://docs.sophos.com/fusion/customer/help/en-us/index.html?contextId=xdr-m365-azure-data-availability

Microsoft 365 and Azure data availability

This page explains the following:

  • How Sophos XDR polls Microsoft APIs.
  • Which timestamp drives collection vs. event time in the product.
  • When a gap between event time and ingest time is expected.

Event time vs. ingest time

When analyzing events, event time typically refers to when Microsoft (or the export) says the activity occurred. Ingest time is when the normalized event for that row is created in Sophos XDR. This is when ingest (normalization) for that row is complete. Ingest time is not when every downstream step finishes; detectors, alerts, investigations or cases, automation, and similar workflows can still run after ingest time. A large gap between event time and ingest time is often expected when Microsoft publishes or updates the record later, when polling has not yet reached that time window, or when search indexing is still catching up. For more information, see Platform delay after collection.

Term Meaning
API time field A timestamp Microsoft uses so each poll can ask for what changed in this time range (for example, lastUpdatedDateTime or createdDateTime in the Graph API). It controls when a row becomes eligible to download, not necessarily what you see as event time.
Event time (in the UI; in raw exports sometimes event_time_usec) When the underlying activity occurred, taken from vendor fields such as activityDateTime or createdDateTime, depending on source—not necessarily the same as the API time field.
Ingest time (in the UI; in raw exports sometimes ingest_time_usec) When the normalized event is created, that is, when the ingest (normalization) for that row is complete. Later product behavior, such as alerts, investigations, and automation, can still occur after this timestamp.
Availability time When present, often closer to the vendor's last modified or updated time than to the original activity (for example, on risk detections that use lastUpdatedDateTime).

Reasons why the event time and ingest time differ may include the following:

  • Vendor delay: Microsoft may expose a log only minutes or hours after the activity, or update the same record later as part of remediation or alert refresh. Ingest follows API visibility and updates, while event time often stays tied to the original activity.
  • Polling and lag: Collection runs on a schedule and uses intentional lag behind "now", so late-arriving data is still captured. Multiple parallel streams with different lag lookbacks are common.
  • Platform pipeline: Transfer, batching, and indexing add additional minutes before data appears in search.

How to interpret an event

Keep the following points in mind when investigating a large gap between event time and ingest time:

  • Identify which Microsoft integration produced the event, then use the integration tables in the following sections to see which vendor fields map to event time vs. what drives each collection cycle (or export cadence).
  • If you have original or vendor JSON, compare the activity or creation timestamps to lastModified, lastUpdated, or lastUpdate fields (exact names depend on the API).
  • If "updated" is much later than "activity", the row was likely ingested when Microsoft published that revision, not when the sign-in or activity first occurred.
  • If both are close but ingest is still much later, consider polling interval and lag, Microsoft throttling, and downstream delay (including search indexing).

API-specific collection behavior

Microsoft Graph API

The collector uses scheduled requests to Microsoft Graph API. Each request asks for records in a time range, using the API time field listed below. The collector applies lag behind the current time, limits how large each range can be, and may run parallel streams with different lookbacks, so late-arriving rows are still captured.

Integrations, API filter field, and event time mapping

Integration Graph resource (list) API time field (drives polling) Typical source of event time
Microsoft Risk Detection and Microsoft Entra ID Protection (Identity XDR) user risk detections .../identityProtection/riskDetections lastUpdatedDateTime activityDateTime
Microsoft Entra ID Protection service principal risk detections .../identityProtection/servicePrincipalRiskDetections lastUpdatedDateTime activityDateTime
Microsoft Entra ID Protection agent risk detections (beta) .../identityProtection/agentRiskDetections (beta) lastModifiedDateTime activityDateTime
Microsoft Graph sign-ins .../auditLogs/signIns createdDateTime createdDateTime
Microsoft Graph directory audits .../auditLogs/directoryAudits activityDateTime activityDateTime
Microsoft Graph Security alerts (legacy) .../security/alerts lastModifiedDateTime eventDateTime, or firstActivityDateTime, or createdDateTime (in that order when a field is missing)
Microsoft Graph Security alerts v2 .../security/alerts_v2 lastUpdateDateTime eventDateTime, or firstActivityDateTime, or createdDateTime (in that order when a field is missing)

Note

For some resources, the API time field is a last modified or updated timestamp, while event time in Sophos XDR comes from when the activity or incident started (for example, activityDateTime, eventDateTime, or firstActivityDateTime, depending on the API). Risk detections, Graph Security alerts, and other mutable objects can change hours later when Microsoft applies remediation, changes a status, or refreshes a record. This updates the timestamp field and can trigger a new ingest, even though event time still reflects the original activity.

Typical poll intervals

These values are typical for Microsoft Graph collection. Deployed intervals can differ by environment and may change over time as availability and rate limits evolve.

Integration Typical interval (minutes) Notes
Microsoft Graph sign-ins / directory audits (legacy shared application) 10 Two streams per API (sign-ins and directory audits each): one with lag on the order of 10 minutes, one long lookback on the order of 4 hours (~250 minutes). Superseded for new setups by tenant-application Graph Audit.
Microsoft Graph sign-ins / directory audits (tenant application) 1 Multiple streams with lag lookbacks (for example, 1, 10, 20, ... 50 minutes) and optional start offset; additional streams may poll on a 10-minute cadence for longer lookbacks (up to several hours).
Microsoft Graph sign-ins / directory audits (Identity XDR) 1 Similar multi–lag stream pattern to tenant-application Graph Audit.
Microsoft Risk Detection; Entra ID Protection user risk detections 5 Includes extra lookbacks (for example, 4-hour stream).
Microsoft Graph Security alerts v2 10 Usually a near-real-time stream plus a long lookback stream (for example, lag 250 minutes).
Microsoft Entra ID Protection service principal and agent risk detections 5 Same general pattern as user risk.

Microsoft 365 Management Activity API

Audit content from the Microsoft 365 Management Activity API is normalized for search and analytics in Sophos XDR. The same subscription, listing, and retrieval pattern applies across offerings. The main differences are the activity feed host that Microsoft assigns for commercial and government clouds, and whether the tenant uses the current onboarding method (customer Entra ID application and certificate) or a legacy onboarding flow.

For more information, see Office 365 Management Activity API reference.

For integration setup (permissions, certificates, GCC vs. commercial), see Microsoft 365 Management Activity API.

Listing, content URIs, and delayed publication

Microsoft describes collection as a two-step flow:

  1. Discover blobs: After a subscription is started for a content type (for example, Audit.AzureActiveDirectory), the client either lists available content (for example, /subscriptions/content with optional startTime or endTime) or receives a webhook when new blobs are ready. Each item includes a contentUri, contentCreated (when Microsoft made that aggregation available), and related metadata.
  2. Download events: The client issues a GET to each contentUri to retrieve the JSON actions and events inside that blob.

A blob appearing in the list means that aggregation is ready to download. Individual events inside the blob can still be delayed relative to when the activity actually occurred, and blobs are not guaranteed to appear in the same order as real world event order. That is why event time (typically each record's CreationTime) can be much earlier than ingest time. For Microsoft's wording on aggregation, listing, retrieval, and latency, see Additional resources below.

Integrations, listing window, and event time mapping

Integration Microsoft activity feed base URL What drives each collection cycle Typical source of event time
Microsoft 365 Management — commercial / enterprise Microsoft 365 https://manage.office.com/api/v1.0/{tenant_id}/activity/feed/... Start a subscription per content type; list blobs with /subscriptions/content using startTime or endTime on when the blob became available (see Microsoft's contentCreated in the list response); GET each contentUri. Uses a customer-registered Entra ID application and certificate. CreationTime on each audit record
Microsoft 365 Management — GCC https://manage-gcc.office.com/api/v1.0/{tenant_id}/activity/feed/... Same subscribe → list → GET contentUri model; GCC endpoint for Microsoft 365 Government — GCC. Customer app + certificate in the government tenant. CreationTime
Microsoft 365 Management — GCC High https://manage.office365.us/api/v1.0/{tenant_id}/activity/feed/... Same model; GCC High endpoint and sovereignty rules per Microsoft. Customer app + certificate. CreationTime
Microsoft 365 Management — legacy https://manage.office.com/... (same API shape as commercial) Same blob semantics; older Sophos XDR product line predating the current register your own Entra ID application + certificate flow documented for commercial/GCC (analogous to legacy vs tenant-application Microsoft Graph Audit). Not offered for new integrations; polling is less aggressive than modern customer-app commercial. CreationTime
Microsoft 365 Identity XDR — Microsoft 365 Management path Commercial-style host for the customer tenant Same Management Activity API and customer-tenant credentials; Entra app registration may be provisioned automatically as part of XDR onboarding rather than pasted in manually. CreationTime

Typical poll intervals

These values are typical. Deployed timings can differ by environment and may change over time.

Why this table is less specific than Microsoft Graph

The Graph section lists minute-level intervals that match shipped stream configuration for those integrations. Microsoft 365 Management integrations also use platform-defined poll intervals and lookbacks, but representative numbers are not documented here to the same level of precision as Graph for this page. Behavior is still scheduled polling: each pass lists content blobs using startTime or endTime tied to blob availability (see Microsoft's List available content), then downloads each contentUri, so the cadence governs how often those listing windows advance, not the CreationTime inside each event.

Integration Typical cadence Notes
Microsoft 365 Management commercial, GCC, GCC High, Identity XDR (Management path) Frequent listing passes (often about one minute apart) startTime or endTime apply to blob availability, not to each event's CreationTime. Lookbacks re-cover prior windows so late-published blobs are still picked up. Tuned for Microsoft throttling and tenant size.
Microsoft 365 Management legacy Less frequent than customer-app commercial Older collector layout and onboarding model; superseded by customer Entra app integrations for new tenants.

Azure Monitor REST API (polling)

The polling integration calls the Azure Monitor Activity Logs - List API per linked subscription. Each run requests events in a time window filtered on eventTimestamp (Microsoft may expose additional filter parameters). Collectors also re-query earlier windows (for example, several hours in the past) because Microsoft can publish or correct Activity Log rows after the fact, similar to lookbacks used for Graph and Microsoft 365 Management.

Authentication uses delegated permissions and operates on behalf of a configured user. See Microsoft Azure Activity Logs.

Integrations, API Filter Field, and Event Time Mapping

Integration API (list) Time field (drives polling) Typical source of event time
Azure Activity Log — Monitor REST (polling) Activity Logs - List (.../providers/microsoft.insights/eventtypes/management/values) eventTimestamp (query window bounds) eventTimestamp, or time if eventTimestamp is missing

Microsoft Graph activity logs are normally enabled through diagnostic export to Event Hub (or another sink), not through this List API path; when present in the exported stream, event time still maps from eventTimestamp or time as above.

Typical poll intervals

These values are typical for the REST Activity Log integration. Deployed timings can differ by environment.

Integration Typical interval (minutes) Notes
Azure Activity Log — Monitor REST (polling) 5 Multiple parallel streams, each running on a 5-minute cadence with different lag lookbacks behind "now" when querying eventTimestamp (for example, 5, 10, 15, 20, 25, 30, 60, 90, 120, and 240 minutes). Max lookback per stream is sized so late-published or corrected rows are still captured, subject to Microsoft rate limits.

Azure Activity and Microsoft Graph Activity Logs (non-polling integrations)

Sophos XDR can ingest Azure Activity (subscription-level Azure control-plane audit) and Microsoft Graph activity (Graph API request audit for the tenant) through diagnostic export (Event Hubs, Storage Account, or similar). Azure Activity Log can instead be collected via REST polling.

See Azure Monitor REST API (polling) fortiming and API fields for that path.

See Microsoft Azure Activity Logs for export and polling descriptions.

Diagnostic export (Event Hubs, Storage Account, etc.)

With Azure Monitor diagnostic settings, you send selected categories to an Azure Event Hub, Storage Account, or other supported sink. Sophos XDR consumes those streams or files; there is no fixed poll interval from our side—cadence and batching follow Azure and your diagnostic configuration.

Event time is taken from vendor fields such as eventTimestamp or time in the payload (exact names depend on category and format). Microsoft Graph activity log records use the same general pattern when exported through Monitor (top-level time and related properties).

Platform delay after collection

Keep the following in mind after the API returns data:

  • Handoff between components is usually under a minute but can take longer under load.
  • Batched writes and indexing can add tens of minutes before events are searchable. Detectors may run before search is available.

These effects widen ingest time vs. vendor timestamps even when polling is healthy.

Content integrity

Query parameters are used only to retrieve data; they do not rewrite vendor JSON. Raw content is preserved (for example, in original_data). If vendor JSON is malformed (invalid structure or syntax) or too sparse (for example, missing fields or values you need for investigation), raise that with Microsoft, since Sophos XDR does not control how Microsoft builds the payload.

Additional resources

Microsoft 365 Management Activity API (blobs, listing, retrieval, delay)

Other