Official intent
Know and limit who — and what — can access and change production systems. The official source remains authoritative.
Read the official campaign ↗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.
Who this applies to: Every environment with programmable controllers, HMIs, historians, or engineering workstations — including small plants where 'the password is on the label' is the current design.
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.
Risks this reduces
- Default and vendor-set credentials that are published in product manuals
- Shared logins that make any change unattributable
- Standing vendor accounts that stay live between support visits
- Unrestricted access to engineering functions that can alter control logic
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.
Who owns it
Plant / OT leader
OT engineer, Identity administrator, Vendors
Medium
Medium
Ownership is a named person, not a department. If nobody can be named, that is the first finding.
Dependencies and prerequisites
Leans on: OT-02 — Validated OT asset inventory
- A validated OT asset inventory, so you know what has credentials at all
- The process owner's agreement to make credential changes, and a maintenance window
- A tested break-glass path that works with the identity system or network unavailable
Action timeline
- Find default and vendor-set passwords on reachable devices
- List every shared/generic login in use
- Change the default and vendor-set passwords you can safely change in the next approved maintenance window
- Confirm break-glass access exists, is documented, and has been tested against an identity or network outage
- Change safe-to-change default credentials in a maintenance window
- Confirm break-glass access exists and is tested
- Assign unique accounts and least privilege where feasible
- Restrict engineering functions to authorized staff
- Review vendor and standing accounts; disable the unneeded
- Set a recurring access review tied to change control
The 90-day target for this practice is the Measured level below: coverage and effectiveness are reported, and exceptions are handled rather than accumulated.
Step-by-step implementation
- Inventory who and what can access each production system, including vendor and shared accounts.
- With the process owner, change default and vendor-set passwords within maintenance windows.
- Move toward unique, least-privilege accounts so actions are attributable and over-access is removed.
- Restrict engineering and administrative functions to authorized personnel and log their use.
- Establish and test break-glass access, then review accounts on a schedule tied to change control.
What good looks like
Seven levels, used identically across every practice, scorecard, and download on this site. The distinction that matters most is between having a tool, deploying it to the correct scope, and operating it consistently.
- Absent
Shared logins and default passwords; nobody can say who changed what.
Is there anything at all — a tool, a document, a person who owns it? - Documented
An OT access policy exists covering vendor accounts, shared logins, and break-glass, with an owner.
Is the intent written down, with a named owner and a scope? - Configured
Default credentials are changed on the devices where it is safe, and account inventories exist per system.
Is it switched on and set up somewhere — even if only in part of the estate? - Deployed
Individuals hold unique, least-privilege access where the platform supports it; engineering functions are restricted to authorized staff.
Does it cover everything in scope, with the exceptions written down? - Measured
Shared logins, standing vendor accounts, and privileged-action logs are reviewed and counted on a cadence.
Can you state a number for coverage or effectiveness, and show the trend? - Governed
Access review is tied to change control, ownership is named, and the review record is retained as evidence.
Is there an accountable owner, a review cadence, and retained evidence?
Validation procedures
Until these pass, the practice is configured — not deployed.
- 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
OT access-control policy including vendor and break-glass procedures
Account inventory and privilege assignments per system
Maintenance-window change records for credential changes
Access-review sign-off and break-glass test results
Retaining these supports your own assurance and gives a reviewer something concrete to examine. It does not constitute an assessment or satisfy a contractual requirement on its own.
Operating metrics
| Metric | How it is calculated | Directional target |
|---|---|---|
| Devices on default credentials | Inventoried OT devices still using vendor-set or default passwords. | Zero where the vendor supports a change; the remainder documented with compensating controls. |
| Standing vendor accounts | Vendor accounts enabled outside an active engagement. | Zero. |
| Break-glass test currency | Days since break-glass access was last successfully tested. | Within the interval the plant agreed, and never unknown. |
Targets are directional guidance for your own programme, not compliance thresholds.
Common failure modes
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.
Two sized paths
Start with a list of every account on every OT device, then close the two things that matter most: default passwords and vendor accounts left enabled. Unique named accounts on every HMI can wait; knowing who can reach production, and removing the credentials that are published in a manual, cannot.
Bring OT accounts under central management with strong authentication where the platform tolerates it, log and review privileged actions, provision vendor access per engagement, and hold access review to the same cadence as change review — while keeping break-glass genuinely independent of the systems it must survive.
Tool categories
Categories, not recommendations. This site ranks no vendors and accepts no paid placement.
A password change can break an automated process or an integration that used it. Identify every consumer of a credential before changing it, schedule inside an approved window with the process owner present, keep a rollback, and never change break-glass and production credentials in the same window.
Framework mappings
Independent mappings are aids to your own analysis — not authoritative equivalence, not coverage, and not a compliance determination. Read the caveat on every row before using it.
Why: The OT overlay tailors the access control family for environments where availability and safe operator action outrank tidy identity design.
What this does not claim: 800-82 is guidance, not a compliance standard. Applying it is good engineering, not an obligation in itself. Pinpointing individual overlay controls is part of the pending SME pass.
Why: The identification and authentication system requirements cover human and software-process accounts and authenticator management in control systems.
What this does not claim: IEC 62443 is a voluntary industrial standard; conformance is a separate, scoped exercise. The specific requirement identifiers are pending verification against the licensed normative text and should be treated as directional until that check completes.
Why: The identity management and access permission outcomes describe this practice's intent.
What this does not claim: The CSF describes outcomes, not testable controls.
Method: Read against the primary source text, then classified by relationship type and confidence. No automated mapping tool was used. How mappings are made →
NIST SP 800-171 relationships have their own requirement-level section below, with links into the full mapping experience.
Related NIST SP 800-171 requirements
Requirement-level relationships from the site’s independent 800-171 mapping. Each one names what it does and does not claim — a practice supports implementation of a requirement; it never satisfies one by itself. Expand a row for the rationale and caveat.
NIST SP 800-171 Rev. 2
3.1.1Authorized access controlPartial implementation supportModerate
Why: Replacing default and shared credentials with unique, owned accounts on controllers, HMIs, and engineering workstations is limiting system access to authorized users — applied to the equipment where that discipline is most often absent.
What this does not claim: This mapping applies only to OT components that process, store, or transmit CUI, or that provide security protection for those components — organizational scoping determines applicability. Even where it applies, the practice covers the OT estate only: the IT side of 3.1.1, including corporate account lifecycle and device gating, is untouched by it.
Review status: Technical review complete.
Open the 3.1.1 page →3.1.2Transaction and function controlPartial implementation supportModerate
Why: Restricting engineering functions — the ability to alter control logic — to authorized staff is limiting the types of functions authorized users may execute, which is this requirement's substance applied to production systems.
What this does not claim: Applies only to OT systems inside the CUI boundary, and only to the function classes OT platforms expose; many legacy controllers cannot distinguish operator from engineer at all, leaving physical and procedural limits to carry the intent. Transaction and function limits across business applications and file systems are entirely outside this practice.
Review status: Pending NIST SME review.
Open the 3.1.2 page →3.1.5Least privilegePartial implementation supportModerate
Why: Individual least-privilege access on OT platforms, engineering functions held to authorized staff, and standing vendor accounts driven to zero are the principle of least privilege enacted on production systems.
What this does not claim: Holds only for OT systems inside the CUI boundary. The requirement's weight in most assessments falls on the IT estate — privileged account separation, security function restriction, admin group review — none of which this OT-focused practice performs; those need their own implementation and evidence.
Review status: Technical review complete.
Open the 3.1.5 page →NIST SP 800-171 Rev. 3
03.01.01Account ManagementDirect implementation supportHigh
Why: The practice's core activity — knowing and limiting who can touch production systems — is account management applied to the OT estate: named users, authorized accounts, and removal when access is no longer needed are the shared substance.
What this does not claim: Supports implementation of the requirement for OT scope only, and OT reality bends the mechanics: shared HMI operator accounts may be unavoidable for line operations, vendor accounts may be contractually managed, and disablement clocks must respect systems that cannot be touched mid-run. Each deviation needs documentation and a compensating measure, and the IT estate's accounts sit outside this practice entirely.
Review status: Pending NIST SME review.
Open the 03.01.01 page →03.01.02Access EnforcementPartial implementation supportModerate
Why: Limiting what each identity may do on production systems — operator versus engineer versus vendor — is authorization enforcement on the assets the practice covers.
What this does not claim: Many OT components cannot enforce per-user authorization at all: legacy controllers with one shared password, HMIs without role support. Where the device cannot enforce, enforcement moves to compensating layers — physical access, network position, supervised sessions — and those must be documented as the enforcement mechanism rather than assumed. Enterprise-side enforcement is outside the practice's scope.
Review status: Pending NIST SME review.
Open the 03.01.02 page →03.01.05Least PrivilegePartial implementation supportModerate
Why: Restricting production access to the people whose tasks require it is least privilege exercised on the OT estate — the practice's limiting function is the requirement's principle in that scope.
What this does not claim: The requirement adds machinery beyond limiting: explicit authorization for security functions and a privilege review on a defined cadence, which OT programs rarely run unprompted. Uptime pressure also pushes toward broad standing access for on-call engineers; that trade has to be documented and reviewed rather than silently accepted.
Review status: Pending NIST SME review.
Open the 03.01.05 page →03.01.06Least Privilege — Privileged AccountsPartial implementation supportModerate
Why: Keeping controller configuration and safety-system access behind a small set of named privileged identities is this requirement's restriction of privileged accounts, applied where its failure hurts most.
What this does not claim: The requirement's second half — privileged users switching to non-privileged accounts for nonsecurity work — collides with the shared consoles and always-logged-on HMIs common in plants; where the pattern cannot hold, the deviation needs a documented compensating measure such as dedicated engineering workstations. Privileged accounts on the IT estate are separate work the practice does not reach.
Review status: Pending NIST SME review.
Open the 03.01.06 page →Review status
| Technical review | Reviewed — pending SME sign-off |
|---|---|
| Editorial review | Reviewed |
| Reviewed by | inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering |
| Last reviewed | |
| Official source verified | |
| Content version | 1.1 |
This guide has been reviewed by practitioners but is awaiting sign-off from a subject-matter expert in this specific domain. Treat the safety and change-control guidance as a floor, not a ceiling, and validate it against your own process and vendor requirements.