This post explains how to map Identity and Access Management (IAM) controls to AC.L1-B.1.I within the Compliance Framework and provides step-by-step, practical actions small businesses can take to satisfy FAR 52.204-21 / CMMC 2.0 Level 1 access-control requirements.
What AC.L1-B.1.I requires (practical interpretation)
AC.L1-B.1.I is a foundational access-control practice within the Compliance Framework: limit access to systems and Covered Defense Information (CDI/CUI) to authorized users, processes, and devices. For FAR 52.204-21 and CMMC 2.0 Level 1 this typically means implementing unique user IDs, enforcing authentication (MFA), controlling account provisioning and deprovisioning, and periodically reviewing access — not just turning on features, but documenting and evidencing that access is appropriately restricted.
Practical IAM implementation steps
1) Inventory, classify, and baseline identities
Start by inventorying user accounts, service/service-to-service accounts, and devices that touch CDI/CUI. Tag systems and data stores that hold or process controlled information. For a small business, a simple spreadsheet or cloud-native identity report (Azure AD > Users & groups; Google Workspace > Users; AWS IAM > list-users) is fine — include username, role, business justification, last sign-in, and linked systems. This baseline lets you scope which identities require controls to meet AC.L1-B.1.I.
2) Implement role-based access and least privilege
Design a small, reusable role model: developer, finance, HR, contract admin, and an elevated admin role. Map each role to the minimal set of permissions needed. In Azure AD use groups + Azure RBAC role assignments; in AWS use IAM groups and policies. Example for a small business: create a "ContractAdmins" Azure AD group that has Reader access to the contract repo and Contributor to the document storage container, rather than granting these permissions individually. Use deny rules sparingly and prefer least-privilege allow lists.
3) Enforce strong authentication and session restrictions
Require MFA for all accounts that can access CDI/CUI. For cloud identities, enable conditional access or equivalent: require compliant devices or known networks for access to sensitive systems, block legacy auth protocols (IMAP/POP), and set session lifetimes. Example conditional policy (Azure AD): require MFA + device compliance for access to SharePoint and Exchange Online where contract documents reside. Small businesses can implement MFA via built-in identity providers (Microsoft Authenticator, Google Authenticator, or hardware tokens for privileged accounts).
4) Secure service accounts, automation, and secrets
Do not use shared human accounts for automation. Create scoped service principals or IAM roles; store credentials in a secrets manager (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault) and rotate them on a schedule (e.g., every 90 days). For example, a CI/CD pipeline should assume an IAM role with narrowly scoped permissions instead of embedding long-lived API keys in build scripts. Use short-lived tokens where possible (AWS STS, Azure AD access tokens).
5) Logging, access reviews, and evidence collection
Enable and retain authentication and access logs to demonstrate compliance: CloudTrail (AWS), Sign-in logs (Azure AD), Drive/Docs audit logs (Google Workspace). Implement quarterly access reviews (or more frequent for higher-risk roles), documenting approvals and remediation actions. For small teams, export monthly sign-in reports and keep a change log that shows when accounts were created/disabled and who approved the change — this is your evidence for AC.L1-B.1.I.
Specific technical examples and quick snippets
Example AWS IAM policy snippet limiting S3 access to a specific bucket for a role (attach to role used by contract processing app):
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["s3:GetObject","s3:PutObject"],
"Resource": ["arn:aws:s3:::contracts-cui-bucket/*"]
}]
}Compliance tips, best practices, and small-business scenarios
Tip 1: Automate onboarding/offboarding — integrate HR with identity provisioning (SCIM) so accounts are created with proper groups and removed on termination. Tip 2: Remove or disable inactive accounts after 30–60 days; enforce unique human accounts (no shared credentials). Tip 3: Keep an access matrix that maps roles to systems and business justification; this makes audits quick. Small business scenario: a 12-person contractor can implement Azure AD P1 conditional access + Okta SSO for perimeter control, use Bitwarden for shared credentials (for non-CUI service accounts only), and set up quarterly access reviews documented in a simple PDF evidence pack.
Risk of non-implementation
Failing to implement AC.L1-B.1.I exposes CDI/CUI to unauthorized access, lateral movement, and data exfiltration. Practically, that can lead to contract termination, exclusion from future government work, FCI or CUI disclosure fines, and reputational damage — plus the inability to produce audit evidence for FAR 52.204-21/CMMC assessments. Even small misconfigurations (exposed S3 buckets, unprotected admin accounts) are common root causes in breach investigations.
Summary — prioritize inventory, least privilege, MFA, service-account hygiene, and logging. For a small business seeking compliance with the Compliance Framework and AC.L1-B.1.I, implement role-based permissions, enforce MFA/conditional access, secure automation with secrets managers, and document routine access reviews. Start with a 30–60 day plan: inventory identities, apply MFA, group-based RBAC, configure logging, and run your first access review to produce the evidence you’ll need for FAR 52.204-21 / CMMC 2.0 Level 1 assessments.
