Who was actually using the account?¶

Start with the specific event you care about and work outwards.

The registered holder may narrow the possibilities. The account controller may narrow them further. But the person who actually sent a message, approved a payment or changed a setting is an event-specific question.

Fix the event first¶

Suppose the provider records:

That gives you a precise place to start.

Now ask:

• which session produced the event;
• which device or application held that session;
• whether the account was already signed in;
• whether the activity could have come from a linked or remote client; and
• who controlled the relevant device at 14:01.

The nearest login may not be the answer¶

A session can remain active for days or weeks.

So an event at 14:01 may have been performed through a session created much earlier.

Do not assume the most recent password login identifies the person who performed the later action.

What does a successful login actually prove? and session cookies explain why.

Bring in independent context¶

Useful evidence may include:

• possession of the device;
• local app or browser artefacts;
• other accounts active on the same device;
• CCTV;
• building access;
• work records;
• location evidence;
• messages arranging the action;
• financial activity; and
• knowledge shown in the content.

Several independent sources agreeing can make the attribution very strong.

Test realistic alternatives¶

If the account was shared, check who else had access.

If the session could have come from a linked desktop, check that.

If compromise is plausible, look for the security and recovery evidence.

Do not invent remote theoretical possibilities just to weaken the finding. Test alternatives that genuinely fit the evidence.

The practical point is: attribute the event, not the account in general. Follow the activity through its session and device, then use independent evidence to identify the person at the relevant time.