Multi‑factor authentication (MFA) is one of the most cost‑effective and measurable controls small contractors can implement to meet FAR 52.204‑21 and CMMC 2.0 Level 1 control IA.L1‑B.1.VI; this post walks you through practical steps, platform‑specific examples, evidence you’ll need for assessments, and common pitfalls to avoid.
What IA.L1‑B.1.VI Requires (Practical Summary)
IA.L1‑B.1.VI in CMMC 2.0 Level 1 maps to the basic identity/authentication requirements called out by FAR 52.204‑21: ensure that access to contractor information systems protecting Federal contract information (FCI) is authenticated using more than one factor where appropriate. For small contractors this typically means enforcing MFA for remote access, cloud consoles, privileged/local administrative accounts, and any service that can access FCI—document the policy, show configuration, and retain logs that prove MFA is enforced and used.
Technical Implementation Steps (Actionable)
Follow these concrete steps: 1) Inventory all accounts, services, and access paths (VPN, cloud consoles, RDP, email, file shares). 2) Categorize accounts (admin, privileged, standard user, service/non‑interactive). 3) Choose MFA types — prioritize phish‑resistant factors (FIDO2/security keys) for admins; TOTP apps (Authenticator, Authy) are acceptable for general users; avoid SMS as a primary factor. 4) Configure platform policies to require MFA for targeted groups and cloud apps; enable global enforcement for admins and remote access. 5) Block legacy/IMAP/POP authentication or isolate it to secured systems. 6) Test with a pilot group, then roll out widely with user self‑enrollment and helpdesk procedures. 7) Document changes in change control and capture screenshots, policy exports, and logs as evidence.
Platform‑Specific Examples for Small Contractors
Examples you can implement today: Azure AD (Microsoft 365): enable Azure AD Conditional Access policy — target All users (exclude a break‑glass group), select All cloud apps or specific apps (Exchange Online, SharePoint), Grant -> Require multi‑factor authentication, and set policy to On; enable Security Defaults if you lack Conditional Access. Google Workspace: enforce 2‑step verification for users and require Security Keys for admin accounts. AWS: require MFA for the root account and apply IAM policies that require aws:MultiFactorAuthPresent for console operations (deny when false). VPN/RDP: add MFA at the gateway — use Duo with RADIUS or Okta with a SAML‑enabled VPN; for Windows servers, install Duo Windows Logon or use NPS extension for Azure MFA to protect RDP sessions. These examples are low‑cost: Microsoft 365 Business Premium often includes required features; Duo has a free tier (limited users) and paid plans scale for small businesses.
Service Accounts, Break‑Glass, and Legacy Systems
Service/non‑interactive accounts shouldn’t bypass controls; use managed identities, certificate‑based authentication, or short‑lived tokens instead of shared static credentials. For true break‑glass administrative accounts, restrict membership to a minimal group, require hardware MFA (YubiKey/FIDO2), lock the account in a secure vault, and log all use. For legacy apps that cannot support modern MFA, isolate them on segmented networks, require access only from jump hosts that enforce MFA, and document compensating controls and a remediation timeline (POA&M) for assessors.
Logging, Evidence, and Assessment Tips
Assessors will look for policy documents and technical evidence: Conditional Access policy exports or screenshots, MFA enrollment reports (who has registered/when), sign‑in logs showing MFA challenges and successful authentications, VPN/rd gateway logs with MFA attribution, change control tickets for policy deployment, and user training acknowledgements. Retain logs for the timeframe required by your contract and export sign‑in reports (Azure AD sign‑in logs, Google Workspace admin audit, AWS CloudTrail events showing ConsoleLogin with MFAUsed=true). Keep a short runbook describing how to prove MFA is active during a CMMC assessment.
Risks of Not Implementing MFA
Not enforcing MFA exposes small contractors to account takeover, unauthorized access to FCI, lateral movement into other systems, ransomware, and loss of contract eligibility. From a compliance perspective, failure to implement MFA can result in negative assessment findings, required remediation plans, delayed contract awards, and potential damage to reputation and finances. Real‑world incidents show attackers often compromise accounts with weak passwords and no second factor — MFA reduces the probability of successful compromise dramatically.
Best Practices and Practical Tips
Keep these pragmatic tips in mind: use a phased rollout (pilot → priority groups → full deployment), require phish‑resistant factors for admin/break‑glass accounts, block legacy auth where possible, provide self‑service MFA reset to reduce helpdesk burden, and train users with short videos and phishing examples. Budget for hardware tokens for 1–2 break‑glass users and consider vendor risk (choose well‑supported MFA vendors). Finally, automate evidence collection: schedule exports of sign‑in logs and policy configs weekly to a secure, access‑controlled repository to simplify future assessments.
Conclusion
For small contractors, meeting FAR 52.204‑21 and CMMC 2.0 IA.L1‑B.1.VI is a practical, affordable project: inventory accounts, prioritize privileged and remote access, enforce MFA using strong authenticators, document configurations and logs, and handle exceptions with compensated controls and documented POA&Ms. Implemented correctly, MFA will significantly reduce risk, simplify assessments, and help keep your contracts and client data secure.
