Meeting AC.L2-3.1.1 means you must limit system access to authorized users, the processes acting on their behalf, and authorized devices. In practice, that translates to implementing centralized Identity and Access Management with single sign-on (SSO), enforcing multi-factor authentication (MFA) everywhere, and applying role-based access control (RBAC) so users only get the access they need. For small businesses operating under the Compliance Framework (such as CMMC Level 2 mapped to NIST SP 800-171), this guide lays out a practical reference architecture and step-by-step configuration details using common platforms like Microsoft Entra ID (Azure AD), Okta, Google Workspace, AWS IAM Identity Center, and modern MDM solutions.
What AC.L2-3.1.1 Demands and How Auditors Verify It
The requirement expects you to prove that only authorized identities and devices can access systems and data, that privileged activities are restricted, and that access is reviewed and adjusted as workforce roles change. Auditors typically look for a documented access control policy, SSO configuration showing federated control of apps, enforced MFA policies, RBAC or least-privilege group structures, a joiner-mover-leaver process with evidence of timely deprovisioning, controls for service and API accounts, device compliance or allowlisting, and logs showing successful and denied access attempts. Your System Security Plan should describe these controls, and you should retain screenshots, exported policy JSON, and reports from your IdP and MDM as artifacts.
A Practical Small-Business Architecture
Centralize identities and SSO
Adopt a single identity provider as your source of truth, then federate all business apps to it via SAML or OIDC. In Microsoft Entra ID or Okta, integrate major SaaS apps (Microsoft 365, Google Workspace, AWS, GitHub, Jira) so users never authenticate directly to apps with standalone passwords. Enable SCIM or directory sync to automatically provision and deprovision accounts based on HR status. For AWS, use AWS IAM Identity Center with SAML federation from your IdP and map groups to permission sets; disable local IAM users except for tightly controlled break-glass.
Enforce MFA everywhere, remove weak auth
Require phishing-resistant MFA for all interactive users and admins. In Entra ID, create Conditional Access policies that block legacy protocols, require MFA for all cloud apps, and enforce device compliance for sensitive apps. Prefer FIDO2 security keys or platform authenticators; fall back to app-based TOTP only when necessary. In Okta, set Global Session Policy to always require MFA, disable SMS unless justified, and set sign-on policies per app. Document exceptions, time-box them, and log approvals.
Implement RBAC and least privilege
Define roles tied to business functions (e.g., Engineering-Reader, Engineering-Contributor, Finance-AP, Helpdesk-Tier1, Cloud-Admin-JIT) and manage access via groups, not individuals. In Microsoft 365, use Entra ID PIM to make privileged roles eligible and require just-in-time activation with MFA, approvals, and time limits. In AWS, create permission sets that scope to specific accounts and services following least privilege; assign them to federated groups. In SaaS apps like GitHub, map IdP groups to org teams and repositories with code-owner protections. Prohibit shared accounts and inventory all service accounts with documented owners and least-privilege API tokens or workload identities.
Authorize devices and processes
Limit access to compliant devices using MDM and device compliance signals. In Intune or Google Endpoint Management, require disk encryption, screen lock, OS patch levels, and block jailbroken or rooted devices. Enforce Conditional Access that only allows compliant or hybrid-joined devices to reach sensitive resources like SharePoint CUI sites, code repositories, and admin portals. For processes and workloads, replace static API keys with workload identities (e.g., Entra Workload ID, AWS IAM Roles Anywhere or OIDC federation) and scope policies to the minimum actions and resources necessary.
Step-by-Step Example for a 30-Person Manufacturer
Day 1 centralize: make Microsoft Entra ID the authoritative IdP; sync users from HRIS via SCIM; federate Microsoft 365, AWS IAM Identity Center, GitHub, and Atlassian with SAML; disable direct local logins. Day 2 protect: enforce tenant-wide MFA with Conditional Access, block legacy auth, require device compliance for SharePoint sites tagged for CUI, and roll out FIDO2 keys. Day 3 restrict: create RBAC groups mapped to roles, migrate direct app permissions to group-based assignments, enable Entra PIM for Global Admin and Exchange Admin, and set JIT activation to 2 hours with approval. Day 4 harden service accounts: replace shared API keys with app registrations or AWS IAM roles, store secrets in a managed vault with rotation, tag each non-human identity with an owner and review date. Day 5 verify: run a user access review with department heads, remove unused entitlements, export audit logs, and capture screenshots of policies for the SSP.
Compliance Tips, Evidence, and Maintenance
Codify access control in policy, but back it with automation. Maintain a joiner-mover-leaver workflow integrated with your IdP so terminations disable access within minutes and movers trigger access reviews. Schedule quarterly entitlement reviews for high-risk apps and admin roles, and log approvals in a ticketing system. Save evidence like Conditional Access exports, PIM activation logs, AWS access analyzer findings, GitHub team permission reports, and MDM compliance reports. Test controls by attempting logins from non-compliant devices and from geographies you normally block, and retain the denied log entries. Keep a limited number of break-glass accounts protected by hardware keys, store their credentials offline, and monitor for any use with immediate incident review.
Technical Gotchas to Watch For
Do not leave legacy protocols enabled; disable POP/IMAP and basic auth in Microsoft 365 and enforce modern auth everywhere. Standardize session timeouts and reauthentication prompts for sensitive apps. In AWS, remove inline user policies and replace with managed permission sets via federation. Ensure SCIM deprovisioning actually removes app access rather than only disabling accounts. For VPN or Zero Trust Network Access, integrate with your IdP to require MFA and device posture checks. Monitor non-human identities with anomaly detection and rotate secrets at least every 90 days, or better, eliminate them with short-lived tokens.
Risk of Not Implementing
Without centralized SSO, enforced MFA, RBAC, and device authorization, a single stolen password or lost laptop can expose CUI and critical systems, enabling lateral movement, ransomware deployment, and data exfiltration. Overprivileged accounts amplify blast radius, shared credentials defeat accountability, and unmanaged service keys become long-lived backdoors. From a compliance standpoint, gaps in AC.L2-3.1.1 lead to findings, costly remediation plans, contract risk, and potential loss of business with primes or agencies.
Next Steps
Inventory identities, devices, and applications, then pick an IdP to centralize SSO within 30 days. Enforce MFA and block legacy auth within two weeks, implement role-based groups and JIT for privileged roles within a month, and require device compliance for sensitive resources shortly after. Update your System Security Plan with these controls, capture evidence, and schedule your first quarterly access review. If you need help, start with a focused workshop to map roles, apps, and device policies to AC.L2-3.1.1 and create an implementation backlog you can execute in sprints.
