This post provides a practical, actionable checklist to implement the FAR 52.204-21 / CMMC 2.0 Level 1 access-control requirement (AC.L1-B.1.IV) on WordPress and other content management systems (CMS), with step-by-step technical details, small-business examples, and evidence items to demonstrate compliance to auditors.
\n\nBegin by scoping: identify every CMS instance (WordPress, Drupal, Joomla, headless CMS, hosted SaaS sites), the environment (production, staging, dev), and what Controlled Unclassified Information (CUI) or other sensitive contractor information each stores or processes. For small businesses, a simple spreadsheet with columns: hostname, CMS type/version, admin contact, hosting provider, SSL status, plugins, and last patch date is sufficient to start meeting the Compliance Framework's expectation of knowing where controlled data lives.
\n\nFor WordPress sites, implement these concrete, technical controls: enforce HTTPS, lock down admin editing, rotate salts, and prevent filesystem changes from the dashboard. Add the following to wp-config.php (replace placeholders appropriately):
define('FORCE_SSL_ADMIN', true);\ndefine('DISALLOW_FILE_EDIT', true); // prevents editing themes/plugins from WP admin\n// set authentication keys and salts from https://api.wordpress.org/secret-key/1.1/salt/\nOther steps: remove or rename default \"admin\" user, use unique DB table prefixes (for legacy installs consider migrating), disable XML-RPC if not needed (add_filter('xmlrpc_enabled', '__return_false');), and keep core/plugins/themes updated. Use a staging site for plugin/theme testing before production updates to reduce downtime risk.
AC.L1-B.1.IV expects access controls that limit unauthorized access attempts. For WordPress, use an application-level plugin such as \"Limit Login Attempts Reloaded\", \"Wordfence\", or \"iThemes Security\" to block repeated failed logins and throttle requests. For greater control, implement server-level blocking with Fail2Ban to scan web server logs and ban IP addresses that POST to /wp-login.php or /xmlrpc.php. Example Fail2Ban filter and jail (conceptual):
# /etc/fail2ban/filter.d/wp-login.conf\n[Definition]\nfailregex = ^ .* \"POST /wp-login.php\n# /etc/fail2ban/jail.local\n[wp-login]\nenabled = true\nport = http,https\nfilter = wp-login\nlogpath = /var/log/nginx/access.log\nmaxretry = 5\nbantime = 3600\n For hosted platforms where server logs are not accessible, rely on vendor WAF protections (Cloudflare, Sucuri) and application plugins, and document the protection configuration as evidence.
\n\nRequire multi-factor authentication (MFA) for all admin and privileged users. For WordPress use plugins such as \"WP 2FA\", \"Two Factor Authentication\" or hardware-backed FIDO2 solutions where possible. Enforce strong password policies and use a company-managed password manager (1Password, Bitwarden, LastPass Enterprise) to generate and share credentials securely with role-based vaults. For CMMC Level 1/ FAR 52.204-21 scope, even TOTP (time-based OTP) for administrators satisfies basic MFA expectations.
\n\nDrupal: enable Two-Factor Authentication modules (TFA), use Flood Control settings to limit login attempts, and restrict /user/login via .htaccess or IP allowlists for admin paths. Joomla: use \"Admin Tools\" and \"Two Factor Authentication\" plugins, rename admin accounts, and lock down administrator directory access. For hosted SaaS CMS (e.g., Wix, Squarespace) use the platform's MFA, role-based accounts, and vendor-provided security controls—capture screenshots and vendor docs as evidence for auditors.
\n\nLogging and account lifecycle are essential evidence items. Enable and retain audit logs showing admin logins, failed login attempts, password resets, and account creation/deletion for at least the period required by prime contract terms (document your retention policy). Implement an onboarding/offboarding checklist (create account, assign role, enable MFA, provision access; revoke access on termination and rotate any shared credentials). Automate periodic access reviews (quarterly) where the site owner verifies user lists and privileges—store signed attestations in your compliance repository.
\n\nTo demonstrate compliance with the Compliance Framework, collect these artifacts: inventory spreadsheet, hardened configuration snippets (wp-config additions, .htaccess rules), plugin/config snapshots (screenshots of rate-limiting and MFA settings), Fail2Ban / WAF rules, patch/update logs, account review records, incident response playbook, and backups with retention logs. Best practices: use the principle of least privilege for all CMS accounts, centralize admin accounts in an identity provider where possible (Okta, Azure AD) with SSO + MFA, and maintain a change log for plugin/theme updates.
\n\nFailing to implement these controls leaves CMS platforms vulnerable to credential stuffing, brute-force attacks, unauthorized access by ex-employees or contractors, and lateral movement into other systems. A practical small-business example: a 10-person engineering subcontractor left a default admin account and no MFA in place; attackers exploited weak passwords, accessed project files containing CUI, and the subcontractor lost the prime contract and incurred remediation costs exceeding the firm's annual revenue. Beyond direct loss, contract disqualification, penalties, and reputational damage are realistic risks.
\n\nMeeting FAR 52.204-21 / CMMC 2.0 Level 1 control AC.L1-B.1.IV on WordPress and other CMS is straightforward if you follow a repeatable checklist: inventory systems, enforce HTTPS and secure configs, limit login attempts (plugin or Fail2Ban/WAF), require MFA, enforce least privilege, log and review access regularly, and retain artifacts for auditors. For small businesses, prioritize practical, documented steps (MFA + login throttling + account reviews) to get the majority of risk reduction quickly while building out full evidence and automation over time.
", "plain_text": "This post provides a practical, actionable checklist to implement the FAR 52.204-21 / CMMC 2.0 Level 1 access-control requirement (AC.L1-B.1.IV) on WordPress and other content management systems (CMS), with step-by-step technical details, small-business examples, and evidence items to demonstrate compliance to auditors.\n\nPractical implementation checklist (high level)\n\n1) Scope and inventory\nBegin by scoping: identify every CMS instance (WordPress, Drupal, Joomla, headless CMS, hosted SaaS sites), the environment (production, staging, dev), and what Controlled Unclassified Information (CUI) or other sensitive contractor information each stores or processes. For small businesses, a simple spreadsheet with columns: hostname, CMS type/version, admin contact, hosting provider, SSL status, plugins, and last patch date is sufficient to start meeting the Compliance Framework's expectation of knowing where controlled data lives.\n\n2) WordPress — hardening and configuration (concrete steps)\nFor WordPress sites, implement these concrete, technical controls: enforce HTTPS, lock down admin editing, rotate salts, and prevent filesystem changes from the dashboard. Add the following to wp-config.php (replace placeholders appropriately):\ndefine('FORCE_SSL_ADMIN', true);\ndefine('DISALLOW_FILE_EDIT', true); // prevents editing themes/plugins from WP admin\n// set authentication keys and salts from https://api.wordpress.org/secret-key/1.1/salt/\n\nOther steps: remove or rename default \"admin\" user, use unique DB table prefixes (for legacy installs consider migrating), disable XML-RPC if not needed (add_filter('xmlrpc_enabled', '__return_false');), and keep core/plugins/themes updated. Use a staging site for plugin/theme testing before production updates to reduce downtime risk.\n\n3) Limit login attempts and block brute-force\nAC.L1-B.1.IV expects access controls that limit unauthorized access attempts. For WordPress, use an application-level plugin such as \"Limit Login Attempts Reloaded\", \"Wordfence\", or \"iThemes Security\" to block repeated failed logins and throttle requests. For greater control, implement server-level blocking with Fail2Ban to scan web server logs and ban IP addresses that POST to /wp-login.php or /xmlrpc.php. Example Fail2Ban filter and jail (conceptual):\n# /etc/fail2ban/filter.d/wp-login.conf\n[Definition]\nfailregex = ^ .* \"POST /wp-login.php\n# /etc/fail2ban/jail.local\n[wp-login]\nenabled = true\nport = http,https\nfilter = wp-login\nlogpath = /var/log/nginx/access.log\nmaxretry = 5\nbantime = 3600\n\nFor hosted platforms where server logs are not accessible, rely on vendor WAF protections (Cloudflare, Sucuri) and application plugins, and document the protection configuration as evidence.\n\n4) Multi-factor authentication and passwords\nRequire multi-factor authentication (MFA) for all admin and privileged users. For WordPress use plugins such as \"WP 2FA\", \"Two Factor Authentication\" or hardware-backed FIDO2 solutions where possible. Enforce strong password policies and use a company-managed password manager (1Password, Bitwarden, LastPass Enterprise) to generate and share credentials securely with role-based vaults. For CMMC Level 1/ FAR 52.204-21 scope, even TOTP (time-based OTP) for administrators satisfies basic MFA expectations.\n\n5) Other CMS specifics (Drupal, Joomla, hosted CMS)\nDrupal: enable Two-Factor Authentication modules (TFA), use Flood Control settings to limit login attempts, and restrict /user/login via .htaccess or IP allowlists for admin paths. Joomla: use \"Admin Tools\" and \"Two Factor Authentication\" plugins, rename admin accounts, and lock down administrator directory access. For hosted SaaS CMS (e.g., Wix, Squarespace) use the platform's MFA, role-based accounts, and vendor-provided security controls—capture screenshots and vendor docs as evidence for auditors.\n\nMonitoring, logging, and lifecycle policies\n\nLogging and account lifecycle are essential evidence items. Enable and retain audit logs showing admin logins, failed login attempts, password resets, and account creation/deletion for at least the period required by prime contract terms (document your retention policy). Implement an onboarding/offboarding checklist (create account, assign role, enable MFA, provision access; revoke access on termination and rotate any shared credentials). Automate periodic access reviews (quarterly) where the site owner verifies user lists and privileges—store signed attestations in your compliance repository.\n\nCompliance tips, artifacts, and best practices\n\nTo demonstrate compliance with the Compliance Framework, collect these artifacts: inventory spreadsheet, hardened configuration snippets (wp-config additions, .htaccess rules), plugin/config snapshots (screenshots of rate-limiting and MFA settings), Fail2Ban / WAF rules, patch/update logs, account review records, incident response playbook, and backups with retention logs. Best practices: use the principle of least privilege for all CMS accounts, centralize admin accounts in an identity provider where possible (Okta, Azure AD) with SSO + MFA, and maintain a change log for plugin/theme updates.\n\nRisk of not implementing AC.L1-B.1.IV\n\nFailing to implement these controls leaves CMS platforms vulnerable to credential stuffing, brute-force attacks, unauthorized access by ex-employees or contractors, and lateral movement into other systems. A practical small-business example: a 10-person engineering subcontractor left a default admin account and no MFA in place; attackers exploited weak passwords, accessed project files containing CUI, and the subcontractor lost the prime contract and incurred remediation costs exceeding the firm's annual revenue. Beyond direct loss, contract disqualification, penalties, and reputational damage are realistic risks.\n\nSummary\n\nMeeting FAR 52.204-21 / CMMC 2.0 Level 1 control AC.L1-B.1.IV on WordPress and other CMS is straightforward if you follow a repeatable checklist: inventory systems, enforce HTTPS and secure configs, limit login attempts (plugin or Fail2Ban/WAF), require MFA, enforce least privilege, log and review access regularly, and retain artifacts for auditors. For small businesses, prioritize practical, documented steps (MFA + login throttling + account reviews) to get the majority of risk reduction quickly while building out full evidence and automation over time." }, "metadata": { "description": "Practical, step-by-step checklist for meeting the FAR 52.204-21 / CMMC 2.0 Level 1 access-control requirement for WordPress and other CMS platforms.", "permalink": "/implementing-far-52204-21-cmmc-20-level-1-control-acl1-b1iv-in-wordpress-and-other-cms-a-practical-checklist.json", "categories": [], "tags": [] } }