This post explains, step-by-step, how to configure multi‑factor authentication (MFA) in ways that satisfy FAR 52.204-21 and CMMC 2.0 Level 1 control IA.L1-B.1.VI for small businesses — including what to enable, how to document it for compliance, recommended tools, and real-world examples for typical cloud and VPN environments.
What IA.L1-B.1.VI Means in Practical Terms
At Level 1, IA.L1-B.1.VI is a basic but required access control: ensure accounts accessing systems that process, store, or transmit Federal Contract Information (FCI) are protected with more than one authentication factor. Practically, this means requiring MFA for remote access, privileged actions, and user accounts used to access systems containing FCI—not just relying on passwords. For Compliance Framework documentation, you should be able to show policy language, configuration screenshots, logs of MFA events, and a testing record showing MFA is enforced.
Step-by-step implementation: scope, policy, and inventory
Start by scoping: list all systems that touch FCI (email, cloud file storage, VPN, SaaS apps, servers with CUI/FCI). Classify accounts into categories: standard users, privileged (admins, service owners), third‑party contractors, and service accounts. Update or create an Access Control/MFA policy that mandates MFA for interactive logins to scoped systems and for remote access. For small businesses, document this as part of your System Security Plan (SSP) and include responsible owners and timelines.
Choosing methods and tools — practical choices and configuration notes
Choose authentication methods based on risk and cost: authenticator apps (TOTP / push), FIDO2 hardware keys (YubiKey), and vendor push notifications are preferred; SMS OTP is acceptable only as a last resort (document rationale if used). Cost-effective tool choices for small businesses include: Microsoft 365 Business / Azure AD (for Windows/Office ecosystems), Google Workspace (for Gmail/Docs), AWS IAM MFA for AWS console, and third-party providers like Duo/Okta for mixed environments. For high assurance on privileged accounts use FIDO2 or hardware OTP tokens. Example: in Azure AD, create a Conditional Access policy that targets users/groups and cloud apps and requires the "Require multi-factor authentication" grant; in AWS, enable virtual or hardware MFA for each IAM user and use an IAM policy condition to require MFA for sensitive console actions.
Example AWS IAM policy condition (concept)
To enforce MFA for console actions, add a condition like "aws:MultiFactorAuthPresent": true in IAM policies or SCPs. (When implementing, attach policies to roles/users and test access flows so that break‑glass accounts are not accidentally locked out.)
Configuring common platforms and remote access
Practical configuration notes: Azure AD — enable per-user MFA or (preferably) Conditional Access policies; configure authentication methods (Authenticator app, FIDO2) and disable legacy protocols where possible. Google Workspace — enforce 2-step verification and allow security keys for your OU. AWS — enable MFA devices on IAM users; for federated access, require MFA at the IdP level (SAML). VPN / RDP / SSH: integrate your VPN appliance with your IdP (SAML) or RADIUS backed by an MFA provider (Duo Authentication Proxy). For SSH, use public key auth plus hardware tokens (PAM modules like pam_u2f or yubico PAM) or enforce SAML/SSO jump hosts; avoid allowing password-only SSH for accounts that access FCI. Document exact steps in your Ops runbook and capture screenshots or exported configuration for evidence.
Service accounts, recovery, monitoring, and evidence
Service accounts that cannot do interactive MFA should be minimized; where needed, use managed identities, short‑lived credentials, or certificate-based auth and document compensating controls. Create at least one monitored "break-glass" admin account that uses a hardware token stored securely and record procedures for using it. Enable logging of authentication events (Azure Sign‑ins, AWS CloudTrail, Google admin audit logs) and retain logs per your policy (90 days minimum is a reasonable starting point for Level 1 evidence). For audits, collect: MFA enforcement policy, Conditional Access policy screenshots, list of users with MFA enabled, sample authentication logs showing MFA challenges, and test results from account lockout/recovery exercises.
Risk of non‑implementation and compliance tips
Not implementing MFA increases risk of account takeover, lateral movement, and exfiltration of FCI — which can lead to contract suspension, reputational harm, and penalties. Compliance tips: enforce least privilege, block legacy auth (IMAP/POP/SMTP without modern auth), roll out in waves with pilot groups, provide user training and recovery procedures (backup codes, alternate authenticators), and ensure third‑party vendors who access your systems also use MFA. For small businesses, start with the vendor that covers most of your accounts (e.g., Azure AD or Google Workspace) to get the largest security gain for lowest cost.
In summary, meeting FAR 52.204-21 and CMMC 2.0 Level 1 IA.L1-B.1.VI means scoping systems that handle FCI, enforcing MFA for all interactive access (especially remote and privileged access), selecting phishing‑resistant methods where feasible, integrating MFA into VPN/SSH and cloud access, and maintaining documentation and logs as evidence. With a clear policy, staged rollout, monitored break‑glass procedures, and concrete evidence (screenshots, logs, SSP updates), a small business can implement MFA in a practical, auditable way that satisfies the Compliance Framework requirement.
