This post provides a practical, implementable checklist to satisfy FAR 52.204-21 and CMMC 2.0 Level 1 control IA.L1-B.1.V — "Identify Users, Processes, and Devices" — targeted to small businesses adopting the Compliance Framework practice; it explains what to record, how to technically implement identity mapping, and how to produce the evidence auditors and contracting officers expect.
Implementation checklist overview
The goal of this checklist is to create an auditable inventory and identity mapping for all accounts (human and service), processes (services and scheduled jobs), and devices (endpoints, servers, IoT) that process or store Federal Contract Information (FCI). Start by scoping: identify systems in-scope under FAR 52.204-21, then apply the checklist items below. Treat this as both a technical project (tools, configuration) and administrative work (policies, approvals, evidence retention).
Step 1 — Scope and asset inventory (what to capture)
Required items: device hostname, MAC and IP addresses, device owner, operating system and version, installed services, physical location, and whether the device handles FCI. For users: username, full name, role, authentication source (AD, Azure AD, local), account owner, last login, and access justification. For processes: service name, user or service account running it, start-up method (systemd, Windows service), and network sockets opened. Tools and commands for small businesses: use Microsoft Intune or Jamf for macOS/iOS device inventory, Microsoft Defender/EDR or osquery for endpoint inventory, and an open-source CMDB like GLPI or OCS Inventory NG. Quick commands: on Windows use 'wmic computersystem get name,domain' and 'Get-ADUser -Properties LastLogonDate' in PowerShell; on Linux use 'hostnamectl', 'ss -tulpn' and 'ps -eo user,cmd'. Export inventories to CSV with timestamps and maintain them in a version-controlled repository (e.g., a private Git repo or secured SharePoint).
Step 2 — Identify and uniquely name users, processes, and devices
Ensure unique identifiers: no shared generic accounts for administrative access, unique service accounts for critical services, and predictable device naming (e.g., SITE-ROLE-0001). Configure Active Directory/Azure AD to enforce unique sAMAccountName/UPN and disable local built-in accounts where possible. For processes, adopt service account naming conventions (svc_appname_env). Small-business example: rename "laptop-joe" to "HQ-WRK-001-JD" and create AD user "svc-payroll-prod" for payroll services, with documented owner and expiration. Disable or monitor local accounts with scripts that list local users ('net user' on Windows, 'getent passwd' on Linux) and alert on changes via scheduled jobs.
Step 3 — Enforce device and process identity (authentication methods)
Technical controls to bind identity to device and process: use machine certificates or device-managed identities (Azure AD device registration, Intune), enable TPM-backed device attestation where possible, and require endpoints to authenticate to network via NAC (Cisco ISE, Aruba, or PacketFence). For processes and services, require that services run under named service accounts with minimal privileges rather than root/Administrator. Small-business implementation: set up a simple RADIUS server (FreeRADIUS) for 802.1X wired/wireless authentication and issue machine certificates using an internal CA or cloud CA (Intune + PKI). Configure Windows Group Policy to prevent local administrator account use and enable "Require device to be marked as compliant" for Conditional Access. Document certificate issuance and revocation procedures for device identity lifecycle.
Step 4 — Logging, monitoring, and evidence collection
Capture and retain logs that prove identities and changes: Windows Security Event logs (4624, 4625, 4648), Linux auditd execve logs, and authentication logs from RADIUS/NAC. Aggregate into a central log store (Splunk, Elastic Stack, or cloud logging such as Azure Monitor) and set retention consistent with your contract and internal policy (90 days minimum for many small contracts; check specific contract clauses). Implement alerts for new accounts created, service account privilege escalations, unusual device registration, or unauthenticated devices attempting access. Provide sample evidence: CSV export of asset inventory, screenshots of AD user properties, certificate templates, and logs showing device certificate-based authentication events.
Step 5 — Policies, procedures, and regular validation
Document policies that require account uniqueness, service account approvals, device registration requirements, and deprovisioning timelines. Procedures must cover onboarding/offboarding (create user & device in inventory, assign owner, set access justification), periodic reconciliation (monthly or quarterly cross-check of AD users vs HR roster and inventory), and incident response steps when an unknown device or process is found. For small businesses, set a monthly "identity hygiene" task: run an automated script that lists inactive accounts (no logon > 90 days), orphaned devices (no heartbeat > 30 days), and unapproved services, then route exceptions to management for remediation.
Risks and consequences of not implementing IA.L1-B.1.V
Failing to identify and map users, processes, and devices increases the risk of unauthorized access, lateral movement, and data exfiltration — especially with unmanaged endpoints and shadow services. Noncompliance with FAR 52.204-21 can lead to contract disallowance, audits, and loss of future procurement opportunities. Real-world small-business scenario: a subcontractor with unmanaged IoT sensors allowed on the corporate network, later used as pivot points by attackers to access FCI — remediation costs, contract penalties, and reputational damage often exceed the cost of basic inventory and NAC controls.
Summary: implement a scoped inventory, enforce unique identifiers, adopt device and process authentication controls (certificates, MDM, NAC), centralize logs for evidence, and codify policies and periodic validation. For a small business, prioritize simple, repeatable actions: deploy an MDM, enforce AD naming and disable shared accounts, run monthly reconciliations, and collect the few key artifacts auditors want — inventory CSVs, authentication logs, and documented procedures — to demonstrate compliance with FAR 52.204-21 and CMMC 2.0 IA.L1-B.1.V.
