Home / Knowledge hub / Concurrent sessions
Knowledge hub
Concurrent sessions
One account signed in on several devices at once, and how many you allow.
What it means
Concurrent sessions are two or more active sign-ins for the same account at the same time: a phone, a laptop and a work browser. Each has its own session id or token. Whether that is allowed, limited or blocked is a design decision, not a default that is always right.
The question is not only how many. It is also whether the owner can see them, end them and be told when a new one appears. Without that, session hijacking can run unnoticed alongside the real user for a long time.
Why it matters
Sessions you cannot see are sessions you cannot end. If an attacker has a stolen cookie, a second session from another country looks identical to the real one unless your app shows it. Many account takeovers continue for weeks because the owner has no list to check.
Some businesses have a commercial reason to limit them, such as licences or shared accounts. Others have a compliance reason, because certain rules expect a user to control or restrict their own sessions. Either way it should be a chosen setting.
How it shows up
You meet it in account settings pages that list devices with a sign-out button, in admin consoles that cap simultaneous logins, and in alerts like "new sign-in from a device you do not use". The server needs a session store it can query by user.
The mistakes repeat. No list at all. A list that shows sessions but cannot end them. A password change that leaves other sessions alive. Limits enforced in the browser only. Check that ending a session in the list really kills it, and that it is tied to the right user. See also session management.
Questions people ask
Concurrent sessions, answered
Should we allow concurrent sessions?
For most consumer and business apps, yes, because people use several devices. Restrict them where licences, regulation or very high risk call for it.
Whatever you pick, give users a way to see and end their own sessions.
What happens when the limit is reached?
Either the new sign-in is refused, or the oldest session is ended. Ending the oldest is friendlier, while refusing is stricter.
Tell the user which happened and why.
Do concurrent session limits stop account sharing?
They make it inconvenient, not impossible. Sharers can take turns, and legitimate users hit the limit on a bad day.
Use them for control, not as proof of abuse.
How do we spot a stolen session?
Show device, location and last-used time for each, and alert on a new device. Log sign-ins in the audit log.
Binding to a device helps but is not perfect.
How would a pentest test this?
It checks whether sessions can be listed and ended, whether one account can see or end another's sessions, and whether a password change ends the rest.
The cross-account check is the one that matters most.
Sources
Where this comes from
Related
Terms that sit next to this one
Session management
How your app creates, tracks, renews and ends a signed-in visit.
Session hijacking
Stealing the token that tells your application a browser is logged in.
Device binding
Tying a session or token to one device so a copy elsewhere is refused.
Logout invalidation
Making sure signing out really kills the session on the server, not just in the browser.
Account takeover
An attacker ends up signed in as one of your real users.
Can one account see another's sessions?
Session lists, kill buttons and password changes that leave old sessions alive are checked on the running app, including one account reaching another's data. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.