Multifactor authentication (MFA) is a foundational control required by IA.L2-3.5.2 of NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2: you must ensure that access to Controlled Unclassified Information (CUI) and privileged functions is protected by more than one form of verification — not only for human users, but also for automated processes and devices that access sensitive systems.
Scope and objectives for Compliance Framework implementation
Begin by scoping: identify all user accounts (interactive, privileged, contractor), all non-human identities (service accounts, CI/CD agents, cron jobs), and all devices (workstations, servers, network gear, IoT/OT) that can access systems handling CUI. The objective under the Compliance Framework is to ensure strong, verifiable second factors or equivalent cryptographic mechanisms are applied wherever single-factor authentication would otherwise allow access to CUI or privileged operations.
Practical implementation steps
1) Inventory and classify identities
Inventory is the first technical task. Use Active Directory/Azure AD/Okta logs, asset management, and configuration management databases to produce lists of: (a) privileged human users (admins, DevOps), (b) general users with CUI access, (c) service/process accounts (automation, CI/CD runners), and (d) devices (servers, laptops, printers, OT controllers). For a small business, start small: export AD user lists, query cloud IAM (AWS IAM, Azure AD), and review SSH keys and API keys stored in repos to locate non-human access points.
2) Choose MFA methods and identity provider (IdP)
Select MFA methods that are resistant to phishing and provide non-repudiation: hardware FIDO2 tokens (YubiKey), platform authenticators (Windows Hello for Business backed by TPM), and OTP with secure apps (TOTP using Authenticator apps) where hardware keys aren’t practical. Avoid SMS-only MFA. Pick an IdP that integrates with your environment (Azure AD, Okta, JumpCloud, Google Workspace). For small businesses: Azure AD Security Defaults or Okta’s free tiers can provide immediate MFA enforcement; for more control use Conditional Access (Azure AD P1) or Okta Adaptive MFA to require MFA based on risk and location.
3) Apply MFA to users and interactive access
Enforce MFA for all interactive logins to email, cloud consoles, VPN, and administrative portals. Example actions: enable Conditional Access policy in Azure AD that requires MFA for all admin roles and for sign-ins from untrusted networks; enable Okta policy to require MFA on sign-in for groups with CUI access; enable Security Defaults if you lack Conditional Access licensing. For legacy VPNs or RDP, integrate the VPN with the IdP via RADIUS (e.g., NPS extension for Azure MFA or Okta RADIUS agent) so the VPN honors IdP MFA prompts. For RDP to Windows hosts, implement RD Gateway + IdP integration or require Windows Hello for Business + certificate authentication to meet the intent of multifactor.
4) Secure processes and non-human identities
Non-interactive access (processes) cannot use push-notification MFA. Use cryptographic machine identities and short-lived tokens instead: issue machine certificates from an internal CA and use mutual TLS for device-to-service authentication; use SSH certificate authorities rather than static keys for server access; use OAuth 2.0 client credentials with short-lived tokens and rotate client secrets frequently. For CI/CD, adopt OIDC (GitHub Actions/OpenID) to mint ephemeral cloud credentials (AWS STS, Azure managed identities) instead of long-lived keys. Vault the remaining credentials in a secrets manager (HashiCorp Vault, AWS Secrets Manager) and require access to secrets via authenticated, audited session tokens. These approaches satisfy the control’s requirement by ensuring non-human access uses strong cryptographic proof rather than a password alone.
5) Protect devices with hardware-backed identities and posture checks
Treat devices as identities: enroll endpoints in an MDM (Intune, Jamf, Workspace One) and issue device certificates for 802.1X, Wi‑Fi, and VPN authentication. Use TPM-backed keys for Windows Hello for Business or platform keys on macOS. Combine device compliance checks in Conditional Access policies so that MFA is required and only allowed from managed, patched, and encrypted devices. For small manufacturers or shops with OT, use network segmentation and certificate-based authentication for controllers — do not rely on password-only logins for device management interfaces.
Real-world small-business scenarios and technical examples
Scenario 1: A 30-person consulting firm using Office 365 and an on-prem VPN — immediate wins: enable Azure AD Security Defaults to force MFA, register each admin with a hardware key or Microsoft Authenticator app, integrate VPN with Azure MFA NPS extension, and enforce device compliance through Intune. Scenario 2: A small SaaS dev shop — remove long-lived AWS keys from CI, switch to GitHub OIDC to obtain short-lived IAM roles, and use HashiCorp Vault to issue database credentials per-build. Scenario 3: A small manufacturer with ICS devices — segment OT networks, issue machine certificates via a lightweight internal CA, and require mutual TLS for any remote management sessions. These concrete actions map to the Compliance Framework requirement by providing multifactor or cryptographic second factors tailored to the identity type.
Risks of non-implementation and audit evidence
Failing to implement MFA for users, processes, and devices risks unauthorized access, ransomware, CUI exfiltration, lateral movement, and loss of DoD contracts or regulatory penalties. For audit evidence, collect and export IdP reports showing MFA policies (Conditional Access/Okta policy exports), enrollment logs (who registered which authenticators and when), device enrollment reports from MDM, records of short-lived token issuance and vault access logs, architecture diagrams showing where MFA and device checks are enforced, and exception/compensating-control approvals. Keep change-control records for policy updates and periodic attestation that service accounts use cryptographic identities rather than passwords.
Compliance tips and best practices
Make MFA enrollment mandatory with staged rollout and clear user training; provide backup authenticators and a documented emergency ("break-glass") process (store a hardware key in a safe for emergency admin recovery). Do not permit SMS as the primary second factor. Use adaptive/auth risk-based policies to reduce user friction — require MFA on new devices or high-risk sign-ins. Automate onboarding by enrolling devices and registering user authenticators as part of account provisioning. Periodically review service accounts for lingering static credentials, rotate keys, and run tests: e.g., attempt sign-in without MFA to confirm block, validate that VPN and RDP flows prompt the IdP, and test CI/CD flows to ensure ephemeral tokens are being issued as expected.
In summary, meeting IA.L2-3.5.2 under NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 requires a programmatic approach: inventory identities and devices, choose phishing-resistant MFA methods, integrate an IdP across user and network access points, implement cryptographic identities for processes and devices, and maintain logging and evidence for audits. For small businesses, prioritize IdP integration, device enrollment, secrets vaulting, and moving away from static credentials — these practical steps both reduce risk and satisfy compliance expectations.
