If your small or medium business needs to comply with FAR 52.204-21 / CMMC 2.0 Level 1 (Control AC.L1-B.1.IV), this post gives you hands-on, practical steps to configure web browsers, SaaS applications, and cloud provider settings so authorized users and processes have only the access they need and nothing more.
\n\nAt Level 1, the Compliance Framework requirement mapped to FAR 52.204-21 focuses on basic safeguarding of Federal Contract Information (FCI). In plain terms: limit access to systems and data to authorized users, devices, and processes. Key objectives include account inventory and management, enforcing authentication and session controls, applying least privilege, and demonstrating configuration decisions via logs and documentation. For SMBs this usually means tightening configuration in web browsers, identity providers, SaaS admin consoles, and cloud consoles (AWS/Azure/GCP).
\n\nStart with an inventory: list all user accounts, service accounts, API keys, and third-party app integrations. Implement role-based access control (RBAC) or groups in your identity provider (e.g., Azure AD, Google Workspace, Okta) and assign permissions by role instead of individual exceptions. For cloud consoles, remove root/owner-level access from everyday use—create an administrative break-glass account stored offline for emergencies. Enforce MFA for all accounts that access FCI or admin consoles. Concrete values: set password policy to at least 12 characters, require rotation for service account keys annually, and set session timeout for console access to 15–60 minutes depending on sensitivity.
\n\nBrowsers are the front door for web apps—configure them to reduce exposure. Enforce the following via Group Policy, MDM, or browser management consoles: disable storage of credentials in plaintext, block third-party cookies where feasible, enable automatic updates, and use browser extensions only from a whitelisted list. Implement secure cookie attributes (Secure, HttpOnly, SameSite=strict) on your web apps, enable HSTS (Strict-Transport-Security) with a long max-age, and deploy Content-Security-Policy headers to limit cross-site script execution. Example: set session cookies to expire after 20 minutes of inactivity and require reauthentication for admin workflows.
\n\nEach cloud provider gives controls to enforce least privilege and restrict access. In AWS: enable MFA for the root account, use IAM roles instead of long-lived credentials for EC2/ECS, and enable S3 Block Public Access. Example minimal S3 block settings are enabled from the AWS Console or via the CLI. Turn on CloudTrail with multi-region logging and send logs to an encrypted, write-once S3 bucket for retention. Sample IAM policy (restrictive read-only for a finance role):
\n\n{\n \"Version\": \"2012-10-17\",\n \"Statement\": [\n {\n \"Effect\": \"Allow\",\n \"Action\": [\n \"s3:GetObject\",\n \"s3:ListBucket\"\n ],\n \"Resource\": [\n \"arn:aws:s3:::finance-bucket\",\n \"arn:aws:s3:::finance-bucket/*\"\n ]\n }\n ]\n}\nIn Azure: use Azure AD Conditional Access to require compliant devices and MFA for access to management or SharePoint sites containing FCI. In GCP: use IAM predefined roles and disable legacy roles; set VPC Service Controls to limit data exfiltration. For all providers, turn on provider-level MFA, and remove public exposure of management interfaces (use bastion hosts or VPN + private endpoints).
\n\nMost SMBs use SaaS (Microsoft 365, Google Workspace, Salesforce). Use SSO to centralize authentication and enforce MFA, device compliance, and contextual policies (location, IP). Configure app-scoped API tokens rather than account-scoped tokens where possible, rotate API keys, and periodically review third-party app access (OAuth consent screens). Example practical steps: in Google Workspace, disable less secure apps, require 2-step verification, and set a 90-day user session length for admin consoles; in Microsoft 365, enable Conditional Access policies that block legacy authentication.
\n\nTo meet Compliance Framework audit needs, enable and retain logs showing who accessed what and when. Centralize logs in a simple SIEM or log aggregation (Splunk, Elastic, or native cloud log viewer). Retain at least 90 days of detailed logs (adjust per contract) and export to immutable storage for the period your contract requires. Create a small set of alert rules for suspicious activities: failed logins from new geolocations, privilege changes, creation of new service keys, or removal of MFA. Export and snapshot your configuration pages (e.g., IAM policies, SSO settings) as part of evidence collection for assessments.
\n\nScenario: a 25-person subcontractor handling FCI uses Microsoft 365, AWS, and some SaaS CRM. Step-by-step: 1) Inventory accounts and map to roles. 2) Configure Azure AD groups and assign RBAC to Microsoft 365 and AWS via SSO. 3) Turn on MFA for all users and require compliant devices for admin roles via Conditional Access. 4) In AWS, remove console root use, enable MFA, enable CloudTrail + S3 write-once logs, enable S3 Block Public Access, and create least-privilege IAM roles for developers. 5) Harden browsers via Intune/GPO (auto-updates, disable password autofill for shared devices). 6) Document each configuration change and export screenshots/JSON for evidence. This pragmatic sequence gets you to compliance quickly while minimizing business disruption.
\n\nFailing to configure these settings risks unauthorized access to FCI, data exfiltration, contract loss, and significant reputational damage. For SMBs, that often translates to losing government contracts or facing remedial action. Compliance tips: prioritize the highest-impact controls first (MFA + least-privilege + logging), automate config checks (use CIS benchmarks and cloud provider configuration scanners like AWS Config/Azure Policy), and keep a simple policy document mapping each control to the actual setting and evidence location. Use change control and scheduled reviews (quarterly) so access does not creep upward over time.
\n\nSummary: For SMBs aiming to meet FAR 52.204-21 / CMMC 2.0 Level 1 (AC.L1-B.1.IV), focus on account inventory, RBAC/least-privilege, MFA, browser and cookie hardening, cloud IAM and network posture, SaaS token hygiene, and centralized logging; implement these in small prioritized steps, document every change, and automate continuous checks to maintain compliance without overwhelming your operations.
", "plain_text": "If your small or medium business needs to comply with FAR 52.204-21 / CMMC 2.0 Level 1 (Control AC.L1-B.1.IV), this post gives you hands-on, practical steps to configure web browsers, SaaS applications, and cloud provider settings so authorized users and processes have only the access they need and nothing more.\n\nUnderstanding the control and Compliance Framework objectives\nAt Level 1, the Compliance Framework requirement mapped to FAR 52.204-21 focuses on basic safeguarding of Federal Contract Information (FCI). In plain terms: limit access to systems and data to authorized users, devices, and processes. Key objectives include account inventory and management, enforcing authentication and session controls, applying least privilege, and demonstrating configuration decisions via logs and documentation. For SMBs this usually means tightening configuration in web browsers, identity providers, SaaS admin consoles, and cloud consoles (AWS/Azure/GCP).\n\nImplementation steps\n\nAccounts, IAM and least-privilege (practical actions)\nStart with an inventory: list all user accounts, service accounts, API keys, and third-party app integrations. Implement role-based access control (RBAC) or groups in your identity provider (e.g., Azure AD, Google Workspace, Okta) and assign permissions by role instead of individual exceptions. For cloud consoles, remove root/owner-level access from everyday use—create an administrative break-glass account stored offline for emergencies. Enforce MFA for all accounts that access FCI or admin consoles. Concrete values: set password policy to at least 12 characters, require rotation for service account keys annually, and set session timeout for console access to 15–60 minutes depending on sensitivity.\n\nWeb and browser configuration (practical controls)\nBrowsers are the front door for web apps—configure them to reduce exposure. Enforce the following via Group Policy, MDM, or browser management consoles: disable storage of credentials in plaintext, block third-party cookies where feasible, enable automatic updates, and use browser extensions only from a whitelisted list. Implement secure cookie attributes (Secure, HttpOnly, SameSite=strict) on your web apps, enable HSTS (Strict-Transport-Security) with a long max-age, and deploy Content-Security-Policy headers to limit cross-site script execution. Example: set session cookies to expire after 20 minutes of inactivity and require reauthentication for admin workflows.\n\nCloud provider specifics (AWS, Azure, GCP) with examples\nEach cloud provider gives controls to enforce least privilege and restrict access. In AWS: enable MFA for the root account, use IAM roles instead of long-lived credentials for EC2/ECS, and enable S3 Block Public Access. Example minimal S3 block settings are enabled from the AWS Console or via the CLI. Turn on CloudTrail with multi-region logging and send logs to an encrypted, write-once S3 bucket for retention. Sample IAM policy (restrictive read-only for a finance role):\n\n{\n \"Version\": \"2012-10-17\",\n \"Statement\": [\n {\n \"Effect\": \"Allow\",\n \"Action\": [\n \"s3:GetObject\",\n \"s3:ListBucket\"\n ],\n \"Resource\": [\n \"arn:aws:s3:::finance-bucket\",\n \"arn:aws:s3:::finance-bucket/*\"\n ]\n }\n ]\n}\n\n\nIn Azure: use Azure AD Conditional Access to require compliant devices and MFA for access to management or SharePoint sites containing FCI. In GCP: use IAM predefined roles and disable legacy roles; set VPC Service Controls to limit data exfiltration. For all providers, turn on provider-level MFA, and remove public exposure of management interfaces (use bastion hosts or VPN + private endpoints).\n\nSaaS, SSO and identity provider hardening\nMost SMBs use SaaS (Microsoft 365, Google Workspace, Salesforce). Use SSO to centralize authentication and enforce MFA, device compliance, and contextual policies (location, IP). Configure app-scoped API tokens rather than account-scoped tokens where possible, rotate API keys, and periodically review third-party app access (OAuth consent screens). Example practical steps: in Google Workspace, disable less secure apps, require 2-step verification, and set a 90-day user session length for admin consoles; in Microsoft 365, enable Conditional Access policies that block legacy authentication.\n\nLogging, monitoring, and demonstrating compliance\nTo meet Compliance Framework audit needs, enable and retain logs showing who accessed what and when. Centralize logs in a simple SIEM or log aggregation (Splunk, Elastic, or native cloud log viewer). Retain at least 90 days of detailed logs (adjust per contract) and export to immutable storage for the period your contract requires. Create a small set of alert rules for suspicious activities: failed logins from new geolocations, privilege changes, creation of new service keys, or removal of MFA. Export and snapshot your configuration pages (e.g., IAM policies, SSO settings) as part of evidence collection for assessments.\n\nReal-world SMB scenario and step-by-step checklist\nScenario: a 25-person subcontractor handling FCI uses Microsoft 365, AWS, and some SaaS CRM. Step-by-step: 1) Inventory accounts and map to roles. 2) Configure Azure AD groups and assign RBAC to Microsoft 365 and AWS via SSO. 3) Turn on MFA for all users and require compliant devices for admin roles via Conditional Access. 4) In AWS, remove console root use, enable MFA, enable CloudTrail + S3 write-once logs, enable S3 Block Public Access, and create least-privilege IAM roles for developers. 5) Harden browsers via Intune/GPO (auto-updates, disable password autofill for shared devices). 6) Document each configuration change and export screenshots/JSON for evidence. This pragmatic sequence gets you to compliance quickly while minimizing business disruption.\n\nRisks of not implementing and compliance tips\nFailing to configure these settings risks unauthorized access to FCI, data exfiltration, contract loss, and significant reputational damage. For SMBs, that often translates to losing government contracts or facing remedial action. Compliance tips: prioritize the highest-impact controls first (MFA + least-privilege + logging), automate config checks (use CIS benchmarks and cloud provider configuration scanners like AWS Config/Azure Policy), and keep a simple policy document mapping each control to the actual setting and evidence location. Use change control and scheduled reviews (quarterly) so access does not creep upward over time.\n\nSummary: For SMBs aiming to meet FAR 52.204-21 / CMMC 2.0 Level 1 (AC.L1-B.1.IV), focus on account inventory, RBAC/least-privilege, MFA, browser and cookie hardening, cloud IAM and network posture, SaaS token hygiene, and centralized logging; implement these in small prioritized steps, document every change, and automate continuous checks to maintain compliance without overwhelming your operations." }, "metadata": { "description": "Practical, step-by-step guidance for small and medium businesses to configure web browsers, SaaS, and cloud settings to satisfy FAR 52.204-21 / CMMC 2.0 Level 1 access control requirements.", "permalink": "/how-to-configure-web-and-cloud-settings-to-meet-far-52204-21-cmmc-20-level-1-control-acl1-b1iv-practical-implementation-for-smbs.json", "categories": [], "tags": [] } }