IAM for manufacturing: managing access across OT and IT

Identity and access management (IAM) in manufacturing is harder than in an office. Plants run operational technology (OT) on older operating systems, industrial control systems (ICS) that can't support modern authentication, and production lines that can't stop for a security update.

I spent 20 years working in manufacturing plants as an industrial cleaner before moving into cybersecurity. The job took me into almost every area of a plant, from production floors to maintenance shops, often outside regular shifts. I occasionally saw machines and terminals running on shared logins, and outside technicians plugging laptops into equipment. On the floor, those were simply how the work got done.

This guide covers how to apply IAM controls across OT and IT, which standards apply, and how to reduce unauthorized access without disrupting production.

Why IAM is different in manufacturing

IT systems usually support modern identity tools: Active Directory or Microsoft Entra ID, single sign-on, and MFA. Patching and rebooting them is routine.

OT systems often run older operating systems like Windows 7 or proprietary real-time systems, use vendor-specific protocols, and can only be patched or rebooted during planned downtime. Many programmable logic controllers (PLCs) and human-machine interfaces (HMIs) support only a handful of local accounts, with no MFA or role-based access.

Those constraints mean IT's controls can't be copied straight onto the plant floor. Done well, IAM limits the damage from a compromised account and leaves an audit trail for investigations. Done poorly, it can lock operators out of critical systems or create enough friction that people work around it.

Standards that apply

Which standards apply depends on who you sell to. These are the ones manufacturers run into most:

If you supply Canadian defence contracts, see our guide to CPCSC Level 1 requirements for the 13 controls in detail.

IEC 62443 matters most for the plant floor. Its parts split by role: 3-2 covers risk assessment and dividing the plant into zones, 3-3 covers system security requirements, 4-1 covers how product suppliers develop securely, and 4-2 covers the technical requirements for individual components like PLCs and HMIs.

Its security levels run from SL 1, protection against casual or accidental misuse, to SL 4, protection against skilled, well-resourced attackers. Target security levels are set for each zone and conduit, so a safety system can sit at a higher level than a monitoring zone. That lets you spend the most effort where the risk is highest.

The core IAM controls

1. Unique accounts for every user

Give every person who touches IT or OT systems their own account. Shared accounts like "operator1" or "admin" make it impossible to tell who did what, which stalls any investigation.

• IT: manage accounts in Active Directory or Microsoft Entra ID, and disable local accounts except for documented emergency access.
• OT: many devices support only a few accounts. Where unique accounts aren't possible, route access through a jump server or privileged access management (PAM) tool that records which person used the shared account and when.

2. Least privilege and role-based access

Give people access only to the systems and functions their job needs. An operator doesn't need engineering rights, and an IT administrator doesn't need access to production control systems unless the role requires it.

• IT: assign permissions through groups by job function, and review access quarterly.
• OT: separate operator and engineer accounts. Restrict engineering functions like uploading programs, changing setpoints, or reconfiguring devices to authorized staff.

3. Multi-factor authentication

Require MFA for remote access, privileged accounts, and cloud applications. A stolen password alone won't get an attacker in.

• IT: enable MFA on VPNs, email, cloud apps, and every admin account.
• OT: legacy devices usually can't do MFA, so apply it at the edge instead. Require MFA on the VPN or jump server used to reach OT systems, and never expose OT systems directly to the internet.

4. Privileged and vendor access

Privileged accounts can change configurations and upload programs, which makes them high-value targets. Vendor and integrator access deserves the same care, because outside technicians often need deep access for short periods.

• IT: store privileged credentials in a PAM tool, rotate them automatically, and record privileged sessions.
• OT: route vendor access through a monitored jump server instead of letting laptops connect directly to equipment. Avoid hard-coded vendor credentials, and rotate vendor passwords after each maintenance visit.

Over the years, I occasionally saw outside technicians connect laptops straight to equipment on the floor. A monitored jump server gives those visits a clear record of who connected, when, and what they changed.

5. Network segmentation

