This post explains how to implement IAM policies and related controls to meet FAR 52.204-21 and CMMC 2.0 Level 1 Control AC.L1-B.1.II (limit access to authorized users, processes, and devices), with practical AWS and Azure examples tailored for small businesses and contractor environments subject to the Compliance Framework.
Key objectives and Implementation Notes (Compliance Framework)
The core objective of AC.L1-B.1.II is to ensure only authorized users and processes can access systems that process or store Federal contract information (FCI) or other covered data. Implementation Notes for the Compliance Framework: enforce least privilege, require strong authentication (MFA), restrict access by role and location where appropriate, use short-lived credentials for automation, and log/authenticate all access. For small businesses this usually means combining identity provider controls (Azure AD, AWS SSO/IAM) with policy-level enforcement (IAM policies, RBAC) and monitoring (CloudTrail/Azure Monitor).
AWS: practical implementation strategy
In AWS, implement AC.L1-B.1.II by: 1) centralizing identity with AWS SSO or an external IdP, 2) creating least-privilege IAM roles and permission boundaries, 3) enforcing MFA for console/API access, 4) constraining use by source IP or VPC endpoints where reasonable, and 5) enabling CloudTrail and AWS Config to capture access activity. Use IAM groups for coarse grouping (employees, contractors) but prefer role assumption for cross-account/sensitive tasks. For programmatic access prefer short-lived STS credentials via role assumption instead of long-lived access keys.
AWS policy patterns and examples
Example: require MFA and company IP range for console access, while allowing role assumption for CI/CD from the build system's IP/VPC. This JSON is a compact "Deny" policy attached as an IAM identity policy or SCP (if using AWS Organizations) to enforce conditions:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyIfNoMFA",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"Bool": {"aws:MultiFactorAuthPresent": "false"}
}
},
{
"Sid": "DenyIfNotFromOffice",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"NotIpAddress": {"aws:SourceIp": ["203.0.113.0/24","198.51.100.0/24"]}
}
}
]
}
Attach the deny policy at the account-level for users and roles that must follow these rules; use permission boundaries for contractor accounts where you want to cap maximum privileges. For small businesses: create an "Admin" role with MFA required and a "Developer" role with scoped permissions to specific services (e.g., s3:GetObject, s3:PutObject on a designated bucket ARN). Example resource-scoped allow statements should use precise ARNs: "arn:aws:s3:::my-company-prod-bucket/*".
Azure: practical implementation strategy
In Azure, implement AC.L1-B.1.II using Azure AD, Azure RBAC, Conditional Access, and Privileged Identity Management (PIM). Create least-privilege custom roles when built-in roles are too broad. Use Conditional Access policies to require MFA and restrict sign-ins to trusted networks or compliant devices. Use Azure Managed Identities for resources (VMs, App Services) to avoid secrets and use role assignments scoped to resource groups or resource-level (never subscription-wide unless necessary).
Azure configuration snippets and examples
Example Conditional Access policy (conceptual PowerShell/Azure AD steps): require MFA for all users accessing management portals, but permit service principals only from named app IDs and with certificate-based authentication. For small businesses: enable PIM for your Global Admins to require JIT activation and approval, and schedule access reviews quarterly. Example CLI to create a role assignment scoped to a resource group:
az role assignment create \
--assignee \
--role "Contributor" \
--scope /subscriptions//resourceGroups/my-app-rg
</code></pre>
Combine this with a Conditional Access policy that enforces "Require MFA" plus a location filter (named locations) so interactive console admin sessions are always MFA-protected and identifiable. For automation, register service principals and constrain them with certificate credentials and Azure AD app role assignments rather than user accounts.
Compliance tips, monitoring and best practices
Practical tips: 1) Document role definitions and map them to job functions (SOD). 2) Use automated onboarding/offboarding with HR triggers to remove access promptly. 3) Enable logging: CloudTrail + CloudWatch (AWS), Azure Activity Logs + Log Analytics (Azure). 4) Run periodic access reviews (quarterly for Level 1) and use IAM access advisor or Azure access reviews to remove unused permissions. 5) Use permission boundaries (AWS) or managed identities/scoped role assignments (Azure) to limit blast radius. 6) Where possible, enforce policies at the organization level (AWS SCPs or Azure Management Group policies) so local changes cannot bypass controls required by the Compliance Framework.
Risk of not implementing AC.L1-B.1.II
Failing to limit access to authorized users/processes increases the risk of unauthorized disclosure of contract-related information, credential theft, lateral movement, and misconfiguration. For contractors this can mean contract termination, inability to bid for future federal contracts, reputational harm, and potential civil penalties. Technically, long-lived keys, broad roles, or missing MFA/logging make incident detection and response slow and remediation more expensive.
Summary: implement least-privilege roles, require MFA and conditional access, prefer short-lived credentials (STS or managed identities), scope permissions to specific ARNs/resource IDs, enforce organization-level deny guards (SCPs/Policies), and maintain logging and periodic access reviews. These practical steps in AWS and Azure will help a small business meet FAR 52.204-21 / CMMC 2.0 Level 1 AC.L1-B.1.II obligations while keeping operational overhead manageable.
