Microsoft 365 Roadmap item 568784 lists the feature as general availability for September 2026 across worldwide commercial tenants, GCC, GCC High, and DoD. A Microsoft Learn article on investigating identities already documents the revised Timeline tab in detail, including its data sources, new fields, and event-detail experience. That creates an unusual status mismatch: the roadmap still labels the item In development even though Microsoft’s product documentation describes the functionality as available. Administrators should treat September as a staged rollout window, rather than assume every tenant received it on September 1.
Modern Workspace Pro, reproducing Microsoft 365 Message Center post MC1461705, reports that deployment began in mid-September and is expected to finish by mid-October 2026. Microsoft has not publicly provided a tenant-by-tenant availability checker or a precise order for commercial, government, and sovereign-cloud rollout.
One identity, rather than one account at a time
The revised Timeline tab appears on an identity’s page in the Microsoft Defender portal. Microsoft’s premise is that a human identity can span multiple accounts and providers: an on-premises Active Directory account, a Microsoft Entra ID account, SaaS accounts, and other connected identity sources. The timeline is designed to correlate events where the person is either the actor or the target, across those linked accounts.
This matters most in hybrid environments, where an investigation can otherwise start with a suspicious cloud sign-in, move to a device logon record, then require a separate search for a directory change or SaaS action. Microsoft says the timeline brings together activity from Defender for Identity, Defender for Endpoint, Defender for Cloud Apps, and Microsoft Sentinel, alongside Entra sign-ins and Microsoft Graph audit activity.
The documented source tables make the integration more concrete. The unified view normalizes records from AlertInfo, IdentityLogonEvents, IdentityQueryEvents, IdentityDirectoryEvents, CloudAppEvents, DeviceLogonEvents, EntraIdSignInEvents, and GraphApiAuditEvents. That is a wider investigative surface than Defender for Identity’s traditional focus on Active Directory telemetry.
Microsoft also says it removes duplicates. When the same sign-in is present in both Entra ID and cloud-app data, for example, the timeline favors the Entra ID record. That should reduce noisy timelines, but it has a practical consequence for analysts: the event retained in the interface may not be the record they expected from a connected product. The new Source table field is therefore more than a cosmetic addition; it is how an analyst can establish which data set produced the displayed event before pivoting into advanced hunting.
Session and token fields improve pivots, not visibility by default
The new timeline schema adds Session ID and Unique token identifier fields, plus Target and Additional information. Microsoft’s documentation says those columns are available through column customization but are not shown or filterable by default. Teams that want to use them must deliberately add the fields to their investigation views and adjust their runbooks accordingly.
For Entra sign-ins, Session ID is a session-level value and UniqueTokenId identifies the token associated with the sign-in. In practice, those identifiers can help an analyst connect a suspicious authentication event to related token activity, a Graph audit action, or a session that appears across multiple entries. The benefit is strongest during investigations of token theft, replay, consent abuse, or unusual activity that follows an apparently legitimate authentication.
They are not magic correlation keys. A normalized timeline field can only be populated when its original source record contains the value. Microsoft explicitly notes that columns remain empty for events whose source table did not provide them. A device logon event, an on-premises directory lookup, and a SaaS activity record will not necessarily contain a shared session or token value even when they belong to the same incident.
That limitation is important because the feature’s unified presentation could encourage overconfidence. The Timeline tab reduces context switching; it does not establish causation between every record it places near another one. Analysts still need to validate timestamps, IP addresses, devices, user agents, account mappings, and the underlying source records.
Conditional Access moves into the investigation path
Microsoft is also expanding Conditional Access context for Entra sign-in events. The timeline shows applied Conditional Access policy information inline, while selecting a relevant Entra sign-in opens an event-details pane with a Conditional Access tab. That tab can show each evaluated policy, its grant controls, and its result, such as success, not applied, or blocked.
For incident response, this closes a common gap. A risky sign-in is far easier to interpret if the analyst can see whether MFA was required, whether a compliant-device policy applied, whether a location rule was bypassed or not applicable, and whether access was actually blocked. Previously, a responder might have to leave the identity investigation page and validate that policy outcome in Entra sign-in reporting.
The feature does not replace Entra reporting or policy administration. Microsoft’s own EntraIdSignInEvents schema shows that the underlying data remains licensing-dependent: customers need Microsoft Entra ID P2 to collect and view activity in that advanced-hunting table. Organizations without the appropriate data source and entitlement should not expect the unified timeline to create missing sign-in telemetry.
The same principle applies across the wider timeline. Connected Defender products, Sentinel workspaces, cloud-app connectors, and available telemetry determine what the analyst can see. The interface is a consolidation layer, not a substitute for deploying or licensing the contributing services.
SaaS correlation has a documented boundary
The strongest promise in Microsoft’s announcement is a cross-environment identity view that reaches beyond Windows and Active Directory into SaaS and cloud services. Microsoft’s Identity inventory documentation confirms that enabling the Defender for Cloud Apps Identity inventory integration brings SaaS and cloud application accounts into the Identity inventory and unlocks unified experiences including the identity timeline.
But Microsoft also documents a boundary that should temper expectations. Identity correlations created in the unified inventory, including manual and policy-based links between accounts, do not currently flow into several Defender for Cloud Apps functions. Built-in detections, UEBA, scoped deployment, governance actions, Defender for Cloud Apps policies, the activity log, cloud discovery enrichment, and RBAC scoping continue to rely on the separate Cloud Application Accounts inventory.
In plain terms, a manually linked SaaS account may improve the context visible to an investigator on the Identity page, while still not changing how Defender for Cloud Apps detects behavior, scopes a policy, or applies governance action. Security teams should avoid writing procedures that assume an account correlation established for investigation automatically changes enforcement elsewhere in the Defender stack.
This is the material caveat missing from the short roadmap description. Microsoft is unifying the investigation experience faster than it is unifying every downstream identity-data pipeline.
What SOC teams should check during rollout
No migration or client deployment is indicated. The change is web-based and targets security administrators, incident responders, and SOC analysts using the Defender portal. The immediate task is operational preparation, not endpoint management.
- Confirm that analysts can open the Identity page from the identity inventory, alerts, incidents, devices, advanced-hunting results, and other Defender investigation surfaces.
- Add Source table, Session ID, Unique token identifier, Target, and Additional information to the Timeline tab where those fields support existing incident workflows.
- Test an Entra sign-in that has Conditional Access results and verify that the details pane exposes the policy evaluation expected by the team.
- Review whether Defender for Cloud Apps identity inventory integration is enabled before promising SaaS-account coverage to responders.
- Update hunting and response notes to distinguish a correlated identity timeline from the underlying product record, especially where duplicate event handling favors Entra data.
Microsoft’s Learn documentation also says the Defender portal can display timeline timestamps in either the selected local time zone or UTC. For distributed SOCs, that setting deserves attention before comparing the timeline with Sentinel queries, Entra logs, firewall telemetry, or third-party incident records. A correlation workflow is only as reliable as its time normalization.
The rollout’s concrete consequence is that Defender analysts should increasingly be able to start with a person, rather than an isolated alert or account, and follow the evidence across identity, endpoint, cloud, and SaaS records. The remaining work for administrators is to verify that their connected products, licensing, identity correlations, and investigation procedures actually supply the context the new timeline is built to display.