How to Configure SSO and MFA for AC.L2-3.1.1 in Microsoft Entra ID (Azure AD), Okta, and Google Workspace

AC.L2-3.1.1 requires you to limit system access to authorized users, processes acting on their behalf, and devices. For most small businesses, the fastest, most defensible way to satisfy this is to centralize authentication with Single Sign-On (SSO) and enforce Multi-Factor Authentication (MFA) everywhere. Below are actionable, platform-specific configurations for Microsoft Entra ID (Azure AD), Okta, and Google Workspace that align to AC.L2-3.1.1 and produce audit-ready evidence.

Translate AC.L2-3.1.1 into concrete objectives

Your implementation should prove that only authorized identities and devices access systems, and that access is enforced consistently. Key objectives: centralize logins in one Identity Provider (IdP); require phishing-resistant MFA for all human users; gate sensitive apps by user role and device posture; block legacy/auth-bypass paths; manage joiner-mover-leaver provisioning; and log everything. Implementation notes: use SAML or OIDC SSO for all SaaS; prefer FIDO2/WebAuthn or authenticator app push over SMS; require compliant devices for admin and sensitive apps; and capture screenshots, exported policies, and logs as evidence.

Microsoft Entra ID (Azure AD): Conditional Access-first, phishing-resistant MFA

Make Entra ID your IdP of record. In Entra admin center, configure Enterprise applications for SAML/OIDC SSO to all critical apps (e.g., AWS, Salesforce, Slack, GitHub, QuickBooks). Use automatic provisioning (SCIM) where supported so access is tied to group membership. Under Users > Groups, create role-based groups (e.g., Finance, Engineering, Contractors) and assign app access to groups only—never to individuals. Disable per-user MFA and use Conditional Access (CA) exclusively; enable combined registration so users register MFA and SSPR together. In Authentication methods policy, enable Microsoft Authenticator (push number match) and FIDO2 security keys; restrict SMS/voice to a monitored break-glass context.

Harden sign-in with Conditional Access, device compliance, and identity protection

Create CA policies: require MFA for all users and cloud apps; block legacy/basic authentication; require compliant or Hybrid Azure AD joined devices for high-risk or high-impact apps (admin portals, finance, code repos); and require MFA for risky sign-ins using Identity Protection. Protect the registration process with MFA. Enforce session controls with sign-in frequency (e.g., 12 hours) and disable persistent browser sessions for admins. Integrate Intune and define compliance policies (disk encryption, screen lock, OS version) to back “require compliant device” rules. Lock down OAuth: limit user consent, enable admin consent workflow, and review enterprise app permissions monthly. Create two emergency access accounts with long, random passwords, exclude from CA only when necessary, and monitor for sign-ins. Capture evidence: export CA policy JSON, take screenshots of Authentication methods, list of enabled SAML apps, Identity Protection risk policies, and sign-in logs showing MFA challenges.

Okta: Strong enrollment policies, sign-on rules, and device trust

Configure Okta as the IdP for your SaaS via Applications > Browse App Catalog and prefer SAML or OIDC. Map access via Universal Directory groups, synced from HRIS/AD if present. Turn on Lifecycle Management and SCIM provisioning so account creation/disable is automatic and timely. In Security > Multifactors, enable Okta Verify (push), FIDO2/WebAuthn, and WebAuthn platform authenticators; restrict or remove SMS/Email except for break-glass. Require MFA enrollment at first login and set re-authentication prompts for sensitive apps and admin roles. In Security > Authentication > Sign On, build policy rules per group: deny by default; allow only from trusted networks with MFA; require device assurance for finance/admin apps.

Enforce phishing-resistant MFA and device assurance

