Independent DIB implementation resource — not affiliated with or endorsed by the U.S. Department of WarView the official DoW campaign ↗
OT-01OPERATIONAL TECHNOLOGYOFFICIAL INTENTEXPERT REVIEWED

Identity and Access Control

OT access is often shared logins, default passwords, and standing vendor accounts nobody tracks. Bringing identity and access control to production means unique accountability, least privilege, controlled use of engineering functions, and removing the generic and default credentials attackers look for first — done in a way that never blocks a safe, timely operator action.

EXPLAINER · 5 SCENES · ≈40 SEC · CAPTIONS, NO AUDIO

OT-01 in 40 seconds

The problem, the plain-words meaning, three key moves, and what “done” looks like.

Official intent

What the campaign asks for

Know and limit who — and what — can access and change production systems. The official source remains authoritative.

Read the official campaign ↗

Why it matters

If everyone shares one login, you cannot tell who made a change or stop a compromised credential. Default and vendor accounts are among the most common OT footholds. Controlling access limits both malicious action and honest mistakes on systems where a wrong command has physical, sometimes safety-critical, consequences.

Coordinate before touching production

Access changes on production systems can lock out operators when they need control most. Never remove or alter credentials on a live system without the process owner's agreement, a tested rollback, and break-glass access that works during a network or identity outage. Prioritize safety and availability over tidy identity design.

Minimum / Strong / Advanced

1
Minimum

Default passwords are changed, generic shared logins are inventoried, and vendor/standing accounts are known and controlled.

2
Strong

Individuals have unique, least-privilege access; engineering/administrative functions are restricted; and access is reviewed on a schedule.

3
Advanced

Access is centrally managed with MFA where the environment supports it, privileged actions are logged, and joiners/movers/leavers are handled promptly — with break-glass preserved.

Implementation timeline

First 24 hours
  • Find default and vendor-set passwords on reachable devices
  • List every shared/generic login in use
Next 30 days
  • Change safe-to-change default credentials in a maintenance window
  • Confirm break-glass access exists and is tested
Next 60 days
  • Assign unique accounts and least privilege where feasible
  • Restrict engineering functions to authorized staff
By day 90
  • Review vendor and standing accounts; disable the unneeded
  • Set a recurring access review tied to change control

Implementation steps

  1. Inventory who and what can access each production system, including vendor and shared accounts.
  2. With the process owner, change default and vendor-set passwords within maintenance windows.
  3. Move toward unique, least-privilege accounts so actions are attributable and over-access is removed.
  4. Restrict engineering and administrative functions to authorized personnel and log their use.
  5. Establish and test break-glass access, then review accounts on a schedule tied to change control.

Validation

  • Pick a production device and confirm it no longer uses a default or vendor-set password.
  • Verify break-glass access works with the identity system or network unavailable.
  • Review the account list for shared logins and disabled-but-not-removed vendor accounts.

Evidence to retain

Governance

OT access-control policy including vendor and break-glass procedures

Configuration

Account inventory and privilege assignments per system

Operations

Maintenance-window change records for credential changes

Validation

Access-review sign-off and break-glass test results

Common failure modes

What looks done but is not

Changing a password and breaking an automated process that used it, leaving a vendor's standing account active between visits, and adding MFA that locks operators out during an outage. Attribution without safe recovery is not access control.

Framework mappings

Independent mappings are aids, not authoritative equivalence or compliance determinations.

FrameworkRequirementRelationshipConfidence
NIST SP 800-82 Rev. 3AC (ICS overlay)DirectHigh
NIST SP 800-1713.1.5SupportingModerate
NIST CSF 2.0PR.AA-05DirectModerate