Implementing multi-factor authentication (MFA) for privileged accounts—both remote and local—is a core requirement of NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 (IA.L2-3.5.3). This post explains a practical, compliance-focused way to integrate third-party MFA providers (Duo, Okta, Azure AD) into your environment, with specific technical options for VPN, RDP/SSH, local console logins, and identity providers, plus real-world small-business scenarios, risks, and best practices.
Why IA.L2-3.5.3 matters and what it requires
IA.L2-3.5.3 demands the use of multi-factor authentication for privileged access to systems containing Controlled Unclassified Information (CUI) and related environments. For compliance frameworks it means: identify privileged identities (Domain Admins, local Administrators, cloud tenant roles), apply MFA for remote access (VPN, remote desktop, cloud console), and where practical, enable MFA for local administrative logons or provide equivalent protections (smart cards, Windows Hello for Business, FIDO2). The goal is to reduce risk from credential theft and lateral movement.
High-level implementation plan (Compliance Framework oriented)
Start with an inventory: list privileged accounts, endpoints where admins sign in (workstations, jump boxes, servers), and remote access paths (VPN, RDP Gateway, Azure AD Application Proxy). Next, choose an integration model: 1) central IdP (Azure AD/Okta) as SAML/OIDC provider for cloud and modern apps, 2) RADIUS/NPS integration for legacy VPNs and on-prem services, or 3) endpoint agents for local interactive logins (Duo Windows Logon, Okta Access Gateway, or Azure AD Join with Conditional Access). Implement in phases: protect remote entry points first (VPN, remote management), then local console and on-host sudo/interactive sessions.
Practical integrations: Duo, Okta, Azure AD — technical specifics
Duo: use Duo Authentication Proxy as a RADIUS server in front of Microsoft NPS for VPNs and RDP gateways. For Windows local logon, install Duo Windows Logon client on workstations/jump boxes and limit enforcement to members of an AD group (e.g., "PrivilegedAdmins"). For Linux, use Duo Unix (pam_duo): add pam_duo.so to /etc/pam.d/sshd and /etc/pam.d/sudo and configure /etc/duo/pam_duo.conf with your integration keys. Okta: deploy Okta Verify or hardware tokens; integrate with AD using the Okta AD Agent and secure on-prem resources with Okta Access Gateway or a RADIUS bridge for VPNs. Azure AD (Microsoft Entra): use Conditional Access policies to require MFA for specific privileged groups and directory roles, enable the NPS extension for Azure MFA for on-prem RADIUS-based VPNs, or publish internal apps via Azure AD Application Proxy for secure, SSO-enabled RDP web access.
Local privileged access: approaches for Windows and Linux
Windows local admin logons: options include Duo Windows Logon, Microsoft Windows Hello for Business (PKI-backed), or smart-card/FIDO2 enforcement via Group Policy and Conditional Access. For on-prem RDP to administrative systems, place a jump host that is Azure AD-joined or protected by a gateway requiring MFA. Linux admin/sudo: enforce MFA in PAM (pam_duo, pam_oauth2_token, or a PAM module for Okta/Azure) and require SSH key+FIDO2 as a second factor where possible. Example: add "auth required pam_duo.so" above pam_unix in /etc/pam.d/sudo and sshd, and configure SSH to accept only public-key auth so MFA augments key use rather than SMS OTP.
Small-business scenarios and step-by-step example
Scenario A (manufacturing subcontractor with CUI): The company uses an on-prem VPN (FortiGate) and several admin workstations. Steps: 1) create "Privileged-Admins" AD group; 2) deploy Duo Authentication Proxy on a hardened VM, configure it to forward auth to Duo cloud and to AD, then point FortiGate to the Duo-provisioned RADIUS server; 3) install Duo Windows Logon on admin workstations for console logons; 4) log events to a SIEM (e.g., Splunk) to show compliant logging and review. Scenario B (cloud-first small software firm): Use Okta as primary IdP, assign admin role protection policy requiring Okta Verify with push and hardware tokens for highest-risk accounts, and use Okta's Access Gateway or Azure AD Application Proxy to wrap on-prem apps. Document the policies, show test results, and retain screenshots and logs as evidence for audits.
Compliance tips, best practices, and evidence collection
Prefer phishing-resistant methods (FIDO2, hardware tokens, or platform authenticators) for privileged users; avoid SMS where possible. Use group-based Conditional Access policies to scope MFA to privileged identities and require reauthentication for sensitive operations. Maintain an exception/waiver process and document compensating controls if full local-console MFA is impractical. Collect evidence: policy documents, group membership exports, Conditional Access policy screenshots, MFA provider logs showing successful challenges for privileged users, and SIEM alerts demonstrating enforcement. Schedule quarterly tests and annual attestations as part of your compliance program.
Risks of not implementing MFA for privileged users
Without MFA, privileged credentials are a high-value attack vector—phished or reused passwords enable lateral movement, domain compromise, and exfiltration of CUI. Noncompliance risks include loss of contracts, failed audits, remediation costs, and potential regulatory fines. For a small business, a single compromised admin account can result in supply-chain fallout and long-term reputational and financial damage.
Implementing third-party MFA for remote and local privileged users is achievable for small businesses with careful inventory, phased deployment, and use of appropriate integration patterns (SAML/OIDC for cloud, RADIUS/NPS for VPN, endpoint agents for local logon). Choose phishing-resistant factors where possible, document everything, and test logging and alerting. Meeting IA.L2-3.5.3 is both a technical and process effort—combine identity controls with least privilege and monitoring to reduce risk and demonstrate compliance.