Enable Okta FastPass with device binding and Okta Device Assurance to require OS version, disk encryption, and screen lock. Integrate your MDM (Intune, Jamf, Kandji) so device posture is evaluated at sign-in. Turn on ThreatInsight to block known malicious IPs, and enable anomaly detection for brute force and password spraying. For service accounts and API tokens (processes acting on behalf of users), restrict to OAuth tokens with the minimum scopes, store secrets in a vault, rotate regularly, and disable interactive login. Evidence: export Sign-On and MFA policy configurations, screenshot Device Assurance rules, list of SAML/OIDC apps, SCIM provisioning status, and System Log events showing MFA prompts and blocked legacy attempts.

Google Workspace: Enforce 2SV, context-aware access, and OAuth controls

Mandate 2-Step Verification (Admin console > Security > Authentication > 2SV) for all users with enforcement after a short grace period; allow Google Prompt and FIDO2 security keys, and disable SMS/voice except for break-glass. Use Admin roles with least privilege and require 2SV for admins with security keys. Configure Context-Aware Access (Security > Context-Aware Access) to allow access only from trusted IPs and managed devices for sensitive apps (Admin console, Drive for Finance). Enable Endpoint Verification on desktops and Advanced mobile management to enforce screen lock, encryption, and OS patch levels.

Centralize SSO for third-party apps and lock down OAuth

Set up Google as SAML IdP for key SaaS apps (Apps > Web and mobile apps > Add app > Add custom SAML) and enable auto-provisioning (SCIM) where available. If you use an external IdP (Entra ID or Okta) for SSO to Google, configure federation and enforce 2SV at the external IdP for consistent controls. Under API controls, restrict third-party OAuth access to trusted apps only, review domain-wide delegation, and block “less secure apps” and basic IMAP/POP where possible. Evidence: screenshots of 2SV enforcement, context-aware policies, SAML app list, OAuth app access settings, and audit logs exported to BigQuery or your SIEM showing MFA and denied access from unmanaged devices.

Real-world small business scenario and practical tips

Example: a 120-employee manufacturer with contractors centralizes SSO in Entra ID. All apps (ERP, CAD, Git, finance) are integrated via SAML/OIDC and assigned to RBAC groups. Conditional Access enforces MFA and compliant devices for ERP and admin portals; contractors receive app access only during active contracts and are excluded from sensitive apps and device-conditional policies (they must use FIDO2 keys). Finance uses hardware keys exclusively. Legacy SMTP and POP are blocked; OAuth consent is admin-only. Monthly, IT exports CA policies and sign-in logs, and reviews group memberships and dormant accounts. A service account for an integration runs with a scoped app registration and certificate-based auth, rotated annually, with no interactive login. This setup directly demonstrates that only authorized users and devices can access systems, satisfying AC.L2-3.1.1 with strong artifacts.

Risk of not implementing and how to monitor continuously

Without centralized SSO and MFA, your attack surface balloons: password-spray and phishing attacks lead to account takeover, ransomware deployment through OAuth tokens, and data exfiltration from unmonitored apps. You also risk compliance failure and loss of contracts. Mitigate by disabling legacy/basic auth everywhere, enforcing phishing-resistant MFA, requiring managed devices for sensitive apps, and streaming logs to a SIEM. In Entra ID, export Sign-in and Audit logs; in Okta, stream System Log; in Google, export Admin, Login, Drive logs. Set alerts for impossible travel, excessive MFA denials, new OAuth grants, admin role changes, and failed SCIM deprovisioning. Keep evidence packs: quarterly screenshots of policies, exported configs (JSON/YAML where supported), and sample log queries demonstrating enforcement.

Summary

To meet AC.L2-3.1.1, make your IdP the control point: onboard all apps to SSO, require phishing-resistant MFA, gate sensitive access by device posture, and remove legacy bypasses. Microsoft Entra ID, Okta, and Google Workspace each provide the knobs—Conditional Access or Sign-On policies, strong MFA methods, device trust, SCIM provisioning, and comprehensive logging—to prove only authorized users, processes, and devices can access systems. Implement the configurations above, collect artifacts as you go, and you’ll achieve both strong security and audit-ready compliance.