Multifactor authentication (MFA) combined with a documented identity verification process is a simple, high‑impact control that contractors can implement quickly to meet FAR 52.204-21 and CMMC 2.0 Level 1 (IA.L1-B.1.VI) expectations; this post walks through a practical, small‑business oriented plan covering policy, technical configuration, enrollment, recovery, monitoring, and evidence collection so you can both reduce risk and produce audit-ready artifacts.
What the control requires (practical interpretation for Compliance Framework)
At a minimum, IA.L1-B.1.VI expects organizations to ensure that user logins to systems containing Controlled Unclassified Information (CUI) or covered contractor information are protected beyond passwords and that the identity of new users is verified during enrollment. For a small business following "Compliance Framework" this translates into: (1) enforce MFA for remote and privileged accounts; (2) establish and document an identity proofing/enrollment process; and (3) retain records (enrollment logs, policy, screenshots) demonstrating those controls are in place.
Practical implementation steps
1) Scope and policy first
Start by scoping: list systems that process or store covered contractor information (email, file shares, cloud apps, VPN, HR/finance). Create a short MFA policy that includes which accounts must use MFA (all user accounts, admin/root accounts, service admins), acceptable MFA methods (hardware tokens, authenticator apps, push + device attestation), enrollment requirements (identity documents, HR verification), and an exceptions process. Keep the policy concise — one page for small orgs — and publish it where auditors and staff can access it.
2) Choose MFA methods that balance security and cost
Prefer phishing‑resistant methods where possible: FIDO2/WebAuthn hardware tokens (YubiKey) or platform authenticators (Windows Hello, Apple Passkeys). For low-cost options, Time‑based One‑Time Passwords (TOTP, 6 digits, 30s timestep, HMAC‑SHA1) from authenticator apps are acceptable for Level 1 when combined with identity proofing. Avoid SMS for primary authentication due to SIM‑swap risk. For cloud providers: enable hardware key enforcement in Google Workspace, create Conditional Access rules in Azure AD requiring MFA for all sign-ins to Office 365 and Azure portals, and require MFA on the AWS root and IAM accounts (use the IAM policy condition aws:MultiFactorAuthPresent = true for sensitive operations).
3) Identity verification and enrollment process
Define a repeatable enrollment flow. Example for a 12‑person subcontractor: HR initiates account creation and emails the IT admin; the admin verifies identity using one of these methods — (A) in-person government ID check with signature and photo taken, (B) remote identity verification using a video call + scanned ID and liveness check recorded, or (C) HR confirmation tying identity to hiring paperwork. Record who verified what and retain the enrollment log. Then provision an account via your Identity Provider (IdP) and enroll MFA. For remote identity proofing, keep procedures and vendor receipts (if using a verification SaaS) as evidence.
4) Technical integration examples and concrete settings
Configure your IdP / platforms with an enforceable policy: Google Workspace — Security > Authentication > 2‑step verification > enforce for all users and require Security Keys for admins; Azure AD — create a Conditional Access policy: Users = All; Cloud apps = All; Conditions = Sign-in risk/Locations as needed; Grant = Require multi-factor authentication and require compliant or hybrid Azure AD joined device if you have managed devices; AWS — enable MFA on the root account and attach IAM policies that include "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}} for sensitive IAM actions or use AWS Organizations SCPs to restrict privileged console/API actions without MFA. For VPNs and on-prem systems, integrate MFA via RADIUS or SAML to the same IdP so users have a consistent second factor.
5) Recovery, exceptions and offboarding
Define a recovery process that minimizes identity risk: use one emergency "break‑glass" account stored offline (paper in safe) with hardware token; require supervisor approval and logging when used. Allow backup codes or secondary hardware tokens but require storage policies (encrypted records, physically protected). Implement automated deprovisioning tied to HR: when an employee leaves, disable access immediately and revoke MFA tokens at the IdP. Record deletion or revocation timestamps as evidence for audits.
6) Logging, monitoring and evidence collection
Enable and retain authentication logs for at least 12 months (or as required by contracts). Forward logs to a simple SIEM or cloud log store (Splunk, Elastic, Sentinel, or even secure cloud storage) and configure alerts for spikes in failed logins or MFA bypass attempts. For compliance evidence collect: the MFA policy, screenshots of IdP enforcement settings, enrollment logs showing who verified identities, a sample Conditional Access policy JSON, and periodic access review records. These artifacts map directly to Compliance Framework evidence requirements.
Real-world small business scenarios
Scenario A: A 12‑employee defense subcontractor using Microsoft 365 Business. They enable Azure AD Security Defaults, then create a Conditional Access policy to require MFA for all users and enforce hardware tokens for admins. HR handles identity proofing during hiring (photo ID and signed form). They store enrollment logs as CSV exports from Azure AD and save screenshots of Conditional Access policies in the compliance binder.
Scenario B: A 20‑person engineering firm using Google Workspace opts for YubiKeys for all senior staff and TOTP for other users. IT uses a simple intake form where managers request access and confirm identity. MFA rollouts include a 60‑day window, training session, and weekly reminders; exceptions go to the CISO with documented approvals.
Risks of not implementing this control
Without MFA and documented identity verification you dramatically increase the risk of credential compromise, lateral movement, and data exfiltration. For contractors this can mean exposure of covered information, loss of contracts or termination under FAR obligations, reputational harm, potential regulatory fines, and failure during CMMC assessment. Operationally, recovery after a breach is more expensive and disruptive than implementing MFA and a few simple enrollment steps.
In summary, meeting IA.L1-B.1.VI under FAR 52.204-21 and CMMC 2.0 Level 1 is achievable for small businesses by scoping systems, documenting a concise policy, choosing appropriate MFA methods (favor phishing-resistant options), defining a repeatable identity proofing and enrollment process, integrating MFA across cloud and VPN systems, and retaining logs and artifacts for evidence. Implementing these steps reduces risk substantially and provides clear audit evidence for Compliance Framework assessments.
