AC.L2-3.1.6 is an Access Control requirement within the NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 family that focuses on controlling and monitoring how users authenticate and access controlled unclassified information (CUI); this post explains how to implement that control using Azure AD, Okta, and Google IAM with practical, small-business-friendly steps, technical configuration tips, and audit evidence you can present to assessors.
Interpretation and core implementation objectives
For Compliance Framework purposes the practical objectives are: enforce strong authentication, limit and detect unauthorized access attempts, apply session and device posture controls, and retain authentication and access logs for audit/forensics. In a small-business context that means: require multi-factor authentication (MFA) for all privileged and remote access, apply conditional policies that block risky sign-ins (legacy auth, unknown devices, high-risk locations), implement account lockout or smart lockout behavior, and forward logs to a central repository for retention and alerting.
Azure AD: concrete steps and settings
Azure AD (with at least P1 licensing for Conditional Access) is commonly used by small contractors. Implement these items: create a baseline Conditional Access policy that targets 'All users' but excludes a documented break-glass admin account; require 'Require multi-factor authentication' for Cloud apps (or specific app sets that handle CUI); block legacy authentication under Conditions → Client apps by excluding 'Other clients' and selecting 'Configure' → block legacy. Use Named Locations to exempt corporate WAN but require MFA from outside those locations. Configure session controls: sign-in frequency to force re-authentication for sensitive apps and Persistent browser session set to 'Never persistent' for CUI apps. For lockout behavior, leverage Azure AD Smart Lockout (configure via Azure AD PowerShell/MS Graph) to protect against brute-force attempts. Finally, stream Sign-in logs and Audit logs to a SIEM or to Azure Monitor/Log Analytics with retention aligned to contract requirements (commonly 1–2 years or per DFARS clauses).
Azure example (small business)
Example: A 25-person defense subcontractor with Azure AD P1 creates a Conditional Access policy named "CUI Access - MFA & Device" targeted to All Users except 'emergency_admin', Cloud apps: all CUI apps, Conditions: client apps include mobile & desktop clients, Grant: require MFA + require device to be marked compliant (Intune). They enable Smart Lockout with default thresholds and forward Sign-in logs to Microsoft Sentinel with an alert rule for 'failed attempts > 10 in 10 minutes followed by a success'. Documentation: export and retain the policy JSON, screenshots of policy, and SIEM alerts for evidence.
Okta: concrete steps and settings
Okta’s strengths for small orgs are adaptive sign-on policies, device trust, and a detailed system log. Implement sign-on policies that require MFA (prefer WebAuthn/FIDO2 where possible) for all interactive logins and especially for administrative roles; use Okta’s Adaptive MFA rules to enforce additional factors when the sign-in risk is high (unknown IP, unusual device). Configure account lockout and recovery settings in Security → Authentication → Sign-On Policies: set max failed attempts (for example 5), set a temporary lockout duration (e.g., 30 minutes) and require administrator unlock for persistent locks used for privileged accounts. Use Okta Device Trust (or integrate with endpoint management) to ensure devices are compliant before granting access to CUI apps. Forward the System Log to your SIEM and set alerts for "user authentication.success after multiple failures" and "suspicious IP geolocation changes."
Okta example (small business)
Example: The same subcontractor uses Okta for SSO of engineering tools: they create a policy "CUI SSO - MFA & Device Trust" applying to All Apps; the rule requires MFA for users not on the corporate IP range and requires Device Trust for macOS and Windows devices via Okta Device Trust. They set sign-on policy to lock accounts after 6 failed attempts and export System Log records weekly to an S3 bucket for retention and audit. Evidence for assessors includes sign-on policy screenshots, exported System Log samples, and a runbook for unlocking accounts.
Google Workspace / Cloud Identity: concrete steps and settings
Google’s controls include Context-Aware Access (CAA), enforced 2-step verification (2SV), and endpoint management. Turn on Advanced Protection or require security keys for privileged accounts. Use CAA to create access levels based on IP, device security status, and user identity, and apply those levels to apps with OAuth scopes that access CUI. Enforce 2SV for all users and set a policy to block less-secure apps (disallow basic auth for email). Configure session length and disable persistent cookies for CUI apps by setting session control parameters in CAA. For logging, enable Admin Audit and Login Audit logs and route them to Google Cloud Logging or export to BigQuery/Cloud Storage for long-term retention and queryability.
Google example (small business)
Example: That subcontractor using Google Workspace enables 2-step verification by default, enrolls all admins in security key-based 2SV, creates a Context-Aware Access level called "CUI Access" requiring corporate IP range + device management, and assigns it to the G Suite apps that handle CUI. They export Login Audit logs to Cloud Storage and set an alert for "suspicious login from new country followed by access to Drive file in CUI folder". Provide auditors with CAA policy exports, 2SV enforcement report, and sample login audit logs.
Practical monitoring, evidence, and small-business operational tips
Whatever IAM platform you use, implement these recurring operational steps: 1) Inventory and map users to roles and list who has access to CUI; 2) Document IAM policies (policy text, scope, exceptions such as break-glass accounts); 3) Configure automated alerts for anomalous authentication sequences (multiple failures then success, impossible travel, high-risk sign-ins); 4) Retain logs centrally and keep an immutable copy for the required retention window; 5) Run quarterly access reviews and record outcomes. For auditors, provide policy exports, screenshots of enforcement, examples of alerts and responses, and a runbook describing how a locked or compromised account is handled.
Risk of not implementing AC.L2-3.1.6 correctly
If you do not enforce strong authentication controls, smart lockout, session limits, and monitoring you increase the risk of credential compromise, unauthorized access to CUI, lateral movement, and data exfiltration. For small businesses this can mean losing DoD contracts, failing CMMC assessment, regulatory and contractual penalties, and severe reputational damage. Practical consequences include ransom and remediation costs, required incident reporting, and potential suspension from government procurement.
Summary: To meet AC.L2-3.1.6 under NIST SP 800-171 / CMMC 2.0 Level 2, use IAM platform features to require MFA, enforce conditional access and device compliance, implement account lockout or smart lockout protections, centrally retain and alert on authentication logs, and document everything for auditors; Azure AD, Okta, and Google all provide the building blocks—choose the policies that fit your environment, test them on a pilot group, and operationalize monitoring and evidence collection so that your small business can demonstrate continuous compliance.
