{
  "title": "How to Create an Evidence-Ready Checklist for FAR 52.204-21 / CMMC 2.0 Level 1 - Control - IA.L1-B.1.V: Users, Processes, and Devices",
  "date": "2026-04-06",
  "author": "Lakeridge Technologies",
  "featured_image": "/assets/images/blog/2026/4/how-to-create-an-evidence-ready-checklist-for-far-52204-21-cmmc-20-level-1-control-ial1-b1v-users-processes-and-devices.jpg",
  "content": {
    "full_html": "<p>This blog post walks through creating an evidence-ready checklist for FAR 52.204-21 / CMMC 2.0 Level 1 control IA.L1-B.1.V — the requirement to identify and authenticate users, processes, and devices — with practical implementation steps tailored for organizations following the Compliance Framework and actionable examples for a small business.</p>\n\n<h2>Understanding IA.L1-B.1.V and the Compliance Framework context</h2>\n<p>IA.L1-B.1.V expects covered contractors to ensure that only identified and authenticated users, processes, and devices can access systems that store or process Federal Contract Information (FCI) or Controlled Unclassified Information (CUI). Under the Compliance Framework this maps to basic identity and authentication controls: unique user IDs, account provisioning/deprovisioning, device identification and inventory, and evidence that authentication checks are enforced before granting access. For small businesses, Level 1 is about implementing practical, demonstrable controls rather than enterprise-only solutions.</p>\n\n<h3>Key objectives to show in evidence</h3>\n<p>When building your checklist, capture these key objectives as discrete evidence points: (1) every human user has a unique identifier, (2) service and system processes are accounted for and use separate non-human identities, (3) devices that connect to contractor networks are inventoried and validated, (4) authentication mechanisms are enforced (passwords, MFA where feasible), and (5) access changes are tracked (onboarding, role changes, offboarding). Each objective should map to one or more artifacts in your evidence repository.</p>\n\n<h3>What concrete evidence looks like</h3>\n<p>Concrete evidence items to collect and retain: exported user lists (CSV/PDF) from Active Directory/Azure AD with creation/last-logon timestamps; onboarding/offboarding tickets or signed access request forms; screenshots or exported group policy settings showing password complexity and account lockout policies; MFA enrollment and sign-in log exports (e.g., Azure AD sign-in logs); device inventory lists with serial/MAC addresses and owner fields; MDM/NAC enrollment reports (Intune/Jamf/NAC logs); privileged account inventory and justification docs; and sampled authentication logs showing successful and failed auth attempts. Store each artifact with a descriptive filename, date, and retention metadata in your Compliance Framework evidence repository (SharePoint, secured cloud bucket, or GRC tool).</p>\n\n<h2>Step-by-step evidence-ready checklist (practical)</h2>\n<p>Use the following checklist as a template. Each item should have an owner, expected artifact type, and retention policy. Sample checklist entries: 1) Maintain a current user account inventory (Owner: IT Manager; Artifact: users_export_YYYYMMDD.csv). 2) Document account provisioning workflow and approved access request form (Artifact: onboarding_form.pdf + ticketing ID). 3) Enforce unique IDs — disable shared/local generic accounts and document exceptions (Artifact: shared_accounts_report.pdf). 4) Publish password policy and capture GPO/tenant policy settings (Artifact: gpo_password_policy_screenshot.png). 5) Enroll devices in MDM/NAC and export enrollment report weekly (Artifact: intune_device_report_YYYYMMDD.csv). 6) Maintain service/process account inventory and access justification (Artifact: service_accounts.xlsx). 7) Keep authentication logs for the contractually required retention period and a sample of recent logs (Artifact: azure_signins_YYYYMM.csv). 8) Document offboarding checklist and sampled closed tickets showing account disablement within SLA (Artifact: offboard_ticket_12345.pdf).</p>\n\n<h2>Implementation guidance for a small business scenario</h2>\n<p>Scenario: a 25-person subcontractor uses Microsoft 365, Azure AD, Intune for endpoints, and a single on-prem Windows server for engineering tools. Practical steps: use Azure AD as the authoritative identity store and enable unique user accounts for everyone; enable MFA for privileged users and for external access; enforce conditional access policies limiting access to compliant (Intune-enrolled) devices; configure Intune to require device enrollment, full-disk encryption, and a PIN; disable local Administrator shared accounts on endpoints and replace with documented, time-limited service accounts where necessary. For evidence, schedule a monthly extraction of Azure AD users (PowerShell script), Intune device export, and a GPO/endpoint configuration snapshot stored in your evidence repository. Assign the IT Manager to reconcile HR’s new-hire list weekly with Azure AD to prove provisioning consistency.</p>\n\n<h3>Technical examples and commands</h3>\n<p>Example commands to produce evidence quickly: - Export Azure AD users: Connect-AzureAD; Get-AzureADUser -All $true | Select DisplayName,UserPrincipalName,AccountEnabled,CreationDate | Export-Csv users_export_YYYYMMDD.csv - Export Intune devices: Use Microsoft Graph or Intune portal export to CSV; sample Graph PowerShell snippet: Get-MgDeviceManagementManagedDevice | Export-Csv intune_device_report_YYYYMMDD.csv - Export local Windows accounts inventory: wmic useraccount get name,sid,enabled > local_users_YYYYMMDD.txt - Sample Linux user last login: lastlog -u username. Capture screenshots of policy settings (GPO or Azure AD conditional access), and include hashes or checksum metadata for each exported evidence file to demonstrate integrity.</p>\n\n<h2>Compliance tips, best practices, and pitfalls to avoid</h2>\n<p>Tips: (1) Automate exports and retention — schedule scripts to push artifacts into your evidence repository with standardized filenames and metadata. (2) Map evidence to control objectives in a simple traceability matrix (Control → Evidence file(s) → Owner → Refresh cadence). (3) Use least privilege and document privileged role assignments and periodic reviews. (4) Treat device identity as first-class — require enrollment for access to corporate resources and keep a reconciliation process between asset management and identity systems. Pitfalls: relying solely on manual checklists without sampled logs, keeping evidence only in email, or failing to remove access promptly during offboarding (these are common audit findings).</p>\n\n<h2>Risk of not implementing IA.L1-B.1.V properly</h2>\n<p>Failure to identify and authenticate users, processes, and devices increases risk of unauthorized access, data exfiltration, lateral movement by attackers, and compromise of FCI/CUI. For contractors this can mean contract penalties, loss of contract, failing a CMMC assessment or FAR audit, and reputational damage. From a practical standpoint, lacking evidence of routine provisioning and deprovisioning invites findings during compliance reviews — even if controls are informally in place, absent artifacts are treated as noncompliance.</p>\n\n<p>Summary: Build a concise, repeatable evidence checklist tied to IA.L1-B.1.V that includes user and device inventories, onboarding/offboarding records, authentication policy snapshots, MFA/enrollment reports, and sampled logs. Automate exports, assign clear owners, and store artifacts in a centralized evidence repository with naming and retention metadata. For small businesses, focus on demonstrable, low-cost controls (Azure AD/Intune, ticketing records, GPO screenshots) that map directly to Compliance Framework objectives — this approach minimizes risk and creates a defensible position for audits and assessments.</p>",
    "plain_text": "This blog post walks through creating an evidence-ready checklist for FAR 52.204-21 / CMMC 2.0 Level 1 control IA.L1-B.1.V — the requirement to identify and authenticate users, processes, and devices — with practical implementation steps tailored for organizations following the Compliance Framework and actionable examples for a small business.\n\nUnderstanding IA.L1-B.1.V and the Compliance Framework context\nIA.L1-B.1.V expects covered contractors to ensure that only identified and authenticated users, processes, and devices can access systems that store or process Federal Contract Information (FCI) or Controlled Unclassified Information (CUI). Under the Compliance Framework this maps to basic identity and authentication controls: unique user IDs, account provisioning/deprovisioning, device identification and inventory, and evidence that authentication checks are enforced before granting access. For small businesses, Level 1 is about implementing practical, demonstrable controls rather than enterprise-only solutions.\n\nKey objectives to show in evidence\nWhen building your checklist, capture these key objectives as discrete evidence points: (1) every human user has a unique identifier, (2) service and system processes are accounted for and use separate non-human identities, (3) devices that connect to contractor networks are inventoried and validated, (4) authentication mechanisms are enforced (passwords, MFA where feasible), and (5) access changes are tracked (onboarding, role changes, offboarding). Each objective should map to one or more artifacts in your evidence repository.\n\nWhat concrete evidence looks like\nConcrete evidence items to collect and retain: exported user lists (CSV/PDF) from Active Directory/Azure AD with creation/last-logon timestamps; onboarding/offboarding tickets or signed access request forms; screenshots or exported group policy settings showing password complexity and account lockout policies; MFA enrollment and sign-in log exports (e.g., Azure AD sign-in logs); device inventory lists with serial/MAC addresses and owner fields; MDM/NAC enrollment reports (Intune/Jamf/NAC logs); privileged account inventory and justification docs; and sampled authentication logs showing successful and failed auth attempts. Store each artifact with a descriptive filename, date, and retention metadata in your Compliance Framework evidence repository (SharePoint, secured cloud bucket, or GRC tool).\n\nStep-by-step evidence-ready checklist (practical)\nUse the following checklist as a template. Each item should have an owner, expected artifact type, and retention policy. Sample checklist entries: 1) Maintain a current user account inventory (Owner: IT Manager; Artifact: users_export_YYYYMMDD.csv). 2) Document account provisioning workflow and approved access request form (Artifact: onboarding_form.pdf + ticketing ID). 3) Enforce unique IDs — disable shared/local generic accounts and document exceptions (Artifact: shared_accounts_report.pdf). 4) Publish password policy and capture GPO/tenant policy settings (Artifact: gpo_password_policy_screenshot.png). 5) Enroll devices in MDM/NAC and export enrollment report weekly (Artifact: intune_device_report_YYYYMMDD.csv). 6) Maintain service/process account inventory and access justification (Artifact: service_accounts.xlsx). 7) Keep authentication logs for the contractually required retention period and a sample of recent logs (Artifact: azure_signins_YYYYMM.csv). 8) Document offboarding checklist and sampled closed tickets showing account disablement within SLA (Artifact: offboard_ticket_12345.pdf).\n\nImplementation guidance for a small business scenario\nScenario: a 25-person subcontractor uses Microsoft 365, Azure AD, Intune for endpoints, and a single on-prem Windows server for engineering tools. Practical steps: use Azure AD as the authoritative identity store and enable unique user accounts for everyone; enable MFA for privileged users and for external access; enforce conditional access policies limiting access to compliant (Intune-enrolled) devices; configure Intune to require device enrollment, full-disk encryption, and a PIN; disable local Administrator shared accounts on endpoints and replace with documented, time-limited service accounts where necessary. For evidence, schedule a monthly extraction of Azure AD users (PowerShell script), Intune device export, and a GPO/endpoint configuration snapshot stored in your evidence repository. Assign the IT Manager to reconcile HR’s new-hire list weekly with Azure AD to prove provisioning consistency.\n\nTechnical examples and commands\nExample commands to produce evidence quickly: - Export Azure AD users: Connect-AzureAD; Get-AzureADUser -All $true | Select DisplayName,UserPrincipalName,AccountEnabled,CreationDate | Export-Csv users_export_YYYYMMDD.csv - Export Intune devices: Use Microsoft Graph or Intune portal export to CSV; sample Graph PowerShell snippet: Get-MgDeviceManagementManagedDevice | Export-Csv intune_device_report_YYYYMMDD.csv - Export local Windows accounts inventory: wmic useraccount get name,sid,enabled > local_users_YYYYMMDD.txt - Sample Linux user last login: lastlog -u username. Capture screenshots of policy settings (GPO or Azure AD conditional access), and include hashes or checksum metadata for each exported evidence file to demonstrate integrity.\n\nCompliance tips, best practices, and pitfalls to avoid\nTips: (1) Automate exports and retention — schedule scripts to push artifacts into your evidence repository with standardized filenames and metadata. (2) Map evidence to control objectives in a simple traceability matrix (Control → Evidence file(s) → Owner → Refresh cadence). (3) Use least privilege and document privileged role assignments and periodic reviews. (4) Treat device identity as first-class — require enrollment for access to corporate resources and keep a reconciliation process between asset management and identity systems. Pitfalls: relying solely on manual checklists without sampled logs, keeping evidence only in email, or failing to remove access promptly during offboarding (these are common audit findings).\n\nRisk of not implementing IA.L1-B.1.V properly\nFailure to identify and authenticate users, processes, and devices increases risk of unauthorized access, data exfiltration, lateral movement by attackers, and compromise of FCI/CUI. For contractors this can mean contract penalties, loss of contract, failing a CMMC assessment or FAR audit, and reputational damage. From a practical standpoint, lacking evidence of routine provisioning and deprovisioning invites findings during compliance reviews — even if controls are informally in place, absent artifacts are treated as noncompliance.\n\nSummary: Build a concise, repeatable evidence checklist tied to IA.L1-B.1.V that includes user and device inventories, onboarding/offboarding records, authentication policy snapshots, MFA/enrollment reports, and sampled logs. Automate exports, assign clear owners, and store artifacts in a centralized evidence repository with naming and retention metadata. For small businesses, focus on demonstrable, low-cost controls (Azure AD/Intune, ticketing records, GPO screenshots) that map directly to Compliance Framework objectives — this approach minimizes risk and creates a defensible position for audits and assessments."
  },
  "metadata": {
    "description": "Practical, evidence-focused guidance for meeting FAR 52.204-21 / CMMC 2.0 Level 1 control IA.L1-B.1.V by identifying and authenticating users, processes, and devices with concrete checklist items and sample artifacts.",
    "permalink": "/how-to-create-an-evidence-ready-checklist-for-far-52204-21-cmmc-20-level-1-control-ial1-b1v-users-processes-and-devices.json",
    "categories": [],
    "tags": []
  }
}