Concurrency

Concurrency is the same user accessing your service from multiple device-and-IP combinations at the same instant. It's one of the strongest account sharing signals Rupt has: even careful sharers slip up and use the account from two places at once.

How Rupt detects it

When an evaluation runs, Rupt checks for any other in-flight session for the same user that:

• Is on a different IP, AND
• Is on the same device type (mobile, tablet, computer), AND
• Is currently active.

Active session presence is tracked in real time, so the detection window matches the user's actual session, not a coarse time bucket. If a second login lands while the first is still live, concurrent_sessions flips to true on the evaluation and you'll see it surface in the account sharing risk score.

Using it in policies

concurrent_sessions is exposed directly as a check, so you can write a policy condition over it:

If event_type = access AND concurrent_sessions = true → challenge.

The built-in account_sharing risk already weights concurrent_sessions heavily, so it shows up in the risk score recorded on the evaluation. To act on it in a policy today, match the concurrent_sessions check directly, which also gives you surgical control: always blocking concurrent sessions on premium tiers but ignoring them on free ones, for example.

Pairs well with

• Impossible travel: physical impossibility plus simultaneous access is near-conclusive sharing.
• High device counts: if the account has accumulated many devices over time and shows live concurrency, the case is stronger.