Identity management is essential in any connected organisation, but applying office IT controls unchanged to operational technology can create a false sense of security. A factory network contains controllers, HMIs, drives, engineering workstations and safety-related systems whose failure may affect physical processes. The right question is therefore not simply whether a user has been authenticated. Plant managers and engineering teams must also ask what that identity can change, which machines can be reached, how the change will affect operation and whether the system can return to a known, controlled state.

The factory floor has different consequences

In a conventional IT environment, access control is commonly designed around information: who may read a file, administer a server or use an application. In operational technology, an authorised action can alter a setpoint, download PLC logic, reset an alarm or change a drive parameter. The resulting consequence may be downtime, damaged equipment or unexpected machine behaviour. For teams reassessing this boundary, practical IEC 62443 principles for industrial automation provide a useful framework for connecting identity, architecture and operational risk rather than treating authentication as an isolated control.

This difference changes the security objective. Confidentiality still matters, particularly for recipes, production data and intellectual property, but integrity and availability often demand equal or greater attention. An account may be valid and its password strong, yet the access remains poorly controlled if it reaches every controller on the line or allows an unrecorded configuration change. OT security must therefore be assessed against the process, machine states and credible consequences of interference—not only against a directory policy.

Identity must reflect operational roles

Shared maintenance accounts and default credentials make it difficult to establish who performed an intervention. Replacing them with individually assigned identities improves accountability, but this is only the first step. Permissions should correspond to real tasks: an operator may need to acknowledge process messages, a maintenance engineer may need diagnostic access, and an integrator may require temporary programming rights. None of those roles automatically needs unrestricted administration across the entire OT estate.

Least privilege must also account for time, location and machine state. Remote service access that is reasonable during an approved maintenance window may be inappropriate during normal production. Privileged access should be enabled for a defined task, limited to the relevant assets and removed when the work ends. Multi-factor authentication can strengthen remote entry, but it does not compensate for excessive permissions or a route that exposes an entire production network after login.

Segmentation contains legitimate and hostile activity

A flat network turns one compromised identity or engineering laptop into a potential route across multiple machines. IEC 62443 addresses this architectural problem through the concept of zones and conduits. Assets with comparable security needs are grouped into zones, while communication between them is restricted through defined conduits. The aim is not segmentation for its own sake, but control over which systems communicate, using which services and for what operational purpose.

In practice, corporate IT, remote-access services, engineering stations and machine-level controls should not be connected merely because communication is technically convenient. A demilitarised zone or controlled intermediary can prevent direct access from business or external networks to controllers. Unused ports, interfaces and services should be disabled where feasible. These measures reduce the attack surface and limit lateral movement if a credential, endpoint or component is compromised. They also make responsibility clearer during troubleshooting and incident response.

Change control is an OT security control

Authentication proves something about the person or system requesting access; it does not prove that the proposed change is safe. PLC programs, HMI projects, network configurations and drive parameters need controlled versioning and authorisation. Before deployment, the team should define the scope, affected assets, dependencies, acceptance criteria and rollback conditions. After deployment, it should be possible to identify who approved the change, who implemented it, which version was installed and whether the expected behaviour was confirmed.

This discipline becomes particularly important when software interacts with interlocks, start-up sequences, operating modes or safety-related functions. A change may appear minor at application level while altering timing, signal interpretation or recovery after communication loss. Where machine behaviour may be affected, the change should trigger an appropriately scoped risk review. ISO 12100 analysis and IEC 62443 analysis answer different questions, but their results must meet where a cyber event could alter a hazardous situation or weaken an adopted protective measure.

Functional safety remains a separate engineering task

Cybersecurity controls do not replace functional-safety design. A firewall cannot establish the required performance of a safety function, and a strong password cannot validate an emergency-stop circuit. Safety-related control functions still require suitable architecture, verification and validation, including consideration of ISO 13849 where applicable. Conversely, a correctly designed safety function does not remove the need to secure the accounts, software and interfaces that surround it.

The useful engineering question is whether digital interference can change an assumption on which risk reduction depends. Can a standard PLC alter a safety parameter? Can a remote user reset the system while a person is in a hazard zone? Can one engineering account modify both standard and safety configurations? Are checksums, approved backups and machine-specific versions available after service work? These questions connect cyber scenarios with residual risk without incorrectly treating every cyberattack as a new physical hazard in itself.

Monitoring must lead to an operational response

Office security teams often collect authentication and endpoint events, but OT monitoring must also recognise process-relevant changes. Useful records can include failed logins, remote sessions, PLC downloads, firmware changes and modifications to critical configurations. The objective is not to collect every possible event. It is to retain enough evidence to distinguish authorised maintenance from abnormal activity and to reconstruct what happened before production or safety was affected.

Alerts need named owners and response procedures that respect plant conditions. Immediately isolating a machine may itself create process risk, while leaving suspicious access active may allow further interference. IT, automation, maintenance and safety personnel should therefore agree in advance who can disconnect assets, stop production, preserve evidence and authorise recovery. Tested backups of controller programs and configurations are part of this response, but restoration should also confirm that the recovered version belongs to the correct asset and remains compatible with connected equipment.

A process-first implementation sequence

A practical programme begins with an inventory of assets, software, interfaces, users and remote-access paths. The team can then define the system under consideration, map zones and conduits, identify credible compromise paths and rank them according to operational consequence. Identity rules, segmentation and monitoring should be selected from that analysis rather than purchased as disconnected products. Legacy equipment may require compensating controls when modern authentication or encrypted communication cannot be added directly.

Finally, governance must follow the machine through design, commissioning, operation, retrofit and decommissioning. Account reviews, vulnerability decisions, update testing and periodic architecture checks should be assigned to specific roles. Any significant digital modification should prompt a review of affected risks and documentation. This approach does not promise automatic compliance or eliminate the manufacturer’s and operator’s responsibilities. It does, however, turn OT cybersecurity from a collection of IT controls into a managed engineering process built around controlled access, constrained communication and traceable change.