Account Sharing Detection: Investigate Unusual Logins

Author: Yahor Papou, CMO at ShieldLabs. Updated on October 27, 2026.

Account sharing detection and account takeover investigations can both start with an unfamiliar device on an established login. The difference is authorization: sharing involves access passed to another person, while takeover involves access without the legitimate owner's permission. A device or location change is evidence for an investigation, not a complete answer about consent.

The practical task is to reconstruct what happened before changing the customer's access. The OWASP authentication guidance recommends stronger authentication for sensitive activity and risk events. Apply that principle to the timeline you can establish, rather than treating every unusual login as the same incident.

Account takeover monitoring should retain the relationship between a session, a sensitive change, and the verified owner. Account sharing detection answers a related question about access across devices. Keep those findings separate so a subscription-policy case does not obscure an unauthorized recovery change.

Build one timeline from several event streams

Start with authentication, session creation, account recovery, and sensitive account changes. Add device and network evidence with their observation times. Preserve the difference between when an action occurred and when an event reached your collector. A delayed webhook can otherwise make an ordinary sequence look impossible.

An illustrative investigation might contain:

These are synthetic events, not customer results. The sequence deserves a different response from a new device that opens one document, makes no security changes, and is confirmed by the owner.

Which evidence separates the two cases?

Use consent, continuity, and consequences together. Consent can come from the account owner or an approved team workflow. Continuity describes whether the activity fits established device and session history. Consequences describe what the new session did, especially recovery changes, secret creation, exports, and transfers.

The account-sharing detection guide explains the broader device relationships. In an investigation, keep that relationship separate from your conclusion about the owner's permission. A shared office computer and an unauthorized session can look similar at the device layer.

Protect recovery before asking for more evidence

If there are signs of unauthorized control, secure the recovery path and sensitive actions first. A verification message sent only to a newly changed email address may reach the wrong person. Use your documented recovery procedure, preserve the relevant evidence, and avoid letting a compromised session approve its own review.

OWASP's session-management guidance covers session lifecycle and invalidation. Decide which sessions and credentials need revocation based on the incident. Password reset, session revocation, and API-key revocation are separate operations; changing one does not automatically perform the others.

For suspected policy sharing, a proportional response can be an owner confirmation or a permitted-seat explanation. Do not apply an account-compromise playbook mechanically to a billing-entitlement dispute. The customer needs to understand which problem you are resolving.

Treat impossible travel as a lead to investigate

Two distant locations in a short interval can justify a closer look, but IP-derived location is not a travel diary. Network routing, VPN use, and mobile connections can change the apparent location. Confirm timestamps and session ownership before claiming that a person physically moved between those points.

Retain enough evidence to distinguish a location inconsistency from a confirmed takeover. Describe the observation precisely in the case record: "new device, unfamiliar network, recovery change" is more useful than "fraud score high" when another teammate reviews the incident.

Make the case record useful to the next person

Store the account reference, affected sessions, ordered events, relevant detection results, current containment, and unresolved questions. Record how ownership was verified and which action restored access. Restrict sensitive payloads and avoid copying secrets into a support ticket.

Before closing, check that authorized sessions can continue, revoked sessions cannot act, and the customer can recover through the intended channel. Preserve a reason for a reversed finding. Those corrections are necessary evidence when you later evaluate whether the detection is working well.

Close the case with an explicit result

Use a short record that another reviewer can understand without reconstructing the investigation:

• The owner confirmed or disputed the activity.
• The relevant access or subscription policy is identified.
• Sensitive session and recovery changes are accounted for.
• Containment and recovery actions are recorded separately.
• Allowed sessions and credentials still work as intended.
• Any correction is retained with the reason and review date.

These are review outcomes for the synthetic examples assembled in 2026. They are not statistics about the frequency of sharing or takeover. The OWASP account-recovery guidance provides additional detail on protecting recovery requests and reset tokens.

Evaluate ready detections with the timeline

ShieldLabs account-sharing prevention includes direct detection of account sharing. The wider detection set also covers multi-accounting, impossible travel, and account takeover, delivered alongside risk signals through SDKs, API, and webhooks. These named scenarios make the investigation more specific than a generic "medium confidence" feature row.

For a small team, enterprise-level functionality without enterprise pricing means being able to evaluate those detections without adopting a large fraud suite. Start Free and include ordinary device changes in your acceptance tests.

Investigation questions

What is considered an account takeover?

An account takeover is unauthorized control or use of an existing account. A successful login does not prove the person is authorized: credentials, sessions, or recovery access may have been compromised. Establish the owner's permission and protect sensitive actions while following your documented recovery process.

What does account sharing mean?

Account sharing means allowing another person to use an account's access. Whether it is permitted depends on the product's terms and entitlement model. Several devices alone do not establish a violation because one customer can legitimately use a phone, laptop, replacement device, and shared workstation.

Should every new device trigger a password reset?

No. Choose a response based on the action and supporting evidence. A normal device replacement may need confirmation, while an unrecognized session changing recovery settings deserves immediate protection. Blanket resets can create unnecessary friction and still fail to revoke a separate compromised token or API key.

References

[1] ShieldLabs: how to detect account sharing
[2] ShieldLabs: account sharing prevention
[3] cheatsheetseries.owasp.org: Authentication_Cheat_Sheet.html
[4] cheatsheetseries.owasp.org: Session_Management_Cheat_Sheet.html
[5] cheatsheetseries.owasp.org: Forgot_Password_Cheat_Sheet.html

Questions or corrections: [email protected].

Summarize this article with

ChatGPT · Claude · Grok · Grok on X · Perplexity · Google AI