This guide walks you through a practical, actionable implementation of multifactor authentication (MFA) to satisfy NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control IA.L2-3.5.2, covering human user authentication plus the often-overlooked machine/process and device identity controls required by the Compliance Framework.
Understanding the requirement and scope
IA.L2-3.5.2 requires use of multifactor authentication for local and network access to accounts — both privileged and non-privileged — and the Compliance Framework expects equivalent protections for non-human identities (processes, service accounts) and devices that authenticate to your network or services. Practically, this means you must: (1) require MFA for interactive logins and remote access (VPN, cloud consoles, RDP/SSH where applicable), (2) provide an MFA-equivalent strong authentication method for programmatic or machine access (client certs, mTLS, short-lived tokens), and (3) ensure devices present verifiable, cryptographically-backed identities (device certificates, MDM enrollment, TPM-backed keys).
Step‑by‑step implementation
Start with a repeatable project plan: inventory identities and access paths -> choose MFA and machine-authentication methods -> pilot with a subset of users and services -> deploy breadth-first for high-risk access -> harden and monitor. Below are the concrete steps and technical choices to make during each phase so a small business can implement within tight budgets and limited admin staff.
1) Inventory and risk-based scoping
Enumerate all human accounts (including contractors), service accounts, API keys, SSH keys, VPN/RDP entry points, cloud console logins, and devices that access Controlled Unclassified Information (CUI) or support systems that do. Use scripts to enumerate accounts (Azure AD Graph, Google Workspace Admin SDK, on-prem AD queries). Classify by risk (privileged vs. non-privileged, internet-exposed vs. internal-only) so you can prioritize MFA for highest risk first (remote access, admin consoles, cloud provider accounts).
2) Choose MFA methods and identity architecture
For human users prefer phishing-resistant factors: FIDO2/WebAuthn (YubiKey, Titan), enterprise smart cards, or platform authenticators (Windows Hello for Business backed by TPM). Secondary options are authenticator apps (TOTP/Push) but avoid SMS where possible. For non-human and device authentication use client certificates / mutual TLS, short-lived OAuth 2.0 bearer tokens from an identity broker (private_key_jwt client authentication), or machine identity via PKI distributed during MDM enrollment (SCEP/EST). Use an Identity Provider (IdP) that supports Conditional Access (Azure AD, Okta, Ping) to centralize policies and device compliance checks.
3) Implement MFA for users (technical details)
Integrate your IdP with all critical services via SAML/OpenID Connect. Create Conditional Access policies requiring MFA when: sign-in occurs from untrusted networks, administrative roles are used, or when accessing CUI repositories. Example: Azure AD Conditional Access policy that requires FIDO2 or Microsoft Authenticator push for sign-ins from external IP ranges and for members of the 'PrivilegedAdmins' group. For legacy systems (RDP/SSH), deploy a bastion or jump host that enforces MFA (RDP Gateway with SAML, SSH via certificate-based central CA). Log enrollment events and store recovery/backup codes securely in an enterprise password manager or vault (HashiCorp Vault, Bitwarden Enterprise).
4) Implement MFA-equivalent for processes and devices
Service accounts and machine identities cannot use human OTPs — treat them with strong machine authentication: (a) issue client certificates from your PKI and require mTLS for API and service access; (b) use OAuth 2.0 client credentials with private_key_jwt where the private key is hardware-protected (HSM or TPM) and rotate keys frequently; (c) manage SSH keys centrally and enforce short-lived certificates using a signing CA (e.g., OpenSSH CA + automated issuance via HashiCorp Vault or small-scale CA tooling). For devices, enroll endpoints in an MDM (Intune, Jamf) and require device compliance/attestation as part of Conditional Access; enforce PKI-based wifi/VPN authentication so only managed devices can connect.
Small business real‑world example
Example: A 25-person defense subcontractor handling CUI implements a low-cost but strong stack: Azure AD for identity, Intune for device enrollment, and YubiKey FIDO2 keys for privileged staff. VPN access is replaced with Azure AD Application Proxy and Conditional Access, requiring device compliance and MFA. For CI/CD and automation, they move from static API keys to short-lived tokens issued by Vault with mTLS client auth backed by a small HSM appliance. This reduced helpdesk load by using self-service MFA enrollment and backup codes, while auditors see centralized logs of authentication events in their SIEM (Splunk or Elastic).
Compliance tips and best practices
Document MFA policies and exceptions in your System Security Plan (SSP) and Plan of Action & Milestones (POA&M). Use enrollment and recovery controls: require in-person or supervised remote verification for issuing hardware tokens; store backup codes in a locked vault; and maintain an escalation path for lost device recovery. Adopt logging and alerting: forward authentication events and Conditional Access signals to your SIEM, monitor for repeated failed authentications and new device enrollments. Regularly test recovery flows and tabletop breach exercises to ensure MFA enforcement doesn’t block business-critical operations during outages.
Risk of not implementing IA.L2-3.5.2
Without MFA (or equivalent machine/device authentication), attackers can pivot from credential theft to full network compromise. Real-world consequences include CUI exfiltration, ransomware, contract termination, loss of eligibility for DoD work, and regulatory fines. Small businesses are frequent targets because they often lack layered defenses; a single compromised admin account without MFA can lead to complete supply chain compromise.
In summary, meeting IA.L2-3.5.2 requires planning, inventory, and a mix of human MFA and cryptographic machine/device authentication. Prioritize phishing-resistant factors for users, use PKI/mTLS or private_key_jwt for processes, enforce device compliance via MDM, centralize policies in an IdP with Conditional Access, and record everything in your SSP and logs to satisfy auditors. Implement incrementally: protect external access and privileged accounts first, then expand to all accounts and services while monitoring and refining controls.
