How to Meet NIST SP 800-171 REV.2 / CMMC 2.0 Level 2 - Control - IA.L2-3.5.3

Requirement

NIST SP 800-171 REV.2 / CMMC 2.0 Level 2 - Control - IA.L2-3.5.3 – Use multi-factor authentication for local and network access to privileged accounts and for network access to nonprivileged accounts.

Understanding the Requirement

This control (defined in NIST SP 800-171 REV.2 / CMMC 2.0 Level 2) requires that all privileged accounts be identified and protected with multi-factor authentication (MFA) both for local and network-based logins, and that network access to non-privileged accounts also requires MFA. In practice this means inventorying privileged accounts, enforcing MFA for local privileged logins (for example local administrator accounts on workstations, servers, and network devices), requiring MFA for network-based access such as Microsoft 365, Active Directory, VPN, and SSH, and applying MFA for non-privileged accounts whenever those accounts are accessed over the network.

Technical Implementation

• Inventory and classify privileged accounts. Create a simple inventory (spreadsheet or ticketing system) of accounts that have elevated rights: domain admins, local administrators on servers/workstations, service accounts, and privileged network-device accounts. Assign an owner for each privileged account and remove or reduce privileges where not required.
• Protect local privileged accounts with MFA or equivalent controls. For Windows endpoints, implement Windows Hello for Business, smart cards, or require use of a centrally managed privileged access solution. If true MFA for local console login is not feasible, deploy Microsoft LAPS (Local Administrator Password Solution) to ensure unique, rotated local admin passwords and require remote privileged sessions to occur through an MFA-protected jump host.
• Require MFA for cloud and directory logins. Enable MFA for all accounts that access cloud services (Microsoft 365, Google Workspace) and for Active Directory administrative accounts. For organizations using Azure AD, implement Conditional Access policies to enforce MFA on privileged groups and for risky sign-ins; for on-prem AD consider Azure AD Join/Hybrid and Conditional Access or a third-party MFA gateway for AD logins.
• Enforce MFA for remote access (VPN, RDP, SSH). Integrate your VPN with an MFA provider that supports RADIUS, SAML, or native connectors (for example Duo, Okta, or vendor-supplied MFA). For SSH, require key-based authentication combined with an MFA step (Duo for SSH, PAM OTP modules, or a bastion host that enforces MFA). Block direct admin RDP/SSH access from the internet—force connections through an MFA-protected jump box.
• Use privileged access controls and session management. If budget allows, deploy a lightweight Privileged Access Management (PAM) or vault (e.g., CyberArk core, HashiCorp Vault, or smaller SaaS PAMs) to broker admin credentials, enforce MFA before checkout, and record privileged sessions. For SMBs, a managed PAM service or a simple jump-host + MFA approach often provides strong protection with lower operational overhead.
• Monitor, test, and train. Ensure MFA failures and privileged authentications are logged and reviewed (SIEM or simple log aggregation). Periodically test MFA enforcement (simulated logins or tabletop exercises) and train system administrators and employees with security responsibilities so they understand how to perform privileged tasks through MFA-protected workflows.

Example in a Small or Medium Business

Acme Engineering has 25 employees, an on-premises Active Directory synced to Azure AD for Microsoft 365, and a site-to-site VPN plus a small number of remote users who use a VPN client. They started by inventorying accounts and identified five domain admins, ten local admin accounts on servers, and a handful of service accounts. The IT team disabled unused local admin accounts and deployed LAPS to manage the remaining local admin passwords. They enabled Azure AD Conditional Access to require MFA for privileged AD groups and made MFA mandatory for all Microsoft 365 accounts using the Microsoft Authenticator app. For remote access they replaced the legacy VPN with a vendor that integrates with their MFA provider so every VPN login requires an approval push. For SSH access to Linux servers they introduced a bastion host that enforces MFA before granting shell access and logs all administrative sessions. The organization documented the changes, assigned responsibility to the network admin, and ran one training and a test recovery exercise to validate that normal operations were not blocked by MFA enforcement.

Summary

Combining a clear inventory and classification of privileged accounts with practical technical controls—MFA for cloud and directory logins, MFA-protected VPN/SSH/jump hosts, unique local admin password management, and session monitoring—meets the IA.L2-3.5.3 requirement. For SMBs the pragmatic path is to remove unnecessary privileges, enforce MFA for all networked sign-ons, protect local privileged access with LAPS or a jump host model, and ensure administrators are trained and logs are reviewed; this mix of policy and technical measures gives strong, affordable protection for privileged and networked accounts.