A user role is a named bundle of permissions that you assign to people, so that instead of granting rights to each individual you grant them to a role once and then hand people that role. This is the practical backbone of role-based access control, and it is what keeps a SCADA system both secure and manageable as the number of users grows. Creating a good role is an exercise in deciding exactly what a category of person, an operator, a maintenance tech, a manager, a read-only observer, should and should not be able to do, and then encoding that decision as a set of granular permissions. This guide walks through building a role from scratch: naming it clearly, choosing each permission deliberately, scoping the role to the areas it applies to, and assigning users, all guided by the principle that people should get the least access their job actually requires.
How to create a user role in SCADA in one line: To create a user role in SCADA, give the role a clear name that describes the job it represents, then select the specific permissions that job needs, such as viewing screens, acknowledging alarms, changing setpoints, or editing configuration, granting only what the role genuinely requires. Scope the role to the plant areas or asset groups it should cover so it cannot touch equipment outside its remit, then assign the appropriate users to the role. Follow least privilege throughout, starting from no access and adding only what is needed, so a role never carries powers its holders will not use.
The name of a role should describe the job or category of person it represents, not the individual and not the vague level of trust. Names like Operator, Shift Supervisor, Maintenance, Read-Only Observer, and Configuration Engineer immediately tell anyone reviewing the system who the role is for and roughly what it can do. A clear name matters more than it seems, because roles accumulate over the years, and a system full of names like Role1 or JohnsAccess becomes impossible to audit or reason about. The name is the label that a future administrator, possibly during a security review, will use to decide whether a role's powers still make sense.
The substance of a role is its permissions, and modern SCADA systems break access into fine-grained rights rather than a single coarse level. Typical permissions include viewing screens and data, acknowledging alarms, changing setpoints and operating equipment, silencing or shelving alarms, running or scheduling reports, and editing the configuration itself, adding tags, building screens, changing alarm limits. These are genuinely different powers with genuinely different consequences: viewing data is harmless, acknowledging an alarm is a record-keeping action, changing a setpoint moves the actual process, and editing configuration can reshape the whole system. Treating them as separate switches is what lets a role grant exactly the capability a job needs and nothing more.
Choosing permissions well means walking through what the role's holders actually do in a normal day and granting each capability only if it is needed. An operator role clearly needs to view screens, acknowledge alarms, and adjust setpoints within their process, but almost certainly does not need to edit tag configuration or delete screens, and giving it those powers only creates the chance of an expensive accident. A read-only observer role, perhaps for a manager or a contractor, gets viewing and nothing else, so they can see the plant without any ability to change it. Working permission by permission, and pausing on each one to ask whether this role truly needs it, is the concrete practice that turns an abstract access-control idea into a safe, specific role.
Permissions answer what a role can do, but scope answers where it can do it, and both matter. Many facilities are divided into areas, units, or asset groups, and a role can be limited to only the areas its holders are responsible for. An operator who runs the north field should be able to acknowledge alarms and change setpoints on north field equipment, but has no business operating the south field they never see, so the role is scoped to the north field alone. Scoping contains mistakes and limits the blast radius of a compromised account: a role that can only touch its own area cannot accidentally, or maliciously, reach across the whole plant.
Least privilege is the principle that ties permissions and scope together, and it is the single most important idea in building roles. It says to start from the assumption that a role has no access at all, and then add only the specific permissions and areas the job genuinely requires, rather than starting from full access and trying to take dangerous powers away. The difference is not just philosophical: starting from nothing and adding produces a role that carries exactly what it needs, while starting from everything and subtracting almost always leaves stray powers behind that nobody remembers granting. Every capability a role holds but does not use is pure risk with no benefit, so least privilege systematically eliminates that surplus.
Applying least privilege also makes the system far easier to audit and to trust over time. When each role holds only what its job needs, a security review can look at a role and quickly confirm its powers are appropriate, whereas a system where everyone has broad access offers no way to reason about who could have done what. It also limits the damage from the most common real-world security failure, a shared or stolen credential, because an account restricted to viewing the north field is a far smaller prize than one that can reconfigure the entire facility. The discipline of granting the minimum is what keeps access control meaningful as the user list grows and people come and go.
With the role's permissions and scope defined, the final step is assigning the actual people to it, which is deliberately the easy part, because all the thinking went into the role. You add users to the role rather than configuring each user's rights individually, and that indirection is the whole payoff of role-based access: when a new operator is hired you assign them the Operator role and they instantly have exactly the right access, and when someone changes jobs you move them from one role to another rather than editing a long list of individual permissions. This also makes offboarding clean, since removing a departing person from their role revokes everything at once with no orphaned permissions left behind.
Role-based access becomes especially important when SCADA moves to the cloud and people log in from anywhere, because the boundary that a physical control room once provided is gone. In a cloud SCADA platform such as Merobix, an operator, a manager, and a contractor might all reach the same system from their own devices over the internet, so the roles are the primary thing deciding who can see and do what. A view-only role for a manager who wants the morning picture, an operator role scoped to the sites a technician actually runs, and a full engineering role held by only a couple of people, all enforced by the platform regardless of where the person signs in, are what make broad remote access safe rather than reckless.
For field operations spread across many remote sites, scoping roles to asset groups also mirrors how the work is actually divided. A contractor responsible for a handful of wells can be given an operator role scoped to just those wells, so they can run their assets without any visibility into or control over the rest of the fleet, which is both a security boundary and a practical convenience that keeps their screens focused. As the operation grows and more people need access to more sites, the roles you built carefully at the start are what let you onboard each new person in seconds by assignment rather than by reconfiguration, which is exactly the scalability that creating roles well is meant to deliver.
Least privilege means starting from the assumption that a role has no access at all and adding only the specific permissions and areas the job genuinely requires, rather than starting from full access and removing dangerous powers. Building up from nothing produces a role that carries exactly what it needs, while cutting down from everything almost always leaves stray powers behind. Every capability a role holds but never uses is pure risk with no benefit, so least privilege eliminates that surplus.
Because it makes access manageable as the user list grows and changes. You define a role's permissions and scope once, then simply add people to the role, so a new hire gets exactly the right access instantly and a job change is just a move from one role to another. It also makes offboarding clean, since removing a departing person from their role revokes everything at once with no orphaned permissions left scattered across the system.
Scoping limits where a role can act, not just what it can do, so an operator responsible for the north field can be restricted to north field equipment and cannot reach the south field. This contains mistakes and limits the blast radius of a compromised account, because a role that can only touch its own area cannot accidentally or maliciously reach across the whole plant. In cloud and multi-site operations, scoping to asset groups also mirrors how the work is actually divided among crews and contractors.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.