Authentication

What is authentication?

Authentication is the process by which a system verifies that a user, device or software process truly is who or what it claims to be before granting access to systems, applications or data. It is the first line of defence in any access management: only once identity has been proven can a system decide what someone is allowed to do. In OT networks, strong authentication prevents unauthorised people from operating or reprogramming a SCADA system, a PLC or an engineering station.

🔄 What is the difference between identification, authentication and authorisation?

Access happens in three consecutive steps, often followed by a fourth for accountability:

1. Identification - you claim an identity, for example with a username, badge number or a device serial number.
2. Authentication - you prove that claim with a password, token, certificate or biometric trait.
3. Authorisation - the system determines which rights belong to that identity.
4. Accounting / logging - actions are recorded so you can trace afterwards who did what.

Without reliable authentication, every authorisation rule is worthless: anyone who can impersonate someone else inherits their rights.

🧠 What authentication factors exist?

Authentication factors fall into three categories:

Single-factor authentication uses one factor, usually a username and password. Multi-factor authentication (MFA) combines at least two factors from different categories, so two passwords do not count as MFA. Security questions (“name of your first pet”) are not an acceptable authenticator under the US guideline NIST SP 800-63B, because the answers are often public or guessable.

🔧 Which authentication methods and protocols are used?

• Passwords - still the most common method. NIST SP 800-63B Revision 4 (August 2025) requires at least 15 characters when the password is the only factor and at least 8 characters within MFA. Mandatory character mixes and periodic changes are discouraged; instead, check new passwords against lists of breached passwords.
• MFA - combines, for example, a password with a code from an app. SMS codes and push notifications can still be bypassed through phishing or “MFA fatigue”: a flood of push requests until the user approves one.
• FIDO2 and passkeys - the W3C WebAuthn standard and the FIDO Alliance’s CTAP protocol use a key pair bound to the genuine website or application. That binding makes FIDO2 phishing-resistant.
• Certificates and PKI - X.509 certificates prove the identity of users (smartcards) and devices. Proper certificate management covers issuance, renewal and revocation.
• Kerberos, LDAP and Active Directory - central directories in which accounts are managed in one place. Active Directory uses Kerberos v5 (port 88) by default; the older NTLM is weaker and is being phased out.
• RADIUS and 802.1X - RADIUS (RFC 2865, UDP port 1812) centralises authentication for network equipment and VPN. With 802.1X, a switch or access point (the authenticator) only admits a device (the supplicant) once a RADIUS server has approved it, preferably with certificates via EAP-TLS. This is the foundation of NAC.

🤖 How do devices and machines authenticate each other?

On the plant floor, most communication is machine to machine. Those connections need authentication too:

• OPC UA - every client and server has its own application instance certificate (X.509). On top of that, a user can sign in anonymously, with a username and password, with an X.509 certificate or with an issued token such as a JSON Web Token. Set the security mode to Sign & Encrypt and disable anonymous access wherever you can.
• TLS with mutual certificates - client and server prove their identity to each other, as with MQTT over TLS or Modbus/TCP Security.
• Modbus/TCP Security - the secured variant published by the Modbus Organization in 2018 wraps Modbus in TLS on TCP port 802, with X.509 certificates for both parties and roles carried in the certificate.
• DNP3 Secure Authentication - version 5 (IEEE 1815-2012) lets an outstation verify critical commands with an HMAC-based challenge-response, which blocks spoofed and replayed messages.

🏭 Why is authentication harder in OT than in IT?

• Protocols without authentication - classic Modbus, DNP3 without Secure Authentication and many older ProfiNET and fieldbus implementations accept any command from anyone who can reach the network.
• Shared accounts - an HMI in the control room is often permanently logged in with a generic “operator” account so that shifts can hand over seamlessly. You can then no longer trace who performed an action.
• Default and hardcoded passwords - in November 2023, attackers broke into the water authority of Aliquippa (Pennsylvania) through a Unitronics PLC that was exposed to the internet with the default password “1111”.
• Availability comes first - an operator must be able to intervene immediately in an emergency. A locked account or a session timeout in the middle of an upset can be more dangerous than the risk it mitigates.
• Legacy systems - older controllers and Windows versions do not support modern methods such as Kerberos-only, FIDO2 or certificates.

