How to use cloud identity providers (Azure AD / Okta / Duo) to meet IA.L2-3.5.3 requirements: configuration and validation for NIST SP 800-171 REV.2 / CMMC 2.0 Level 2 - Control - IA.L2-3.5.3

This post explains how small and mid-sized organizations can use cloud identity providers—Azure Active Directory (Azure AD), Okta, and Duo—to meet IA.L2-3.5.3 requirements under NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 by implementing multifactor authentication (MFA), conditional access, and audit-ready validation steps that demonstrate compliance to auditors and assessors within the Compliance Framework.

What IA.L2-3.5.3 expects and a compliance-first approach

While exact wording for IA.L2-3.5.3 maps to the Identification and Authentication family, the control’s intent is to require stronger authentication for access to Controlled Unclassified Information (CUI) and privileged functions; practically that means enforcing MFA (preferably phishing-resistant where possible) for all remote, privileged, and administrative access and documenting enforcement and monitoring. For organizations following the Compliance Framework, treat IA.L2-3.5.3 as a policy + technical control: (1) policy requiring MFA for defined user classes and access vectors, (2) technical enforcement using Azure AD/Okta/Duo, and (3) evidence collection (policies, configuration screenshots, logs, tests, and exception records).

Azure AD: Conditional Access, authentication methods, and logging

For Azure AD, use Azure AD Premium P1/P2 (Conditional Access) to meet the control. Key configuration steps: create Conditional Access policies that apply to “All Users” or to defined groups (Users, Admins, Contractor) and to “All Cloud Apps” (or specific sensitive apps) with Grant controls set to “Require multi-factor authentication.” Enable a separate policy that blocks "Legacy authentication" (older protocols that bypass modern MFA flows). Enforce registration with the “Require users to register for Azure AD Multi-Factor Authentication” onboarding (Azure AD > Security > Authentication methods > Policies), and prefer phishing-resistant options (FIDO2 security keys / Windows Hello for Business) for administrative accounts. For technical validation: export Sign-in logs from Azure AD (Azure Active Directory > Sign-ins) and enable diagnostic settings to stream logs to Log Analytics, an Event Hub, or a SIEM; retain at least the retention window your auditors expect (usually 6–12 months minimum). Include screenshots of Conditional Access policy settings, MFA registration reports, and sample sign-in log entries where a password-only attempt is denied and MFA is required.

Okta: Adaptive MFA, factor enrollment, and system logs

Okta’s approach centers on Adaptive MFA and fine-grained sign-on policies. In Okta Admin Console, create Sign-On Policies and Factor Enrollment policies that require MFA for all network and administrative access; enable phishing-resistant factors (WebAuthn/FIDO2) and set a minimum of two approved factor types where possible. For cloud-to-cloud applications, configure SAML/OIDC SSO so authentication flows through Okta (ensuring MFA is enforced at the IdP). Enable System Log export to your SIEM via the Events API or Event Hooks and capture enrollment and failed authentication events. For a small business example: a 50-person contractor can create groups (Employees, Contractors, Admins), require MFA for Contractors+Admins for any external access, and set an exception for an emergency break-glass account that uses an offline hardware token stored in a secure, logged vault (documented and rotated quarterly).

Duo: VPN/RADIUS integrations, device trust, and endpoint checks

Duo is commonly used to secure VPN, SSH, and legacy RADIUS/LDAP authenticators. Deploy Duo Authentication Proxy to front on-prem VPNs (or use native integrations for cloud VPNs), require Duo two-factor for all remote connections, and enable Trusted Endpoints/Device Insight to track unmanaged devices. Configure bypass/exceptions carefully: implement an emergency access method (time-limited bypass codes stored in an encrypted password manager) and monitor use. Technical config notes: add Duo as the secondary factor for primary IdP SSO flows where possible (Okta/AD FS integrations) and log Duo authentication events to Duo’s Admin logs or export via Syslog for long-term retention. Example: small org uses Azure AD for SSO, Okta for developer tools, and Duo for VPN—use RADIUS integration so VPN auth triggers Duo MFA even when the primary IdP is elsewhere.

Validation, testing, and audit evidence

Auditors expect demonstrable evidence that MFA is enforced and effective. Build a validation plan that includes: (1) policy artifacts—MFA policy document and exception procedure; (2) configuration screenshots—Conditional Access policies, Okta sign-on rules, Duo application settings; (3) enrolment reports—list of users with MFA registered and types enrolled; (4) test cases—attempt password-only login (should fail), attempt legitimate MFA login (should succeed), test privileged account login (should require phishing-resistant factor if required); and (5) log extracts—sign-in entries showing denied password-only attempts and successful MFA events with timestamps, usernames, and source IPs. Store these artifacts in a compliance binder (PDFs/screenshots) and include a simple test-run log with timestamps and tester identity to prove the checks were performed. Also include evidence of blocking legacy auth and of monitoring for risky sign-ins (e.g., Azure AD Identity Protection or Okta risk score alerts).

Practical tips, risk, and best practices for small businesses

Risks of not implementing IA.L2-3.5.3 include credential theft, elevated attacker access to CUI, lateral movement into sensitive systems, and failing CMMC/NIST audits which can jeopardize government contracts. Best practices: adopt “MFA-first” onboarding (require MFA at first sign-in), force re-registration on significant account changes, prioritize phishing-resistant factors for high-risk and privileged users, rotate and test break-glass access quarterly, and block legacy auth universally. Use role-based groups to avoid overbroad policies, and maintain a simple runbook for onboarding/offboarding MFA (deprovisioning reduces risk of orphaned factors). For small businesses with tight budgets, leverage built-in logs and export to inexpensive Log Analytics or an open-source SIEM and automate periodic reports that demonstrate enforcement.

In summary, meeting IA.L2-3.5.3 with Azure AD, Okta, and Duo is an achievable three-part effort: (1) define an MFA policy aligned to the Compliance Framework, (2) implement enforcement using Conditional Access, Adaptive MFA, and Duo for legacy access, and (3) collect validation artifacts and logs showing denied password-only attempts, successful MFA checks, and enrollment records. Implementing these controls reduces the risk of account compromise, provides clear audit evidence, and positions your organization to satisfy NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 requirements with operational clarity and repeatable validation steps.