Mapping system users and agents is a small but critical piece of meeting FAR 52.204-21 and CMMC 2.0 Level 1 (IA.L1-B.1.V, Code 548) expectations—this guide gives small businesses a practical, tool-driven approach to inventorying every human account, service account, API token, and endpoint agent, and to producing the evidence auditors expect.
\n\nAt a practical level this control asks organizations to identify who (and what) authenticates to covered contractor information systems, classify accounts (human vs non-human), and keep that mapping current and demonstrable. For a small business this means not only listing employee logins but also documenting service principals, scheduled-job accounts, monitoring and EDR agents, CI/CD pipeline tokens, SSH keys, and cloud roles that can access controlled data. The goal is clear: if an account or agent needs access, you can point to it in a documented registry; if not, you can remove or restrict it.
\n\nBegin with automated exports from identity and asset sources: Active Directory / Azure AD (PowerShell: Get-ADUser, az ad user list), AWS IAM (aws iam list-users, aws iam list-roles), Google Workspace, Okta, and on-host lists (Windows: net user, Linux: /etc/passwd). For agents and service identities, query orchestration tools (Kubernetes service accounts), CI/CD systems (GitHub Actions runners and secrets, GitLab CI tokens), and secrets managers. Consolidate into a single CSV with columns such as: user_id, display_name, account_type (human/service), auth_mechanism (password/MFA/SSH key/managed_identity), privilege_level, last_login, associated_device_ids, owner, review_date, and justification. Use scripts (PowerShell, boto3, az cli) to automate regular exports to reduce manual error.
\n\nClassify accounts into at least three buckets: human (employees/contractors), non-human but unique service accounts (one per application), and ephemeral/role-based access (assume-role, managed identities). Tag entries with purpose and data scope (e.g., \"CUI-read-only\", \"build-agent\", \"EDR-agent\"). For small businesses use group-based RBAC (Azure AD groups, AWS IAM groups) to attach permissions rather than many individual grants. Replace long-lived tokens with short-lived role assumptions or managed identities where possible; enforce MFA on all human accounts and require unique service principals per integration so you can revoke one without breaking others.
\n\nControl implementation should include: enabling MFA, enforcing unique credentials for humans, rotating service-account keys, applying PAM for privileged accounts, deploying MDM/endpoint management to track agent presence, and ensuring EDR/antivirus agents are configured to report heartbeat to a central console. For evidence, export identity group membership snapshots, authentication logs (Azure AD sign-in logs, AWS CloudTrail), and configuration screenshots showing MFA and conditional access policies. Implementation Notes (Compliance Framework): map your CSV fields to the framework's evidence requirements and store artifacts in a versioned compliance repository (e.g., a protected Git repo or compliance GDrive) with change history and reviewer sign-off fields.
\n\nExample A: A 15-person defense subcontractor uses Azure AD for SSO, an on-prem Windows server, and AWS for hosting. Action plan: run az ad user list, export Azure sign-in logs, inventory AWS IAM users/roles, list local Windows accounts (PowerShell Get-LocalUser), and enumerate installed agents via Intune or an EDR console. Create a single inventory CSV and schedule a quarterly review. Example B: A small dev shop uses GitHub Actions and deploys via an AWS role. Create a dedicated GitHub App with scoped permissions rather than using a shared deploy key, register the app as a service principal in your inventory, and document token rotation policies and owner contacts.
\n\nKeep these tactical tips in mind: 1) Separate human and non-human access—never use a shared account for multiple people; 2) Use managed identities and IAM roles instead of static keys; 3) Apply naming conventions and tags (svc-, deploy-, ci-, edr-) to make automated discovery robust; 4) Implement quarterly access reviews with owner sign-off recorded; 5) Maintain retention of authentication logs for the period required by your contract and Compliance Framework guidance; 6) Automate alerts for newly created high-privilege accounts and for service-account credential creation.
\n\nBe ready to show auditors concrete artifacts: exports of group membership, MFA enforcement policies, CloudTrail or Azure sign-in log queries (e.g., Azure Monitor Kusto query for failed/successful sign-ins), Splunk or ELK queries showing agent heartbeats, and screenshots of IAM role policies. Useful commands and queries include: az ad user list --output json, aws iam list-users --output json, PowerShell Get-ADUser -Filter * -Properties LastLogonDate, and osquery SQL to list active agents: SELECT name, uid, path, cmdline FROM processes WHERE name LIKE '%edr%';. Keep these outputs timestamped and signed off by the owner to demonstrate periodic review.
\n\nFailing to adequately map users and agents increases the risk of unauthorized access, lateral movement after compromise, stale high-privilege accounts being abused, and inability to quickly revoke access during an incident. From a compliance standpoint, you risk failing FAR 52.204-21/CMMC assessments, which can lead to contract penalties, loss of future contracts, and remediation costs. Operationally, undocumented agents can break environments during credential rotation or change control, causing outages and delayed incident response.
\n\nSummary: For a small business seeking FAR 52.204-21 and CMMC 2.0 Level 1 alignment, build a scripted, centralized inventory of human accounts and non-human agents, classify and tag them, apply least-privilege and short-lived credentials where possible, document reviews and evidence, and automate recurring checks. With the right combination of simple tooling (Azure/AWS/PowerShell/CLI), clear naming conventions, and a documented review process, you can produce auditor-ready artifacts while materially reducing operational and compliance risk.
", "plain_text": "Mapping system users and agents is a small but critical piece of meeting FAR 52.204-21 and CMMC 2.0 Level 1 (IA.L1-B.1.V, Code 548) expectations—this guide gives small businesses a practical, tool-driven approach to inventorying every human account, service account, API token, and endpoint agent, and to producing the evidence auditors expect.\n\nWhat the control means in practice\nAt a practical level this control asks organizations to identify who (and what) authenticates to covered contractor information systems, classify accounts (human vs non-human), and keep that mapping current and demonstrable. For a small business this means not only listing employee logins but also documenting service principals, scheduled-job accounts, monitoring and EDR agents, CI/CD pipeline tokens, SSH keys, and cloud roles that can access controlled data. The goal is clear: if an account or agent needs access, you can point to it in a documented registry; if not, you can remove or restrict it.\n\nPractical implementation steps\nStep 1 — Inventory all users and agents\nBegin with automated exports from identity and asset sources: Active Directory / Azure AD (PowerShell: Get-ADUser, az ad user list), AWS IAM (aws iam list-users, aws iam list-roles), Google Workspace, Okta, and on-host lists (Windows: net user, Linux: /etc/passwd). For agents and service identities, query orchestration tools (Kubernetes service accounts), CI/CD systems (GitHub Actions runners and secrets, GitLab CI tokens), and secrets managers. Consolidate into a single CSV with columns such as: user_id, display_name, account_type (human/service), auth_mechanism (password/MFA/SSH key/managed_identity), privilege_level, last_login, associated_device_ids, owner, review_date, and justification. Use scripts (PowerShell, boto3, az cli) to automate regular exports to reduce manual error.\n\nStep 2 — Classify, tag, and apply least privilege\nClassify accounts into at least three buckets: human (employees/contractors), non-human but unique service accounts (one per application), and ephemeral/role-based access (assume-role, managed identities). Tag entries with purpose and data scope (e.g., \"CUI-read-only\", \"build-agent\", \"EDR-agent\"). For small businesses use group-based RBAC (Azure AD groups, AWS IAM groups) to attach permissions rather than many individual grants. Replace long-lived tokens with short-lived role assumptions or managed identities where possible; enforce MFA on all human accounts and require unique service principals per integration so you can revoke one without breaking others.\n\nStep 3 — Implement controls and produce evidence\nControl implementation should include: enabling MFA, enforcing unique credentials for humans, rotating service-account keys, applying PAM for privileged accounts, deploying MDM/endpoint management to track agent presence, and ensuring EDR/antivirus agents are configured to report heartbeat to a central console. For evidence, export identity group membership snapshots, authentication logs (Azure AD sign-in logs, AWS CloudTrail), and configuration screenshots showing MFA and conditional access policies. Implementation Notes (Compliance Framework): map your CSV fields to the framework's evidence requirements and store artifacts in a versioned compliance repository (e.g., a protected Git repo or compliance GDrive) with change history and reviewer sign-off fields.\n\nReal-world examples and scenarios for a small business\nExample A: A 15-person defense subcontractor uses Azure AD for SSO, an on-prem Windows server, and AWS for hosting. Action plan: run az ad user list, export Azure sign-in logs, inventory AWS IAM users/roles, list local Windows accounts (PowerShell Get-LocalUser), and enumerate installed agents via Intune or an EDR console. Create a single inventory CSV and schedule a quarterly review. Example B: A small dev shop uses GitHub Actions and deploys via an AWS role. Create a dedicated GitHub App with scoped permissions rather than using a shared deploy key, register the app as a service principal in your inventory, and document token rotation policies and owner contacts.\n\nCompliance tips and best practices\nKeep these tactical tips in mind: 1) Separate human and non-human access—never use a shared account for multiple people; 2) Use managed identities and IAM roles instead of static keys; 3) Apply naming conventions and tags (svc-, deploy-, ci-, edr-) to make automated discovery robust; 4) Implement quarterly access reviews with owner sign-off recorded; 5) Maintain retention of authentication logs for the period required by your contract and Compliance Framework guidance; 6) Automate alerts for newly created high-privilege accounts and for service-account credential creation.\n\nTechnical verification and auditor-ready artifacts\nBe ready to show auditors concrete artifacts: exports of group membership, MFA enforcement policies, CloudTrail or Azure sign-in log queries (e.g., Azure Monitor Kusto query for failed/successful sign-ins), Splunk or ELK queries showing agent heartbeats, and screenshots of IAM role policies. Useful commands and queries include: az ad user list --output json, aws iam list-users --output json, PowerShell Get-ADUser -Filter * -Properties LastLogonDate, and osquery SQL to list active agents: SELECT name, uid, path, cmdline FROM processes WHERE name LIKE '%edr%';. Keep these outputs timestamped and signed off by the owner to demonstrate periodic review.\n\nRisks of not implementing the mapping\nFailing to adequately map users and agents increases the risk of unauthorized access, lateral movement after compromise, stale high-privilege accounts being abused, and inability to quickly revoke access during an incident. From a compliance standpoint, you risk failing FAR 52.204-21/CMMC assessments, which can lead to contract penalties, loss of future contracts, and remediation costs. Operationally, undocumented agents can break environments during credential rotation or change control, causing outages and delayed incident response.\n\nSummary: For a small business seeking FAR 52.204-21 and CMMC 2.0 Level 1 alignment, build a scripted, centralized inventory of human accounts and non-human agents, classify and tag them, apply least-privilege and short-lived credentials where possible, document reviews and evidence, and automate recurring checks. With the right combination of simple tooling (Azure/AWS/PowerShell/CLI), clear naming conventions, and a documented review process, you can produce auditor-ready artifacts while materially reducing operational and compliance risk." }, "metadata": { "description": "Step-by-step guidance to inventory, classify, and document system users and non-human agents to meet FAR 52.204-21 and CMMC 2.0 Level 1 IA.L1-B.1.V requirements with practical tools and evidence examples.", "permalink": "/how-to-comply-with-far-52204-21-cmmc-20-level-1-control-ial1-b1v-code-548-practical-mapping-of-system-users-and-agents.json", "categories": [], "tags": [] } }