Why IT Identity Models Break on the Plant Floor

 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:
 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

From an IT audit perspective, shared accounts are a red flag. From an OT operations perspective, they are often unavoidable.

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.

Until organizations accept that fundamental difference, IT identity models will continue to break the moment they hit the plant floor.