August 20, 2026
The numbers we see aren’t the whole picture.
The true number of cyber incidents reported across the Defense Industrial Base (DIB) isn’t publicly tallied. Reports made to the Department of Defense (DoD, “The Department”) Cyber Crime Center aren’t published or aggregated for public view. There is no running count anyone outside government can point to.
That lack of a public number can feel reassuring, but it shouldn’t. The absence of a count doesn’t mean an absence of risk. It simply means much of what’s happening stays out of view.
The threat is still visible if you know where to look: in industry breach data, in the Department’s own posture toward contractor security, and in the rare cases that do surface publicly, like a recent SEC filing from a defense contractor:
IEH Corporation
According to IEH Corporation’s own SEC disclosure, an employee allegedly responded to a phishing email disguised as a business inquiry, clicked a malicious link, and allegedly entered Microsoft 365 credentials into a fraudulent login page. The attacker allegedly gained mailbox access, potentially exposing customer communications, purchase orders, engineering documentation, and export controlled technical information. IEH stated there is no evidence information was stolen, but the incident was serious enough to become one of the few DIB cyber events visible to the public at all.
Why This One Became Visible
Two separate reporting obligations govern disclosure, and they rarely overlap in public view.
DFARS 252.204-7012 requires contractors to report a cyber incident affecting covered defense information to DC3 within 72 hours of discovery. That report is compliance driven and not public. The clock starts at discovery, not at some later determination of materiality.
Separately, SEC Item 1.05 requires public companies to disclose a cybersecurity incident within four business days once it’s determined to be material. That is a different bar, built for investors, and most DIB incidents never reach it.
The IEH filing is what made this incident visible to the public. Most DC3 reports never surface publicly at all. That is exactly why the scale of DIB cyber activity is undercounted rather than absent, and it’s worth sitting with that for a moment.
Somewhere right now, a smaller, less visible version of this exact incident is likely happening at another contractor who won’t file anything publicly, because they won’t have to.
This Isn’t Just a Defense Industry Problem
It would be easy to read the IEH incident as a DIB specific failure. It isn’t, and that’s actually the more important point.
A simple phishing email allegedly worked at IEH not because defense contractors are uniquely vulnerable, but because phishing remains one of the most effective ways into any organization, in any industry. Verizon’s 2025 Data Breach Investigations Report analyzed more than 22,000 incidents and over 12,000 confirmed breaches across sectors.
The human element remained a factor in most incidents overall.
Most cybersecurity failures don’t start with advanced malware. They start with one employee, one plausible-looking email, and one click.
That pattern is the real problem. Adversaries don’t need a sophisticated exploit when a single credential, an unreviewed privileged account, or an unmonitored mailbox will do the job for them. Minimizing the risk of Controlled Unidentified Information (CUI) exposure means closing those everyday weaknesses before they can be leveraged. And that takes more than any single framework point in time assessment.
It takes a resilience posture that sits underneath and beyond DFARS, NIST, and CMMC.
We understand this is a lot to absorb, especially with CMMC’s third party certification currently paused as of July 2026 while the Department reviews the program. We know that pause has created real uncertainty for organizations that were mid-journey toward assessment. That uncertainty is understandable.
But DFARS 252.204-7012 and NIST SP 800-171 self assessment obligations have not paused. They remain fully in force.
The inspection is paused. The building still has to be secure. Third-party verification may be paused, but the underlying security requirements are not.
Resilience is the work you do every day to protect CUI, whether an assessor is scheduled to walk through the door or not.
What Resilience Actually Means
Resilience is the capacity to prevent, detect, contain, and recover from an incident quickly enough that exposure doesn’t become loss.
It is not the presence or absence of a certificate, and it isn’t something you either have or don’t have on a single assessment day. It is built over time, regardless of sector or certification status, by closing the everyday gaps adversaries rely on, like stale credentials, unreviewed privileged access, and unmonitored mailboxes.
Reporting obligations under DFARS and the SEC continue regardless of where an organization sits on a assessment calendar. Resilience is what helps determine whether those obligations ever get triggered in the first place.
We know this can feel like the goalposts keep moving. Programs pause. Timelines shift. Guidance changes.
That responsibility isn’t diminished by a pause in providing 3rd party proof via certification. If anything, a period without the external validation organizations had been planning toward puts even more emphasis on building CUI defenses that actually fit your organization and work every day.
Questions Worth Asking Today
- Would our employees recognize a phishing attempt like this one?
- Is multi factor authentication enforced across every Microsoft 365 account, without exception? Could we quickly identify a compromised mailbox if it happened this afternoon?
- Are privileged accounts reviewed on a real cadence, not just when an audit is coming?
- Do we know exactly where our CUI lives and moves across our systems?
- Would we detect unusual account activity before an attacker had the chance to move laterally? And honestly, if this happened to us tomorrow, would our incident response process actually be ready, or would we be figuring it out in real time?
None of these questions wait on a certification. They require the same diligence that protects revenue, reputation, and every client relationship built on trust.
How Redspin Helps
Whether your organization is preparing for a future CMMC assessment, maintaining DFARS 252.204-7012 compliance in the meantime, or simply working to strengthen its overall security posture, Redspin helps DIB organizations assess, implement, and validate cybersecurity programs aligned to NIST SP 800-171 and CMMC.
From readiness assessments to managed compliance services, the goal is the same one that matters most right now: building the kind of resilience that protects CUI and, ultimately, helps safeguard our nation, regardless of how the certification landscape changes.
