What evidence might identify the session that changed a file?¶

The strongest route is a stable identifier connecting the file event to session, authentication and client records. Where no session ID is retained, a careful correlation of account, time, application, device and network fields may narrow the route.

Start with the object event¶

Preserve the object and version IDs, exact timestamp and time zone, event or request ID, recorded account, application and action. Correlation or request IDs can join records across provider logging systems more reliably than approximate timing.

The session may have been created long before the change. A remembered browser, refresh token or sync client can act without a fresh login immediately beforehand.

Follow the relationship across logs¶

Authentication records may show session creation and MFA. Session or token records may show lifecycle and client details. File audit logs show the object action. Device evidence may contain the same client ID, local path or sync event.

Example join: file event EVT-9041 → session SES-41C2 → client DEV-A7 → sign-in AUTH-1882.

If the provider exposes only an IP address and browser string, state the weaker correlation and test other sessions that share those features.

For example, OneDrive file event EVT-9041 records object OBJ-4407, version V-19, session SES-41C2 and client OD-77 at 14:22. Entra sign-in AUTH-1882 created that session on Surface DEV-A7 at 13:58. The stable session relationship is stronger than matching time and IP alone, but it still attributes a technical route rather than a person.

Session is not person¶

An identified session can be shared, stolen or active on a compromised device. Personal attribution requires evidence of who controlled that device or client and whether an application performed the event.

The next useful comparison is SES-41C2 across token lifecycle, authentication, device registration, OneDrive client logs and local application activity, including other sessions sharing the account or network.