IEC 62443-3-1 Clause 5.2 – Password Authentication

What it is

Password authentication tests something the user or device knows. It remains the default on many IACS hosts and HMIs.

Vulnerabilities addressed

Stops casual and some remote misuse of interactive sessions when passwords are unique, strong and not shared. It does not, by itself, stop captured or guessed secrets, default vendor accounts, or protocols that send credentials in the clear.

Typical deployment

Local OS or application password stores; sometimes a central directory. Shared “operator” accounts are still common on consoles — that defeats unique accountability.

Known issues and weaknesses

• Guessable, dictionary and default passwords.
• Social engineering of resets and initial distribution.
• Lockout policies can deny essential functions if applied blindly to operator consoles.
• Reusable passwords sent across a network are weaker than challenge/response (see 5.3).

Use in IACS

Appropriate as a baseline factor. Combine with tokens or MFA for remote and high-risk interactive access. See SR 1.7 for later strength requirements.

Recommendations

• Passwords should have length and entropy matched to the required security. They should not appear in a dictionary or use predictable sequences.
• Transmit initial and reset passwords by a method that is not social-engineerable (for example face-to-face identity check). Change vendor defaults.
• Do not share accounts where unique identity is required.
• Protect password files and stores.
• Lock out or delay after failed attempts only where this cannot deny essential functions.
• Authenticator feedback must not reveal the secret (mask entry; do not echo the password).