By Muhammad Ali Khan ICS/ OT Cybersecurity Specialist - AAISM | CISSP | CISA | CISM | CEH | ISO27001 LI | CHFI | CGEIT | CDCP
Different Worlds
Identity works beautifully in IT. Users log in. Accounts are provisioned. Access is reviewed. Logs are audited. On paper, the same model should apply everywhere.
Then you step onto a plant floor.
What IT calls an identity is usually a human with a keyboard. What OT calls an identity might be a PLC rung, a historian service, a maintenance laptop, a vendor dial-in session, or a controller that has been running since before Active Directory existed.
Trying to force IT identity models into OT environments without adaptation is one of the fastest ways to create operational risk, safety exposure, and unplanned downtime.
This article explains why traditional IT identity models fail in industrial environments, and what practitioners must understand before attempting to “modernize” identity on the plant floor.
1. IT Identity Assumes People. OT Identity Assumes Processes.
IT identity models are human-centric by design.
They revolve around named users, roles, job functions, and employment status.
OT environments do not work that way.
On the plant floor:
- Machines authenticate to machines
- Processes run continuously, not per login session
- Access is tied to operational states, not job titles
A PLC does not “log in” at 8 a.m. and log out at 5 p.m. A DCS service account cannot be rotated every 90 days without risking a plant trip. A maintenance engineer may need elevated access for 20 minutes, not permanently.
When identity is tied to who someone is instead of what the process needs, the model breaks.
2. Availability Beats Confidentiality Every Time
IT identity models are designed to protect data:
- Prevent unauthorized access
- Enforce least privilege
- Expire credentials aggressively
In OT, the primary mission is different, To keep the process running safely.
If identity controls:
- Delay access during an incident
- Lock out an operator during a fault
- Break an automation dependency
Then identity itself becomes a safety risk.
On the plant floor:
- A failed login can mean a stopped process
- An expired certificate can halt production
- A misconfigured role can trip a safety system
This is why OT teams often bypass identity controls entirely rather than risk downtime.
3. Legacy Systems Were Never Designed for Modern Identity
Many industrial systems:
- Predate Active Directory
- Do not support MFA
- Use shared accounts by design
- Embed credentials directly in firmware or logic
You cannot simply “add IAM” to:
- A 20-year-old PLC
- A serial-connected RTU
- A vendor HMI with hardcoded passwords
IT models assume:
- Software updates are routine
- Authentication libraries can be replaced
- Identity standards are supported
OT systems assume:
- Stability over change
- Certification over updates
- “If it works, don’t touch it.”
Forcing modern identity onto legacy control systems often introduces more risk than it removes.
4. Shared Accounts Exist for Operational Reasons
Shared identities exist because:
- Shift handovers must be instantaneous
- Emergency access cannot wait for account provisioning
- Some systems support only one or two accounts
- Accountability is enforced through procedures, not logins
Replacing shared accounts without redesigning workflows leads to:
- Credential sharing anyway
- Passwords written on cabinets
- MFA tokens taped to HMIs
The problem is not shared accounts. The problem is ignoring why they exist.
5. Identity Lifecycles Do Not Match OT Reality
In IT:
- Joiner → Mover → Leaver
- HR triggers access changes
- Roles map neatly to permissions
In OT:
- Contractors appear during outages
- Vendors need access for one specific asset
- Engineers support multiple plants
- Access is often episodic, not continuous
A technician may need:
- Full access during commissioning
- Read-only during steady state
- No access for months afterward
Traditional IAM struggles with time-bound, asset-specific, operational access.
6. Authentication Alone Does Not Equal Trust in OT
IT identity assumes:
“If you authenticated successfully, you are trusted.” OT cannot afford that assumption.
On the plant floor:
- A valid credential can still cause physical damage
- A trusted account can execute unsafe commands
- An authenticated session can violate process limits
OT trust is contextual:
- What mode is the plant in? "
- What is the safety state?
- What asset is being accessed?
Identity without process awareness is incomplete and dangerous.
7. Vendor Access Breaks Every IT Identity Rule
Industrial environments depend heavily on vendors:
- OEMs
- Integrators
- Remote support teams
Vendor access often:
- Bypasses corporate IAM
- Uses jump hosts or modems
- Operates during emergencies
IT identity models assume:
- Central control
- Uniform enforcement
- Predictable access patterns
OT reality is:
- Access must work at 3 a.m. during a fault
- Vendor systems may be outside your IAM
- Blocking access can cost millions per hour
Without OT-aware access models, organizations either overexpose systems or block support entirely.
8. Compliance Models Were Written for IT, Not Physical Processes
Most identity compliance requirements were written with IT systems in mind:
- SOX
- ISO 27001
- NIST 800-53
Applying them blindly to OT leads to:
- Checkbox security
- Operational workarounds
- A false sense of control
In OT, compliance must align with:
- Safety standards (IEC 61511, IEC 62443)
- Operational risk
- Engineering constraints
Identity controls that ignore physics will always fail.
What Actually Works on the Plant Floor
Identity in OT must be:
- Process-aware
- Asset-centric
- Time-bound
- Fail-safe, not fail-secure
Effective approaches include:
- Segmentation before authentication
- Role separation at the system level, not user level
- Strong monitoring instead of aggressive lockouts
- Controlled break-glass access
- Vendor access brokers designed for OT
Most importantly, identity must be designed with operations, not imposed on them.
Final Thought: Identity Is a Control System
On the plant floor, identity is not an IT control.
It is part of the control system itself.
If it:
- Interrupts operations
- Delays response
- Overrides engineering intent
Then it has failed its purpose.The goal is not to make OT “look like IT.” The goal is to make identity serve safety, reliability, and resilience.
