Walk into most control rooms and you will find the same three habits: a shared "operator" login taped under the keyboard, a password policy written in 2009, and field devices still wearing the credentials they shipped with. Credentials are where the majority of real-world industrial intrusions begin - not exotic exploits - which makes credential security the highest-return work an OT team can do. This guide covers the full stack: killing shared logins, how passwords should actually be stored (and how to catch a vendor doing it wrong), what NIST really says about rotation, phishing-resistant MFA, and the machine credentials - devices, gateways, API keys - that most programs forget.
One of 60+ guides in our SCADA security and compliance series.
The shared control-room login feels harmless - everyone on shift needs the screens, so why not one account? Because it breaks three things at once:
Every framework your auditors care about - ISA/IEC 62443, the NERC CIP standards, NIST SP 800-82 - expects named individual accounts. Modern platforms remove the excuse: accounts are cheap, roles do the permission work, and login is seconds. Merobix, for example, gives every user a named account with a role (viewer, operator, manager, engineer, admin) and site-level authorization, so shift coverage never requires sharing a secret. The related discipline of reviewing who still has access belongs to your insider-threat program.
Your SCADA platform should never be able to tell you a user's password - only verify it. That is the entire design goal of password hashing: store a one-way transformation, so even a stolen database does not yield working credentials - NIST SP 800-63B requires memorized secrets to be salted and hashed with a suitable one-way key derivation function. The quality bar has moved over the years, and plenty of industrial software is still living in the past:
| Storage Method | If the Database Is Stolen | Verdict |
|---|---|---|
| Plaintext | Every credential compromised instantly | Disqualifying - walk away |
| Reversible encryption | One leaked key exposes everything | Disqualifying for passwords |
| Fast unsalted hash (MD5, SHA-1) | Cracked at scale in hours with commodity GPUs and rainbow tables | Obsolete for decades |
| Salted fast hash (SHA-256 + salt) | Slows attacks; still crackable - the algorithm is built for speed | Below the bar |
| Purpose-built slow hash (bcrypt, scrypt, Argon2) | Deliberately expensive per guess; bulk cracking becomes impractical | The modern standard |
bcrypt, scrypt, and Argon2 - the latter standardized in RFC 9106 - are engineered to be slow and (for the latter two) memory-hard, precisely so a thief with a GPU farm cannot grind through millions of guesses per second. Salting - a unique random value per password - kills precomputed-table attacks. Two vendor tests take five minutes: ask "what password hashing algorithm do you use?" and expect a named modern answer without hedging, then try the forgot-password flow - a vendor that emails you your actual password is storing it recoverably, which tells you everything. Merobix uses modern password hashing, and applies the same one-way discipline to secondary secrets: password-reset and registration tokens are stored hashed, so an intercepted database cannot mint valid reset links. The wider cryptography story - TLS, field-level encryption, blind indexes - is covered in our SCADA encryption guide.
The 90-day forced password change is the most durable piece of security folklore in industry. NIST SP 800-63B - the US government's own digital-identity guidance - recommends against mandatory periodic rotation for human passwords, because decades of evidence show what users do under forced change: Winter2025! becomes Spring2026!, passwords migrate to sticky notes, and helpdesk resets spike. Attackers know the patterns better than the policy authors.
What replaces the calendar:
Two honest caveats. Some regulations and insurer questionnaires still mandate periodic change - comply where required, and treat it as paperwork, not protection. And machine credentials are the opposite case: service accounts, API keys, and device secrets have no memory to burden, so scheduled rotation and instant revocation remain good hygiene there.
Every remote or administrative login into an industrial system should require a second factor, full stop. But the factors are not equal:
Merobix supports both tiers - TOTP MFA and FIDO2/passkeys - and adds step-up authentication for high-risk workflows: signing a permit or executing a sensitive action re-challenges the user even inside a valid session, so a hijacked browser tab is not enough to act. Since phishing is precisely how credentials get stolen in the first place, pair this section with our guide to phishing and social engineering in industrial operations, and the full authentication picture - sessions, SSO, lockout design - lives in the SCADA authentication guide.
Credential attacks are automated: password spraying (one common password against many accounts) and credential stuffing (breached email/password pairs replayed everywhere) run quietly for weeks against anything reachable. A platform defends with rate limiting, brute-force detection with account lockout that does not silently expire, and - critically - alerting, so a spray campaign shows up as a security event, not a log entry nobody reads. Merobix implements brute-force detection with persistent account lockout and flags repeated authentication failures through its runtime threat monitoring.
Sessions are credentials too. Look for: session expiry appropriate to context, concurrent-session limits, immediate revocation ("log out everywhere") when a device is lost or a phone is stolen, and administrator ability to kill any session. Merobix ships all four. A platform without session revocation turns one stolen laptop into an open door until the session naturally expires - which may be never.
Human passwords get all the attention, but an industrial platform holds far more machine secrets than human ones - and a fleet-wide shared device password is the machine version of the control-room sticky note. The bar to demand:
Most credential risk is not cracked passwords - it is credentials that outlived their purpose. Run the lifecycle deliberately:
A quarterly review that asks "does every active account belong to a current human with a current need?" catches nearly everything this article warns about - and it is the first evidence any auditor requests.
Key takeaway: Credential security in SCADA is five moves: named accounts for every human (no shared logins), passwords stored with modern slow hashing (bcrypt/Argon2 - and walk away from any vendor that can email you your password), rotation driven by events rather than calendars, MFA everywhere with phishing-resistant passkeys for privileged users, and unique, revocable, cryptographically strong credentials for every device and API integration. Merobix ships this stack as default behavior - hashing, MFA, passkeys, lockout, session revocation, per-device Ed25519 identity, scoped API keys - documented on the security page, and you can pressure-test it in a guided demo.
A shared operator login destroys accountability, immortalizes the password, and inflates privilege. When five people use one account, the audit trail cannot tell you which human changed a setpoint at 2 AM, so incident forensics dead-ends immediately. The password effectively never changes, because rotating it means coordinating everyone on shift - so it outlives departed employees and contractors who still remember it. And the shared account accumulates the union of every user's needed permissions, so a single phished credential carries plant-wide reach. Every security framework, from IEC 62443 to NERC CIP, expects named individual accounts for exactly these reasons.
Passwords should never be stored or recoverable at all - only verified. The platform should keep a salted, computationally expensive hash produced by a purpose-built algorithm such as bcrypt, scrypt, or Argon2, which are deliberately slow so that offline cracking of a stolen database is impractical at scale. Plaintext storage, reversible encryption, and fast general-purpose hashes like MD5 or SHA-1 are all disqualifying. Two quick vendor tests: ask what password hashing algorithm they use and expect a named modern answer, and use the forgot password flow - a vendor that emails your actual password is storing it recoverably, which is a red flag.
For human passwords, scheduled rotation is no longer recommended practice. NIST SP 800-63B advises against mandatory periodic changes because they push users toward predictable patterns and recycled variants, weakening security in practice. Rotate immediately on evidence or suspicion of compromise, on employee departure, and when a shared secret must be retired - otherwise favor length, screening against known-breached password lists, MFA, and lockout. Machine credentials are the opposite case: API keys, device secrets, and service accounts do not suffer human memory limits, so scheduled rotation and prompt revocation for them remains good hygiene. Note that some regulations still mandate periodic change; comply where required while strengthening the controls that do the real work.
Every device should have its own unique credential - never a fleet-wide shared secret, which turns one compromised field device into all of them. The stronger pattern is per-device cryptographic identity: Merobix registers each device uniquely with its own credentials, and devices carry device-generated Ed25519 signing keys used to sign telemetry envelopes, so the platform can verify both who sent each reading and that it was not altered or replayed. API keys used for integrations should be scoped to the minimum permissions needed, have a managed lifecycle, and be revocable individually the moment they leak or the integration is retired.
Enable multi-factor authentication on every remote and administrative login. It is the one control that keeps a stolen or phished password from becoming an intrusion on its own, and in modern platforms it costs minutes per user to enroll. Start with TOTP authenticator apps, and move high-privilege users to FIDO2 passkeys or hardware keys, which are phishing-resistant because the credential is cryptographically bound to the real site and cannot be entered on a fake login page. Close behind it: eliminate any remaining shared logins and change every default password left on PLCs, HMIs, and network gear.
Named accounts with roles, modern password hashing, TOTP and passkey MFA, brute-force lockout, session revocation, and per-device Ed25519 identity - credential security as default behavior, not a configuration project.