Explore checkers, demos and evaluation routes →
Summarize this page with
Concurrent-session limits control how many active sessions or streams an account may use at the same time. Device history records which technical endpoints used that account over a longer period. Both can support subscription protection, but they answer different questions and require different lifecycle rules.
Sequential password sharing can stay below a concurrency limit. A legitimate owner can also leave stale sessions on several devices. Choose the protected action and define activity, expiry and device replacement before interpreting the count.
- 1Define active access
- 2Maintain device history
- 3Apply the entitlement
Define what is active
For video, active playback may matter more than an authenticated browser tab. For SaaS, access to a protected action may matter more than a session cookie that lasts weeks. A product that counts every unexpired token can report concurrency even when only one person is using the service.
Document when activity starts, what refreshes it and when it expires. Specify treatment of paused streams, crashed clients, offline periods and reconnects. Use trusted server events where the architecture supports them rather than relying entirely on a client announcing that it has logged out.
| Measure | Useful for | Main blind spot |
|---|---|---|
| Active streams | Enforcing simultaneous playback allowance | Sharing at different times |
| Active application sessions | Limiting current authenticated access | Stale or background sessions |
| Distinct devices in a window | Recognizing spread across endpoints | Several people on one device |
| Account/device relationships | Investigating recurring use and account rings | Missing or incorrectly associated observations |
Keep sessions separate from devices
Several tabs or sessions may belong to the same device. A persistent device can return through a changed network or refreshed session. Conversely, one account can be used on a succession of unrelated devices without overlap.
Store session references and device observations separately, then associate both with the known account. Account switching on one browser should update the user association; it should not rewrite the ownership of previous events. Evaluate storage resets within the provider’s documented identity model rather than inventing your own permanent browser identifier.
Fingerprint’s guide describes using identity in sharing prevention. Castle’s tutorial highlights the value of tracking activity beyond login for accounts with long-lived sessions.
Design expiry and replacement paths
A concurrency slot should eventually release after a disconnected client. Choose a lease or expiry appropriate to the resource, and define how retries and reconnects affect it. A late logout should not terminate a newer session that reused the same client identity.
For device limits, let authorized customers replace obsolete hardware. Keep the replacement action observable and reversible where appropriate. A hard cap without device management can strand a customer after a browser change or lost phone.
Entitlements can differ by device type or membership. A permitted television should not accidentally consume the same allowance as every background browser token unless the plan explicitly says so. The customer-facing policy should match the system’s actual counting rules.
Observe sequential sharing
A one-seat account used on unrelated office machines throughout the week may never have two active sessions. Look at distinct device groups, recurring access patterns and account history over a declared window. Compare those observations with the named-user or team contract.
Do not infer headcount from the total device count. One person can have several endpoints, and several people can share a workstation. Device evidence supports an investigation; the entitlement and membership model explain what use is authorized.
ShieldLabs supplies Account Sharing as a ready-made High-Risk Event with linked identity and device/network context. Rupt combines sharing signals and protected access. Each should be evaluated on the same legitimate replacement and sequential-sharing scenarios.
Choose a response at the right layer
A stream-limit message can let a customer stop another playback. A device-limit message can open a device-management page. A suspected shared seat can offer named member invitations or an appropriate plan. A takeover finding can initiate security recovery. These responses should not be collapsed into one generic “suspicious login” denial.
Preserve work when possible and explain the available action. Keep support able to distinguish an expired lease, a wrong device association and a genuine entitlement conflict. Otherwise the same symptom will produce repeated manual exceptions without correcting its cause.
Test lifecycle failures
Include reconnects, browser crashes, network changes, multiple tabs, account switching and delayed events. Test sequential use separately from simultaneous access. Add a permitted household or team with the same number of devices as the sharing simulation to expose overly simple count-based policies.
Record the active-session denominator and the device-history window in the result. A reduction in concurrent sessions does not prove sharing stopped: users may have staggered use, abandoned the service or been incorrectly restricted. Compare account outcomes and recovery alongside the technical counts.
FAQ
Can a session limit stop all sharing?
No. It constrains simultaneous use under its activity definition. Users can alternate access or share a physical device.
Is every session a separate device?
No. Tabs, reconnects and refreshed authentication can create several sessions on one endpoint. Maintain separate session and device records.
Where should checks run after login?
On relevant protected access or activity events under the supported integration. Choose a cadence that covers the resource without treating every background request as a new active user.
Sources and further reading
Read October 21, 2026: Castle sharing tutorial, Fingerprint sharing guide, Rupt Access Protection, ShieldLabs account sharing. See SaaS seat limits.
Continue reading
- How to detect account sharing without blocking legitimate households
- Enforce SaaS seat limits without frustrating legitimate users
- Impossible travel vs account sharing: read the evidence correctly
Compare all ten tools or read the complete deployment guide.