That is why OT often compensates with network measures: defence in depth, segmentation and a jump server with MFA in front of the zone where unauthenticated protocols run. These measures are part of overall OT security.

🔐 What do NIS2 and IEC 62443 require of authentication?

In IEC 62443-3-3, SR 1.1 requires MFA for access via untrusted networks from security level 3 and for all networks at security level 4. For organisations under NIS2, MFA on remote access and administrative accounts is the practical minimum. See also the overview of security standards.

🧭 How do you set up authentication in an OT environment step by step?

1. Inventory all access points - HMIs, engineering stations, PLC web interfaces, remote access connections and vendor service accounts.
2. Replace default passwords - immediately at commissioning, including on switches, firewalls and field devices.
3. Make accounts personal - use individual accounts from a central directory wherever possible, for example a separate OT domain without a trust relationship with the office domain.
4. Enforce MFA at the edges - on VPN, jump server and management interfaces; preferably choose FIDO2 or smartcards.
5. Manage privileged accounts separately - with PAM, just-in-time rights and session recording for vendors.
6. Authenticate devices - with 802.1X, OPC UA certificates and mutual TLS where the equipment supports it.
7. Log and monitor - record failed and successful logins in central logging and alert on anomalies.

A pragmatic compromise for the control room is a shared “view” session that always stays visible, while write actions require a personal login, for example with a badge and PIN.

❓ Frequently asked questions

What is the difference between authentication and authorisation?

Authentication establishes who or what is requesting access, while authorisation determines what that verified identity is allowed to do. Authentication always comes first. In IEC 62443-3-3, authentication falls under FR 1 and authorisation under FR 2.

Is MFA mandatory under NIS2?

NIS2 explicitly lists multi-factor authentication or continuous authentication as a measure “where appropriate” in Article 21(2)(j). In the Netherlands, this obligation has applied through the Cyberbeveiligingswet since 15 August 2026. For remote access and administrative accounts, MFA is therefore required in practice.

Why is SMS-based MFA less secure?

MFA via SMS or a one-time code can be intercepted by fake websites that relay the code in real time, or through SIM-swap fraud. Phishing-resistant authentication such as FIDO2 or certificate-based smartcards binds the proof cryptographically to the genuine service. A login attempt captured on a fake website is therefore useless.

How long should a password be?

NIST SP 800-63B Revision 4 requires at least 15 characters when a password is the only authentication factor, and at least 8 characters when it is part of MFA. Long passphrases are stronger and easier to remember than short complex passwords. Forced periodic changes are only needed after a suspected compromise.

Do Modbus and DNP3 support authentication?

Classic Modbus has no authentication at all: any device that can reach the network can read and write registers. Modbus/TCP Security, published in 2018, adds TLS with certificates, and DNP3 offers Secure Authentication version 5. Both are still rarely deployed, so network segmentation remains necessary.

Can operators use a shared account?

Shared accounts make it impossible to attribute actions to a person and conflict with IEC 62443-3-3 SR 1.1, which requires unique identification of users. Control rooms often solve this with a shared read-only session and a personal login for control actions. Where a shared account is unavoidable, compensate with physical access control and logging.

📌 In summary

Authentication proves that a user, device or process is who it claims to be, and is therefore the foundation of every access decision. In OT environments, you combine personal accounts, phishing-resistant MFA at the edges, certificates for devices and segmentation around unauthenticated protocols, embedded in access management, least privilege, access control and Zero Trust. That way you meet IEC 62443, NIS2 and the Dutch Cybersecurity Act without putting process availability at risk.