Partial implementation supportModerate confidence
Why: Limiting access to authorized users is enforced at the authentication gate, and the practice hardens exactly that gate: phishing-resistant MFA enforcement plus the legacy-protocol blocking that closes the paths where weak or stolen credentials admitted unauthorized access.
What this does not claim: May partially address the requirement: 3.1.1 spans the whole account and device authorization lifecycle — whether an account should exist, whether a departed employee's access died, whether an unknown device may connect. Stronger authentication says nothing about any of that; the lifecycle and device-side work is separate and must be evaluated within the organization's defined system boundary.
Practice-side activities- Enforce MFA so that access requires a live, authorized identity rather than a reusable secret
- Block legacy authentication protocols that admit access outside modern policy enforcement
Evidence this produces- Identity-provider enforcement policy export
- Sign-in logs showing legacy-protocol access attempts denied
Review status: Pending NIST SME review · Reviewed by Brilliant at the Basics editorial — practitioner-authored; NIST SME review pending · updated 2026-08-06
DependencyModerate confidence
Why: You cannot limit access to authorized users, processes, and devices without an authoritative list of which users, processes, and devices exist. The reconciled inventory this practice maintains is the reference the requirement's enforcement and evidence are both measured against.
What this does not claim: The inventory authorizes nothing and blocks nothing at connection time — it is the precondition, not the enforcement. Account lifecycle discipline, device gating, and the authorization decisions themselves are separate work the requirement still demands.
Practice-side activities- Reconcile directory accounts and enrolled devices against personnel and asset records on a cadence
- Register service accounts and system-to-system connections with named owners
Evidence this produces- Reconciliation reports between identity stores and the inventory
- The service-account register with owner and purpose per entry
Review status: Pending NIST SME review · Reviewed by Brilliant at the Basics editorial — practitioner-authored; NIST SME review pending · updated 2026-08-06
Partial implementation supportModerate confidence
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.
Practice-side activities- Change default and vendor-set credentials during approved maintenance windows
- Establish unique accounts per individual where the platform supports it, with an inventory per system
- Remove standing vendor accounts between support engagements
Evidence this produces- Per-system account inventories with owners
- Records of default credentials changed, dated per device
Where this holds: Holds only for OT systems within the organization's CUI boundary; weakens on legacy platforms that cannot support individual accounts, where compensating measures carry the intent.
Review status: Technical review complete · Reviewed by inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering · updated 2026-08-06
