This post explains how to design, deploy, and document multi-factor authentication (MFA) and device identity controls so a small contractor can meet FAR 52.204-21 and CMMC 2.0 Level 1 expectations for IA.L1-B.1.VI—practical steps, small-business examples, and what evidence auditors expect.
Overview: goals and what to satisfy
The core objective for IA.L1-B.1.VI under CMMC 2.0 Level 1 (and associated FAR expectations) is to ensure that access to contractor systems and controlled unclassified information (CUI) is authenticated using MFA and that devices accessing those systems can be identified and meet a minimum posture standard. For most small businesses this means: (1) require MFA for all users accessing contractor systems and cloud services used to process CUI, and (2) implement device identity (MDM/endpoint enrollment or device certificates/hybrid join) so access decisions can factor device compliance. Implementation should be practical, auditable, and minimally disruptive to business operations.
Practical implementation steps (high level)
Start with an asset and access inventory: list who needs access, which services (email, SaaS, VPN, RDP, source control), and which endpoints are used (corporate laptops, personal devices, mobile phones). Map each access path to an authentication method and a device identity option. For each service identify where to enforce MFA (IdP/SSO, VPN concentrator, cloud app) and where device signals (managed/compliant, certificate, or join state) can be read by a policy engine such as Azure AD Conditional Access or Okta Access Policies.
Choosing MFA methods and configuring IdP
Prefer phishing-resistant MFA where possible: FIDO2/WebAuthn keys (YubiKey, platform authenticators), platform-based passwordless (Windows Hello for Business), or push notifications to authenticator apps; reserve TOTP (time-based one-time passwords) as fallback. Avoid SMS for primary authentication due to SIM swap risk. Implement MFA at the identity provider level (Azure AD, Okta, Google Workspace) so MFA applies consistently to SaaS, VPNs using SAML/OIDC, and RDP gateways. Example configuration: in Azure AD, enable Conditional Access policy "Require MFA for all users" scoped to cloud apps and exclude break-glass emergency accounts; in Okta, enable "Enrollment required" and set Authenticator Enrollment Policies to allow FIDO2 and Okta Verify push.
Device identity and posture: MDM and certificates
Device identity options include: managed device enrollment (Microsoft Intune, Jamf, Google endpoint management), device certificates (SCEP/PKI), and Azure AD Join / Hybrid Azure AD Join. For small businesses using Microsoft 365, a practical setup is Intune enrollment + Azure AD Join for corporate Windows devices and Jamf for macOS. Define a minimal compliance posture (disk encryption enabled, OS patch window < 60 days, firewall enabled, EDR agent present). Configure your Conditional Access policy to require "device marked as compliant" or "hybrid Azure AD joined" before granting access to CUI-bearing services.
Small-business example: Microsoft 365 + Intune
Scenario: 35-person contractor handling limited CUI. Steps: (1) Enable Azure AD secure defaults, set up a dedicated emergency break-glass account protected with hardware MFA and stored credentials. (2) Configure Intune automatic enrollment for corporate devices via Azure AD Join. (3) Create Intune compliance policy: require BitLocker/FileVault, require minimum OS versions, require approved EDR. (4) Create Azure Conditional Access policy scoped to users and Microsoft 365 apps with Grant controls = Require multi-factor authentication + Require device to be marked as compliant. (5) Block legacy authentication protocols in Exchange Online. Document screenshots of policies and export device inventory and compliance reports as evidence.
Logging, evidence collection, and audit readiness
Auditors will expect both configuration artifacts and operational evidence. Capture: policy screenshots, IdP policy JSON/exports, MDM enrollment lists (CSV of devices with owner, OS, serial, compliance state), recent sign-in logs showing MFA prompts and successful device-compliant grants, and change-control tickets for the rollout. Integrate logs with a SIEM (Azure Sentinel, Splunk, an MSSP) to retain and search sign-in events for 6–12 months depending on contract language. Prepare a short runbook describing user onboarding, lost-device handling, and break-glass account usage.
Operational risks and why this matters
Failure to implement MFA and device identity controls raises several risks: increased likelihood of account compromise (credential stuffing, phishing), unauthorized devices accessing sensitive data, lateral movement after initial compromise, and potential loss of contracts or penalties under FAR obligations. Operational trade-offs include user friction and helpdesk load—mitigate these with phased rollouts, communications, self-service MFA enrollment, and redundant recovery methods (e.g., hardware token for privileged users).
Compliance tips and best practices
Best practices: use least-privilege access and time-limited elevated access, enforce conditional access per app (not blanket policies), require device encryption and EDR for any device accessing CUI, document policy exceptions with mitigations, and maintain an emergency access plan. For small teams, leverage managed services (M365 + Intune, Okta + Jamf) to reduce operational burden. Run a tabletop test that simulates lost credentials and a device compromise to validate your detection and recovery procedures before an audit.
In summary, meeting FAR 52.204-21 and CMMC 2.0 Level 1 IA.L1-B.1.VI is achievable for small businesses by combining IdP-enforced MFA (prefer phishing-resistant options), device identity and posture enforcement via MDM or certificates, clear documentation, and logging that produces auditable evidence. Follow a staged rollout, prioritize high-risk accounts and services, and keep remediation and helpdesk procedures simple and documented to reduce both risk and operational headaches.
