This post gives hands‑on, audit-oriented steps to build a single, authoritative inventory that maps authorized users, processes acting on behalf of users, and devices—meeting the intent of FAR 52.204-21 and the CMMC 2.0 Level 1 control IA.L1-B.1.V—so a small business can demonstrate who/what is allowed, how access is granted, and where to find evidence during an assessment.
\n\nAt its core IA.L1-B.1.V requires you to know and prove which human users, non‑human processes (service accounts, automation, API clients), and devices are authorized to access your systems containing Federal contract information (FCI) or Controlled Unclassified Information (CUI) in-scope for FAR 52.204-21 and CMMC Level 1. The Compliance Framework expectation is an authoritative, auditable mapping (not just loose memory or disparate lists). Without it, auditors cannot validate access decisions and you expose your business to unauthorized access, lateral movement, and potential contract penalties or loss.
\n\nStart by defining scope: which systems, applications, and data stores are in-scope for FAR & CMMC coverage. For each entity choose authoritative unique identifiers: for users use employeeID or userPrincipalName (UPN); for devices use asset_tag, serial number, or enrollment ID from your MDM; for processes use a service-principal ID, API key label, or GUID. Consistent keys prevent duplicate records when you reconcile multiple sources.
\n\nAuthoritative sources typically include your Identity Provider (Azure AD, Okta), on‑prem AD exports, MDM (Intune, Jamf), EDR (CrowdStrike, Defender), CMDB/NAC, DHCP server logs, and your ticketing/HR system. Export CSVs or use APIs for automation. Practical examples: use PowerShell Get-ADUser -Properties employeeID,email to pull AD; az ad user list or Okta API to list cloud users; Microsoft Graph to list Intune enrolled devices; Jamf API to export Mac serials. Collect evidence timestamps (lastLogin, lastCheckin) so you can show recency during an audit.
\n\nProcesses acting on behalf of users include service accounts, scheduled tasks, CI/CD pipelines, backup jobs, OAuth client IDs, and service principals. Identify these by scanning: account names with “svc_” prefixes, long-lived credentials in secrets managers, and entries in scheduled task lists. Example: GitHub Actions using a PAT — record the GitHub App client ID, which repository, owner, and the human approver who created it. For each process record: type (service/API/automation), owner (human approver), scope of access, credential type, creation/rotation dates, and whether MFA or short-lived tokens are used.
\n\nConsolidate exports into a normalized inventory table (CSV or a small CMDB). Suggested columns: entity_id, display_name, entity_type (user/process/device), owner_employeeID, auth_method, enrolled (yes/no), asset_tag, serial_number, os, last_checkin, privileged (Y/N), authorized_resources, approval_doc_ref, evidence_export (file path/URL), and last_recon_date. Reconcile duplicates by matching serial numbers, UPNs, or employeeID. For a 15-person company you can manage this spreadsheet manually; for larger orgs automate merges with scripts (Python/pandas) pulling APIs and deduping on unique keys.
\n\nFor each mapped entry collect proof of authorization: access request ticket, signed approval email, onboarding record in HR, or role assignment snapshot from AD/Azure. For processes, attach ticket/PR approving the automation. For devices, include MDM enrollment screenshots and last compliance posture (patch level, EDR installed). Keep exports with timestamps and hash values so the auditor can see the data you used to build the inventory and when it was captured.
\n\nSmall business example: 15 employees, 10 laptops (7 Windows, 3 macOS), 5 mobile phones, an on‑prem Windows Server, and cloud resources in Azure. Practical tech stack: Azure AD (IdP), Intune (MDM), Defender/EDR, and a simple CMDB (Google Sheet or Airtable). Implementation steps: 1) Run az ad user list --query '[].{id:objectId,upn:userPrincipalName,employeeId:employeeId}' > users.json; 2) Use Microsoft Graph to export Intune device inventory including serialNumber and managedDeviceId; 3) Pull EDR host list and merge on serialNumber or hostname. Tag each device row with the primary user (assignment) and note whether it is corporate‑owned or BYOD. For service processes, list scheduled tasks on the server (Get-ScheduledTask) and document the owner account and purpose.
\n\nMake the inventory a living process: schedule daily or weekly automated reconciles and a quarterly manual access review. Implement policy items required by Compliance Framework: unique accounts (no shared user accounts), documented approvals for service accounts, credential rotation policy, and device enrollment enforcement via MDM. Configure conditional access/NAC that denies network access to devices not enrolled or failing posture checks—this both reduces risk and provides evidence you enforce device authorization.
\n\nFailure to maintain a clear mapping causes multiple risks: undetected orphaned accounts or stale service keys, unmanaged devices with missing EDR, lateral movement from unmanaged devices, and inability to quickly identify a compromised principal. From a compliance perspective, you risk failed audits, contract suspension or termination, and loss of business. In real incidents, we’ve seen adversaries exploit forgotten service accounts and unpatched BYOD endpoints to exfiltrate IP—an avoidable result of poor inventory hygiene.
\n\nKeep evidence export files with consistent filenames and timestamps, store them in an immutable location (WORM S3 bucket or secure evidence folder), and retain a change log that records who modified the inventory and why. Use tags/labels (e.g., CUI‑in‑scope = true) to quickly filter in-scope assets. Automate alerts for stale check-ins (>30 days) and orphaned service accounts. During audits provide: the consolidated CSV, source exports, screenshots of IDP/group assignments, an access review report, and your inventory reconciliation runbook.
\n\nSummary: build a scoped, authoritative inventory that uses unique identifiers; collect authoritative exports from IdP, MDM, EDR, CMDB and HR; document processes acting for users with owner and approval evidence; map devices to users and enrollment status; automate reconciliation and retain source evidence. These steps turn a compliant intent into audit-ready proof that satisfies FAR 52.204-21 and CMMC 2.0 Level 1 IA.L1-B.1.V and materially reduces security and compliance risk for small businesses.
", "plain_text": "This post gives hands‑on, audit-oriented steps to build a single, authoritative inventory that maps authorized users, processes acting on behalf of users, and devices—meeting the intent of FAR 52.204-21 and the CMMC 2.0 Level 1 control IA.L1-B.1.V—so a small business can demonstrate who/what is allowed, how access is granted, and where to find evidence during an assessment.\n\nWhy this control matters (and the compliance context)\nAt its core IA.L1-B.1.V requires you to know and prove which human users, non‑human processes (service accounts, automation, API clients), and devices are authorized to access your systems containing Federal contract information (FCI) or Controlled Unclassified Information (CUI) in-scope for FAR 52.204-21 and CMMC Level 1. The Compliance Framework expectation is an authoritative, auditable mapping (not just loose memory or disparate lists). Without it, auditors cannot validate access decisions and you expose your business to unauthorized access, lateral movement, and potential contract penalties or loss.\n\nStep-by-step: build the inventory\n1) Define scope and unique identifiers\nStart by defining scope: which systems, applications, and data stores are in-scope for FAR & CMMC coverage. For each entity choose authoritative unique identifiers: for users use employeeID or userPrincipalName (UPN); for devices use asset_tag, serial number, or enrollment ID from your MDM; for processes use a service-principal ID, API key label, or GUID. Consistent keys prevent duplicate records when you reconcile multiple sources.\n\n2) Discover data sources and collect authoritative exports\nAuthoritative sources typically include your Identity Provider (Azure AD, Okta), on‑prem AD exports, MDM (Intune, Jamf), EDR (CrowdStrike, Defender), CMDB/NAC, DHCP server logs, and your ticketing/HR system. Export CSVs or use APIs for automation. Practical examples: use PowerShell Get-ADUser -Properties employeeID,email to pull AD; az ad user list or Okta API to list cloud users; Microsoft Graph to list Intune enrolled devices; Jamf API to export Mac serials. Collect evidence timestamps (lastLogin, lastCheckin) so you can show recency during an audit.\n\n3) Map processes acting for users\nProcesses acting on behalf of users include service accounts, scheduled tasks, CI/CD pipelines, backup jobs, OAuth client IDs, and service principals. Identify these by scanning: account names with “svc_” prefixes, long-lived credentials in secrets managers, and entries in scheduled task lists. Example: GitHub Actions using a PAT — record the GitHub App client ID, which repository, owner, and the human approver who created it. For each process record: type (service/API/automation), owner (human approver), scope of access, credential type, creation/rotation dates, and whether MFA or short-lived tokens are used.\n\n4) Normalize, reconcile, and create the mapping matrix\nConsolidate exports into a normalized inventory table (CSV or a small CMDB). Suggested columns: entity_id, display_name, entity_type (user/process/device), owner_employeeID, auth_method, enrolled (yes/no), asset_tag, serial_number, os, last_checkin, privileged (Y/N), authorized_resources, approval_doc_ref, evidence_export (file path/URL), and last_recon_date. Reconcile duplicates by matching serial numbers, UPNs, or employeeID. For a 15-person company you can manage this spreadsheet manually; for larger orgs automate merges with scripts (Python/pandas) pulling APIs and deduping on unique keys.\n\n5) Verify authorization and lifecycle evidence\nFor each mapped entry collect proof of authorization: access request ticket, signed approval email, onboarding record in HR, or role assignment snapshot from AD/Azure. For processes, attach ticket/PR approving the automation. For devices, include MDM enrollment screenshots and last compliance posture (patch level, EDR installed). Keep exports with timestamps and hash values so the auditor can see the data you used to build the inventory and when it was captured.\n\nTechnical tools and concrete examples for a small business\nSmall business example: 15 employees, 10 laptops (7 Windows, 3 macOS), 5 mobile phones, an on‑prem Windows Server, and cloud resources in Azure. Practical tech stack: Azure AD (IdP), Intune (MDM), Defender/EDR, and a simple CMDB (Google Sheet or Airtable). Implementation steps: 1) Run az ad user list --query '[].{id:objectId,upn:userPrincipalName,employeeId:employeeId}' > users.json; 2) Use Microsoft Graph to export Intune device inventory including serialNumber and managedDeviceId; 3) Pull EDR host list and merge on serialNumber or hostname. Tag each device row with the primary user (assignment) and note whether it is corporate‑owned or BYOD. For service processes, list scheduled tasks on the server (Get-ScheduledTask) and document the owner account and purpose.\n\nOperationalize and remain audit-ready\nMake the inventory a living process: schedule daily or weekly automated reconciles and a quarterly manual access review. Implement policy items required by Compliance Framework: unique accounts (no shared user accounts), documented approvals for service accounts, credential rotation policy, and device enrollment enforcement via MDM. Configure conditional access/NAC that denies network access to devices not enrolled or failing posture checks—this both reduces risk and provides evidence you enforce device authorization.\n\nRisks of not implementing this mapping\nFailure to maintain a clear mapping causes multiple risks: undetected orphaned accounts or stale service keys, unmanaged devices with missing EDR, lateral movement from unmanaged devices, and inability to quickly identify a compromised principal. From a compliance perspective, you risk failed audits, contract suspension or termination, and loss of business. In real incidents, we’ve seen adversaries exploit forgotten service accounts and unpatched BYOD endpoints to exfiltrate IP—an avoidable result of poor inventory hygiene.\n\nCompliance tips and best practices\nKeep evidence export files with consistent filenames and timestamps, store them in an immutable location (WORM S3 bucket or secure evidence folder), and retain a change log that records who modified the inventory and why. Use tags/labels (e.g., CUI‑in‑scope = true) to quickly filter in-scope assets. Automate alerts for stale check-ins (>30 days) and orphaned service accounts. During audits provide: the consolidated CSV, source exports, screenshots of IDP/group assignments, an access review report, and your inventory reconciliation runbook.\n\nSummary: build a scoped, authoritative inventory that uses unique identifiers; collect authoritative exports from IdP, MDM, EDR, CMDB and HR; document processes acting for users with owner and approval evidence; map devices to users and enrollment status; automate reconciliation and retain source evidence. These steps turn a compliant intent into audit-ready proof that satisfies FAR 52.204-21 and CMMC 2.0 Level 1 IA.L1-B.1.V and materially reduces security and compliance risk for small businesses." }, "metadata": { "description": "Step-by-step guidance to create an audit-ready inventory that maps authorized users, processes acting for users, and devices to satisfy FAR 52.204-21 and CMMC 2.0 Level 1 IA.L1-B.1.V requirements.", "permalink": "/how-to-build-an-audit-ready-inventory-for-far-52204-21-cmmc-20-level-1-control-ial1-b1v-practical-steps-to-map-users-processes-acting-for-users-and-devices.json", "categories": [], "tags": [] } }