Multi-factor authentication (MFA) is one of the fastest, highest-impact controls you can deploy to meet FAR 52.204-21 and the CMMC 2.0 Level 1 IA.L1-B.1.VI requirement: it reduces account compromise risk significantly and is a required safeguard for systems that store or process Federal Contract Information (FCI).
Why MFA matters for Compliance Framework
Under the Compliance Framework this control is intended to ensure that access to systems containing FCI is protected by more than a password. Practically, that means enforcing MFA for interactive logins to email, cloud consoles, VPNs, RDP/SSH gateways, and administrative access points. For small businesses working on federal contracts, meeting this control demonstrates a baseline safeguarding posture and is commonly validated during contract audits or self-attestation under FAR 52.204-21.
Step-by-step implementation
1) Inventory accounts and access paths
Start by documenting all accounts that can access FCI: cloud identities (Microsoft 365, Google Workspace, AWS, Okta), VPN/remote access accounts, on-premises admin accounts, and service accounts used through interactive logins. Mark which accounts are privileged (admins) vs. regular user accounts. For a small business this often means a handful of Office 365 admin accounts, all user mailboxes, an AWS root/admin account, and a VPN user pool.
2) Choose supported MFA methods and policy scope
Select MFA factors appropriate to your risk and user base. Recommended approaches: authenticator apps (TOTP), push notifications, SMS only as a last resort, and FIDO2/hardware tokens for high-value accounts. Define scope: require MFA for all interactive logins that access FCI and for remote/privileged access specifically. Document acceptable factors and any temporary exception process in your System Security Plan (SSP) and POA&M.
3) Implement in identity providers (examples)
Microsoft 365 / Azure AD — Use Conditional Access policies (preferred) or Security Defaults for very small shops. Steps: Azure AD > Security > Conditional Access > New policy; Assign to All Users (or All Cloud Apps where FCI is accessed); Grant > Require multi-factor authentication; Enable. For hybrid VPNs, use the NPS extension for Azure MFA to add MFA to AD-backed VPN authentication.
Google Workspace — Admin console > Security > 2-step verification > Enforce for organizational units. For stronger protection, enable Security Keys and require them for admins. Test with a subset OU before enforcing globally.
AWS — Enable MFA on the root account immediately and enforce MFA for IAM users via permissions or by enforcing console/API operations when MFA is present. Example policy condition to require MFA for sensitive actions (pseudo-JSON):
{ "Version":"2012-10-17", "Statement":[{ "Effect":"Deny", "Action":"*", "Resource":"*", "Condition":{"Bool":{"aws:MultiFactorAuthPresent":"false"}} }] }
Okta / Identity-as-a-Service — Create an MFA enrollment policy and a sign-on policy that requires MFA for all directory or application sign-ons that access FCI resources. Use adaptive rules (device/trusted network exceptions) carefully and log any exceptions.
Practical small-business scenario
Example: A 15-person subcontractor uses Microsoft 365 for email, AWS for a small application hosting FCI, and a pfSense-based OpenVPN for remote workers. Implementation plan: enable Azure AD Conditional Access to require MFA for all users; use the Azure NPS extension to require MFA for OpenVPN authentication via RADIUS; enable AWS root MFA and create an IAM policy that denies console access if the session is not MFA-authenticated. Document each change with screenshots and export of policies for evidence.
Operational details and hardening
Set up MFA enrollment workflow and recovery: require users enroll at least two factors (e.g., authenticator app + phone number or hardware key) to reduce helpdesk resets. Enforce periodic reviews: re-evaluate users with MFA exemptions at least quarterly, rotate hardware tokens for lost/stolen items, and require MFA re-enrollment after account changes. Log all authentication events centrally (Azure Sign-in logs, Google Admin logs, CloudTrail, VPN logs) and retain them per your retention policy for audit evidence.
Compliance evidence and audit readiness
Collect and store evidence: conditional access policy exports or screenshots, MFA enrollment reports, AWS policy documents, VPN RADIUS config showing MFA integration, enrollment logs, and incident response notes for any MFA failures. Include these artifacts in your SSP for the Compliance Framework mapping and maintain a POA&M for any partial implementations or exceptions (with remediation timelines and compensating controls such as stricter network segmentation).
Risks of not implementing MFA
Failing to implement MFA leaves passwords as a single point of failure. Real-world consequences include account takeover, exfiltration of FCI, ransomware pivots, reputation damage, contract termination, and potential penalties under federal contracting rules. For small businesses, a single compromised admin account can lead to losing multiple contracts and significant downtime.
Best practices and final tips
Prefer phishing-resistant methods (FIDO2/hardware tokens) for administrative accounts; require at least two enrolled factors per user; automate policy enforcement via the IdP rather than per-application where possible; test with a pilot group; and train users on phishing and recovery procedures. Document every step in your Compliance Framework artifacts so auditors can trace the implementation back to IA.L1-B.1.VI and FAR 52.204-21.
Summary: Deploying MFA to meet CMMC 2.0 Level 1 and FAR 52.204-21 is a practical, high-value control you can implement quickly by inventorying access paths, selecting appropriate factors, enforcing MFA in your IdP and network gateways, collecting compliance evidence, and operationalizing ongoing reviews—doing so materially reduces compromise risk and keeps your contracts and reputation intact.
