29 Jul 2026 · 5 min read
The plant should still let you in when the link is down
security · ot · architecture · scada · ignition
Somebody in IT has asked you to put every login in the plant behind one identity system. It is a good ask. You have twenty-odd password namespaces, several of them shared, at least one written on a label under a keyboard.
Before you agree, pick the worst moment you can imagine. The WAN link to head office is down, something is misbehaving on the floor, and the operator's session has just expired.
Who can log in?
If the honest answer is nobody, you have not centralised your identity. You have made your plant depend on a network you do not control, at exactly the hour it is least likely to be there.
What the design review usually proposes
ONE IDENTITY PROVIDER · EVERYTHING FEDERATES TO IT
The thing that is wrong with it is invisible, which is the whole difficulty. It is the direction of the dependency. Every login inside the fence now rests on a link the plant does not own and cannot repair.
Two facts that break it
Both of these are documented by the vendors themselves, and neither tends to come up before the project is approved.
TWO THINGS THE DESIGN REVIEW WON'T MENTION
IGNITION
No identity-provider failover
IdPs do not support the concept of ‘failover’ in the same way as User Sources.
Inductive Automation staff, on their own forum
Link down, IdP unreachable, nobody logs in to Perspective. The only working fallback is a local user source per site.
MICROSOFT
The on-premises MFA server is gone
MFA Server isn’t available for new deployments and is deprecated.
Microsoft Learn · stopped servicing requests September 2024
The documented replacement for RADIUS clients is the NPS extension, which calls Microsoft on every authentication event.
The first one is worth understanding rather than just noting, because it is not an oversight. The gateway hands the browser to the identity provider, and if there is nothing to hand it to, there is no login screen left to fall back to. Failover is a property of user sources, and an external provider is not one. There is an open feature request for it, which tells you it is a known gap rather than a misunderstanding on my part.
The second one matters because it removes the escape hatch most estates were quietly relying on. There is no longer a supported Microsoft path to answering a second-factor challenge without a round trip off site.
The rule: federation flows down, dependency never flows up
TWO TIERS · IDENTITY ABOVE, SESSIONS BELOW
Corporate identity stays authoritative for who works here — joiners, movers, leavers, the HR-driven record. A second identity provider inside the plant is authoritative for sessions. It brokers upward to corporate when the link is there, and keeps issuing tokens when it is not.
This is not a workaround. Microsoft's own Enterprise Access Model puts access control in the control plane and concedes that for legacy OT, network-level control is sometimes the only option available. The plant tier is where you honour that.
Keycloak is the common choice for the local tier because it is free, it self-hosts, it speaks OIDC and SAML in both directions, and it will happily broker to Entra ID while remaining the thing your gateways actually talk to. The product matters less than the position.
What each layer can actually speak
This is the part that decides your project plan, and it is less uniform than any vendor slide suggests.
WHAT EACH LAYER WILL ACTUALLY ACCEPT
No native MFA. No IdP failover.
SAML is Enterprise-only. No built-in MFA.
Cloud-only identity does not survive a link drop.
SAML cannot authenticate to the CLI.
SAML is not the documented admin path.
TACACS+ encrypts the whole packet; RADIUS only the password.
TIA V19 and later; access control on by default.
CIP Security on 5580 v32+; GuardLogix excluded.
The lowest common denominator, and it always will be.
Two entries surprised me. PLCs now have real identity. Siemens' User Management Component imports users and groups from Active Directory and the ring server itself acts as an identity provider to the CPUs, with access control on by default in TIA Portal from V19. Rockwell reaches the same place through FactoryTalk Directory rather than the controller. Either way, an engineering session can now carry a named person instead of a shared password that four contractors also know.
And the CLI is always the exception. PAN-OS supports SAML for the administrator web interface, then states plainly that administrators cannot use SAML to authenticate to the CLI. Whatever you build, the command line stays local. Plan the break-glass path rather than discovering it.
The second factor that works with no internet
A six-digit code from a phone app is the right instinct for a plant, and the reason is arithmetic rather than preference.
ISOLATED NETWORK · WHICH SECOND FACTORS STILL WORK
Validated entirely inside your network. Keycloak has it built in; FortiAuthenticator serves it over RADIUS.
Also offline, and phishing-resistant, which TOTP is not. The better answer where the software supports it.
The phone must reach the vendor and the vendor must reach you.
Weakest of the four even when the signal is there.
This is what the NPS extension does on every single login.
Everything below that line outsources the decision to somebody else's server, and an isolated network is defined by not being able to reach one. That is the entire argument, and it does not rest on anybody's product preference.
Three things to take seriously before you commit to it:
- Time becomes a security control. Fortinet says it directly: the algorithm is time-based, so an isolated network needs its own NTP source. Clock drift stops being cosmetic and starts locking people out of a running plant.
- Phones are banned in plenty of control rooms. Hardware OATH tokens cost less than the argument about it.
- TOTP is not phishing-resistant. FIDO2 is, and it is also offline, because the verification happens at the thing you are logging in to. If you are building new, put FIDO2 on the engineers and TOTP everywhere else.
Where the risk actually is
Worth recalibrating before you spend a quarter on the elegance of your login page. Dragos' 2026 report found that 73% of their incident response cases had VPN or credential reuse as the entry point — attackers authenticating legitimately through VPN portals, firewall interfaces and vendor tunnels rather than exploiting anything.
73% OF OT INCIDENTS START WITH A VALID LOGIN · SO ORDER THE WORK
Separate directory, separate accounts, separate password namespace. Cheapest control on this list and the one that closes the 73%.
Never a tunnel that terminates inside the plant. Session recorded, second factor enforced, one way in.
Worth doing, largely because it removes the passwords people were reusing in the first place.
That orders the work for you, and the ordering is not the one most programmes use. It is the same mistake as blaming the protocol for an exposure problem: money goes to the sophisticated control while the cheap structural one stays undone.
The control room is a genuine exception
Be honest about this one going in, because pretending otherwise is how you end up with a badge taped to a reader.
THE CONTROL ROOM · TWO DIFFERENT QUESTIONS
WHO IS WATCHING
A long-lived session on a manned console
- ·Screens, trends, alarm lists
- ·Survives shift change
- ·Badge tap for a name, not a password
WHO AUTHORISED THIS
Credentials demanded at the write, not at the login
- +Setpoint changes and overrides
- +Alarm shelving and bypasses
- +Named in the audit trail, every time
A console watched around the clock cannot re-authenticate a named person for every action, and no amount of policy will change that. What works is separating the two questions. Both Ignition and FactoryTalk can demand credentials at the point of a write rather than at the point of a login, which is where a named identity earns its keep and where an auditor will look first.
The test to run on Monday
Take one machine on a bench, on the plant network, and pull its route to head office. Not a policy discussion, an actual unplugged cable.
Then try to log in to each thing in turn. The SCADA, the dashboard, the Windows box, a switch, the firewall. Write down which ones let you in.
Then ask the second question, which is usually the more uncomfortable one: for everything that failed, does a documented break-glass account exist — sealed, tested, and known to more than one person? Or does it exist as a password in somebody's phone that nobody has admitted to having?
Whatever that exercise produces is your real availability position, and it is a much better thing to take into the design review than any argument about which identity provider is better.
Running single sign-on across an OT estate, or arguing about it right now? I would like to hear which layer fought back hardest. Reply by email.
Keep reading
Newsletter
New essays, by email.
SCADA, cloud, AI, and the plant floor — a short email when something new is published. No noise, unsubscribe anytime.