CMMC 2.0 and application security: What defense contractors need to build now

CMMC timeline so far – and what’s already required

The US Department of Defense (DoD) put Phase 1 of CMMC into effect in November 2025. Phase 1 requires self-assessments in applicable solicitations and contracts, and it’s already active. 

On July 13, 2026, the DoD suspended Phase 2 – which would have required mandatory third-party certification assessments from Certified Third-Party Assessor Organizations (C3PAOs) – and launched a 60-day reform review. The stated reason was practical: with more than 100,000 Defense Industrial Base (DIB) companies still needing third-party assessments and only around 100 approved assessors available to conduct them, DoD CIO Kirsten Davies acknowledged that “the math just simply doesn’t math for small to medium-sized businesses to even get compliant by the transition date.”

But the suspension doesn’t change what’s in contracts already. DFARS clause 252.204-7012 remains in force. The obligation to implement all 110 security requirements from NIST SP 800-171 Revision 2, submit self-assessment scores to the Supplier Performance Risk System (SPRS), and report cyber incidents is unchanged. Prime contractors are already flowing CMMC obligations down to their subcontractors, and the DoD has stated it will continue to enforce compliance through self-assessments and select government-led assessments during the review. 

A CMMC Reform Task Force is conducting a top-to-bottom review of the program, and its findings and any resulting changes to phase requirements will be published on the DoD CIO website. What that report produces – a revised program, a lighter version, or a restored timeline – is an open question, but the underlying contractual requirements are clear. The case for building a clean, continuous, evidence-backed application security program now doesn’t rest on any particular phase date going forward unchanged. It rests on what’s already required – and on an enforcement mechanism that the phase schedule doesn’t control.

Enforcement runs on a separate track and is very much active. The DoJ’s Civil Cyber-Fraud Initiative has pursued False Claims Act cases against contractors who misrepresent their cybersecurity posture, using DFARS 252.204-7012 and not CMMC phase milestones as the basis for liability. In June 2026, LOGZONE Inc., a Huntsville, Alabama defense contractor, agreed to pay $507,144 to resolve allegations that it had submitted fraudulent claims on two Navy contracts while failing to implement required NIST SP 800-171 controls. LOGZONE had self-reported a perfect SPRS score of 110 – while a subsequent DIBCAC audit put the actual score at negative 170. That case wasn’t brought under CMMC. It was brought under the existing contractual cybersecurity requirements, which the Phase 2 suspension leaves untouched.

What CMMC 2.0 actually requires

CMMC 2.0 is a tiered framework:

• Level 1 (foundational) covers organizations that handle only FCI, requires 17 basic safeguarding practices, and is satisfied by an annual self-assessment. 
• Level 2 (advanced) applies to organizations that handle CUI – the more sensitive category – and requires implementing all 110 security requirements drawn from NIST SP 800-171 Rev. 2 across 14 control families. Most Level 2 contracts were expected to require third-party certification when Phase 2 was active; during the current suspension, the DoD is limiting new designations to self-assessed paths. 
• Level 3 (expert) adds requirements from NIST SP 800-172 for the most sensitive programs and involves assessment by the Defense Industrial Base Cybersecurity Assessment Center (DIBCAC); it is also suspended pending the review.

Level 2 is where most contractors’ pressure lives, so it’s the main focus of this article. CMMC Level 2 is not a separate framework from NIST SP 800-171 – it is that standard, with verification layered on top. The 14 control families cover everything from access control and incident response to physical protection and personnel security.

Note: CMMC Level 2 assessments are conducted against NIST SP 800-171 Revision 2. While Revision 3 was published by NIST in 2024 and supersedes the previous version, it has not yet been incorporated into the CMMC program rule

Assessment results feed the SPRS, which contracting officers review before awarding contracts. Gaps in implementation can be documented in a Plan of Action and Milestones (POA&M) with defined remediation timelines, though a defined subset of high-priority requirements must be fully met with no POA&M allowed. The System Security Plan (SSP) documents how each requirement is implemented within your environment and defines the system boundary – it’s the reference document an assessor or contracting officer works from.

