This post shows practical steps for small businesses to implement technical controls — access control lists (ACLs), role-based access control (RBAC), and multi-factor authentication (MFA) — to restrict authorized user functions in compliance with FAR 52.204-21 and CMMC 2.0 Level 1 (Control AC.L1-B.1.II).
What the control requires and why it matters
FAR 52.204-21 requires basic safeguarding of covered contractor information systems; CMMC 2.0 Level 1 maps to these FAR requirements and focuses on limiting system functionality to only what authorized users need. Practically, that means enforcing the principle of least privilege, ensuring users cannot perform administrative or data-access actions outside their role, and using technical mechanisms (ACLs, RBAC, MFA) to prevent unauthorized access to Controlled Unclassified Information (CUI) and contractor systems. Failure to implement these controls increases risk of data exposure, contract loss, and mandatory incident reporting.
Start with inventory, roles, and policies
Begin by inventorying systems, data stores (file servers, SharePoint, cloud buckets, databases), applications, network devices, and admin interfaces that handle CUI or contractor data. Create a simple role matrix: map job functions to the minimum set of capabilities needed (read, write, execute, admin). Document each role and the justifications for allowed functions; this documentation is evidence for audits and will guide ACL and RBAC configuration. For small businesses, keep roles coarse but controlled (e.g., ProjectEngineer_ReadOnly, ProjectEngineer_Edit, ProjectAdmin, ITAdmin) to minimize complexity.
Implement ACLs at the resource level (files, folders, network devices)
Apply ACLs to enforce the permissions defined in your role matrix. On Windows file servers, use NTFS ACLs and prefer PowerShell auditability: example to grant a group Modify rights:
icacls "D:\Projects\Contract123" /grant "CORP\ProjEng_Edit:(OI)(CI)M"setfacl -m g:projeng_edit:rwx /srv/projects/contract123{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::123456789012:role/ProjEngRole"},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::contract123/*"
}]
}Deploy RBAC in identity systems and applications
Implement RBAC at the identity provider level (Active Directory, Azure AD, Okta) and in cloud platforms (AWS IAM, Azure RBAC) so roles carry consistent permissions across systems. In Active Directory: create security groups that match your role matrix and use group nesting for hierarchical roles. Example PowerShell to create and add a user to a group:
New-ADGroup -Name "ProjEng_Edit" -GroupScope Global -GroupCategory Security
Add-ADGroupMember -Identity "ProjEng_Edit" -Members "j.smith"Require MFA for sensitive access and privileged functions
MFA is a required compensating control for reducing account compromise risk. Enforce MFA for all users who access CUI, VPNs, admin consoles, or cloud management planes. Recommended MFA approaches: platform authenticators (FIDO2 / hardware keys like YubiKey) for administrators, time-based OTP (TOTP) apps (Authenticator, Google Authenticator) for staff, and conditional access for high-risk situations (unfamiliar location or device). Example: in Azure AD, create a Conditional Access policy targeting the "Portal and management" apps and require MFA when accessing from unmanaged devices. For on-prem VPNs, integrate with an IdP or RADIUS server (Duo, Azure MFA Server) and block legacy password-only logins. Avoid SMS where possible due to SIM-swap risks.
Monitoring, access reviews, and evidence collection
Implement logging for ACL and RBAC changes, sign-in events, and MFA challenges—for example, enable CloudTrail for AWS, Azure AD sign-in logs, and Windows Security/PowerShell logs. Retain logs for the period required by contract (commonly 90–365 days) and configure alerts for anomalous privilege escalations or failed MFA attempts. Perform periodic access reviews (quarterly or on contract milestones) and record the review decisions. Maintain a simple change-control log that shows who changed group membership or ACLs and why — this becomes critical evidence for FAR and CMMC assessors.
Small business scenario: engineering firm working on a DoD contract
A small 25-person engineering firm handling CUI can meet AC.L1-B.1.II by: (1) defining three roles — Viewer (read-only), Contributor (edit project files), and ProjectAdmin (manage project settings); (2) mapping file shares and SharePoint libraries to these roles and setting NTFS or SharePoint permissions to groups rather than individuals; (3) centralizing identity with Azure AD and enforcing group-based RBAC and Conditional Access that requires MFA for SharePoint Online, VPN, and Azure Portal; (4) configuring S3 buckets for backups with IAM roles permitting only automated backup processes to write and designated roles to read; and (5) documenting access reviews quarterly and keeping sign-in/MFA logs for 180 days. This approach is affordable and scalable with built-in Azure/AWS/AD features and a single MFA vendor like Duo or Azure MFA.
Conclusion — risks, best practices, and final checklist
Not implementing ACLs, RBAC, and MFA leaves CUI exposed to insider misuse, account takeover, and inadvertent disclosure — outcomes that can lead to incident reports under FAR 52.204-21, contractual penalties, and loss of future government work. Best practices: document your role matrix and policies, assign permissions to groups not users, employ MFA for all CUI access and privileged accounts, centralize RBAC in your IdP, automate logging and retention, and perform scheduled access reviews. Quick checklist: inventory resources, define roles, apply ACLs, configure RBAC in your IdP/cloud, enable MFA and conditional access, log and review, and retain evidence. Following these steps gives small businesses an auditable, practical path to meet the control AC.L1-B.1.II while materially reducing their exposure to common threats.
