Meeting IA.L2-3.5.1 under NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 starts with a reliable, auditable inventory that links identities (users, service accounts) to assets (endpoints, servers, cloud instances) and the CUI those assets can access — this post gives a practical, small-business-friendly checklist to build that combined asset & identity inventory and keep it compliant and operational.
\n\nAt Level 2 the requirement centers on identification and authentication: you must uniquely identify organizational users and authenticate them before granting access to systems that process, store, or transmit Controlled Unclassified Information (CUI). Practically, auditors expect evidence you know what assets can access CUI, who can authenticate to those assets, and that identities are mapped to those assets with controls such as MFA and unique credentials. The inventory is the foundational record that proves you can enforce and audit those controls.
\n\nYour inventory must be structured and queryable. At minimum capture: asset ID (GUID), hostname, asset type (workstation/server/IoT/cloud VM), OS/version, IP/MAC, physical location or cloud region, owner/team, CUI access classification (yes/no/partial), installed auth agents (SSO/AD/LDAP), patch status, lastSeen timestamp, and an association list of identities with role/privilege and auth method (password/SAML/MFA/cert). For identities capture: unique userid, identity source (AD/Azure/Okta/Google), account type (person/service/privileged), roles, last login, MFA status, provisioning method (SCIM/manual), linked asset IDs, and expiration or review date. These fields let you prove who can get to CUI and on which devices.
\n\nFollow a staged approach: 1) Define scope and CUI system boundaries — list systems and file locations where CUI exists. 2) Discover assets — use network discovery (nmap -sn 10.0.0.0/24), endpoint management (Intune/JAMF/SCCM), and cloud inventories (AWS CLI: aws ec2 describe-instances) to enumerate assets. 3) Export identities from your IdP/AD (PowerShell: Get-ADUser -Filter * -Properties LastLogonDate,Enabled) and map to assets using login logs, MDM reports, and ssh/WinRM telemetry. 4) Consolidate into a CMDB or single CSV/spreadsheet as a short-term store, then migrate to a proper CMDB (ServiceNow/ManageEngine/GLPI) or an inventory database (Elastic, Fleet). 5) Tag assets that can access CUI and require MFA/privileged controls. 6) Implement automated reconciliation (daily or weekly) and a quarterly manual review with owners. Each step should have a named owner and completion date.
\n\nFor small businesses with limited budget, combine lightweight tools: osquery (fleetctl/osquery) on endpoints to report hostname, installed auth agents, and last login; Intune or JAMF for managed endpoints; and a centralized syslog or SIEM (Splunk, Elastic) to collect authentication events. Example osquery SQL to list users and shells: SELECT uid, username, directory, shell FROM users; Use PowerShell on Windows domain controllers to map accounts to devices: Get-ADComputer -Filter * -Properties OperatingSystem,LastLogonDate | Export-Csv devices.csv. For cloud, enable CloudTrail/AzureActivity and tag instances with a \"cui_access:true\" tag. For services and API tokens, maintain a secrets inventory (HashiCorp Vault / Azure Key Vault / 1Password) and export service-account mappings for the CMDB.
\n\nExample: A 35-person defense subcontractor stores CUI on a Google Drive folder and an on-prem file server. They start with a spreadsheet inventory: list each laptop issued, the assigned employee, whether Google Drive is synced on it, and whether the account has MFA. They run a weekly Intune device export and a PowerShell query of Active Directory users. When an auditor asks for proof of identify-and-authenticate, the company shows the spreadsheet showing each CUI-enabled device, the associated AD accounts, evidence that MFA is enabled in Google Workspace and Azure AD, and access logs (Drive audit log and file server share access). This inexpensive combination meets IA.L2-3.5.1 if the spreadsheet is reconciled weekly and complemented with logs proving authentication events.
\n\nPractical tips: enforce unique accounts (no shared logins), require MFA for any identity mapped to CUI-capable assets, tag CUI-capable assets early and enforce configuration via MDM/Group Policy, and automate discovery so unknown devices are flagged (alert when an unknown asset attempts to access CUI). Use SCIM provisioning to keep identities in sync between HR and IdP to reduce orphaned accounts. Maintain an access-review cadence (quarterly) with documented remediation for stale accounts. Keep a retention of auth logs sufficient for audits (90–365 days depending on contract) and export audit-ready reports from your IdP/AD and MDM.
\n\nWithout a reliable asset+identity inventory you risk undetected orphaned accounts and unmanaged devices that can be avenues for credential theft, lateral movement, and exfiltration of CUI — and you will almost certainly fail an audit. Operationally, you cannot enforce least privilege, cannot prove MFA coverage, and will struggle to respond to incidents (you won't know which accounts to revoke or which machines to isolate). Contractually, failures may lead to lost contracts, required remediation plans, and reputational damage.
\n\nSummary: Build a structured inventory that ties identities to assets and tags CUI access, start with low-cost discovery and exports from AD/IdP/MDM, automate reconciliation and logging, and institutionalize quarterly reviews and access revocation processes — these practical steps will put you in a strong position to meet IA.L2-3.5.1 for NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2.
", "plain_text": "Meeting IA.L2-3.5.1 under NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 starts with a reliable, auditable inventory that links identities (users, service accounts) to assets (endpoints, servers, cloud instances) and the CUI those assets can access — this post gives a practical, small-business-friendly checklist to build that combined asset & identity inventory and keep it compliant and operational.\n\nWhat IA.L2-3.5.1 requires (practical interpretation)\nAt Level 2 the requirement centers on identification and authentication: you must uniquely identify organizational users and authenticate them before granting access to systems that process, store, or transmit Controlled Unclassified Information (CUI). Practically, auditors expect evidence you know what assets can access CUI, who can authenticate to those assets, and that identities are mapped to those assets with controls such as MFA and unique credentials. The inventory is the foundational record that proves you can enforce and audit those controls.\n\nCore fields and structure for your combined inventory\nYour inventory must be structured and queryable. At minimum capture: asset ID (GUID), hostname, asset type (workstation/server/IoT/cloud VM), OS/version, IP/MAC, physical location or cloud region, owner/team, CUI access classification (yes/no/partial), installed auth agents (SSO/AD/LDAP), patch status, lastSeen timestamp, and an association list of identities with role/privilege and auth method (password/SAML/MFA/cert). For identities capture: unique userid, identity source (AD/Azure/Okta/Google), account type (person/service/privileged), roles, last login, MFA status, provisioning method (SCIM/manual), linked asset IDs, and expiration or review date. These fields let you prove who can get to CUI and on which devices.\n\nStep-by-step implementation checklist\nFollow a staged approach: 1) Define scope and CUI system boundaries — list systems and file locations where CUI exists. 2) Discover assets — use network discovery (nmap -sn 10.0.0.0/24), endpoint management (Intune/JAMF/SCCM), and cloud inventories (AWS CLI: aws ec2 describe-instances) to enumerate assets. 3) Export identities from your IdP/AD (PowerShell: Get-ADUser -Filter * -Properties LastLogonDate,Enabled) and map to assets using login logs, MDM reports, and ssh/WinRM telemetry. 4) Consolidate into a CMDB or single CSV/spreadsheet as a short-term store, then migrate to a proper CMDB (ServiceNow/ManageEngine/GLPI) or an inventory database (Elastic, Fleet). 5) Tag assets that can access CUI and require MFA/privileged controls. 6) Implement automated reconciliation (daily or weekly) and a quarterly manual review with owners. Each step should have a named owner and completion date.\n\nDiscovery and mapping techniques (technical)\nFor small businesses with limited budget, combine lightweight tools: osquery (fleetctl/osquery) on endpoints to report hostname, installed auth agents, and last login; Intune or JAMF for managed endpoints; and a centralized syslog or SIEM (Splunk, Elastic) to collect authentication events. Example osquery SQL to list users and shells: SELECT uid, username, directory, shell FROM users; Use PowerShell on Windows domain controllers to map accounts to devices: Get-ADComputer -Filter * -Properties OperatingSystem,LastLogonDate | Export-Csv devices.csv. For cloud, enable CloudTrail/AzureActivity and tag instances with a \"cui_access:true\" tag. For services and API tokens, maintain a secrets inventory (HashiCorp Vault / Azure Key Vault / 1Password) and export service-account mappings for the CMDB.\n\nReal-world small-business scenario\nExample: A 35-person defense subcontractor stores CUI on a Google Drive folder and an on-prem file server. They start with a spreadsheet inventory: list each laptop issued, the assigned employee, whether Google Drive is synced on it, and whether the account has MFA. They run a weekly Intune device export and a PowerShell query of Active Directory users. When an auditor asks for proof of identify-and-authenticate, the company shows the spreadsheet showing each CUI-enabled device, the associated AD accounts, evidence that MFA is enabled in Google Workspace and Azure AD, and access logs (Drive audit log and file server share access). This inexpensive combination meets IA.L2-3.5.1 if the spreadsheet is reconciled weekly and complemented with logs proving authentication events.\n\nCompliance tips and best practices\nPractical tips: enforce unique accounts (no shared logins), require MFA for any identity mapped to CUI-capable assets, tag CUI-capable assets early and enforce configuration via MDM/Group Policy, and automate discovery so unknown devices are flagged (alert when an unknown asset attempts to access CUI). Use SCIM provisioning to keep identities in sync between HR and IdP to reduce orphaned accounts. Maintain an access-review cadence (quarterly) with documented remediation for stale accounts. Keep a retention of auth logs sufficient for audits (90–365 days depending on contract) and export audit-ready reports from your IdP/AD and MDM.\n\nRisks of not implementing a combined inventory\nWithout a reliable asset+identity inventory you risk undetected orphaned accounts and unmanaged devices that can be avenues for credential theft, lateral movement, and exfiltration of CUI — and you will almost certainly fail an audit. Operationally, you cannot enforce least privilege, cannot prove MFA coverage, and will struggle to respond to incidents (you won't know which accounts to revoke or which machines to isolate). Contractually, failures may lead to lost contracts, required remediation plans, and reputational damage.\n\nSummary: Build a structured inventory that ties identities to assets and tags CUI access, start with low-cost discovery and exports from AD/IdP/MDM, automate reconciliation and logging, and institutionalize quarterly reviews and access revocation processes — these practical steps will put you in a strong position to meet IA.L2-3.5.1 for NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2." }, "metadata": { "description": "Step-by-step practical guidance to build and maintain a combined asset and identity inventory that satisfies NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control IA.L2-3.5.1.", "permalink": "/how-to-build-an-asset-identity-inventory-for-nist-sp-800-171-rev2-cmmc-20-level-2-control-ial2-351-practical-implementation-checklist.json", "categories": [], "tags": [] } }