This post shows how to design, populate, and operationalize an identity inventory to satisfy NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control IA.L2-3.5.1, with practical templates, examples, and clear steps small businesses can implement right away.
\n\nIA.L2-3.5.1 requires organizations to identify users, processes acting on behalf of users, and devices that access organizational systems and controlled unclassified information (CUI). The key objectives are: (1) a complete, authoritative identity inventory covering humans and non-human identities (service accounts, API keys, devices); (2) unique identifiers so each identity is auditable; and (3) integration with access control and monitoring so identities are discoverable and traceable across systems. For Compliance Framework practitioners, this maps to demonstrating who/what exists, how identities are provisioned/deprovisioned, and where audit evidence lives.
\n\nStart by defining the canonical fields you will capture for every identity. A minimal, practical schema for a small business looks like this: unique_id (GUID), identity_type (human, service, device), username, display_name, email, department, role, privilege_level, source_system (Azure AD, Google Workspace, Okta, Local AD, Linux), home_directory/asset_id, provisioning_owner (HR/IT), creation_date, last_auth_date, status (active/suspended/terminated), attest_date, evidence_link. Keep this schema in a CSV/DB and ensure the unique_id is immutable. Assign a single inventory owner (e.g., IT Security Manager) and a business owner for attestations (HR or department head).
\n\nUse the following CSV header as a working template; you can import/export from spreadsheets, a CMDB, or identity store APIs:
\nunique_id,identity_type,username,display_name,email,department,role,privilege_level,source_system,asset_id,provisioning_owner,creation_date,last_auth_date,status,attest_date,evidence_link\n
Example rows:
\nf47ac10b-58cc-4372-a567-0e02b2c3d479,human,jsmith,John Smith,jsmith@acmeco.com,Engineering,Engineer,User,AzureAD,workstation-101,HR,2024-03-01,2026-04-01,active,2026-04-01,https://evidence/acme/attest/jsmith\n
e2b7a3d6-ff2b-4a7a-9b2d-9b0b3c2d7e22,service,svc-payroll,payroll-service,svc-payroll@acmeco.com,Finance,payroll,Privileged,Okta,service-account-47,IT,2023-07-15,2026-03-15,active,2026-03-20,https://evidence/acme/attest/svc-payroll\n\n
For small businesses, a hybrid approach works best: export identities from each source system, normalize into your inventory schema, and then automate going forward. Tools and commands to use: Azure AD - use Microsoft Graph or PowerShell (Get-MgUser, Get-MgServicePrincipal), Google Workspace - GAM or Admin SDK Directory API, Okta - Okta Users API, On-prem AD - dsquery / PowerShell Get-ADUser, Linux servers - collect /etc/passwd and systemd user lists. For devices, use your EDR/MDM (Intune, Jamf, CrowdStrike) to export device IDs and map to usernames. Automate with a weekly job (PowerShell/Python) that reconciles source lists against the canonical inventory and flags diffs (new, changed, removed).
\n\nConfiguring the inventory is necessary but not sufficient. Implement lifecycle rules: tie provisioning to HR events (hire/transfer/terminate) using SCIM or scripted workflows, automatically set status to 'terminated' when HR marks an employee as separated, and revoke credentials within 24 hours for terminated staff. Schedule quarterly access reviews and capture attestations: each department head reviews their identities and signs off (store PDF or a signed ticket in the evidence_link). For service accounts, require an owner, expiration policy, and approval workflow. For audit evidence, keep export snapshots, automation logs, group membership changes, and screenshots of access review confirmations.
\n\nIntegrate your inventory with an Identity Provider (IdP) and access control enforcement: use unique identifiers in IAM (Azure AD objectId, Okta id) as the canonical unique_id. Enable SCIM provisioning where supported so user attributes sync automatically. Tie the inventory to your SIEM: log authentication events (successful/failed logins, MFA failures) along with the inventory unique_id to prove who authenticated. Enforce MFA, conditional access, and least-privilege role-based access control (RBAC); document mappings between inventory role and system privileges. Protect the inventory itself: store it in an access-controlled database or encrypted storage; restrict who can modify status fields and retain full change history (audit trail).
\n\nExample: ACME Engineering (30 staff, Azure AD, G Suite for email, 40 endpoints) - Week 1: export users from Azure AD and G Suite, import into a Google Sheet using the CSV template and assign unique_id GUIDs. Week 2: map service accounts from cloud apps and mark device IDs from Intune. Week 3: implement a PowerShell script that pulls Azure AD users and device lists, reconciles with the sheet, and sends a weekly diff to IT. Week 4: set up quarterly attestation by department heads with a simple ticket in the existing helpdesk that becomes evidence. Week 5: implement conditional access policy requiring MFA for all identities marked active and privileged. This incremental approach creates a defensible, auditable trail aligned to IA.L2-3.5.1.
\n\nWithout an authoritative identity inventory you face uncontrolled access, orphaned service accounts, privilege creep, and inability to show auditors who had access to CUI—leading to data breaches, contract loss, and regulatory penalties. Compliance tips: (1) scope conservatively—include all systems that process or store CUI; (2) ensure non-repudiation—use immutable unique IDs and logs; (3) protect the inventory—encrypt it and limit write access; (4) automate reconciliation to avoid stale entries; (5) include non-human identities explicitly (API keys, service accounts, CI/CD runners); and (6) retain evidence for the required retention period in your Compliance Framework documentation.
\n\nSummary: Build a canonical identity inventory with clear schema, automate discovery and reconciliation from IdPs and device management systems, enforce lifecycle workflows tied to HR, schedule regular attestations, and secure the inventory itself; these concrete steps produce the artifacts and controls auditors expect for NIST SP 800-171 Rev.2 / CMMC 2.0 IA.L2-3.5.1 compliance and significantly reduce the risk of unauthorized access to CUI.
", "plain_text": "This post shows how to design, populate, and operationalize an identity inventory to satisfy NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control IA.L2-3.5.1, with practical templates, examples, and clear steps small businesses can implement right away.\n\nUnderstanding IA.L2-3.5.1 and the Key Objectives\nIA.L2-3.5.1 requires organizations to identify users, processes acting on behalf of users, and devices that access organizational systems and controlled unclassified information (CUI). The key objectives are: (1) a complete, authoritative identity inventory covering humans and non-human identities (service accounts, API keys, devices); (2) unique identifiers so each identity is auditable; and (3) integration with access control and monitoring so identities are discoverable and traceable across systems. For Compliance Framework practitioners, this maps to demonstrating who/what exists, how identities are provisioned/deprovisioned, and where audit evidence lives.\n\nDesigning your Identity Inventory: fields, scope and ownership\nStart by defining the canonical fields you will capture for every identity. A minimal, practical schema for a small business looks like this: unique_id (GUID), identity_type (human, service, device), username, display_name, email, department, role, privilege_level, source_system (Azure AD, Google Workspace, Okta, Local AD, Linux), home_directory/asset_id, provisioning_owner (HR/IT), creation_date, last_auth_date, status (active/suspended/terminated), attest_date, evidence_link. Keep this schema in a CSV/DB and ensure the unique_id is immutable. Assign a single inventory owner (e.g., IT Security Manager) and a business owner for attestations (HR or department head).\n\nTemplate & example (CSV) to get started\nUse the following CSV header as a working template; you can import/export from spreadsheets, a CMDB, or identity store APIs:\nunique_id,identity_type,username,display_name,email,department,role,privilege_level,source_system,asset_id,provisioning_owner,creation_date,last_auth_date,status,attest_date,evidence_link\nExample rows:\nf47ac10b-58cc-4372-a567-0e02b2c3d479,human,jsmith,John Smith,jsmith@acmeco.com,Engineering,Engineer,User,AzureAD,workstation-101,HR,2024-03-01,2026-04-01,active,2026-04-01,https://evidence/acme/attest/jsmith\ne2b7a3d6-ff2b-4a7a-9b2d-9b0b3c2d7e22,service,svc-payroll,payroll-service,svc-payroll@acmeco.com,Finance,payroll,Privileged,Okta,service-account-47,IT,2023-07-15,2026-03-15,active,2026-03-20,https://evidence/acme/attest/svc-payroll\n\nDiscovery and population: practical steps and tooling\nFor small businesses, a hybrid approach works best: export identities from each source system, normalize into your inventory schema, and then automate going forward. Tools and commands to use: Azure AD - use Microsoft Graph or PowerShell (Get-MgUser, Get-MgServicePrincipal), Google Workspace - GAM or Admin SDK Directory API, Okta - Okta Users API, On-prem AD - dsquery / PowerShell Get-ADUser, Linux servers - collect /etc/passwd and systemd user lists. For devices, use your EDR/MDM (Intune, Jamf, CrowdStrike) to export device IDs and map to usernames. Automate with a weekly job (PowerShell/Python) that reconciles source lists against the canonical inventory and flags diffs (new, changed, removed).\n\nLifecycle, attestations, and evidence for compliance\nConfiguring the inventory is necessary but not sufficient. Implement lifecycle rules: tie provisioning to HR events (hire/transfer/terminate) using SCIM or scripted workflows, automatically set status to 'terminated' when HR marks an employee as separated, and revoke credentials within 24 hours for terminated staff. Schedule quarterly access reviews and capture attestations: each department head reviews their identities and signs off (store PDF or a signed ticket in the evidence_link). For service accounts, require an owner, expiration policy, and approval workflow. For audit evidence, keep export snapshots, automation logs, group membership changes, and screenshots of access review confirmations.\n\nTechnical controls and integrations that strengthen the inventory\nIntegrate your inventory with an Identity Provider (IdP) and access control enforcement: use unique identifiers in IAM (Azure AD objectId, Okta id) as the canonical unique_id. Enable SCIM provisioning where supported so user attributes sync automatically. Tie the inventory to your SIEM: log authentication events (successful/failed logins, MFA failures) along with the inventory unique_id to prove who authenticated. Enforce MFA, conditional access, and least-privilege role-based access control (RBAC); document mappings between inventory role and system privileges. Protect the inventory itself: store it in an access-controlled database or encrypted storage; restrict who can modify status fields and retain full change history (audit trail). \n\nSmall-business scenario: an actionable roadmap\nExample: ACME Engineering (30 staff, Azure AD, G Suite for email, 40 endpoints) - Week 1: export users from Azure AD and G Suite, import into a Google Sheet using the CSV template and assign unique_id GUIDs. Week 2: map service accounts from cloud apps and mark device IDs from Intune. Week 3: implement a PowerShell script that pulls Azure AD users and device lists, reconciles with the sheet, and sends a weekly diff to IT. Week 4: set up quarterly attestation by department heads with a simple ticket in the existing helpdesk that becomes evidence. Week 5: implement conditional access policy requiring MFA for all identities marked active and privileged. This incremental approach creates a defensible, auditable trail aligned to IA.L2-3.5.1.\n\nRisks of not implementing an identity inventory and compliance tips\nWithout an authoritative identity inventory you face uncontrolled access, orphaned service accounts, privilege creep, and inability to show auditors who had access to CUI—leading to data breaches, contract loss, and regulatory penalties. Compliance tips: (1) scope conservatively—include all systems that process or store CUI; (2) ensure non-repudiation—use immutable unique IDs and logs; (3) protect the inventory—encrypt it and limit write access; (4) automate reconciliation to avoid stale entries; (5) include non-human identities explicitly (API keys, service accounts, CI/CD runners); and (6) retain evidence for the required retention period in your Compliance Framework documentation.\n\nSummary: Build a canonical identity inventory with clear schema, automate discovery and reconciliation from IdPs and device management systems, enforce lifecycle workflows tied to HR, schedule regular attestations, and secure the inventory itself; these concrete steps produce the artifacts and controls auditors expect for NIST SP 800-171 Rev.2 / CMMC 2.0 IA.L2-3.5.1 compliance and significantly reduce the risk of unauthorized access to CUI." }, "metadata": { "description": "Step-by-step guidance and ready-to-use templates for building and maintaining identity inventories that satisfy NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 IA.L2-3.5.1 requirements for small businesses.", "permalink": "/how-to-configure-identity-inventories-to-meet-nist-sp-800-171-rev2-cmmc-20-level-2-control-ial2-351-compliance-templates-examples.json", "categories": [], "tags": [] } }