When a SCADA vendor licenses client access, they almost always do it one of two ways: by counting how many clients are connected at the same time, or by naming the individual people allowed to connect at all. The choice sounds like an accounting detail, but it decides how much you pay for a shift-based operation, how web viewers are handled, and whether an extra operator can log in during a busy period. This guide contrasts concurrent, session-pool licensing against named-user, per-seat licensing: how each is counted and enforced, what each costs for different usage patterns, and which model fits a control room versus an occasional browser viewer.
Concurrent vs named-user licensing in one line: Concurrent licensing grants a pool of client sessions and counts how many are in use at any one moment, so any user can connect as long as a session is free. Named-user licensing instead assigns a license to each specific person or seat, so only the named individuals may connect regardless of how many are online at once. Concurrent suits shift-based teams who share access, while named-user suits a fixed set of dedicated operators, and the cheaper model depends entirely on the usage pattern.
Concurrent licensing, sometimes called floating licensing for clients, works from a pool of sessions. If a site owns a certain number of concurrent client licenses, that many clients may be connected at the same time, and it does not matter who they are - the license is checked out when a client connects and returned when it disconnects. Enforcement is about the count in use: when the pool is exhausted, the next connection attempt is refused or queued until someone else logs off. Nobody is tied to a particular license; the licenses float to whoever needs one at the moment.
Named-user licensing works from a list of people or seats rather than a count of sessions. Each license is assigned to a specific named individual, and only those named users may connect, so enforcement checks identity rather than headcount. Whether ten named users are all online or none are, the entitlement is the same fixed set of people. This model ties the right to connect to who you are, not to whether a slot happens to be free, which makes access predictable for that named set but offers no flexibility to bring in someone outside it.
The practical difference shows up at the moment of connection. Under concurrent licensing, a user can be turned away not because they lack permission but because the pool is momentarily full, and access frees up as others disconnect. Under named-user licensing, a user either is on the list and can always connect, or is not on the list and never can, with no notion of the pool being full. Understanding which of these enforcement styles a product uses is essential before predicting how it will behave when many people want in at once.
The economics of the two models flip depending on how people actually use the system. Consider a control room staffed around the clock by rotating shifts, where a fixed number of operator stations are manned at any given time but the total roster of operators across all shifts is much larger. Concurrent licensing shines here, because you license for the number of simultaneous seats rather than for every operator on the roster - three stations manned at once needs three concurrent licenses even if fifteen different people cover them across the week. Named-user licensing would force you to license all fifteen, most of whom are never online at the same time, which is far more expensive for the same real usage.
The picture inverts when a small, fixed set of people each need guaranteed, individual access. If ten specific engineers each require reliable connectivity and they may all be online together, ten named-user licenses give each of them a dedicated seat that can never be blocked by a full pool, and there is no larger roster inflating the count. Named-user also simplifies attribution, since every session maps to a known individual, which can matter for accountability. Where the population of potential users is not much larger than the number online at once, named-user is straightforward and may be no more costly than concurrent.
The general rule is that concurrent licensing rewards a large user base with low simultaneity - many people, few at a time - while named-user licensing rewards a small, stable base where nearly everyone might be online together. Estimating the real peak of simultaneous sessions against the total headcount is the calculation that decides which is cheaper, and getting it wrong in either direction means paying for access nobody is using or being unable to bring people online when they need to be.
Control rooms are a natural fit for concurrent licensing. A manned control room has a known, modest number of stations active at once, backed by a much larger pool of operators who cover them across shifts, holidays, and relief. Licensing for the simultaneous seats rather than the whole roster matches what is actually happening and keeps costs proportional to real usage. It also handles the reality that operations bring in extra hands during upsets or turnarounds: as long as the concurrent pool has headroom, an additional operator can log in without provisioning a new named seat first.
Occasional web viewers - a manager glancing at a dashboard, a maintenance planner checking a status a few times a week, a wide audience who each connect rarely - stress the two models very differently. Named-user licensing for a large, sporadic viewer population is expensive and wasteful, because you pay for every named person even though only a handful are ever online. Concurrent licensing suits this pattern well, since a small pool of sessions can serve a large audience precisely because their access is intermittent and rarely overlaps. Many web-viewer offerings therefore lean toward concurrent or session-based counting for exactly this reason.
Cloud SCADA reshapes how these models play out in practice. A platform such as Merobix, serving screens to browsers across a distributed oil and gas operation, faces exactly the mix these models address - a core of steady operators plus a broad, intermittent audience of viewers spread across sites. Handling access as pooled sessions rather than a per-person seat for everyone who might ever look keeps a widely-viewed system affordable, because the licensing tracks concurrent use rather than the total number of people with an interest. For a field operation where many stakeholders occasionally check on remote assets, the concurrent, session-based approach aligns cost with how the system is really used.
It depends entirely on the ratio between how many people could use the system and how many are actually online at once. Concurrent is cheaper when a large user base connects with low simultaneity, like shift-based operators sharing a few stations or occasional web viewers. Named-user can be competitive when a small, fixed group each need guaranteed access and might all be online together. Estimating the peak of simultaneous sessions against total headcount is the calculation that decides it.
When every concurrent license is checked out, the next connection attempt is refused or queued until an existing user disconnects and returns a session to the pool. This means a user with full permission can still be temporarily blocked simply because the pool is momentarily at capacity. Sizing the pool with enough headroom for busy periods, such as upsets or shift overlaps, avoids operators being locked out exactly when extra hands are needed.
Because web viewers are typically a large, intermittent audience where only a small fraction are ever online at once. Named-user licensing would charge for every person who might ever look, most of whom rarely connect, which is wasteful. Concurrent licensing lets a small pool of sessions serve a broad audience precisely because their access rarely overlaps, so cost tracks actual simultaneous use rather than the total number of people with access.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.