One crucial point that’s frequently overlooked: CMMC applies down the supply chain. If a prime contractor handles CUI, its subcontractors – including software vendors, SaaS providers, and IT service firms whose systems touch the prime’s CUI environment – can be pulled into scope through flow-down clauses, even without a direct DoD contract of their own.

Why application security is one part of the required answer

Fourteen control families is a broad scope. Most of them – physical protection, personnel security, media protection, maintenance, configuration management of physical devices – are unrelated to application security. But five of those 14 families have direct, specific technical requirements that application security testing and management contribute to in a meaningful and documentable way:

• Risk Assessment (RA)
• System and Information Integrity (SI)
• Security Assessment (CA)
• Configuration Management (CM)
• Audit and Accountability (AU)

These families contain the specific activities that a modern AppSec program is designed to support: periodic vulnerability scanning, flaw identification and remediation, continuous monitoring, POA&M tracking, and audit log retention.

How key CMMC requirements map to AppSec practices

Five families out of 14 might seem a narrow slice, but these are the families where an assessor will look for technical evidence of controls operating continuously, not just policies on paper. Getting them right requires documented, repeatable practices rather than one-time activity. The sections below walk through what each family asks for and what that means in practice in the specific context of application security.

Risk Assessment control – periodic, documented vulnerability scanning

The Risk Assessment family requires organizations to periodically scan their systems and applications for vulnerabilities and to remediate those findings in accordance with risk assessments (RA.L2-3.11.2 and RA.L2-3.11.3). The word “periodically” matters here. A once-a-year penetration test satisfies a calendar requirement but leaves long windows between assessments during which new vulnerabilities can be introduced, whether through a new code deployment, a new dependency, or a newly disclosed CVE.

A recurring, automated dynamic application security testing (DAST) program running against your live applications gives you the continuous coverage the requirement envisions. Combined with SAST and SCA scanning earlier in the development cycle, it creates a program that catches vulnerabilities at the point they’re introduced, not months later. The “in accordance with risk” language in RA.L2-3.11.3 is where the quality of findings matters as much as their quantity: a remediation queue flooded with false positives makes genuine and effective risk prioritization nearly impossible. Verification features like proof-based scanning, which automatically verifies many types of vulnerabilities to confirm they’re real and exploitable, directly address this – teams can put confirmed, high-risk findings at the top of the queue, distinct from triaging noise.

System and Information Integrity control – timely flaw identification and correction

The System and Information Integrity family requires organizations to identify, report, and correct system and application flaws in a timely manner (SI.L2-3.14.1). A subset of SI requirements must be met even with no POA&M available, making these among the harder constraints in Level 2. “Timely” isn’t defined in the control text, but assessors look for evidence that your program treats exploitable findings differently from theoretical ones – that you have a process connecting discovery to remediation, and that high-severity findings move through that process faster.

Runtime-verified prioritization, which uses dynamic runtime intelligence to validate whether a statically identified flaw is actually exploitable in the running application, gives teams the exploitability context needed to set realistic, defensible remediation timeframes. When a developer or a remediation team asks how urgent an issue is, the answer should come from verified runtime evidence, not from a CVSS score in isolation.

Security Assessment control – continuous monitoring and POA&M management

The Security Assessment family requires periodic assessment of security controls, ongoing monitoring, and maintaining an SSP that documents the current state of implementation (CA.L2-3.12.1 through CA.L2-3.12.4). This is also where POA&M tracking lives – the formal record of what’s not yet fully implemented, the timeline for closing the gap, and the compensating controls in place in the meantime.

This is where application security posture management (ASPM) earns its place in a CMMC program. ASPM centralizes findings across testing types, tracks remediation status over time, and surfaces the kind of evidence that an SSP references and that a C3PAO or self-assessor actually reviews, including current control posture, findings history, and remediation trends. Moving from a collection of point-in-time scan reports to a continuous, aggregated view of your AppSec posture is the operational difference between satisfying the letter of the requirement and being able to demonstrate it credibly under assessment conditions.

Configuration Management control – vulnerability tracking through the change process

The Configuration Management family requires establishing baseline configurations and controlling changes to systems (CM.L2-3.4.1 through CM.L2-3.4.5). In an AppSec context, this means vulnerability tracking needs to be tied into your change-control processes so that a finding doesn’t just sit in a scan report but flows into the same ticketing and code management workflows where the fix actually happens.

