Meeting FAR 52.204-21 and the CMMC 2.0 Level 1 control IA.L1-B.1.V requires that you can reliably identify who (user), what (process), and what device is interacting with your information systems—this post gives a practical, step-by-step implementation guide tailored for small businesses that must demonstrate basic cyber hygiene for handling government information.
Why identification matters and the compliance context
CMMC 2.0 Level 1 and FAR 52.204-21 focus on “basic cyber hygiene.” The IA.L1-B.1.V control specifically expects organizations to identify and track users, processes acting on behalf of users, and devices before granting access or recording activity. For a small business, that means no shared generic accounts for business-critical systems, an inventory of devices that connect to systems containing Controlled Unclassified Information (CUI), and visibility into service/process identities that perform automated actions. Without these controls you cannot provide audit trails, enforce least privilege, or detect misuse—opening you to contract noncompliance, data loss, and lateral attacker movement.
Step 1 — Scope and inventory (the foundation)
Start by scoping systems that process or store CUI and related contractor information. Build an asset inventory that records: user accounts and unique IDs, device identifiers (MAC address, hardware UUID, serial, MDM enrollment ID), and known service/process accounts (e.g., "backup-agent", "svc-db-sync"). For a small business (10–50 seats) use a simple spreadsheet or a lightweight CMDB (AssetTiger, GLPI) that includes: hostname, OS, last-known user, enrollment state, and purpose. Tag assets with "CUI_access" to prioritize protection and monitoring.
Step 2 — Policy and identity model
Create a short Identification Policy that defines: unique user identifiers (no shared logins for people), naming conventions for service/process accounts, device enrollment requirements, and account lifecycle processes (onboarding, inactivity, offboarding). Map these to Compliance Framework practices: tie each policy item back to IA.L1-B.1.V so assessors can trace how the policy enforces identification. Example policy points: require unique user IDs, require machine certificates or MDM enrollment for devices accessing CUI, and ban shared administrative accounts for day-to-day work.
Step 3 — Implement user identification and authentication
Adopt a centralized identity provider where possible: Active Directory (on-prem or Azure AD), Okta, or Google Workspace. Enforce unique user accounts, enable MFA for all accounts with access to CUI systems, and implement password policies (e.g., minimum length 12, passphrases preferred). Disable/deny creation of local shared accounts on endpoints; use RDP/SSH jump servers or privileged access workstations for admin tasks. For Linux servers, use centralized authentication (LDAP/AD) and configure sudoers so actions are logged with the operator's username. Keep a log of account creation/termination dates for auditability.
Step 4 — Identify and control processes and service accounts
Service and automated processes must be identifiable and scoped to least privilege. Provide each automated function a dedicated service account or machine identity rather than using shared root/admin credentials. For example, your nightly backup job should run under "svc-backup@yourdomain" with only the minimal privileges needed and keys/certificates stored in a secrets manager (HashiCorp Vault, AWS Secrets Manager, or stored securely in an on-prem HSM). Ensure system/process logs include process ID (PID), service account name, and command line; enable syslog or Windows Event forwarding to a centralized log collector so you can trace which process performed sensitive operations.
Step 5 — Device identification and enrollment
Bring devices under management: use an MDM (Microsoft Intune, Jamf, or a lightweight solution like ManageEngine) or enforce enrollment via certificates (SCEP / device certs). Enrolled devices get unique machine identities (X.509 certificates) and can be associated to users. For network-level control, implement 802.1X with RADIUS for wired/wireless access or a NAC solution to enforce that only compliant, enrolled devices access segments containing CUI. For smaller firms, enforce MDM + VPN with certificate-based machine authentication and split-tunnel restrictions to reduce exposure.
Step 6 — Logging, detection and periodic validation
Produce logs that show user ID, process identity, device identifier, timestamp, and action for sensitive events (login, file access to CUI, privilege escalation). Ship logs to a centralized system (SIEM or cloud-native logs) and configure alerting for anomalies: multiple logins from a new device, service accounts initiating interactive logins, or unknown devices accessing CUI resources. Schedule quarterly reviews: account recertification, device inventory reconciliation (MDM vs DHCP logs), and review of service accounts. Maintain a simple audit checklist mapping controls to evidence (policies, logs, MDM reports) for FAR/CMMC assessment.
Real-world small-business example
Consider a 25-person subcontractor building software for a DoD prime. Implementation steps they used: enroll all laptops in Microsoft Intune, connect devices to Azure AD, require MFA using Microsoft Authenticator, create service accounts for CI/CD pipelines stored in Azure Key Vault, and enable Microsoft Defender for Endpoint to collect process-level telemetry. They tagged systems that handle CUI and used Conditional Access to permit only Azure AD–joined or compliant devices. During their FAR 52.204-21 self-attestation, they produced the device inventory, Intune enrollment report, and sign-in logs linking user accounts and device IDs to demonstrate IA.L1-B.1.V compliance.
Risks, tips and best practices
Risks of not implementing identification controls include undiscoverable misuse (shared accounts), ransomware spread via unmanaged devices, failed audits and lost contracts, and inability to demonstrate who or what performed actions on systems. Best practices: never use shared human accounts, separate administrative accounts from day-to-day accounts, rotate and protect service credentials in a secrets manager, require device enrollment/certificates for CUI access, and run periodic account/device reconciliation. Small businesses should automate as much evidence collection as possible (MDM reports, sign-in logs, exportable audit reports) to reduce assessment overhead.
In summary, implementing IA.L1-B.1.V requires building an inventory, formalizing identification policy, enforcing unique user and device identities, assigning and limiting service/process accounts, and centralizing logs for traceability—each step should be sized for a small business, leveraging affordable MDM, centralized identity, and secrets management to demonstrate compliance with FAR 52.204-21 and CMMC 2.0 Level 1 while reducing operational risk.
