- Decide which device populations the organization-defined parameter covers — managed endpoints, network infrastructure, OT gateways — and write the choice down; an unexamined 'all devices' is rarely honest.
- Certificate- or platform-based device identity (802.1X, device state in conditional access policy) is the workable mechanism; MAC-address allowlists are inventory, not authentication.
- OT constraints are real: legacy controllers cannot authenticate, which should be a documented boundary-and-compensation decision, not a silent exemption.
03.05.02OFFICIAL TITLEPENDING NIST SME REVIEW
03.05.02 — Device Identification and Authentication
03.05 Identification and Authentication · NIST SP 800-171 Rev. 3
Independent summary of the official requirement
Requires uniquely identifying and authenticating organization-defined devices or types of devices before establishing a system connection.
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
Machines authenticate too. Before a device gets a connection, the network or service verifies it is a known, expected machine — so an attacker's laptop plugged into a conference-room port does not become an internal host by virtue of its location.
Across revisions
The device half of Rev. 2's 3.5.1 and 3.5.2, now standalone, with the covered devices or device types an organization-defined parameter.
Mapped practices
Brilliant at the Basics practices that support this requirement
No practice maps to this requirement — deliberately.
The campaign’s twenty practices are a priority list, not a control catalog, and none of them works this requirement’s substance directly. It still applies to you if it is in your contract’s scope: address it through your own implementation and the related artifacts below, and treat the absence of a mapping here as honesty, not permission to skip it.
Doing the work
Implementation considerations and evidence
- Device-authentication configuration — 802.1X, certificates, or device-state policy
- The documented device population the parameter covers, with owned exceptions
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 |