In many SCADA products the software will not run - or will not run fully - unless it can reach something that tells it it is allowed to. That something is the license server: the component that holds the site's entitlements and hands them out to runtimes and clients as they start up. Understanding it matters because when it is unavailable, parts of a live control system can stop working, which is not a risk a 24/7 plant can ignore. This guide explains how the license-server model works, the difference between a hardware dongle and soft activation, what happens during a grace period or outage, and why redundancy is not optional.
SCADA license server in one line: A SCADA license server is a networked service that holds a site's software entitlements and issues them to SCADA runtimes and clients at runtime, typically as floating licenses that are checked out when a component starts and returned when it stops. It enforces how many instances or seats may run at once, and because a live control system can depend on it to keep operating, it is often deployed redundantly so a single failure does not take licensed functions offline.
The license-server model separates the right to run software from the machine that runs it. Instead of each computer holding its own permanently installed license, a central server holds a pool of entitlements, and when a runtime or client starts it contacts that server and checks out the license it needs. While the license is checked out it is unavailable to others; when the component shuts down cleanly it returns the license to the pool for someone else. This is what makes floating, or networked, licensing possible: a site with more installed clients than licenses can still operate as long as no more than the licensed number are running at the same time.
Checkout is a live, ongoing relationship, not a one-time check. Many implementations require the client to periodically renew or heartbeat its checkout so the server knows the license is still in use, and if a client vanishes without returning its license the server can reclaim it after a timeout so the seat is not lost forever. The server tracks what is checked out, by whom, and against which entitlement, which is also what allows administrators to see how licenses are actually being consumed across the site.
Because the runtime depends on reaching the server, the network path between them becomes part of the control system's dependency graph. A firewall rule, a routing change, or a name-resolution problem that blocks the client from reaching the license server can prevent software from starting or continuing, even though nothing is wrong with the SCADA software itself. This coupling is the price of the flexibility floating licensing provides, and it is the main reason license-server placement and reachability get engineered as carefully as the SCADA servers they serve.
The entitlement a license server holds has to be anchored to something so it cannot be freely copied, and there are two common approaches. A hardware dongle - a USB or similar device - physically carries the license, so the entitlement is present only where the dongle is plugged in; moving the license means moving the dongle. Soft activation instead binds the entitlement to characteristics of the machine or to an online activation record, so no physical device is involved but the software validates against that binding. Dongles are simple and offline-friendly but can be lost or damaged, while soft activation avoids the physical device at the cost of tying the license to a host that must be handled carefully during hardware changes.
What happens when the license server is unreachable depends on the product, but the concept common across many is the grace period: a defined window during which checked-out clients keep running even though they cannot reach the server, giving operations time to fix the problem before anything stops. A short network blip is usually absorbed without effect. A longer outage that exhausts the grace period is where the risk bites, because licensed functions can begin to shut down or drop to a degraded mode, and on a live plant that can mean losing screens, historian collection, or entire runtimes at the worst possible moment.
This failure behaviour is exactly why the license server cannot be treated as a low-stakes utility. The point of a grace period is to buy time, not to make outages harmless, so a site still needs the server to come back before the window closes. Knowing precisely how a given product behaves on license-server loss - which functions keep running, for how long, and what degrades first - is essential input to how the license infrastructure is designed and how urgently an outage must be treated.
For a plant that runs continuously, a single non-redundant license server is a single point of failure sitting quietly behind the whole control system. It may be a small, unglamorous service, but if it goes down and the grace period expires, licensed SCADA functions start to fail even though every SCADA server and network path is healthy. That is an unacceptable exposure for a system whose entire purpose is to keep watching and controlling a process around the clock, so operators of 24/7 systems commonly deploy the license server redundantly - a pair or a failover arrangement - so the loss of one host does not threaten the entitlements the runtimes depend on.
Redundancy for the license server follows the same logic applied to the rest of a high-availability SCADA design: identify anything the running system needs, and make sure no single failure of it can bring the system down. The license server earns a place on that list precisely because its role is easy to overlook until it fails. Treating it as critical infrastructure - patched carefully, backed up, monitored, and duplicated - keeps a licensing dependency from becoming the weakest link in an otherwise resilient architecture.
In cloud and hosted SCADA such as Merobix, much of this concern shifts from something each site must build and maintain to something engineered once into the managed platform, with the licensing and availability handled centrally rather than depending on a small on-site server that a plant team has to keep alive. For an operator running many remote sites, that removes a fragile, easily-forgotten component from every location and folds it into infrastructure that is designed for continuous operation, so a distributed field operation is not one overlooked license box away from a widespread outage.
Behaviour depends on the product, but many implementations provide a grace period during which already-running, checked-out clients keep operating even though they cannot reach the server, giving operations time to restore it. A brief network blip is usually absorbed with no effect. If the outage lasts long enough to exhaust the grace period, licensed functions can begin to shut down or drop to a degraded mode, which is why a license-server loss on a live plant is treated as urgent.
A dongle is a physical device, usually USB, that carries the license, so the entitlement exists only where the dongle is plugged in and moving it means physically relocating the device. Soft activation binds the license to characteristics of the host machine or to an online activation record instead, so no hardware device is involved. Dongles are simple and work offline but can be lost or damaged, while soft activation avoids the physical part but ties the license to a host that needs care during hardware changes.
Because on a 24/7 SCADA system a single non-redundant license server is a hidden single point of failure. If it goes down and the grace period expires, licensed functions can stop even though every SCADA server and network path is otherwise healthy. Deploying the license server as a redundant pair or failover arrangement means the loss of one host does not threaten the entitlements the runtimes depend on, keeping a licensing dependency from becoming the weakest link in the design.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.