Defense contractors are being asked to demonstrate they can protect controlled unclassified information (CUI) and the government is in the process of re-evaluating how that protection is measured. The suspension of the Cybersecurity Maturity Model Certification (CMMC) Phase 2 third-party assessment requirements has in effect reignited the question of whether automated, artificial intelligence-based penetration testing could be a faster, cheaper alternative to the current model of independent assessment.
It’s a very attractive proposition. A test that is continually probing the system is far more relevant than one that only happens every three years. The two approaches are however answering very different questions and conflating them would be to substitute one flawed measure of security for another.
The July 2026 CMMC reform effort called for discussion of the existing state of commercial cybersecurity and self-attestation. Take that as a policy question, not as an indication that AI penetration testing will become a federal requirement. The underlying obligations of safeguarding covered defense information, as per Defense Federal Acquisition Regulation Supplement 252.204-7012 and National Institute of Standards and Technology Special Publication 800-171, are still very much in force for contractors.
The case for adversarial testing is strong. Attackers do not wait for an assessment window. They exploit exposed devices, misconfigurations and unpatched vulnerabilities when an opening appears. The 2026 Verizon Data Breach Investigations Report identified vulnerability exploitation as a leading initial access path. A periodic review cannot accurately tell a contractor whether a newly exposed service is exploitable today.<![CDATA[]]>
Automated penetration testing can help close that timing gap. It can repeatedly check reachable assets, attempt the exploitation within the bounds of what’s allowed and then retest the fix. For some of the technical controls, evidence that an attack actually failed may be more convincing than a policy stating that the control should be in place.
A penetration test is not in any way a complete analysis of how CUI is protected. A great many breaches are the result of stolen credentials, compromised third parties or the simple misuse of legitimate access. A tool that’s probing the network perimeter is simply not going to see the sensitive data being copied to an unauthorized collaboration site, sent via a normal email or left on an unmanaged device. A successful exploit doesn’t tell you whether the defenders would even detect and contain a skilled attacker who was already inside.
Independent assessments have their own limitations. They look at the documented controls, interview the people and look at the evidence of implementation. They can only assess the state of things at a particular point in time and can’t in any way guarantee that the environment will remain secure once they’ve left. That said, the breadth of their assessment is important. Security governance, people practices, external service providers, incident response and the actual handling of CUI are not things that can be reduced to a series of automated attacks.
Another distinction worth considering is independence. A contractor can have a sophisticated test platform and still have complete control over which systems are tested, how the platform is configured and what the results are reported. Greater automation does not necessarily lead to independent evidence.
That concern is not theoretical. The gap between self-reported cybersecurity scores and the scores assigned by the government has in fact been a factor in False Claims Act enforcement. One example cited by law firm Arnold & Porter involved a contractor who had reported a perfect score which was in stark contrast to a later Defense Industrial Base Cybersecurity Assessment Center evaluation. The point is not that self-assessment is inherently unreliable. The risk of unverified claims is a separate risk from the technical vulnerabilities they may in fact be describing.
The better approach is layered assurance. First, independently confirm that the required controls are in place and that the stated CUI boundary is indeed where the sensitive information actually is. Second, test the exposed technical controls continuously or following any significant change. Third, run some detection and response exercises to see whether the security team can actually detect and contain an adversary using legitimate accounts and standard admin tools.
Those layers should feed into each other. If discovery finds CUI outside of the approved boundary, then that finding should modify the assessment scope. If adversarial testing exposes a weak access path, then you document the remediation and retest. If a response exercise shows that the malicious activity went completely undetected, then a clean vulnerability scan should not be taken as evidence of readiness.<![CDATA[]]>
Cost is the other reason why policymakers should be wary of treating automated testing as a simple drop in. The cost of AI tools may seem low when you look at it on a per call basis, but the reality is that the amount of work involved in a sustained testing campaign is considerable. You’ve got reconnaissance, you’ve got exploit attempts, you’ve got evidence analysis, you’ve got reporting and you’ve got the need to validate everything repeatedly. The more systems, the more applications, the more findings, the more work you end up with.
Cape Endeavors conducted an analysis, published in a recent white paper using a hypothetical scenario of 500 hosts and 20 web apps. The analysis of the underlying model suggested a model token cost of around $395 for a single on-demand test cycle as opposed to around $4,200 per month for a high frequency continuous design. These are illustrative compute costs only and not actual market quotes or all in contractor prices. They don’t include vendor margins, infrastructure, human review and, most crucially, the engineering effort required to fix the issues found. Different architectures and different testing cadences would lead to very different costs.
That distinction is important for the small and midsize business within the defense industrial base. A requirement to test continuously would turn what might have been a one-off assessment cost into a perpetual operating cost. If government policy eventually defines the scope, the frequency or indeed the class of service providers that can carry out the testing, then the contractor would have very little flexibility in managing that obligation. There should not be any assumption today of a universal Level 2 AI testing mandate.
Contractors can still make good decisions at this stage. They should have an accurate inventory of CUI and the systems that process it, maintain their system security plans and plans of action up to date, minimize unnecessary exposure and document any changes and remediation. Better scoping will lead to both a lower security risk and a lower number of systems to test. Fewer recurring misconfigurations will in turn lead to fewer alerts to investigate and fewer issues to retest.
For federal policymakers, the principle is simple: Define the assurance outcome first and then pick the tool. Ask yourself whether the approach in question will verify implementation, will find CUI outside of the authorized boundaries, will find exploitable weaknesses, will measure detection and response. You need credible evidence and clear accountability for exclusions and outstanding findings. Then you must look at the ongoing cost to the contractor base.
AI can speed up technical validation and make it more frequent. It can’t on its own prove that all the appropriate safeguards are in place, that all CUI is in the right place or that the organization will deal with compromise appropriately. The point isn’t to pick between human assessment and machine testing. The point is to stop treating either of them as the complete answer.
Terrence J. McGraw is a retired U.S. Army lieutenant colonel and chief executive officer of Cape Endeavors.
Copyright
© 2026 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.
——————————————————-
Click Here For The Original Source.
