Shared credentials make attribution impossible and revocation too broad, which is dangerous in OT where vendor access, engineering workstations, and device commands can all affect production. Static authentication also leaves little protection against replay, credential reuse, or stale access on systems that may run for decades. Certificate-based identity reduces those risks by binding access to specific devices and people.
Why Shared Credentials Break Trust in Brownfield OT
Brownfield OT networks often keep older controllers, engineering workstations, vendor tunnels, and maintenance paths in service for long periods, so shared credentials become a shortcut that quietly erodes accountability. When multiple people and systems use the same login, it is no longer possible to prove who issued a command, which device originated access, or whether a credential was copied into an unapproved path. That ambiguity matters more in OT because the same authenticated session can touch production state, not just information. Shared access also makes emergency revocation blunt: if one account is compromised, shutting it down can interrupt legitimate operations across plants, shifts, and suppliers. In practice, many teams discover the weakness only after they need to unwind access quickly and realise they cannot do so without disrupting operations.
Static authentication compounds the problem by leaving long-lived secrets in place after personnel changes, vendor transitions, equipment refreshes, or process changes. Brownfield environments often stretch those secrets across remote access, jump hosts, and legacy HMIs, which increases reuse and stale-authorisation risk. A better model is to bind access to the actual device or person, then reduce lifespan so compromise does not remain useful for months or years. For background on this shift, see the Ultimate Guide to NHIs — Static vs Dynamic Secrets and the OWASP Non-Human Identity Top 10.
How It Works in Practice
The core issue is that brownfield OT was usually built for continuity, not identity precision. Static passwords, shared local accounts, and vendor-maintained credentials were acceptable when the main goal was keeping equipment reachable. But once those credentials are used across multiple operators, service providers, and support tools, access becomes difficult to scope and harder to audit. The result is a trust model that assumes every holder of the secret is equally authorised, even when their task, location, or time window is different.
Operationally, this creates several failure patterns. A reused password can outlive the person who knew it. A copied secret can survive in engineering notes, scripts, backups, or remote support tooling. A shared account can make logging look complete while hiding the real actor behind the keyboard. And because OT changes are often infrequent, stale access may remain undetected until an incident, an audit, or a plant outage forces review.
- Use unique identities where the system can support them, especially for remote administration and vendor access.
- Prefer short-lived credentials or certificates over reusable passwords when equipment and tooling allow it.
- Separate human access, service access, and vendor support paths so one compromise does not expose all three.
- Preserve command-level logging and session records so access can be attributed after the fact.
Current guidance in identity security and zero trust points toward stronger binding between identity, device, and session context rather than blind reuse of a static secret. That aligns with NIST SP 800-207 Zero Trust Architecture and the Secret Sprawl Challenge.
These controls tend to break down in plants with vendor-delivered legacy equipment that cannot support per-user authentication or modern certificate workflows.
Common Variations and Edge Cases
Tighter authentication often increases operational overhead, so teams have to balance traceability against uptime and maintenance convenience. In brownfield OT, that trade-off shows up most clearly where the technology stack is mixed: some devices can support certificates or unique accounts, while others only accept a shared local login or a hard-coded service credential. Best practice is evolving here, and there is no universal standard for every legacy platform.
One common edge case is vendor support. A supplier may insist on shared access because it simplifies field service, but that convenience can create a permanent blind spot if access is not time-bound and individually attributable. Another edge case is safety or availability engineering: in some environments, replacing a shared login too quickly can disrupt validated workflows, so the safer path is often staged migration, not immediate removal. The practical test is whether the control reduces blast radius without making routine operations brittle.
The biggest mistake is treating a shared credential as harmless because the environment is “air-gapped” or “old.” OT networks usually have more exposure than they appear to, especially through remote access, engineering laptops, removable media, and adjacent IT systems. The risk rises when the same secret is valid across multiple sites or when password rotation is so disruptive that it is effectively never done. The NIST Cybersecurity Framework 2.0 remains useful here because it frames identity, access, and resilience as linked governance problems, not isolated technical tasks.
Risk and Threat Considerations
Shared credentials create a high-value trust boundary failure in OT because one secret can unlock multiple operators, multiple sessions, and sometimes multiple sites. That turns credential compromise into a broad access event rather than a single-account problem, and it weakens incident response because defenders cannot quickly separate legitimate activity from abuse.
Failure mechanism: Attackers and insiders can reuse copied passwords, exploit credential replay, or pivot through remote access paths that were never meant to be individually accountable. In brownfield environments, the same shared secret often appears in vendor support channels, scripts, and legacy access paths, which expands the attack surface and prolongs exposure after a compromise.
Impact: Unauthorized commands, production disruption, and delayed containment become more likely because responders cannot confidently revoke only the malicious access. The longer the secret remains static, the longer an attacker can retain access even after the original exposure is discovered.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63, NIST Zero Trust (SP 800-207), CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Shared and static secrets are the core exposure in brownfield OT access |
| NHI-05 — Inventory and Ownership | Brownfield OT needs clear ownership of shared and legacy access paths | |
| NHI-07 — Rotation and Revocation | Static credentials persist too long in OT and are hard to revoke selectively | |
| Recommendation — Replace shared static secrets with unique, short-lived credentials where OT systems allow it. Assign owners to every legacy OT credential and retire accounts with no accountable owner. Enforce rotation and revocation processes that can remove access without disrupting unrelated operations. | ||
| NIST SP 800-63 | AAL2 — Authentication Assurance Level 2 | Stronger authentication reduces risk from reusable shared credentials |
| Recommendation — Use multi-factor or stronger authenticators for access paths that reach OT production assets. | ||
| NIST Zero Trust (SP 800-207) | AC-4 — Information Flow Control | OT access should be constrained by session and path, not just a shared secret |
| Recommendation — Limit OT sessions to approved paths and enforce context-aware access decisions. | ||
| CIS Controls v8 | 6 — Access Control Management | The question centers on managing and revoking over-broad shared access |
| Recommendation — Remove shared accounts, scope access tightly, and review who can reach OT systems. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | Brownfield OT risk comes from weak identity attribution and static authentication |
| PR.PT — Protective Technology | Certificate-based identity and session controls are protective technologies for OT | |
| Recommendation — Strengthen identity attribution and restrict authentication methods for OT access. Deploy protective access technologies that reduce reliance on reusable static secrets. | ||
Practitioner Guidance
What to prioritise: Focus first on the credentials that can reach production systems, engineering workstations, or vendor remote access paths. If one shared secret can touch more than one zone, treat it as a blast-radius problem before it becomes a cleanup problem.
Decision rule: If a login cannot be tied to one person or one machine, it should not be the long-term access method for OT administration. Where legacy constraints prevent immediate elimination, bound the access with time windows, approved use cases, and tighter monitoring rather than leaving it as a standing exception.
What to verify: Confirm that rotation actually works without breaking validated operations, and verify that logs still show who initiated the action after the change. A control is not effective if the organisation can only enforce it on paper.
Practitioner takeaway: The real objective is not just removing passwords, but preventing any single secret from becoming an unbounded production control path that cannot be traced, narrowed, or safely revoked.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
