Multi-factor authentication (MFA) is one of the most effective controls for protecting covered contractor information and meeting both FAR 52.204-21 and CMMC 2.0 Level 1 (Control AC.L1-B.1.I) requirements; this post gives a practical, small-business-focused roadmap to implement MFA for authorized users and secure non-interactive processes where MFA is not feasible.
What the requirement means in practice
Under the Compliance Framework, FAR 52.204-21 requires basic safeguarding of contractor information systems that process federal information, and CMMC 2.0 Level 1 control AC.L1-B.1.I specifically targets authentication for authorized users and processes. In practical terms this means: require a second factor for interactive human access to accounts (especially remote and privileged accounts), and ensure non-interactive processes (service accounts, automation) use strong cryptographic authentication and short-lived credentials when MFA cannot be applied.
Implementation roadmap — steps for a small business
1) Inventory: catalog all user accounts, privileged roles, remote access points (VPN, RDP), cloud identities, and machine/service accounts. 2) Risk-tier users: identify privileged admins, contractors, and users with access to Controlled Unclassified Information (CUI) for immediate enforcement. 3) Select MFA technologies: prefer phishing-resistant factors (FIDO2/hardware keys, platform authenticators, certificate-based) and avoid SMS/voice where possible. 4) Pilot: enable MFA for a small user group, verify workflows, update support processes. 5) Rollout and enforcement: enforce via identity provider conditional access, VPN/RADIUS integration, or OS-level policy. 6) Document exceptions and compensating controls for non-interactive processes.
Technical choices and integration details
Choose an identity provider that supports strong conditional access (Azure AD, Okta, Google Workspace, Duo, JumpCloud). For cloud environments: enforce MFA with Conditional Access (Azure AD) or Sign-On Policies (Okta). For on-prem or VPN: integrate your VPN with an MFA gateway using RADIUS or SAML. For legacy systems that cannot integrate directly, place them behind a jump host or bastion that requires MFA.
Applying MFA to authorized users: concrete examples
Example A — Azure AD: Create a Conditional Access policy targeting all users and cloud apps, require "Grant — Require multi-factor authentication", set exclusions only for managed service accounts. Use named locations and device state to reduce friction for trusted corporate devices. Example B — Okta: Configure a Sign-On Policy that requires 2-step verification for any login originating from untrusted networks and make 2FA required for the "CUI Access" group. Example C — Google Workspace: Enforce 2-Step Verification, whitelist FIDO security keys for high-risk accounts.
Handling non-interactive processes and service accounts
Many processes cannot perform interactive MFA; the Compliance Framework allows strong alternatives. Replace long-lived static credentials with one or more of the following: managed identities (Azure Managed Identity, AWS Instance Profile), mutual TLS / client certificates, OAuth 2.0 client_credentials with private_key_jwt, or short-lived tokens obtained from a secure token service. For AWS, prefer IAM roles for EC2/ECS with short-lived credentials and avoid embedding keys. If a process must use credentials, store them in a secrets manager and enforce automatic rotation and strict access controls.
Example AWS policy to require MFA for specific actions
For user-level enforcement in AWS, you can require MFA for console or API actions using the aws:MultiFactorAuthPresent condition. Example snippet to deny an action unless MFA is present (attach to IAM user or role conditions):
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ec2:TerminateInstances",
"Resource": "*",
"Condition": { "Bool": { "aws:MultiFactorAuthPresent": "false" } }
}
]
}
Compliance tips, best practices, and monitoring
Prefer phishing-resistant MFA (hardware tokens, WebAuthn/FIDO2) for privileged accounts. Disable SMS/voice as a primary factor if possible. Maintain an emergency "break glass" account with strict controls and audited use. Log all authentication events centrally (SIEM) and monitor for compromised factor signals (failed MFA attempts, suspicious geolocation). Keep an MFA enrollment and recovery process documented and supported — lost second-factor is one of the most common user friction points.
Risks of not implementing MFA or doing it poorly
Without effective MFA, small businesses face higher risk of credential compromise, lateral movement, and exfiltration of CUI. Consequences include contract violations, loss of federal business, possible suspension from contracting, reputational damage, and financial loss from breach remediation. Poor implementations (e.g., allowing SMS, failing to protect service accounts) leave critical gaps that attackers frequently exploit.
Verification, audit evidence, and sustaining compliance
To demonstrate compliance under the Compliance Framework, retain: inventory and risk-tier documentation, identity provider policies (Conditional Access/Sign-On policies), logs of MFA events, exception records with compensating controls, and evidence of training and user enrollment. Periodically test MFA by conducting simulated phishing and access reviews, and include MFA enforcement in your annual compliance assessment.
In summary, meeting FAR 52.204-21 and CMMC 2.0 Level 1 AC.L1-B.1.I requires a pragmatic mix of enforced MFA for human users and strong cryptographic authentication for processes; small businesses should inventory identities, choose phishing-resistant factors, integrate MFA into identity and access flows (cloud, VPN, bastions), protect service accounts with managed identities or short-lived tokens, and maintain logging and documented exceptions to sustain compliance and reduce breach risk.