Separate OT networks from IT networks with firewalls, so a compromised office laptop can't reach control systems directly.

Many plants organize this with the Purdue Model, a layered reference architecture that predates IEC 62443 and is used in ISA-95. It runs from Level 0 (physical process) and Level 1 (basic control) through Level 2 (supervisory) and Level 3 (site operations), then an IT/OT DMZ often called Level 3.5, up to Levels 4 and 5 (enterprise systems). IEC 62443 adds its own model of zones, groups of assets with similar security needs, and conduits, the controlled paths between them. Many plants map those zones onto Purdue levels.

6. Account lifecycle management

Create accounts at hiring, adjust them when roles change, and disable them the day someone leaves. Lingering contractor and former-employee accounts are an easy way in.

• IT: connect onboarding and offboarding to your directory, and review accounts quarterly.
• OT: keep a written access list for systems that can't connect to the directory. Disable contractor and integrator access the day their work ends.

7. Logging and monitoring

Log sign-ins, privileged actions, and access to sensitive systems, and review the logs regularly.

• IT: send logs from your directory, VPN, cloud apps, and key servers to a central log platform, with alerts for failed logins and after-hours access.
• OT: many PLCs log little or nothing. Log at the edges instead: firewalls, jump servers, and engineering workstations.

Common mistakes

Copying IT controls onto OT without testing. Forcing password expiry or lockouts on an HMI account can lock operators out mid-shift. Test IAM changes in a staging environment or during planned downtime.

No emergency access procedure. If the PAM system or MFA server is down, operators still need a way into critical systems. Document a break-glass procedure, test it, and review every use of it.

Hard-coded credentials in SCADA or MES systems. Some supervisory control and manufacturing execution systems ship with built-in service account passwords. Change them where the vendor supports it, limit their permissions, and rotate them on a schedule.

No separation between IT admins and OT engineers. IT staff rarely need routine access to production control systems, and OT engineers rarely need domain admin rights on the corporate network. Separate roles reduce the chance of an accident or attack crossing from one side to the other.

Treating shared floor logins as harmless. I saw some terminals and machines on the floor running under shared logins. On a busy line, a shared login feels convenient, but it erases the record of who made a change.

How to implement IAM in a plant

1. Inventory every system. List each IT and OT system, who can access it, and which authentication methods it supports.
2. Rank systems by risk. A standalone test PLC carries less risk than the HMI running a production line. Use IEC 62443 zones and security levels to decide where to start.
3. Segment the network. Separate IT from OT, divide OT into zones, and allow only the traffic each zone needs.
4. Put MFA at the edge. Require MFA on VPNs, jump servers, and remote access gateways that reach OT systems.
5. Control privileged and vendor access. Start with IT admin accounts and engineering workstations, then route vendor access through monitored jump servers.
6. Turn on logging. Log sign-ins and privileged actions on every system that supports it, and log at the network edge for systems that don't.
7. Document and test. Write down your access policies, access lists, and emergency procedures, and test them during planned downtime.
8. Review access quarterly. Check who has access to what, and remove what's no longer needed.

If you're starting from scratch, begin with steps that carry little production risk: unique accounts where devices allow them, MFA on remote access, IT/OT segmentation, and logging at the edges. Each one closes a common gap without touching the controllers themselves.

Tools to know

Sources

• IEC 62443 overview, International Electrotechnical Commission
• IEC 62443-3-2:2020, Security risk assessment for system design, International Electrotechnical Commission
• ISA/IEC 62443-3-3: What is it and how to comply, Cisco
• CPCSC program overview, Public Services and Procurement Canada
• Protecting specified information in non-Government of Canada systems and organizations (ITSP.10.171), Canadian Centre for Cyber Security
• CMMC 2.0: The model, the rules, and the timeline, SaltyCloud (source for CMMC Level 2's use of NIST SP 800-171 Revision 2)
• ISO 27001:2022 Annex A 8.5 Secure authentication, ISMS.online (source for the 2022 Annex A control themes)

Sources checked October 2026.