Limiting system access to authorized users is a core requirement of FAR 52.204-21 and CMMC 2.0 Level 1 (Control AC.L1-B.1.I); this post gives hands-on, practical steps using IAM tools in AWS, Azure, and on-prem environments so a small business can implement least-privilege access, enforce MFA, and produce audit evidence for compliance.
Understanding the requirement (Compliance Framework)
At its simplest, AC.L1-B.1.I requires that only authorized users and devices can access contractor systems containing Federal Contract Information (FCI). For Compliance Framework implementation this maps to an access control policy, documented role definitions, and technical enforcement: identity proofing (who you are), authentication (MFA), authorization (least privilege), and logging (who accessed what and when). The objective is to prevent unauthorized data exposure and to demonstrate controls to auditors.
AWS implementation steps (practical)
Start with centralized identity: use AWS IAM Identity Center (AWS Single Sign-On) or federate from your corporate IdP (Azure AD) so you avoid dozens of long-lived IAM users. Implement these steps: 1) Define roles and groups (e.g., Admins, Dev, Auditor, Contractor) and create least-privilege IAM policies scoped to resources and tags; 2) Enforce MFA at the Identity Center/IdP level; 3) Use permission boundaries and IAM Access Analyzer to detect overly broad policies; 4) Require short-lived credentials by using roles (AssumeRole) rather than access keys; and 5) Enable CloudTrail and log to a central, immutable S3 bucket with lifecycle and encryption for audit evidence. Example minimal policy to allow read-only access to a single S3 bucket (attach to group/role):
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::acme-contract-bucket",
"arn:aws:s3:::acme-contract-bucket/*"
]
}]
}
Also add an IAM policy condition to require MFA for console access (example condition):
{
"Condition": {
"Bool": { "aws:MultiFactorAuthPresent": "true" }
}
}
Azure implementation steps (practical)
In Azure, use Azure AD for identity, Azure RBAC for resource authorization, and Conditional Access + PIM for enforcement and just-in-time elevation. Steps: 1) Map roles to built-in or custom Azure roles and assign at the narrowest scope (resource or resource group); 2) Create security groups for role membership and use dynamic group rules or SCIM to automate provisioning; 3) Enforce MFA and block legacy authentication via Conditional Access policies; 4) Use Azure AD PIM for eligible role activation (just-in-time admin) and record approval workflow; 5) Enable diagnostic logging for Activity Logs and Azure AD sign-ins and send to Log Analytics/Storage for retention. Example CLI to assign Reader to a service principal for a single resource group:
az role assignment create --assignee --role "Reader" --scope /subscriptions//resourceGroups/
</code></pre>
Also document Conditional Access policy settings that require MFA for non-corporate networks and for privileged role activation; export policy screenshots or JSON for audit evidence.
On‑prem implementation steps (practical)
For on‑prem Windows/Linux systems backed by Active Directory or LDAP, implement centralized identity and group-based authorization: 1) Use AD groups to represent roles and assign group-based rights through GPOs or Sudoers; 2) Eliminate shared/local admin accounts—use per-user privileged accounts and a Privileged Access Workstation (PAW) for administrative tasks; 3) Integrate MFA for remote access (RADIUS/NPS, AD FS, Duo/Okta/Azure MFA) and require it for VPN and RDP; 4) Implement a PAM solution (CyberArk, BeyondTrust, or open-source Vault/or its SSH secret backend) to rotate secrets and provide session recording; 5) Enforce least privilege via file permissions, sudo rules, and login restrictions (GPO: Deny log on locally for everyone except required accounts). Example PowerShell to add a user to a group:
Add-ADGroupMember -Identity "ACME_Contractors_ReadOnly" -Members "CN=Jane Smith,OU=Contractors,DC=acme,DC=local"
Real-world example and scenario for a small business
Example: a 25-person small defense contractor stores FCI in AWS S3 and uses Azure AD for corporate identity. Implementation path: federate AWS SSO with Azure AD so employees use corporate credentials, create groups (Engineering, Finance, ContractAdmin), assign S3 and EC2 roles to those groups with narrowly scoped policies, require Azure Conditional Access MFA for any SSO login, and create a documented access matrix listing who has what access and why. For on-prem SCADA or test lab machines, require VPN + MFA and configure jump hosts with session recording; use AD groups to limit who can RDP into lab hosts. Run quarterly access reviews where managers certify group membership and rotate any long-lived keys stored in Secrets Manager/Key Vault.
Compliance tips and best practices
Actionable tips: 1) Center identity on a single authoritative IdP and federate cloud accounts; 2) Prefer roles and short-lived tokens over long-lived credentials; 3) Enforce MFA for all interactive access; 4) Automate provisioning/deprovisioning (SCIM) to avoid orphaned accounts; 5) Implement logging and retention aligned to your compliance evidence requirements (e.g., export CloudTrail and Azure sign-in logs with retention policy); 6) Maintain an access control matrix, screenshots of role assignments, and periodic attestation records to produce during an audit; 7) Test your access revocation process by simulating employee termination and verifying removed access across systems.
Risks of not implementing the requirement
Failing to limit access increases the chance of FCI exposure, credential theft, lateral movement, and accidental data leakage. For contractors, this can mean contract termination, monetary penalties, loss of eligibility for future contracts, and reputational damage. From a technical standpoint, long-lived keys, excessive privileges, and lack of MFA are common root causes of breaches that start with compromised credentials and expand to complete system access.
Summary
To meet FAR 52.204-21 and CMMC 2.0 Level 1 AC.L1-B.1.I, implement centralized identity, enforce least-privilege role-based authorization, require MFA, use short-lived credentials and PAM for privileged accounts, and keep comprehensive logs and attestation records. Use AWS IAM Identity Center (or IAM roles), Azure AD/RBAC/Conditional Access and PIM, and AD/LDAP groups + GPOs or PAM on-prem for consistent enforcement. These technical steps, combined with documented procedures and periodic reviews, provide both security and the evidence auditors expect.
