Can a cloud account be accessed from several devices?¶
Yes. The same account may be active in a browser, phone application and desktop synchronisation client at the same time. Those routes can all reach the same files while producing different kinds of activity.
One file, three very different events¶
Dave opens a spreadsheet in OneDrive through Edge on his laptop. His Android phone still has the OneDrive app signed in. The Windows OneDrive sync client is also watching the local folder.
Dave experiences this as “my OneDrive”. The service has three technical routes to distinguish:
The event name and client context can change the interpretation. A cloud upload may be a deliberate browser action or the consequence of a local file being synchronised.
Start with the event that matters¶
If the issue is a file appearing in cloud storage at 21:31, do not begin by asking which device is “the cloud device”. Ask which route could have produced that event.
Compare:
- the provider's operation or event name;
- the account or actor identifier;
- the application, client or user-agent information;
- any device identifier;
- the IP address and recorded time;
- the local file and sync history on candidate devices; and
- interactive activity around the same time.
Microsoft currently documents FileSyncUploadedFull as an upload of a new or changed file to SharePoint or OneDrive using the OneDrive sync app. That does not mean the event is useless. It changes the next question from “Who clicked Upload?” to “Which synchronised computer changed or acquired the local file?”
Google Drive can describe familiar actions differently
Google Workspace's Drive log documentation gives several useful examples:
- files copied between Drive and a local device using Drive for desktop can produce Download and Item content synced events;
- previewing a file in the Drive mobile app can be logged as a Download event;
- an Item content prefetched event means a Google application retrieved content so it would be available if needed - it does not mean the nearby file was necessarily shown to the user; and
- App ID, App name, User device ID and IP address are available for relevant events, but not every attribute is reported for every event.
This is why event names must be interpreted using the provider's definitions. Ordinary words such as “download” can cover behaviour that is not identical to a person deliberately saving a file.
A session is the continuing route, not the whole conversation
After sign-in, a browser or application can continue making authorised requests without asking for the password every time. A cloud session helps the service keep that continuing activity separate from another browser or application using the same account.
An access token is one mechanism an application may use to prove that it has authority for a request. Session and token behaviour varies by provider. Do not infer that changing a password necessarily ended every existing route unless the provider's records or documentation establish that outcome.
Join provider and device evidence¶
Suppose Microsoft records FileSyncUploadedFull for Dave's account. On Dave's laptop, the file appears in the local OneDrive folder and the sync database records activity at the corresponding time. That combination supports the proposition that this installation synchronised the file.
It still does not automatically show that Dave personally made the underlying change. The laptop may be shared, the file may have arrived from another program, or the synchronisation may have happened after an earlier edit. Browser history, application activity, file metadata and access opportunity may supply the remaining bridge.
The point to remember
“The account used several devices” is only the starting point. Identify the exact cloud event, work out which client could produce it, and compare that route with the corresponding evidence on the device.
