Identifying who (users), what (processes or services acting on behalf of users), and which devices access your covered contractor information systems is one of the simplest but most frequently incomplete tasks in meeting FAR 52.204-21 and CMMC 2.0 Level 1 IA.L1-B.1.V — this post gives a practical, small-business-focused implementation checklist you can execute this quarter to produce audit-ready evidence and reduce real operational risk.
\n\nYour objective under the Compliance Framework is to produce a repeatable inventory and authoritative mapping that answers three questions for each access actor: (1) Is this a human user, (2) Is this a process/service acting on behalf of a human (or another system), and (3) Which device(s) are used? The inventory must be accurate, owned, and regularly reviewed. For small organizations this typically covers Active Directory/Azure AD identities, cloud service principals, service accounts, IoT/OT devices, mobile endpoints, and contractor/third-party accounts.
\n\nList every identity provider (IdP) and identity store: on-prem AD, Azure AD, Okta, Google Workspace, AWS IAM, GitHub orgs, and any LDAP directories. Export canonical attributes for each account (username, objectGUID/UID, email, employeeID, account type, creation date, last login). For Windows AD use: Get-ADUser -Filter * -Properties whenCreated,lastLogonTimestamp,employeeID; for Azure AD use MS Graph or AzureAD PowerShell (Get-AzureADUser). Consolidate exports into a single CSV/CMDB record with an owner field and a risk tag (privileged/non-privileged/contractor/service).
\n\nEnumerate service accounts, API clients, OAuth apps, CI/CD runners, automation bots, and scheduled tasks. Query cloud tenants for service principals (Azure: Get-AzADServicePrincipal; AWS: list IAM users/roles with tags), scan repositories for PATs/secrets, and inspect job schedules (cron, Task Scheduler, Jenkins agents). Tag each as \"process-acting-for-user\" if the principal performs user-driven actions (e.g., a build agent pushing artifacts on behalf of devs) and record where secrets/keys are stored (vaulted or plaintext).
\n\nUse your MDM (Intune, Jamf), NAC solution, or endpoint management (SCCM/Endpoint Manager) to export device lists with device IDs, OS, last check-in, owner, and compliance state. For unmanaged networks, run network discovery (Nmap with service detection), SNMP sweeps, or use an agent (Wazuh, CrowdStrike) to identify IoT and legacy devices. Link devices to user accounts where possible (mobile device owner, AD logged-on user, SSH key owner) and classify device types (workstation, server, printer, IoT) for risk prioritization.
\n\nFor every recorded user/process/device assign a single owner (role or person) responsible for onboarding, offboarding, and quarterly reviews. Implement provisioning/deprovisioning workflows integrated with HR (e.g., automatic disable on termination). Ensure service accounts use centralized credential stores (Azure Key Vault, HashiCorp Vault, CyberArk) with rotation policies and that privileged accounts are MFA-protected or require jump hosts. Produce exportable evidence artifacts: CSVs from IdP, screenshots of MDM exports, service principal lists, and SIEM events showing authentication activity.
\n\nExample A — 40-person engineering shop: On-prem AD synchronized to Azure AD with Intune-managed laptops and GitHub-hosted CI. Action plan: (a) Run Get-ADUser and Get-AzureADUser exports, (b) list GitHub Actions runners and org-level secrets, (c) use Intune to export device inventory and map owner UPNs, (d) rotate all long-lived GitHub PATs and move secrets into Azure Key Vault with access policies limited to the runner's managed identity. Use a script to match device lastLogon to user lastLogin to catch orphaned devices. Evidence: AD export + Intune CSV + GitHub org audit log.
\n\nEnforce naming conventions (svc- prefix for service accounts, CON- or CTOR- for contractors), require all non-human identities to be labeled in the IdP with \"service\" and a justification, and enforce least privilege by mapping each identity to roles with narrowly defined permissions. Automate reviews: schedule a quarterly entitlement review via a workflow that emails owners a list and requires affirmation or remediation. Instrument controls: emit identity lifecycle events to your SIEM and create alerts for new high-privilege account creation or service principal consent grants. Use secrets scanners (GitGuardian, truffleHog) to find credentials accidentally checked into repositories.
\n\nWithout an accurate mapping of users, processes, and devices you face elevated risks: unauthorized access via orphaned accounts or unmanaged devices, undetected service-account misuse, lateral movement after breach, and failure to evidence controls during audits leading to contract penalties or lost bids. Small businesses often suffer the worst impact because a single privileged orphaned credential or exposed token can give attackers immediate access to proprietary data and contractor systems.
\n\nSummary: Execute this checklist by discovering all identity sources, cataloging service/process accounts, inventorying devices and mapping ownership, enforcing lifecycle controls and vaulting credentials, and producing audit-ready exports and SIEM alerts. For a small business the highest-impact quick wins are consolidating identity sources, vaulting service secrets, enabling MDM, and instituting quarterly entitlement reviews — these actions both reduce risk and directly support FAR 52.204-21 / CMMC IA.L1-B.1.V compliance.
", "plain_text": "Identifying who (users), what (processes or services acting on behalf of users), and which devices access your covered contractor information systems is one of the simplest but most frequently incomplete tasks in meeting FAR 52.204-21 and CMMC 2.0 Level 1 IA.L1-B.1.V — this post gives a practical, small-business-focused implementation checklist you can execute this quarter to produce audit-ready evidence and reduce real operational risk.\n\nScope and key objective\nYour objective under the Compliance Framework is to produce a repeatable inventory and authoritative mapping that answers three questions for each access actor: (1) Is this a human user, (2) Is this a process/service acting on behalf of a human (or another system), and (3) Which device(s) are used? The inventory must be accurate, owned, and regularly reviewed. For small organizations this typically covers Active Directory/Azure AD identities, cloud service principals, service accounts, IoT/OT devices, mobile endpoints, and contractor/third-party accounts.\n\nImplementation checklist (actionable steps)\n\n1) Discover identity sources and build an authoritative identity registry\nList every identity provider (IdP) and identity store: on-prem AD, Azure AD, Okta, Google Workspace, AWS IAM, GitHub orgs, and any LDAP directories. Export canonical attributes for each account (username, objectGUID/UID, email, employeeID, account type, creation date, last login). For Windows AD use: Get-ADUser -Filter * -Properties whenCreated,lastLogonTimestamp,employeeID; for Azure AD use MS Graph or AzureAD PowerShell (Get-AzureADUser). Consolidate exports into a single CSV/CMDB record with an owner field and a risk tag (privileged/non-privileged/contractor/service).\n\n2) Identify processes & service identities acting on behalf of users\nEnumerate service accounts, API clients, OAuth apps, CI/CD runners, automation bots, and scheduled tasks. Query cloud tenants for service principals (Azure: Get-AzADServicePrincipal; AWS: list IAM users/roles with tags), scan repositories for PATs/secrets, and inspect job schedules (cron, Task Scheduler, Jenkins agents). Tag each as \"process-acting-for-user\" if the principal performs user-driven actions (e.g., a build agent pushing artifacts on behalf of devs) and record where secrets/keys are stored (vaulted or plaintext).\n\n3) Inventory devices and map to users/processes\nUse your MDM (Intune, Jamf), NAC solution, or endpoint management (SCCM/Endpoint Manager) to export device lists with device IDs, OS, last check-in, owner, and compliance state. For unmanaged networks, run network discovery (Nmap with service detection), SNMP sweeps, or use an agent (Wazuh, CrowdStrike) to identify IoT and legacy devices. Link devices to user accounts where possible (mobile device owner, AD logged-on user, SSH key owner) and classify device types (workstation, server, printer, IoT) for risk prioritization.\n\n4) Assign ownership, implement lifecycle controls, and document evidence\nFor every recorded user/process/device assign a single owner (role or person) responsible for onboarding, offboarding, and quarterly reviews. Implement provisioning/deprovisioning workflows integrated with HR (e.g., automatic disable on termination). Ensure service accounts use centralized credential stores (Azure Key Vault, HashiCorp Vault, CyberArk) with rotation policies and that privileged accounts are MFA-protected or require jump hosts. Produce exportable evidence artifacts: CSVs from IdP, screenshots of MDM exports, service principal lists, and SIEM events showing authentication activity.\n\nTechnical details, small-business scenarios, and real-world examples\nExample A — 40-person engineering shop: On-prem AD synchronized to Azure AD with Intune-managed laptops and GitHub-hosted CI. Action plan: (a) Run Get-ADUser and Get-AzureADUser exports, (b) list GitHub Actions runners and org-level secrets, (c) use Intune to export device inventory and map owner UPNs, (d) rotate all long-lived GitHub PATs and move secrets into Azure Key Vault with access policies limited to the runner's managed identity. Use a script to match device lastLogon to user lastLogin to catch orphaned devices. Evidence: AD export + Intune CSV + GitHub org audit log.\n\nCompliance tips and best practices\nEnforce naming conventions (svc- prefix for service accounts, CON- or CTOR- for contractors), require all non-human identities to be labeled in the IdP with \"service\" and a justification, and enforce least privilege by mapping each identity to roles with narrowly defined permissions. Automate reviews: schedule a quarterly entitlement review via a workflow that emails owners a list and requires affirmation or remediation. Instrument controls: emit identity lifecycle events to your SIEM and create alerts for new high-privilege account creation or service principal consent grants. Use secrets scanners (GitGuardian, truffleHog) to find credentials accidentally checked into repositories.\n\nRisk of not implementing this requirement\nWithout an accurate mapping of users, processes, and devices you face elevated risks: unauthorized access via orphaned accounts or unmanaged devices, undetected service-account misuse, lateral movement after breach, and failure to evidence controls during audits leading to contract penalties or lost bids. Small businesses often suffer the worst impact because a single privileged orphaned credential or exposed token can give attackers immediate access to proprietary data and contractor systems.\n\nSummary: Execute this checklist by discovering all identity sources, cataloging service/process accounts, inventorying devices and mapping ownership, enforcing lifecycle controls and vaulting credentials, and producing audit-ready exports and SIEM alerts. For a small business the highest-impact quick wins are consolidating identity sources, vaulting service secrets, enabling MDM, and instituting quarterly entitlement reviews — these actions both reduce risk and directly support FAR 52.204-21 / CMMC IA.L1-B.1.V compliance." }, "metadata": { "description": "Step-by-step checklist to inventory and identify users, agent/service processes acting on behalf of users, and devices to meet FAR 52.204-21 and CMMC 2.0 Level 1 identification requirements.", "permalink": "/implementation-checklist-identifying-users-processes-acting-on-behalf-of-users-and-devices-for-far-52204-21-cmmc-20-level-1-control-ial1-b1v.json", "categories": [], "tags": [] } }