This post gives a practical, step-by-step approach to configuring multifactor authentication (MFA) and device verification to satisfy FAR 52.204-21 and CMMC 2.0 Level 1 Control IA.L1-B.1.VI within your Compliance Framework — including technical configuration examples, small-business scenarios, and evidence collection guidance for auditors.
What IA.L1-B.1.VI requires and the risk if you don’t implement it
IA.L1-B.1.VI, as applied under the Compliance Framework and FAR 52.204-21 basic safeguarding requirements, expects contractors to limit access to covered information by verifying user identity and the device used to access systems that process or store Federal Contract Information (FCI). Not implementing MFA and device verification leaves credentials as the single point of failure: account compromise, lateral movement, exfiltration of FCI, contract termination, financial penalties, and reputational harm. For small businesses, a single phishing event or stolen password can rapidly escalate into a reportable compromise and loss of future government work.
Technical approaches to MFA — what to choose and why
Choose MFA methods that balance security and usability: prefer phishing-resistant methods (FIDO2/WebAuthn hardware tokens, platform authenticators) for administrator and privileged accounts; use authenticator apps (TOTP) for most users; avoid SMS-based OTP as a primary factor. Integrate MFA at the identity provider (IdP) layer (Azure AD, Google Workspace, Okta, Duo) so cloud apps, VPNs, and on-prem services using SAML/OIDC/RADIUS inherit protection. For legacy VPNs or appliances, layer MFA via RADIUS->IdP or deploy a VPN that supports SAML. For small shops, a practical stack is: IdP with MFA + device posture checks + hardware tokens for admins.
Device verification strategies — how to prove the endpoint is trusted
Device verification can be implemented through a Mobile Device Management (MDM)/Endpoint Management solution (Microsoft Intune, Jamf, VMware Workspace ONE) with device compliance policies, certificate-based authentication (SCEP/PKI), or network access control (NAC) that checks device posture before granting access. Key elements: register devices to inventory, enforce encryption and OS patch levels, install management profiles or certificates, and mark devices as "compliant" in the IdP. For unmanaged BYOD, enforce app-level controls (containerized access via Microsoft App Protection, Google Workspace context-aware access) rather than full device control, and require MFA for those sessions.
Implementation steps for a small business (practical scenario)
Example: a 25-person contractor using Microsoft 365, a cloud-hosted VPN, and a few on-prem Windows servers. Step 1: inventory users and tier accounts (admins, devs, staff). Step 2: enable Azure AD Conditional Access — create policy to require MFA for all cloud apps and block legacy authentication. Step 3: enroll corporate devices into Intune; create a compliance policy requiring disk encryption, minimum OS build, and an MDM profile. Step 4: configure Conditional Access to require device compliance for sensitive apps and to require MFA for all interactive logins. Step 5: secure VPN by replacing old RADIUS with SAML-based VPN or place Duo/Okta as MFA proxy. Step 6: pilot with a small group, capture screenshots and logs, then full roll-out, and provide brief training and an enrollment cheat sheet for users.
Configuration specifics and audit evidence to collect
Concrete settings: in Azure AD Conditional Access choose “Users and groups” = all contractor accounts, “Cloud apps” = All cloud apps (or targeted apps), Grant controls = Require multi-factor authentication AND Require device to be marked as compliant; set Session controls appropriately and exclude break-glass admin account in a separate policy requiring hardware token MFA. In Google Workspace, enable endpoint verification and Context-Aware Access, and require 2-step verification. For VPNs, configure IdP integration with SAML and enforce MFA at the IdP. Evidence for auditors: Conditional Access policy screenshots and exports, MDM device inventory CSV, logs showing successful MFA events and device compliance checks (timestamped), and your written policies and procedures mapping IA.L1-B.1.VI to the technical controls (policy→procedure→technical evidence). Keep logs for the retention period specified in your Compliance Framework guidance.
Compliance tips and best practices
Best practices: start by protecting privileged and contractor-facing accounts, then extend to all users. Use phishing-resistant MFA for admins, enforce "block legacy auth" to prevent bypass, disable "remember MFA on this device" for high-risk apps or set short durations, document exceptions in an approval workflow, and maintain an emergency break-glass process with strict auditing. Periodically test your configuration with phishing/emulation and verify device compliance drift. For the Compliance Framework, map each technical control to a policy control ID, maintain change logs and screenshots as artifacts, and schedule quarterly reviews to prove ongoing conformance.
Summary
Meeting FAR 52.204-21 and CMMC 2.0 Level 1 Control IA.L1-B.1.VI is achievable for small businesses by combining IdP-based MFA, device verification through MDM or endpoint verification, and by documenting policies and evidence within your Compliance Framework. Prioritize phishing-resistant MFA for privileged users, enforce device compliance for access to FCI, instrument logging for auditability, and roll out changes iteratively with user training — doing so reduces compromise risk and provides clear artifacts to demonstrate compliance during assessments.
