To satisfy FAR 52.204-21 and CMMC 2.0 Level 1 control AC.L1-B.1.I, small government contractors must ensure that only authorized users and devices can access systems that process, store, or transmit Federal Contract Information (FCI); this post gives practical, step-by-step Identity and Access Management (IAM) and multifactor authentication (MFA) configuration advice you can implement today to meet that requirement and produce audit evidence.
What the control requires (plain language)
The AC.L1-B.1.I control is straightforward: restrict system access to authorized users and devices. In Compliance Framework terms this means (1) uniquely identify users, (2) require an additional authentication factor, (3) enforce that only managed/compliant devices connect, and (4) retain evidence (logs, enrollment records, policies) to show these controls are in effect. For small businesses this typically maps into an identity provider (IdP) configuration, endpoint management enrollment, conditional access policies, and logging/retention settings.
Core IAM and MFA components you must implement
At minimum deploy: a centralized IdP (Azure AD, Okta, Google Workspace), MFA for all accounts (preferably phishing-resistant methods like FIDO2 or authenticator apps with push), device management (MDM/EMM such as Intune, Jamf, or Google-endpoint management), and conditional access that ties identity to device posture. Technically: enable SSO with SAML/OIDC, implement RBAC or groups for least-privilege access, require device compliance attributes in access policies, and use short-lived credentials or role-based temporary tokens for service access.
Step-by-step example: Azure AD + Intune (practical config)
Example for a small shop using Microsoft 365: 1) Enroll devices in Intune (Windows Autopilot for Windows, Company Portal for macOS/iOS/Android). 2) Create an Intune Device Compliance policy requiring BitLocker/FileVault, minimum OS version, device password, and automatic updates. 3) In Azure AD > Conditional Access create a policy named "Require MFA + compliant device": Assign to All Users (exclude break-glass accounts), Cloud apps: All cloud apps, Conditions: none required, Grant: Require device to be marked compliant AND Require multi-factor authentication. 4) Block legacy authentication under Azure AD > Authentication methods or use a Conditional Access policy to block older protocols. 5) Enable Sign-in Logs export to Log Analytics or Azure Sentinel for retention and evidence: in Azure AD > Diagnostic settings send AuditLogs and SignInLogs to your log workspace and set retention to meet contract requirements. These settings create explicit evidence: Intune enrollment records, Conditional Access policy configuration, and sign-in logs showing compliance and MFA events.
Alternative stacks for small businesses (Okta, Google Workspace, AWS)
If you use Okta and Jamf: configure Okta Device Trust (certificate-based or Okta Verify with Device Trust) and require Device Trust in Okta sign-on policies; set Jamf to enforce encryption and OS patches. For Google Workspace: enable Endpoint Verification and Context-Aware Access, require "device is managed" for access to Gmail and Drive when handling FCI. For AWS console access enforce MFA in IAM policies with a condition aws:MultiFactorAuthPresent and use AWS SSO or IAM Identity Center for central management; require temporary STS tokens for programmatic access and rotate long-lived keys into a secrets manager with short life spans.
Operational practices, logging, and evidence for auditors
Operationalize the controls: implement onboarding/offboarding flows (SCIM provisioning where possible), monthly access reviews for group membership, and an audit runbook that captures screenshots and exports of policy configurations. Enable centralized logging: Azure AD sign-in logs, Okta System Logs, Google Workspace audit logs, AWS CloudTrail. Configure alerts for suspicious sign-ins (impossible travel, atypical locations) and review MFA failures. Evidence package for compliance: policy screenshots, device enrollment reports, MFA enrollment logs, recent sign-in logs that show "device is compliant" and "MFA satisfied," and written procedures for break-glass and account lifecycle.
Compliance tips and best practices
Use least-privilege RBAC and break up privileges into roles; enforce MFA for all users and require stronger MFA (hardware keys or passkeys) for privileged accounts. Remove or disable legacy/authentication protocols and disallow shared accounts—use service principals or roles with short-lived tokens instead. Maintain a documented break-glass account (offline-secured MFA token and monitored usage), encrypt MFA backup codes and store them in a corporate vault, and test recovery procedures quarterly. Map each artifact to the Compliance Framework control during audits (e.g., Evidence #1: Conditional Access policy export; Evidence #2: Intune device inventory CSV).
Risk of not enforcing authorized user and device access
Failing to enforce these controls increases risk of credential compromise, unauthorized data access or exfiltration of FCI, contract noncompliance, and potential removal from federal contracting. Practically, an un-enrolled device or a user without MFA is a single point of failure that can let attackers pivot into internal systems; auditors will flag absence of device posture controls, and regulators may apply contractual penalties or demand remediation within tight timelines.
In summary, meeting FAR 52.204-21 and CMMC AC.L1-B.1.I is achievable for small businesses by centralizing identity with an IdP, enforcing MFA for all users, requiring managed/compliant devices via MDM and conditional access, and maintaining logs and evidence. Start with a simple configuration (force MFA, enroll devices, create a single conditional access policy tying MFA to device compliance), operationalize onboarding/offboarding and logging, and iterate toward stronger MFA and device-posture checks as your maturity grows—this combination delivers both security and auditable compliance evidence.
