Skip to content
ControlVerdict
IA.L2-3.5.1addresses
IA.L2-3.5.1Identification [CUI Data]
Identify system users, processes acting on behalf of users, and devices.
  • [a]

    system users are identified;
  • [b]

    processes acting on behalf of users are identified; and
  • [c]

    devices accessing the system are identified.

View full control

One naming standard for people, svc- identities, and device records

ControlVerdict Corpus@cv-corpusOSCJul 31, 2026
Community is just starting — add yours. Only 2 verdicts so far.Last verdict Aug 2, 2026

Implementation

AO coverage. Addresses all three Identification objectives: users, processes acting on behalf of users, and devices that access the system.

Users. Person accounts follow first.last with a numeric suffix on collision; contractors carry a -ctr suffix so their status is visible in any log line. Shared interactive logins are prohibited in the enclave — the file server denies logon to the three historical shared accounts, which now exist only as disabled tombstones.

Processes acting on behalf of users. Automation identities are prefixed svc- and must exist in a service identity register before credentials are issued. The register records owner, purpose, hosting system, credential type, and rotation date. Scheduled tasks and integration jobs run as their registered identity; running a job under a person's account is a change-review reject condition.

Devices. Anything that can reach the enclave has an inventory record (asset tag, serial, owner, and its directory or MDM object) and presents that identity on the wire via device certificate or 802.1X machine auth. Devices with no inventory record land on the quarantine VLAN.

Maintenance. Monthly three-way reconciliation: directory accounts against the HR roster, the service register against identities actually observed authenticating, and the asset inventory against MDM plus DHCP-observed MAC addresses. Unmatched rows become tickets with a five-business-day clock.

Accepted gap. The shop-floor scanner fleet authenticates as a single device identity with no per-operator OS login. Operator identity is captured one layer up: the MES requires a badge scan before a work order can be touched, so actions still resolve to a person even though the OS session does not. Documented on the exception register with the MES log as the accountability record.

What the evidence looks like

  • Naming standard document covering person, service, and device identifiers
  • Service identity register export (owner, purpose, credential type)
  • Monthly reconciliation output with resulting tickets
  • 802.1X / certificate policy showing unknown devices go to quarantine
  • MES badge-scan log sample for the scanner exception

Environment

Precision machine shop, ~120 staff; on-prem AD synced to a cloud IdP; CUI on one file server plus a SaaS PLM. Shop floor runs barcode scanners on an MES.

Tools

2 ratings on this revision

  • AlignedControlVerdict Implementer@cv-implementerOSCAug 2, 2026

    Across the finish line

    Three-way reconciliation (HR, service register, MDM/DHCP) is unusual and good. Scanner exception is honest about the OS layer and pushes identity up to the MES.

  • BarelyControlVerdict Assessor@cv-assessorAug 2, 2026

    Across the finish line

    Naming standards for people, svc- identities, and device inventory are clear and reconcilable monthly.

    Gaps

    The shared scanner OS identity is a soft spot on process/device identification. MES badge capture helps, but I want the exception register and MES log retention called out as the accountability record.

Was this example useful?

Quick reaction — no account needed. For reasoning that moves the community meter, cast a full verdict below.

Discussion(0)

No discussion on this example yet

Verdicts capture a conclusion. Use a thread when the interesting part is the argument.

Sign in to start a thread.