Integrations between an AppSec platform and developer tooling – issue trackers, code repositories, CI/CD pipelines – make remediation work auditable rather than anecdotal. When a finding is opened, assigned, fixed, and verified, that lifecycle should be traceable in the same systems a change-management audit trail draws on.

Audit and Accountability control – the evidence trail reviewed by assessors

The Audit and Accountability family requires generating, retaining, and reviewing records sufficient to show what happened and when (AU.L2-3.3.1 through AU.L2-3.3.9). For an AppSec program, that translates to: scan logs, finding records, remediation history, monitoring reports, and evidence that the program runs continuously rather than being assembled retroactively before an assessment.

This is the layer that ties everything else together. A technically sound AppSec program that doesn’t produce durable, reviewable records is harder to defend under assessment than a slightly less technically sophisticated program that does. Self-assessors populating SPRS scores and C3PAOs conducting formal reviews both draw on the same underlying evidence.

How Invicti supports the technical work

Invicti provides an application security platform with an integrated suite of discovery, testing, and management tools built around industry-leading DAST and API security capabilities. Its runtime intelligence approach means that dynamic findings are used to validate and prioritize results from static analysis tools, reducing the noise that makes risk-based programs hard to operate at scale.

Across the five CMMC domains discussed above, the Invicti Platform supports the technical work in several specific ways:

• Recurring DAST scans, scheduled across your application inventory and triggered within CI/CD pipelines, give you the periodic and continuous coverage that Risk Assessment requirements call for. 
• API security testing extends that coverage to REST, SOAP, and GraphQL interfaces – relevant for any contractor whose CUI-handling environment includes web services or internal APIs.
• Proof-based scanning verifies whether findings are genuinely exploitable, which is the operational prerequisite for remediating “in accordance with risk.” Remediation teams can rank confirmed, high-risk findings at the top of the queue rather than working through a mix of real vulnerabilities and false positives.
• DAST-SAST correlation and runtime-verified prioritization map to the flaw identification and timely correction requirements in System and Information Integrity. Knowing that a statically identified vulnerability is also reachable and exploitable at runtime gives teams the context they need to set realistic, defensible remediation timelines.
• ASPM ties the Security Assessment, Audit and Accountability, and Configuration Management evidence together in one place. Centralizing findings from DAST, SAST, SCA, and API testing, tracking remediation status through integrations with developer tooling like Jira, GitHub, and Azure DevOps, and generating compliance and executive reporting creates the continuous, auditable record that a self-assessor populating an SPRS score or a C3PAO reviewing your SSP will draw on.

Invicti’s SCA and software bill of materials (SBOM) capabilities round out the platform’s supply-chain risk coverage – an area that sits adjacent to the core CMMC control families but is increasingly relevant to any contractor with open-source dependencies in CUI-handling systems.

An application security platform such as Invicti supports the technical work behind five of the 14 control families to build and maintain the evidence assessors actually review. A C3PAO certifies your organization when required; an SSP documents your full system environment; a POA&M tracks gaps across all 14 families – and Invicti’s role is building and maintaining the technical evidence behind the application security controls those assessors review.

Building a defensible AppSec program in a CMMC environment

The requirements are in your contracts today, and the enforcement mechanism behind them doesn’t pause with the phase schedule. The most time-consuming part of any assessment – establishing continuous scanning, reducing false-positive noise so remediation can actually be risk-based, building an evidence trail that holds up to review – takes months to do well. The contractors who move through assessments most smoothly are the ones who didn’t wait to start that work until the deadline was confirmed.

If you’d like to see how the Invicti platform supports the technical work behind CMMC’s AppSec-relevant controls, contact our team to walk through your specific environment and compliance context.

‍

Disclaimer: The CMMC program is a live regulatory process. Phase dates, assessment requirements, and program structure are subject to change pending the outcome of the DoD’s 60-day CMMC Reform Task Force review, which was launched July 13, 2026. Verify current program status at dodcio.defense.gov and acquisition.gov before acting on any specific date or requirement referenced here.