This post explains how to plan, implement, and document multi-factor authentication (MFA) to satisfy FAR 52.204-21 and CMMC 2.0 Level 1 Control IA.L1-B.1.VI, with practical, small-business friendly examples, configuration details, and audit-ready evidence you can produce for assessors.
What IA.L1-B.1.VI and FAR 52.204-21 require
At a practical level, CMMC 2.0 Level 1 and FAR 52.204-21 require contractors to implement basic access protections for systems that process, store, or transmit controlled unclassified information (CUI) and other government-related data; IA.L1-B.1.VI calls for identity authentication controls such as multi-factor authentication where appropriate. For Compliance Framework implementation, that means you must identify systems in scope, require two or more authentication factors for user access to those systems (especially for remote and privileged access), and document/configure controls so evidence can be produced during an assessment.
Implementation steps for Compliance Framework
Inventory and scope
Begin by inventorying accounts and systems that handle CUI or sensitive government information: cloud mailboxes (Exchange Online), collaboration sites (SharePoint/Drive), VPNs, remote desktops, and administration consoles. Create a simple spreadsheet mapping system -> owner -> authentication method today -> whether it is in-scope for IA.L1-B.1.VI. For a 10–50 person small business this often reduces to M365 accounts, a VPN appliance, and any SSH access to servers—start there and expand as needed.
Choose MFA methods and vendors
Prefer strong, phishing-resistant methods: hardware-backed FIDO2/WebAuthn (YubiKey, Titan), platform authenticators (Windows Hello for Business), or push-based authenticator apps (Duo/Okta/Google Authenticator) using TOTP (RFC 6238). Avoid SMS OTP for primary protection because NIST SP 800-63B and modern guidance consider it weaker against SIM swap attacks. For small businesses, a practical baseline is: require authenticator app or FIDO2 for admins, allow TOTP for users, and keep SMS only as a documented last-resort recovery option.
Integrate MFA with your identity infrastructure
Map integration steps for each system: for Microsoft 365 use Azure AD Conditional Access or Security Defaults to require MFA for all admin accounts and remote sign-ins; enable Self-Service Password Reset (SSPR) with MFA enrollment and enforce registration. For Google Workspace, turn on 2-Step Verification, enforce Advanced Protection Program for privileged users, or require security keys. For on-prem or appliance-based VPNs, use RADIUS or SAML integration to a cloud IdP (Azure AD, Okta, Duo) so MFA is applied centrally. Document the exact config: Conditional Access policy names, required controls (e.g., Grant -> Require multi-factor authentication), and date of enforcement.
Protect remote, privileged, and system access (VPN, SSH, admin consoles)
Remote access and administrator accounts are highest risk—apply MFA here first. For VPNs: configure the VPN to use an IdP that enforces MFA (SAML or RADIUS with Duo/Azure MFA). Example: configure Palo Alto GlobalProtect to use SAML to Azure AD and create a Conditional Access policy that requires MFA for any sign-in from outside trusted corporate IP ranges. For SSH and Linux servers, deploy public-key authentication plus hardware-backed FIDO2 keys or use solutions like SSH certificates tied to an IdP (Vault, Smallstep) with MFA during certificate issuance. For break-glass scenarios, maintain one emergency account with documented controls, locked offline credentials, and stored evidence of use.
Logging, evidence, and audit readiness
To meet Compliance Framework expectations, collect configuration evidence and operational logs: screenshots of policy settings (e.g., Azure Conditional Access policy definitions), MFA enrollment reports, sign-in logs showing MFA challenge and success (timestamp, username, IP), and incident/change tickets for enabling MFA. Forward authentication logs to a SIEM (Azure Sentinel, Splunk, or even a secure log archive) with retention aligned to contract requirements. Produce a simple evidence binder: policy doc, scope spreadsheet, configuration screenshots, enrollment statistics, and representative sign-in logs covering a 30–90 day window.
Risks of not implementing MFA
Without MFA, credential compromise via phishing or credential stuffing is the most common attack vector—attackers can access CUI, exfiltrate data, and move laterally. For government contractors that can mean contract suspension, financial penalties, loss of future contracts, and reputational damage. Technically, lack of MFA increases risk of ransomware and unauthorized administrative changes; from a compliance perspective, assessors will flag missing MFA as a deficiency and require remediation plans that can delay contract performance.
Compliance tips and best practices
Practical best practices: pilot MFA with a small user group before org-wide rollout; enforce MFA first for admins and remote users; use conditional access policies to reduce user friction (e.g., allow trusted device exceptions with strong controls); document accepted authenticators and an exception approval process; implement and document a secure recovery workflow (backup codes stored in enterprise password manager); disable legacy auth protocols that bypass modern MFA (IMAP/POP/SMTP basic auth). Train users with short walkthroughs and phishing simulations and keep a list of artifacts assessors will expect.
In summary, meeting FAR 52.204-21 and CMMC 2.0 IA.L1-B.1.VI is achievable for small businesses by scoping systems, selecting phishing-resistant MFA methods, integrating with your identity provider (Azure AD, Google Workspace, Okta, Duo, etc.), protecting VPN/SSH/admin access, collecting audit evidence (policies, screenshots, logs), and rolling out MFA with training and exception controls—do this methodically and you will both reduce breach risk and produce the documentation needed to demonstrate compliance.
