This post walks you through a concrete, auditable path from policy to evidence for satisfying NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control IA.L2-3.5.1 — identifying system users, processes acting on behalf of users, and devices — with practical steps a small business can implement today.
Overview: What IA.L2-3.5.1 Requires
IA.L2-3.5.1 requires organizations to uniquely identify users, processes acting on behalf of users (service accounts, automation, scripts), and devices so you can attribute actions and enforce access controls. For Compliance Framework implementations this means having documented policies, an authoritative inventory (people, accounts, devices), technical enforcement (authentication, device registry), and auditable evidence (logs, reports, review records) showing you can point to "who/what" for each action in your systems.
Step-by-Step Checklist — From Policy to Evidence
1) Policy and Scope: Create a short policy (1 page) that defines identities (human vs non-human), device types (corporate, BYOD, IoT), ownership, and acceptable authentication methods. Include scope (systems housing CUI), roles responsible (IAM owner, IT admin, CISO), and cadence for reviews. Store the policy in your compliance repository and assign a document owner and versioning metadata.
2) Build an Authoritative Inventory (People & Accounts): Maintain a single source-of-truth for users and accounts (AD/Azure AD, JumpCloud, or a CMDB). For each identity, capture: username, real name, role, business justification, account type (human/service), creation date, last activity, and owner. Use automated exports (e.g., Azure AD: az ad user list; AD: Get-ADUser -Filter * -Properties DisplayName,LastLogonDate). This inventory is a required evidence artifact.
3) Device Identification and Onboarding: Implement device enrollment (MDM/Intune/MobileIron) and a device registry in your CMDB. Ensure each device record contains hostname, MAC, asset tag, OS, device owner, enrollment ID, and compliance status. Enforce enrollment for corporate devices using 802.1X or certificate-based authentication for network access, and record the onboarding event as evidence (MDM enrollment report, NAC logs).
4) Map Processes/Service Accounts: Catalog all service accounts, automation identities, and API clients — include where they run, what privileges they have, and their credential method (managed identity, key, certificate). Require short-lived credentials or managed identities where possible (AWS IAM roles, Azure Managed Identities) and keep rotation records and permission-review evidence.
5) Logging, Correlation, and Access Reviews: Configure authentication logging to a central SIEM (syslog/CEF to Splunk/Elastic/MS Sentinel). Collect logs that map user and device identifiers to events (successful/failed auth, privilege escalations, device enrollment/unenrollment). Schedule periodic access reviews (quarterly) with sign-off records and remediation tickets exported as evidence.
Evidence Artifacts and How to Collect Them
Evidence you will produce: a) Policy document with version history; b) Exported user inventory (CSV/JSON) from authoritative IAM; c) Device registry / CMDB export; d) MDM enrollment reports; e) NAC/802.1X authentication logs tying a MAC/hostname to a username; f) Service-account inventory and credential rotation logs; g) SIEM queries and result snapshots that show authentication events; h) Signed access review spreadsheets/tickets. Store these in a read-only evidence repository with retention and hashing (SHA256) to preserve integrity.
Technical Implementation Details (Practical)
Implementations vary by environment, but common technical tasks include: enable MFA and single sign-on with SAML/OAuth (Okta/Azure AD/Google Workspace); enable device certificates and 802.1X on switches and wireless controllers; deploy MDM and require enrollment before granting access; configure NAC (e.g., Cisco ISE, Aruba ClearPass) to check device posture and produce logs that map switch port or IP to device IDs; forward authentication logs to SIEM and create searchable fields for user, src_ip, device_id, and process/service account. Example SIEM search (Splunk): index=auth sourcetype=wineventlog OR syslog user=* OR service_account=* | stats count by user, src_ip, device_id.
Small-Business Scenarios and Real-World Examples
Example A — 30-employee systems integrator: Use Azure AD for identity, Intune for device enrollment, and CrowdStrike for endpoint telemetry. Steps: enable automatic Intune enrollment for corporate Windows devices, require Azure AD join, configure Conditional Access to block sign-in from non-compliant devices, export Azure AD user and device lists monthly, and run quarterly access reviews with department heads. Evidence: Azure AD user CSV, Intune device compliance report, Conditional Access policy export, signed review spreadsheet.
Example B — 15-person engineering firm without on-prem AD: Use JumpCloud or Google Workspace for user management, manage laptops with Jamf (macOS) or Intune, and use a cloud NAC or firewall logs to associate IP/MAC to usernames. For service accounts, move ephemeral automation to GitHub Actions with OIDC tokens or cloud-managed service accounts with strict role binding and rotation logs. Evidence: JumpCloud user export, Jamf enrollment report, automation credentials audit.
Compliance Tips, Best Practices, and Acceptance Criteria
Best practices: automate discovery and exports, enforce enrollment and MFA via policy, separate human vs non-human identities, require least privilege for service accounts, and keep retention of logs aligned with organizational policy (90–365 days depending on risk). Acceptance criteria example: 100% of corporate devices enrolled in MDM; 100% of privileged/service accounts documented; quarterly access reviews completed and signed; authentication logs indexed in SIEM with at least 90 days retention. Name evidence files consistently (policy_v1_2026-04-01.pdf, users_export_2026-03-31.csv, intune_enrollment_2026-03-31.pdf) and include a metadata manifest for each audit package.
Risk of Not Implementing IA.L2-3.5.1
Failure to uniquely identify users, processes, and devices increases risk of unauthorized access, lateral movement, and inability to investigate incidents. Auditors will flag gaps in attribution, and for CUI-handling contractors this can lead to noncompliance findings, contract penalties, or loss of contract eligibility. Operationally, lack of mapping means longer incident response times and ineffective access revocation (you may disable the wrong account or miss a rogue device).
Summary: To meet IA.L2-3.5.1, adopt a simple policy, create authoritative inventories for users, service accounts, and devices, enforce enrollment and strong authentication, centralize logs in a SIEM, and produce periodic signed access reviews. For small businesses this can be achieved with cloud-native IAM/MDM/NAC tools and disciplined evidence collection — automated exports, well-named artifacts, and routine reviews will create a defensible audit trail for NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 compliance.
