Part 3 of 5 in our Security in plain words series. A new hire, a leaver or a change of job should not mean a visit to every controller on site. Here is how we design identity so that it does not.
The cost of a shared login
It is a familiar picture. The controller login is one user name and password, written inside a cabinet door or kept in a spreadsheet half the plant can open. Where devices do have individual accounts, each one keeps its own list of who may log in. Either way, people change faster than the lists do.
A new engineer starts, and someone has to add them on every unit. A technician changes duties, and their rights are wrong until someone notices. A contractor finishes, and their login lives on, because nobody is sure which units they were added to. When something goes wrong, the record says "admin" did it, which tells you nothing.
None of this is a failure of discipline. It is what happens when identity is tied to devices rather than to people and roles.
Units that know roles, not people
The way we design identity turns that around. Each person carries a credential - a certificate - issued by the site's own authority. It says who they are, which site it is for and which role they hold. The unit trusts the site's authority and knows what each role may do. It keeps no list of who may log in.
So a new person is a credential issued, not a change on every unit, and a changed role is a new credential. Nothing on the units has to be touched, which keeps a fleet of controllers manageable without a central directory the plant network would have to reach.
The key a person signs in with from the browser stays where it cannot be copied: in the security chip of their own PC, or in a hardware key that asks for a PIN and a touch, which holds the command-line key too. In this design there is no password to share, because people log in without one.
One ladder of roles, at every door
Roles only help if they mean the same thing everywhere. We design four, each with everything the one below it has:
- Viewer - sees every page and value, and changes nothing.
- Operator - also runs the day-to-day commands and adjusts live values within their limits.
- Engineer - also changes the flows and works at the unit's command line.
- Administrator - also looks after the unit's security: its certificate, whom it trusts and its updates.
The same ladder applies at every door a person uses - the console, Tributary Studio, the engineer's command line and the data interface - so "operator" never means one thing on one screen and something else on another.
Software gets credentials of its own. Each client of the data interface has its own token and role, and a read-only role is refused any write; i3X vs MQTT describes how writes are checked. A machine never uses a person's credential, and a person never uses a machine's.
Ending access, and keeping the record
A security design is judged by how it handles the bad day. When someone leaves on bad terms, or loses the key that holds their credential, waiting for the credential to run out is not an answer. In our design an administrator ends that one person's access early, and any session they have open closes with it. Everyone else carries on.
In the same design, every login and every security change is recorded - who, in which role, from where and when - and the record survives a power cut. Refused attempts are counted and reported, so a unit that is being probed says so.
And the design has no back door: no vendor key opens a customer's unit. When a supplier's engineer needs to help, the customer's administrator lets them in, as an engineer at most, for a limited time and on the record, and the access ends by itself.
The handover: from integrator to owner
Integrators know this moment well. Commissioning is done, the plant is running, and the site passes to its owner. It is common for the integrator's logins to stay behind, because removing them risks locking everyone out. The way we design the handover makes it clean, in three steps:
- The owner's authority is set up. The plant owner creates its own authority, or names the one its IT department already runs, and issues its first administrator.
- Both are trusted, side by side. The integrator loads the owner's authority onto every unit beside its own. The integrator's trust carries an end date, but no unit lets it go until the owner's administrator has logged in on that unit and proven the new trust works. A unit never removes its last working way in.
- Every integrator credential is refused. The owner's administrator then removes the integrator's authority from every unit, and the integrator's credentials stop working. From then on the integrator helps the way any supplier does: when the owner lets them in.
The owner ends up with a site that answers only to its own people, and the integrator hands over without leaving a door open behind it.
What to ask of any controller
Whichever controller you choose, these are fair questions before it goes onto your site:
- Is there a default or shared login, and can it be removed entirely?
- Does each person have their own credential, issued by an authority you control?
- Does a new hire or a leaver mean a change on every unit?
- Can you end one person's access straight away, open sessions included?
- Can you tell who did what, and does the record survive a power cut?
- Can the supplier get in without your say-so?
- At handover, how are the integrator's credentials removed?
If the answers are hard to get, talk to us. We are glad to walk through how we design identity for a site like yours.
About CATIM. CATIM - Creating Automation Technology In Motion - empowers people to engineer automation solutions that solve hard technical problems. CATIM Nimbus, the CODESYS edge controller with advisory AI, is the next generation of the Nimbus platform it has built since 2019.