This post gives a hands-on, cloud-native approach to enforcing the access-control expectations of FAR 52.204-21 and CMMC 2.0 Level 1 control AC.L1-B.1.II by using IAM policies and identity controls in AWS, Azure, and GCP. It focuses on practical implementation steps a small business can follow to ensure only authorized users and processes access covered contractor information, and to produce the audit trails and evidence required for compliance reviews.
What AC.L1-B.1.II / FAR 52.204-21 expects (short)
At Level 1, the control requires that organizations limit system access to authorized users, processes acting on behalf of users, and devices — in other words, implement least-privilege access and simple protections for Covered Contractor Information (CCI/CUI-related functionality). For cloud providers this translates into: centralized identity management, role/group-based assignments, enforcement of MFA and session controls, and logging of access events so you can demonstrate who accessed what and when.
Implementation strategy across AWS, Azure, and GCP
AWS: identity-first, attach policies to roles/groups and log everything
In AWS you implement AC.L1-B.1.II by combining IAM roles/groups, IAM policies, MFA enforcement, and auditing via CloudTrail. Practical steps for a small business (10–50 employees): 1) use a single AWS Organization with AWS SSO or an external IdP (OIDC/SAML) and enable attribute-based access control (ABAC) with principal tags; 2) create groups for functional roles (dev, ops, finance) and assign only the managed/custom roles those groups need; 3) require MFA for all human console/API access with a policy condition (aws:MultiFactorAuthPresent); 4) apply permission boundaries for service accounts and use IAM roles for service-to-service access rather than long-lived keys. Example AWS IAM condition snippet (JSON) that allows S3 read only for principals tagged with department=finance and requires MFA:
{
"Version":"2012-10-17",
"Statement":[{
"Effect":"Allow",
"Action":"s3:GetObject",
"Resource":"arn:aws:s3:::finance-bucket/*",
"Condition":{
"StringEquals":{"aws:PrincipalTag/department":"finance"},
"Bool":{"aws:MultiFactorAuthPresent":"true"}
}
}]
}
Azure: Azure AD + RBAC + Conditional Access + PIM
Azure's implementation centers on Azure AD identities, Role-Based Access Control (RBAC) for resources, and Conditional Access policies. For a small business: 1) onboard users into Azure AD and use groups for role mapping; 2) assign built-in RBAC roles (e.g., Reader, Contributor, Storage Blob Data Reader) to groups rather than individuals; 3) enforce Conditional Access requiring MFA for all sign-ins that access subscription resources and block legacy auth; 4) use Privileged Identity Management (PIM) for any elevated roles so admin rights are time-bound and require justification/approval. Example practical mapping: create a 'finance-storage-readers' AAD group, assign Storage Blob Data Reader at the resource scope, and create a Conditional Access policy that requires MFA from non-corporate networks. Capture evidence with sign-in logs, audit logs, and Azure Activity Logs exported to a Log Analytics workspace or an external SIEM for retention and reporting.
GCP: IAM roles, service accounts, and IAM Conditions
On GCP, use IAM roles and IAM Conditions to restrict who can access resources and under what circumstances. Small-business steps: 1) centralize identities in Google Workspace or an external IdP; 2) create groups and grant predefined/custom roles to groups; 3) use service accounts for automation and avoid user keys — prefer short-lived OAuth tokens or Workload Identity Federation if connecting non-Google workloads; 4) apply IAM Conditions to limit access by attributes (e.g., request.time, resource.name, request.auth.claims). Example IAM Condition expression for a bucket that restricts object read to users in your domain and only when MFA was asserted through your IdP (claim dependent):
{
"title": "domain-and-mfa",
"description": "Allow read only for verified domain users with MFA",
"expression": "request.auth.claims.email.endsWith('@example.com') && request.auth.claims.amr.contains('mfa')"
}
Compliance tips and best practices (operational)
Do these recurring operational things to keep AC.L1-B.1.II demonstrable and effective:
- Inventory identities and map them to roles/owners; maintain an access matrix for CCI-relevant resources.
- Use group-based assignments and avoid attaching permissions directly to user accounts.
- Require MFA for interactive and privileged access; enforce via Conditional Access (Azure), IAM policy conditions (AWS), or IdP settings (GCP).
- Automate provisioning/deprovisioning with SCIM and tie to HR offboarding workflows to reduce orphan accounts.
- Restrict service account keys; prefer short-lived credentials; require approvals for key creation and log all key activity.
- Schedule regular access reviews (quarterly or on contract milestones) and log the review evidence.
- Centralize and retain audit logs (CloudTrail, Azure AD logs, Cloud Audit Logs) in an immutable store for the period required by contracts and your compliance program.
Risk of not implementing AC.L1-B.1.II controls
Failing to limit access to authorized users risks unauthorized disclosure or modification of covered contractor information, leading to contract violations, potential financial penalties, and reputational damage. Practically, risks include leaked credentials, over-privileged users accidentally exposing S3/Blob buckets or GCS objects, and no audit trail to demonstrate who accessed CCI — all of which make passing a compliance assessment difficult and increase the chance of a reportable security incident.
In summary, meeting FAR 52.204-21 and CMMC 2.0 Level 1 AC.L1-B.1.II in the cloud is an identity exercise: centralize identity, enforce least privilege via IAM roles/groups/policies, require MFA and conditional checks, use short-lived credentials for automation, and keep detailed audit logs. For a small business this is achievable with disciplined group-based RBAC, a few targeted IAM conditions/Conditional Access rules, automated provisioning/deprovisioning, and a simple logging retention pipeline so you can both prevent unauthorized access and demonstrate compliance when audited.
