Independent DIB implementation resource — not affiliated with or endorsed by the U.S. Department of WarView the official DoW campaign ↗
3.14.7OFFICIAL STATEMENT BELOWDERIVED REQUIREMENTPENDING NIST SME REVIEW

3.14.7Unauthorized use identification

3.14 System and Information Integrity · NIST SP 800-171 Rev. 2 · The heading label is this site's navigational shorthand; the official language is the statement below.

Official requirement statement (verbatim)

Identify unauthorized use of organizational systems.

NIST SP 800-171 Rev. 2 — Protecting CUI in Nonfederal SystemsNIST SP 800-171A — Assessing Security Requirements for CUI
Independent interpretation

What this requirement is after

Unauthorized use gets identified: the account active off-hours from a strange location, the server suddenly serving a purpose nobody approved, the software nobody installed. Distinct from detecting attacks — this is detecting misuse, including by insiders.

Across revisions

Withdrawn as a standalone in Rev. 3 (03.14.07); identifying unauthorized use folds into the consolidated System Monitoring requirement, 03.14.06.

Mapped practices

Brilliant at the Basics practices that support this requirement

Partial implementation supportModerate confidence

Why: Unauthorized use in a plant looks like a connection or command with no business existing — a new device on the control network, a workstation talking to a PLC it never touched, a write from an unexpected source. Baseline-deviation monitoring is built to surface exactly that.

What this does not claim: May partially address the requirement. Separating unauthorized use from authorized-but-unusual operations takes process knowledge the sensor lacks — a contractor laptop during a shutdown may be entirely legitimate — so the practice yields candidates for review, not determinations, and identification of unauthorized use across the IT estate (accounts, applications, data access) is untouched by OT network monitoring.

Practice-side activities
  • Alert on new devices and never-before-seen conversations on OT segments
  • Review anomalies against work orders and maintenance schedules before declaring misuse
Evidence this produces
  • New-device and anomaly alerts with dispositions
  • Review records tying anomalies to authorized work, or escalating them

Where this holds: OT segments inside the assessed boundary only; the requirement's reach across business systems needs its own mechanisms.

Review status: Technical review complete · Reviewed by inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering · updated 2026-08-06

Doing the work

Implementation considerations and evidence

Implementation considerationsIndependent guidance — tailor to your environment
  • Define what authorized use looks like first — hours, locations, roles, approved software — because unauthorized is only detectable against a stated normal.
  • Leverage signals already present: sign-in risk detections, new-software reports, and anomalous-access alerts from platforms the organization already runs.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • Documented definitions or baselines of authorized use
  • Records of investigated anomalies with dispositions

Suggested owners, derived from the mapped practices and artifacts: OT engineer. 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 lands in Rev. 3

Provenance

Sources and review status

Primary sourcesNIST SP 800-171 Rev. 2 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A — Assessing Security Requirements for CUI
Review statusPending NIST SME review
Content version1.0
Updated