ILC Dover LP and ILC Astrospace LLC have agreed to pay $13 million to resolve allegations of misrepresenting cybersecurity compliance in contracts with the Army, the Missile Defense Agency, and NASA. The Justice Department states that the conduct occurred from January 2018 to October 2024. This is the largest False Claims Act cybersecurity settlement to date. No liability has been determined, so consider these as lessons from allegations, not findings.
The allegations aren't unusual. They resemble issues found in routine assessments. That's the point.
Why These Mistakes Keep Happening
Compliance programs often fail at the seams. IT handles controls, business development signs contracts, and someone else completes the questionnaire. No one owns the claim that the entire system is compliant.
Time adds another layer. A contractor might sign a contract with good intentions, but implementation can lag for years while invoices continue. Each invoice can imply certification. The alleged period here spans nearly seven years.
Mistake 1: Assuming a Cloud Provider's Marketing Equals Authorization
Why it happens: Cloud vendors market "government-ready" or "compliant" environments, and procurement teams accept this without verification.
Consequence: The government alleges ILC stored Controlled Unclassified Information with an external cloud service provider without ensuring it met FedRAMP Moderate baseline requirements and DFARS requirements. Under DFARS 252.204-7012(b)(2)(ii)(D), an external provider handling covered defense information must meet FedRAMP Moderate baseline equivalency. The contractor is responsible for this diligence.
Fix: Before any CUI is stored in a cloud environment, verify the provider's status in the FedRAMP Marketplace. Confirm the specific service offering is in scope and obtain the Customer Responsibility Matrix. Map each control assigned to you under the Shared Responsibility Model to a named owner. Re-verify annually and whenever the provider changes services.
Mistake 2: Implementing Most Controls and Calling It Done
Why it happens: Teams focus on easy tasks and defer difficult ones. Percent-complete becomes a comfort metric.
Consequence: The government alleges ILC didn't fully implement NIST SP 800-171 and 800-53 controls, including those whose absence could enable significant network exploitation or exfiltration of controlled defense information. Partial implementation isn't a defense when a contract requires the full set.
Fix: Score every requirement individually. Rank gaps by exploitation risk and prioritize high-impact ones. Document each gap as not implemented, partially implemented, or implemented, with evidence for each. Never let a rollup percentage replace a requirement-level record.
Mistake 3: Treating the System Security Plan as Paperwork
Why it happens: The SSP is written once for an assessment, then filed away. Systems change, but the document doesn't.
Consequence: Allegations include failing to develop, implement, and update system security plans for each covered information system. NIST SP 800-171 requirement 3.12.4 requires an SSP that describes system boundaries, operating environments, and how requirements are met. An outdated SSP indicates unfounded representations.
Fix: Tie SSP review to change management. Any new system, cloud service, data flow, or boundary change should trigger an SSP update. Assign one accountable owner per covered system and require a dated sign-off at least annually.
Mistake 4: Skipping the POA&M
Why it happens: Teams fear a POA&M is an admission of weakness, so gaps go undocumented.
Consequence: The government alleges ILC did not develop and implement plans of action and milestones to identify and mitigate weaknesses. A POA&M (requirement 3.12.2) shows you know your gaps and are addressing them. Having no POA&M while having gaps means undocumented, unmanaged risk.
Fix: Log every gap with a responsible owner, a funded remediation action, and a target date. Review open items regularly. Be aware that under 32 CFR Part 170, POA&M use in CMMC assessments is restricted and time-bound, so don't treat it as a permanent parking lot.
Mistake 5: Ignoring the Person Who Knows the Most
Why it happens: Internal security staff raise concerns, leadership hears them as friction, and the escalation path ends in a manager's inbox.
Consequence: The settlement resolves a whistleblower suit filed by Philip Root, ILC's former Director of Cybersecurity. He'll receive $2.35 million of the settlement, and the contractor will pay $288,000 for his attorney's fees and expenses. Your cybersecurity lead is the most credible witness in a False Claims Act case because they know what you were told and what you knew.
Fix: Build a reporting channel that bypasses the line when the line is the problem, with a direct path from your security lead to the compliance officer, general counsel, and audit committee. Log concerns, track responses, and set a response deadline. Prohibit retaliation in writing and enforce it.
Prevention Checklist
- Every cloud service handling CUI is verified against the FedRAMP Marketplace at the offering level, with the Customer Responsibility Matrix on file.
- Each NIST SP 800-171 requirement has an individual status, an evidence artifact, and a named owner.
- An SSP exists for every covered system and is updated on any boundary, architecture, or cloud service change.
- A POA&M tracks every known gap with an owner, a date, and a funding decision.
- Any compliance representation in a proposal, SPRS entry, or invoice certification is reviewed against current evidence before it goes out.
- Your cybersecurity lead has a documented, non-retaliatory path to escalate directly to compliance and legal.
- Open escalations are reviewed at the leadership level on a fixed schedule.
- Flow-Down Requirements are reflected in subcontractor agreements and verified, not assumed.
Ask one question of every compliance claim your company makes: could someone inside your organization prove it wrong? If the answer is yes, fix the gap before they do.
