Small contractors handling federal information must implement multi-factor authentication (MFA) and secure process access to comply with FAR 52.204-21 and CMMC 2.0 Level 1 (control AC.L1-B.1.I); this post walks through practical, prioritized steps you can take today, with real-world examples and specific technical notes tailored for constrained IT environments.
What the control requires and key objectives
At Level 1, the control focuses on limiting system/process access to authorized users and maintaining basic safeguards for Federal contract information (FCI) and controlled unclassified information (CUI) where applicable. Key objectives are: 1) establish and enforce authenticated access using MFA where credentials protect sensitive data or processes, 2) ensure processes and automated services do not create unchecked access paths, and 3) produce auditable evidence that access controls and MFA are configured and working. Implementation Notes for small contractors: you can often meet these objectives using cloud identity providers (Azure AD, Google Workspace), simple on-prem solutions (AD with smart card/FIDO), or lightweight PAM modules on Linux servers.
Step-by-step implementation for small businesses
1) Inventory: list all user accounts, administrative accounts, service accounts, and systems that access FCI/CUI (email, file shares, cloud SaaS, VPN, RDP). 2) Policy: update your access control policy to require MFA for interactive logins to any system storing or accessing FCI/CUI and to require documented justification for any exceptions. 3) Choose MFA methods: prioritize phishing-resistant methods (FIDO2/WebAuthn hardware tokens or platform authenticators) or TOTP apps; avoid SMS as primary MFA. 4) Enforce: enable MFA at the identity provider (Azure AD Conditional Access, Google Workspace 2-step enforcement), and block legacy authentication protocols when possible. 5) Harden service/process access: replace embedded passwords in scripts with certificate-based authentication, IAM roles, or machine identities; where service accounts must exist, restrict scope and add monitoring. 6) Test and document: perform user rollouts, test break-glass procedures, and collect screenshots/config export for compliance evidence.
Technical implementation examples
Cloud example (Microsoft 365/Azure AD): enable Security Defaults or create Conditional Access policies to require MFA for all users and for sign-ins from unmanaged devices. Example PowerShell / MS Graph approach: enable per-user MFA or configure Conditional Access via the Azure portal and create a "Require multifactor authentication" grant control for "All cloud apps" with exclusions for a single break-glass account. AWS example: enable MFA on the root account and require MFA for console authentication and for IAM users accessing sensitive resources; CLI snippet to create a virtual MFA device: aws iam create-virtual-mfa-device --virtual-mfa-device-name my-mfa --outfile /tmp/mfa_qrcode.png. Linux server example: use PAM modules such as pam_u2f or pam_yubico for hardware tokens, or pam_google_authenticator for TOTP; ensure /etc/ssh/sshd_config has ChallengeResponseAuthentication yes and appropriate PAM includes. Windows domain example: deploy Windows Hello for Business or require smart card/FIDO2 sign-in via Group Policy/Intune for domain-joined systems.
Handling service accounts, automated processes, and exceptions
Service accounts and automated processes often can't do interactive MFA; secure them by using machine identities (X.509 certificates), IAM roles (AWS), managed identities (Azure Managed Identity), or short-lived tokens issued by an automation system (HashiCorp Vault, AWS STS). Where service accounts must have long-lived credentials, rotate them frequently, log all use, restrict network access (IP allow-lists), and document the business need as an exception approved by leadership. Maintain a tightly controlled "break-glass" account: minimal use, MFA-enabled with hardware token stored securely, and monitored logs for all uses.
Monitoring, auditing, and evidence collection
Enable centralized logging and retention: Azure AD Sign-in logs, Google Workspace Admin audit logs, AWS CloudTrail, Windows Event Forwarding, or a lightweight SIEM. Configure alerts for failed MFA attempts, new device enrollments, and privilege escalations. For compliance audits, export MFA configuration screenshots, conditional access policy definitions, MFA enrollment reports, and a signed exception register. Regularly run access reviews (quarterly for small shops) and keep signed attestation that policies are reviewed and enforced.
Risks of non-implementation and best practices
Failing to implement MFA and secure process access increases the risk of account compromise, lateral movement, exfiltration of FCI/CUI, contract termination, and penalties under FAR. Real-world scenarios: a subcontractor had credentials phished via a legacy IMAP client and an attacker exfiltrated proposal documents; MFA would have stopped interactive access. Best practices: enforce least privilege and role-based access control, prefer passwordless/FIDO2 where supported, block legacy auth, document and rotate credentials for service accounts, and train users on phishing and device security. Keep an auditable trail of policies, technical configs, and incident response steps to satisfy CMMC assessors and contracting officers.
Summary: Small contractors can achieve AC.L1-B.1.I compliance by taking a pragmatic, prioritized approach — inventory access paths, mandate phishing-resistant MFA for interactive users, secure non-interactive service access with machine identities, enable logging/monitoring, and keep thorough documentation. Start with cloud identity controls (Azure AD/Google Workspace) or lightweight PAM integrations, exclude only well-justified exceptions, and maintain the evidence and processes auditors expect; these steps reduce risk and put your organization on a clear path to compliance.
