This post gives a practical, step-by-step checklist to identify information system users, processes acting on behalf of users (service/service accounts, automation, CI/CD agents), and devices — focused on helping small businesses meet FAR 52.204-21 and CMMC 2.0 Level 1 control IA.L1-B.1.V under a Compliance Framework.
\n\nAt Level 1 IA.L1-B.1.V you must be able to know who can access your systems, which automated processes act with user privileges, and which devices connect to or store covered federal contract information (FCI). Practically, that means building and maintaining an inventory of: user accounts (human and non-human), service/process identities (API keys, bots, CI runners, service accounts), and endpoint/device assets (laptops, servers, mobile devices, cloud instances). This inventory becomes the authoritative source used for account provisioning/deprovisioning, access reviews, and incident response.
\n\nBelow is a prioritized checklist you can implement with small-business resources; each item includes actionable steps and example commands/tools you can use immediately.
\n\nAction steps: extract authoritative lists from your identity stores (Active Directory, Azure AD/Entra, Google Workspace, AWS IAM). Export fields like username, email, group memberships, last login, account type (human vs service), and owner. Example commands: PowerShell for AD: Get-ADUser -Filter * -Properties Enabled,LastLogonDate | Select Name,SamAccountName,Enabled,LastLogonDate | Export-Csv users.csv; AWS CLI: aws iam list-users --output json. Add these to a CSV or lightweight CMDB with columns: account_id, display_name, account_type, last_login, owner, business_unit, privileged (Y/N).
Action steps: inventory non-human credentials and automation points — service accounts, API tokens, CI/CD runners, scheduled tasks, and delegated OAuth clients. Scan sources: CI systems (GitHub Actions, GitLab CI, Jenkins), cloud service principals, local service accounts (Windows services, systemd unit files), and secrets vaults (HashiCorp Vault, AWS Secrets Manager). Example detection: enable Sysmon Event ID 1 (process create) on Windows to see parent/child chains; on Linux, enable auditd rule for execve (auditctl -a always,exit -F arch=b64 -S execve -k exec_log) and use osquery to query processes for long-running agents. Document each process: name, identity used, privileges, owner, purpose, and expiration/rotation cadence for credentials.
Action steps: discover and classify devices using MDM/UEM (Intune, Jamf), endpoint detection (EDR), network discovery (Nmap, ARP-scan), and cloud inventory APIs. For small businesses: run a weekly Nmap scan for local subnets (nmap -sP 192.168.1.0/24), collect DHCP/AD records, and require device enrollment for corporate access. Track these fields in your inventory: hostname, OS, OS version, asset tag, MAC, IP, user/owner, encryption (BitLocker/FileVault), MDM status, antivirus/EDR status, last_seen. Integrate with your onboarding/offboarding procedure so device ownership is updated when staff change roles.
Action steps: centralize logs to correlate users/processes/devices — use a SIEM (ELK, Splunk, Azure Sentinel) or lightweight log aggregator (syslog server, cloud log store). Configure key sources: AD authentication logs, cloud IAM logs (AWS CloudTrail, Azure Activity), Sysmon/auditd process events, EDR telemetry, and VPN or proxy logs. Useful technical details: filter Sysmon Event ID 1 for process creation to map which service account started a process; auditd execve records show exact command-line args for Linux. Use osquery queries (e.g., select * from logged_in_users;) to validate who is actively logged on. Correlate by unique identifiers (username, device hostname, IP) and feed inventory updates automatically when last_seen > X days or account last_login > Y days.
Example 1 (50-employee services firm): They used Google Workspace for identity, 3 AWS accounts, and GitHub Actions for builds. Steps taken: exported Workspace users, enabled \"service account\" naming policy (svc-*) for CI/automation, required GitHub Actions to run under dedicated machine users with time-limited tokens, and enforced device enrollment for VPN. They used a simple Google Sheet CMDB with a script that pulls Google Workspace and AWS IAM lists nightly and flags stale accounts (no login > 90 days).
\n\nExample 2 (local MSP with mixed Windows/Linux estate): Enabled Sysmon and auditd to capture process creation, deployed osquery to collect running agents and scheduled tasks, and used Intune/Jamf to maintain device enrollment. When a rogue Jenkins job used legacy SSH keys, process logs tied the activity to the Jenkins service account and the team revoked the key and rotated credentials — preventing data extraction from a sensitive client directory.
\n\nFailure to identify users/processes/devices risks unauthorized access, undetected lateral movement, compromised automation (bots or CI/CD), and data exfiltration. From a compliance perspective, lacking this inventory can lead to audit findings, contract penalties under FAR, or loss of federal contracts. Compliance tips: enforce least privilege, implement naming conventions (human: firstname.lastname; service: svc-system-purpose), rotate all non-human credentials regularly, require multifactor authentication for user and privileged accounts, and automate periodic attestations (quarterly) where system owners verify inventory accuracy.
\n\nBest practices: integrate identity and device records into one source of truth (CMDB), automate discovery and reconciliation runs, tag cloud resources with owner and environment, and treat process identity like a first-class asset (expiration, owner, justification). For small teams, prioritize low-cost tooling: osquery + Fleet for endpoint visibility, free tiers of cloud logs, and simple scripts to export and reconcile CSVs into a shared inventory with change history.
\n\nSummary: Implementing IA.L1-B.1.V is achievable for small businesses by building a single inventory of users, service/process identities, and devices; instrumenting process and system logs (Sysmon, auditd, cloud logs); and integrating those feeds into a lightweight CMDB and review process. Regular discovery, automation, and clear operational owner responsibilities will minimize risk and keep you compliant with FAR 52.204-21 and CMMC 2.0 Level 1.
", "plain_text": "This post gives a practical, step-by-step checklist to identify information system users, processes acting on behalf of users (service/service accounts, automation, CI/CD agents), and devices — focused on helping small businesses meet FAR 52.204-21 and CMMC 2.0 Level 1 control IA.L1-B.1.V under a Compliance Framework.\n\nWhat the Control Requires\nAt Level 1 IA.L1-B.1.V you must be able to know who can access your systems, which automated processes act with user privileges, and which devices connect to or store covered federal contract information (FCI). Practically, that means building and maintaining an inventory of: user accounts (human and non-human), service/process identities (API keys, bots, CI runners, service accounts), and endpoint/device assets (laptops, servers, mobile devices, cloud instances). This inventory becomes the authoritative source used for account provisioning/deprovisioning, access reviews, and incident response.\n\nPractical Implementation Checklist\nBelow is a prioritized checklist you can implement with small-business resources; each item includes actionable steps and example commands/tools you can use immediately.\n\n1) Inventory Users and Accounts\nAction steps: extract authoritative lists from your identity stores (Active Directory, Azure AD/Entra, Google Workspace, AWS IAM). Export fields like username, email, group memberships, last login, account type (human vs service), and owner. Example commands: PowerShell for AD: Get-ADUser -Filter * -Properties Enabled,LastLogonDate | Select Name,SamAccountName,Enabled,LastLogonDate | Export-Csv users.csv; AWS CLI: aws iam list-users --output json. Add these to a CSV or lightweight CMDB with columns: account_id, display_name, account_type, last_login, owner, business_unit, privileged (Y/N).\n\n2) Identify Processes Acting on Behalf of Users\nAction steps: inventory non-human credentials and automation points — service accounts, API tokens, CI/CD runners, scheduled tasks, and delegated OAuth clients. Scan sources: CI systems (GitHub Actions, GitLab CI, Jenkins), cloud service principals, local service accounts (Windows services, systemd unit files), and secrets vaults (HashiCorp Vault, AWS Secrets Manager). Example detection: enable Sysmon Event ID 1 (process create) on Windows to see parent/child chains; on Linux, enable auditd rule for execve (auditctl -a always,exit -F arch=b64 -S execve -k exec_log) and use osquery to query processes for long-running agents. Document each process: name, identity used, privileges, owner, purpose, and expiration/rotation cadence for credentials.\n\n3) Inventory and Manage Devices\nAction steps: discover and classify devices using MDM/UEM (Intune, Jamf), endpoint detection (EDR), network discovery (Nmap, ARP-scan), and cloud inventory APIs. For small businesses: run a weekly Nmap scan for local subnets (nmap -sP 192.168.1.0/24), collect DHCP/AD records, and require device enrollment for corporate access. Track these fields in your inventory: hostname, OS, OS version, asset tag, MAC, IP, user/owner, encryption (BitLocker/FileVault), MDM status, antivirus/EDR status, last_seen. Integrate with your onboarding/offboarding procedure so device ownership is updated when staff change roles.\n\n4) Logging, Correlation, and Technical Controls\nAction steps: centralize logs to correlate users/processes/devices — use a SIEM (ELK, Splunk, Azure Sentinel) or lightweight log aggregator (syslog server, cloud log store). Configure key sources: AD authentication logs, cloud IAM logs (AWS CloudTrail, Azure Activity), Sysmon/auditd process events, EDR telemetry, and VPN or proxy logs. Useful technical details: filter Sysmon Event ID 1 for process creation to map which service account started a process; auditd execve records show exact command-line args for Linux. Use osquery queries (e.g., select * from logged_in_users;) to validate who is actively logged on. Correlate by unique identifiers (username, device hostname, IP) and feed inventory updates automatically when last_seen > X days or account last_login > Y days.\n\nReal-world Examples and Small-Business Scenarios\nExample 1 (50-employee services firm): They used Google Workspace for identity, 3 AWS accounts, and GitHub Actions for builds. Steps taken: exported Workspace users, enabled \"service account\" naming policy (svc-*) for CI/automation, required GitHub Actions to run under dedicated machine users with time-limited tokens, and enforced device enrollment for VPN. They used a simple Google Sheet CMDB with a script that pulls Google Workspace and AWS IAM lists nightly and flags stale accounts (no login > 90 days).\n\nExample 2 (local MSP with mixed Windows/Linux estate): Enabled Sysmon and auditd to capture process creation, deployed osquery to collect running agents and scheduled tasks, and used Intune/Jamf to maintain device enrollment. When a rogue Jenkins job used legacy SSH keys, process logs tied the activity to the Jenkins service account and the team revoked the key and rotated credentials — preventing data extraction from a sensitive client directory.\n\nRisks of Not Implementing the Requirement and Compliance Tips\nFailure to identify users/processes/devices risks unauthorized access, undetected lateral movement, compromised automation (bots or CI/CD), and data exfiltration. From a compliance perspective, lacking this inventory can lead to audit findings, contract penalties under FAR, or loss of federal contracts. Compliance tips: enforce least privilege, implement naming conventions (human: firstname.lastname; service: svc-system-purpose), rotate all non-human credentials regularly, require multifactor authentication for user and privileged accounts, and automate periodic attestations (quarterly) where system owners verify inventory accuracy.\n\nBest practices: integrate identity and device records into one source of truth (CMDB), automate discovery and reconciliation runs, tag cloud resources with owner and environment, and treat process identity like a first-class asset (expiration, owner, justification). For small teams, prioritize low-cost tooling: osquery + Fleet for endpoint visibility, free tiers of cloud logs, and simple scripts to export and reconcile CSVs into a shared inventory with change history.\n\nSummary: Implementing IA.L1-B.1.V is achievable for small businesses by building a single inventory of users, service/process identities, and devices; instrumenting process and system logs (Sysmon, auditd, cloud logs); and integrating those feeds into a lightweight CMDB and review process. Regular discovery, automation, and clear operational owner responsibilities will minimize risk and keep you compliant with FAR 52.204-21 and CMMC 2.0 Level 1." }, "metadata": { "description": "A concise, practical checklist to inventory and identify all users, service processes acting on their behalf, and devices to meet FAR 52.204-21 / CMMC 2.0 Level 1 IA.L1-B.1.V requirements for small and midsize organizations.", "permalink": "/practical-checklist-identify-information-system-users-processes-acting-on-behalf-of-users-and-devices-for-far-52204-21-cmmc-20-level-1-control-ial1-b1v.json", "categories": [], "tags": [] } }