For the past couple of months I have been conducting deep security research into the firmware running inside protection relays deployed across the U.S. power grid. What I found was sobering. Not because the vulnerabilities were surprising to discover — but because of how long they had been there, how many devices were affected, and how straightforward they were to identify once you knew where to look.
Through static analysis of production firmware — no live system access, no lab hardware, no exploitation of deployed devices — I documented 35+ critical vulnerabilities across multiple firmware components affecting tens of thousands of devices deployed globally in critical infrastructure. Every finding was coordinated through CISA ICS-CERT following responsible disclosure protocols. CVE assignments are pending public release.
The research answered one question clearly. The vulnerabilities are findable. The methodology works. Static analysis of ICS firmware produces court-admissible, publication-ready evidence of architectural security failures without touching a single live device.
But the research raised a more important question. If one researcher working independently can find this much in this little time — what is happening across the hundreds of other ICS firmware platforms deployed in critical infrastructure that nobody has analyzed yet?
The answer is uncomfortable. Most ICS firmware has never been systematically analyzed for security vulnerabilities. Not because the problems are not there. Because the process of finding them is too slow, too complex, and requires expertise that most organizations do not have in-house. Manual extraction, binary analysis, protocol security assessment, standards compliance review, and evidence-driven report writing — done manually, this takes weeks per firmware version. Most organizations never start.
That is the gap I am building to close.
I am launching two things simultaneously. The first is a firmware security consulting practice — delivering remote firmware and protocol security assessments to utilities, ICS consultancies, defense contractors, and critical infrastructure operators. The same static methodology that produced 35+ CVE-quality findings, delivered as a professional engagement within two weeks, entirely remotely.
The second is VulnHunter AI — an automated ICS firmware security analysis platform that takes firmware from ingestion through deep binary analysis to structured, evidence-driven reporting. The goal is to make the kind of analysis that currently requires weeks of expert manual effort accessible to any organization that needs it, in minutes, without requiring every team member to be a firmware reverse engineering specialist.
The platform starts with ICS firmware and expands from there. Every domain where firmware runs — medical devices, automotive systems, IoT infrastructure, defense systems — faces the same fundamental problem. The methodology scales. The platform will follow.
If you are working in ICS security, OT protection, critical infrastructure risk, or firmware security and this resonates with the problems you are facing — I would genuinely welcome the conversation. Connect with me here or reach out directly.
The work continues. The direction is clear.
Photo by Jacob McGowin on Unsplash