03.01.02OFFICIAL TITLEPENDING NIST SME REVIEW

03.01.02 — Access Enforcement

03.01 Access Control · NIST SP 800-171 Rev. 3

Independent summary of the official requirement

Requires enforcing approved authorizations for logical access to CUI and to system resources in accordance with applicable access control policies (aligned to SP 800-53 AC-3). The system's permission mechanisms must actually apply what account management authorized.

Rev. 3 requirement text is multi-part and parameterized with organization-defined values, so this site summarizes rather than reproduces it. The summary is independent — read the official publication for the binding wording.

NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI ↗

Independent interpretation

What this requirement is after

Approvals on paper mean nothing if the file share is open to Everyone. This is where permissions meet reality: NTFS ACLs, SharePoint sharing settings, application roles, and database grants have to match the authorizations you approved, and drift between the two is the finding. In small environments the usual failures are open shares, over-broad Teams and SharePoint sharing, and applications where everybody is an administrator.

Across revisions

Consolidates the enforcement halves of Rev. 2's 3.1.1 and 3.1.2: limiting access to authorized users and limiting the transactions and functions they may execute both become 'enforce approved authorizations,' with the account lifecycle carved out into 03.01.01.

Mapped practices

Brilliant at the Basics practices that support this requirement

OT-01 — OT identity and access controlOT

Partial implementation supportModerate confidence

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.

Practice-side activities

Use role separation (view, operate, engineer) where OT platforms support it
Document compensating enforcement for devices that cannot distinguish users

Evidence this produces

Role configuration exports from OT platforms that support them
Compensating-measure documentation for legacy components

Review status: Pending NIST SME review · Reviewed by Brilliant at the Basics editorial — practitioner-authored; NIST SME review pending · updated 2026-08-06

Doing the work

Implementation considerations and evidence

Implementation considerationsIndependent guidance — tailor to your environment

Pick the enforcement points that matter — CUI file shares, SharePoint and Teams, line-of-business applications — and reconcile actual permissions against approved authorizations.
Prefer group- and role-based grants over direct user grants; direct grants are where drift accumulates invisibly.
Constrain sharing features — anonymous links, organization-wide links, guest access — so a permission decision cannot be quietly overridden by a share button.

What operating evidence looks likeRecords worth retaining, not a submission checklist

Permission exports for CUI repositories reconciled against the access authorization records
Configuration showing sharing and guest-access constraints on collaboration platforms
A dated access reconciliation with discrepancies and their corrections

Suggested owners, derived from the mapped practices and artifacts: Plant / OT leader. Ownership is a named person in your organization, not a role on a website.

Artifacts

Templates and worksheets with a mapped relationship

No artifact in the library names this requirement yet. The library index groups everything by category and practice.

The other revision

Where this came from in Rev. 2

Provenance

Sources and review status

Primary sources	NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI
Review status	Pending NIST SME review
Content version	1.0
Updated	2026-08-06