July 17, 2026
Why Defense & Space Organizations Are Rethinking Cybersecurity
The battleground moved inside the machine

By Myra Roldan
9 min read
The battleground moved inside the machine
TL;DR
"Why is the demand for embedded systems cybersecurity and systems engineering literacy rising so sharply, and why in defense and research contexts specifically?"
- Defense, space, and critical infrastructure organizations are asking me for embedded systems cybersecurity help, not more AI & IT tools
- The threat has shifted from stealing your data to degrading your mission
- The real gap is a missing shared language between cyber teams and systems engineers
- Security has to become a systems engineering discipline, what I call cyber-physical mission engineering
- Engineers, security teams, and leaders all need integrated literacy, and they need it now
Over the past six months, I have noticed an interesting pattern in the kinds of organizations asking for help with cybersecurity and systems engineering. It is not the usual mix of enterprises and IT-centric teams. The requests are coming from national defense organizations, space agencies, embedded systems manufacturers, and government research centers that sit close to the heart of national power in countries like regions like US, Canada, Europe, Australia, and Asia.
The part that has really caught my attention is that they are not asking for another penetration test or a new security awareness program. They are asking for something more fundamental; a way to understand and secure embedded, cyber-physical systems as part of mission and national-level resilience.
In other words, the real battleground has quietly shifted. This article is my attempt to name that shift, explain why it is happening now, and lay out what it means for the next decade of cybersecurity, systems engineering, and defense strategy.
From IT security to mission resilience
For the past two decades, cybersecurity has largely been framed as an IT problem. We built firewalls, deployed antivirus, hardened servers, and locked down laptops and phones. We worried about data theft, ransomware, compliance, and uptime. Security has lived in the world of networks, endpoints, and applications for decades.
That framing is breaking down, and it is breaking down fast.
National defense and critical infrastructure organizations are starting to realize that the systems they truly depend on are not servers and laptops anymore. Their most strategic assets are embedded and cyber-physical systems like satellites and ground stations, avionics and flight control, timing infrastructure, and navigation. Weapons platforms, radar, sensor fusion, and the industrial control systems that keep everything else in mission critical systems running. And these systems are no longer the closed, bespoke boxes they used to be. They are software-defined, networked, remotely updatable, and increasingly running AI at the edge across air, space, maritime, and terrestrial domains.
That changes what security means at a fundamental level. When your core mission depends on cyber-physical systems, a vulnerability is not just a data breach risk anymore. It is a potential loss of situational awareness, a degraded weapons capability, or a compromise of the navigation and timing infrastructure your entire country relies on.
The stakes are existential. Right?
Why the interest is spiking now
I jut returned from Europe where I had spent 3 weeks with teams of engineers. I've been trying to piece together the answer to a question that has been pigning my brain, "Why is the demand for embedded systems cybersecurity and systems engineering literacy rising so sharply, and why in defense and research contexts specifically?" The patterns I'm seeing and experiencing are three forces converging which we could say have been accelerated by the 2026 Iran Conflict. To be clear the war didn't start the convergence, it has served as fuel for the fire, making it impossible to ignore.
Let's dig into the three converging forces.
AI-accelerated, agentic threats
Attackers are now operating with AI-powered tools and autonomous agents that can probe legacy protocols at machine speed, reverse-engineer firmware more efficiently than any human team, and mutate exploit chains faster than static defenses can adapt. We already watched automation change the economics of attacks in IT environments. Those same techniques are now being pointed at embedded and control systems, where the security assumptions are often decades old and visibility is poor.
Here is the mental shift that matters. An attacker with an intelligent agent does not see your avionics, your satellite bus, or your guidance hardware as a black box. They see a stack of software, interfaces, and timing dependencies they can map and manipulate. That is a very different threat model than the one our legacy security practices were built for.
The explosion of embedded systems in defense
Defense and aerospace systems are going through a transformation that usually gets buried in buzzwords like open architectures and software-defined hardware. Strip away the jargon and the story is simple, more computing power in every platform, more software controlling critical functions, more AI models running in real time, and more connectivity between platforms, sensors, and command systems.
Embedded_Systems_Recovery myramade.github.io
Traditional embedded platforms were closed, custom-built, and only occasionally connected to anything. Today's military embedded systems are built on high-performance computing, expected to interoperate across vendors and coalition partners, designed for capability upgrades in the field, and dependent on continuous networked awareness.
Every one of those design choices increases capability. Every one of them also increases attack surface. When your embedded systems start looking like distributed software platforms with thirty-year service lives and sprawling supply chains, security cannot be a bolt-on feature. It has to live inside the architecture, the requirements, and the verification from day one.
Space, timing, and infrastructure as contested terrain
The third force is the growing recognition that space systems, timing infrastructure, and industrial control platforms are no longer quietly humming in the background. They are actively contested terrain in geopolitical and military conflict.
Think about what actually rides on these systems. National economies, military operations, and civil infrastructure all depend on reliable navigation, trustworthy time and frequency sources, and stable communications. Disrupting them is now a viable and attractive move for adversaries. That is why we are seeing investment in sovereign timing infrastructure and atomic clocks, new training programs focused on space and control-system security, and policy efforts that finally treat space and OT as critical infrastructure.
When your national strategy rides on satellites, control systems, and precise time, secure by design stops being a slogan. It becomes an operational necessity.
And if this felt abstract six months ago, it does not anymore. The ongoing conflict with Iran has put every one of these dependencies on display. Shipping through the Strait of Hormuz ground to a halt. Drones and missiles reached infrastructure across the Gulf. Navigation, timing, and energy chokepoints became instruments of the conflict itself. I am not here to litigate the war. I am here to point out what it proves, the systems we treated as background utilities are now front-line terrain.
Iran Update Special Report, July 16, 2026 Iran is trying to deter the United States from striking Iranian energy infrastructure by threatening Houthi attacks on…
The hidden gap — two worlds that don't talk
Against this backdrop, the same pattern shows up inside almost every organization I work with. Two strong communities, sitting in the same building, speaking completely different languages. On one side you have the cybersecurity and IT professionals. They know SOC operations, cloud, threat intelligence, and incident response cold. They are fluent in vulnerabilities, CVEs, frameworks, and controls.
On the other side you have the engineers and systems architects. They know avionics, RTOS, embedded hardware, and real-time control. They are fluent in MBSE, SysML, requirements engineering, and certification.
Both groups are highly capable. But they do not share a common language for modeling adversarial behavior, mapping mission risk into engineering trade-offs, or expressing security requirements inside actual engineering artifacts. So security gets bolted onto systems that were never designed with an adversary in mind. Red-team findings never make it back into architecture updates. Software pushes go out to embedded platforms without anyone fully understanding what they do to safety and cyber-physical behavior.
This is exactly where the surge in demand is coming from. These organizations are realizing they do not need more tools. They need a shared mental model and a common language across cyber, engineering, and leadership.
RTOS Security · Interactive Field Guide An interactive, hands-on field guide to Real-Time Operating System security - 25 modules, real C snippets, a live…
Why I'm being pulled in
The engagements I have led over the last six months, from European universities and research councils to national defense partners and aerospace organizations, all share one theme. They want to learn how to think about cybersecurity inside systems engineering and embedded design, not next to it.
Concretely, they are asking me to teach engineers to model adversarial scenarios alongside safety and performance, integrate threat modeling into MBSE and architecture frameworks, build firmware and RTOS security literacy in non-software audiences, and give leaders practical mental models that connect mission risk to technical decisions.
My background happens to sit right at that intersection betwixt cybersecurity, embedded systems, systems engineering, AI literacy, and instructional design. That blend lets me translate cross-domain risk into plain language for engineers and executives, connect SysML models and mission threads to real attack paths, and design learning experiences that change how people design, not just how they comply.
Looking back, it is not surprising that organizations started hunting for exactly this mix of expertise as the environment shifted. What is striking is how consistent and global the pattern has been.
The reframe for cyber-physical mission engineering
Step back far enough and you can see a new framing emerging. We are moving away from cybersecurity as IT hygiene, meaning patching, perimeter, controls, and compliance. We are moving toward what I call cyber-physical mission engineering: designing systems, architectures, and missions to be resilient against intelligent adversaries.
That new frame changes five things.
Security becomes a design constraint, not an afterthought. Security requirements get authored alongside safety, performance, and certification requirements, and they live inside the same engineering artifacts.
Threat modeling becomes a systems engineering activity. Attack paths get modeled across platforms, networks, and timing dependencies, not just inside a single application or network segment.
Embedded and Operational Technology literacy becomes non-optional for security leaders. CISOs and security architects need enough understanding of embedded platforms to participate meaningfully in design decisions.
Mission threads include adversarial scenarios by default. When you walk through a mission from sensor to shooter to decision, you also walk through how an intelligent adversary might disrupt or mislead each step.
And education spans disciplines. Engineers learn to think adversarially. Security professionals learn to think in MBSE and mission terms. Leaders learn to ask better questions about systemic risk.
The organizations I work with may not use this exact language yet. But their questions, their concerns, and their requested topics all point in this direction.
What needs to happen next
Recognizing a pattern only matters if it leads to action and with the recent 2026 NATO Summit Declaration, it also presents an opportunity or defense, cybersecurity, and AI consultants. Based on what I am seeing, here is where defense and critical infrastructure organizations should focus.
The Ankara Summit Declaration The Ankara Summit Declaration
Build integrated literacy
Create learning paths that deliberately mix systems engineering, embedded and RTOS security, threat modeling, AI-driven attack behavior, and mission engineering. The goal is not to turn every engineer into a security specialist or every security professional into a flight-control engineer. The goal is shared literacy, so these teams can actually collaborate.
Embed security in engineering processes
Update your engineering and acquisition processes so that security requirements are formal, traceable, and owned. Make threat models part of design reviews. Let red-team results drive architecture changes, not just findings reports. Govern AI and software updates to embedded platforms with a cyber-physical lens. In practice this means changing templates, governance gates, and review checklists, not adding one more security document nobody reads.
Treat space, timing, and embedded assets as strategic cyber domains
Explicitly recognize space systems as critical cyber domains, timing and navigation infrastructure as part of your security architecture, and embedded platforms as first-class security concerns rather than just hardware. Then make sure that recognition shows up in org charts, budgets, roles, and strategic planning, not merely in technical conversations.
Elevate mission-level risk to leadership
Give senior leaders a concise, repeatable way to understand how embedded and space systems contribute to national resilience, how cyber-physical vulnerabilities translate into mission degradation, and how investments in engineering-centric security change outcomes over time. This is where clear storytelling and simple mental models earn their keep. Leaders need a narrative they can carry into policy, budgeting, and partnership decisions.
Why I'm sharing this pattern
I am sharing this not just to describe my own work, but because I believe we are at an inflection point. For years, we treated cyber as a specialized technical problem. In national defense and critical infrastructure contexts, it has become a fundamental systems and mission problem. Embedded platforms, space systems, timing infrastructure, and AI-enabled capabilities sit at the center of it.
If you are building embedded systems for defense or aerospace, operating space or timing infrastructure, leading security in a national-security role, or training the next generation of engineers, this is the moment to rethink how you frame, teach, and design security.
The demand I have been seeing is not a fad. It is a signal that the ecosystem is trying to evolve its mental models to match reality. My hope is that by naming this pattern, more organizations will recognize themselves in it and start building the cyber-physical mission engineering capabilities they are going to need. Because whether we acknowledge it or not, our national resilience already rides on embedded, cyber-physical systems in a contested, intelligent environment.
And that is a challenge we cannot solve with IT security alone.
Connect with me on LinkedIn