In aerospace and defense, the line between safety and cybersecurity has disappeared. As aircraft and defense systems become increasingly software-defined and network-connected, the same architectures that deliver speed, agility, and capability also introduce new attack surfaces.
In this environment, a software glitch, a failed component, or a cyber intrusion can have the same catastrophic impact: a system that doesn’t behave as intended when lives and missions are on the line.
Patrick Miller, Product Manager at Lynx, has spent his career at the intersection of safety, security, and performance, working across aerospace, defense, enterprise cloud, and embedded systems.
In this Q&A, Patrick shares how architecture, separation, and long-term thinking can help engineers and product teams design resilient weapons systems.
Listen to the Audio Overview
1. You have a unique background that spans aerospace, defense, enterprise cloud, and now safety-critical embedded systems. What lessons from those different domains help you approach safety and security in critical systems today?
Patrick Miller: The biggest lesson is that every domain taught me something different about risk. Security is as much about governance and auditability as it is about technical controls. In defense and aerospace, I learned that resilience isn’t just about preventing failures, it’s about designing systems that degrade gracefully when something does go wrong.
But the connective tissue across all these domains is, particularly in product management, you must know your customer’s actual need, not just the problem you think you’re solving.
Early in my career, I realized that the “why” behind a security requirement often matters more than the requirement itself.
2. Safety and security are often treated as separate priorities. How do you see them intersecting, particularly in aerospace and defense?
Patrick: They are not separate priorities but two expressions of the same goal: keep the system doing what it’s supposed to do, when it’s supposed to do it, and in the face of adversity.
Safety asks, “What happens when things might fail?”
Security asks, “What happens when someone tries to make them fail?”
In aerospace, especially, legacy systems were designed in an era when the threat model was simple: physical tampering or insider threat. Now we have connected avionics and software-defined platforms with attack surfaces we didn’t have to think about ten years ago.
A safety failure and a security failure can look identical from the flight deck, and both result in the aircraft not doing what the crew intended. The intersection is in architecture. If you design a system with strong separation, say at the kernel level, between safety-critical functions and everything else, you’re solving for both.
3. The industry is moving toward software-defined platforms in aircraft and defense systems. What new risks does this introduce—and what opportunities to improve resilience?
Patrick: A key risk is that a vulnerability in one aircraft or subsystem can theoretically affect an entire fleet. However, this shift also creates the opportunity to build security and resilience from day one, rather than bolting it on afterward.
When the industry is trying to add security to 20-year-old real-time operating systems to modernize embedded platforms for customers, it’s like retrofitting a house with a new foundation. Software-defined systems let you architect with separation, modularity, and defense-in-depth from the start. You can implement zero-trust and cyber-resilience principles in real-time environments in ways you couldn’t with monolithic systems.
4. Aerospace and defense systems often have very long lifecycles. What challenges does that create for sustaining cybersecurity, and how can architecture choices mitigate some of the risks?
Patrick: This is one of the most complex problems in the industry. A crewed aircraft certified today will probably still be flying forty years from now, just as there are crewed aircraft certified forty years ago still flying today. By then, the threat landscape will have evolved dramatically. Cryptographic algorithms considered secure today may be obsolete in a post-quantum world.
The mitigation is architectural resilience. First, design with modularity so that security updates can be applied surgically to vulnerable components without recertifying the entire system. Second, implement strong separation so that compromising one module doesn’t cascade through the entire aircraft. Finally, at the program level, it means thinking about your supply chain and third-party dependencies not as static decisions, but as ongoing risk management.
5. UAVs and other unmanned systems are becoming disposable assets in some missions. How does that change the calculus of how much safety vs. security you embed at the system level?
Patrick: The step-change in the evolution of UAVs flips the traditional paradigm on its head. With a crewed aircraft, safety is paramount because at least one, or more likely, many human lives are at stake. In a contested environment, the calculus is different for a single-use tactical UAV. You might accept a higher technical risk if it means fielding new capabilities faster.
Here’s where I push back on the “disposable” framing: even if the platform is disposable, the capability often isn’t. If an adversary captures and reverse-engineers your UAV, they can gain insights into your tactics, sensors, and comm architecture, which requires constant iteration to stay ahead. So even for “disposable” systems, I think about: What’s worth protecting architecturally?
You can design a UAV that’s tactically expendable but still prevents an adversary from extracting intelligence or spoofing commands.
6. How can teams modernize embedded platforms without introducing unacceptable risk or performance tradeoffs?
Patrick: This is where data-driven prioritization really matters. The temptation is always to boil the ocean: add every new security feature, refactor the entire architecture, and implement the latest standards. Instead, measure the opportunity cost of each modernization decision. What are my top three security gaps today? What are my top three performance bottlenecks? Which modernization efforts address both?
Implementing strong separation boundaries improves real-time performance by preventing one task from blocking another, particularly in multi-core processors. At a practical level, invest in your DevSecOps pipeline early and institute automated testing, static analysis, and security scanning to build confidence to modernize faster.
7. Lynx emphasizes separation kernels and mixed-criticality architectures. What does “designing for separation” mean in practice, and how does it help balance safety and cybersecurity in real-time environments?
Patrick: “Designing for separation” means treating compartmentalization as a primary architectural concern, not an afterthought. It’s the difference between saying “we’ll secure the perimeter and hope nobody gets through” and saying “someone eventually gets through, here are the north-south and east-west limits that prevent further intrusion, here is how we know the threat actor entered and how to neutralize them.”
In practice, that means defining your trust boundaries early. What functions are safety-critical? What modules are network-connected? What functions are mission-critical but not safety-critical? A separation kernel enforces those boundaries between partitions at the hypervisor level: one partition can’t access another’s memory; one partition can’t interfere with another’s timing. In real-time systems, timing is paramount, so this isolation protects both safety and security simultaneously.
8. What emerging standards or regulations do you anticipate having the greatest impact on how manufacturers secure and certify safety-critical systems?
Patrick: The Department of Defense’s Software Fast-Track initiative is pushing contractors to adopt modern DevSecOps practices and accelerate secure software delivery timelines. We’re also watching how NIST 800-53 and 800-171 requirements cascade down through the supply chain, forcing even smaller tier-two and tier-three suppliers to implement rigorous security controls.
The Software Bill of Materials (SBOM) mandate is particularly interesting because it’s forcing manufacturers to have real visibility into their software dependencies, which is foundational for long-term supply chain security.
On the civil aviation side, DO-326a and DO-356 are pushing the industry from a compliance-checkbox approach toward continuous monitoring and threat assessment throughout the aircraft lifecycle. Zero-trust mandates across both defense and critical infrastructure are also driving architectural changes at the platform level, which aligns well with what we’re building at Lynx.
9. You’re both a technologist and a pilot. From an operator’s perspective, what would “built-in cyber resilience” mean to you sitting in the cockpit?
Patrick: It means I can trust the displays and controls to follow my inputs and trust the instruments. It means that if there’s a compromise somewhere in the system or sensor, it fails safely, perhaps with a display warning, but not with an unexpected output from the aircraft. A pilot already has enough mental load as it is and does not want to have to think or worry about cybersecurity while flying.
There’s a saying: “aviate, navigate, communicate.” Built-in resilience means the architects and engineers did their job right so that cybersecurity is invisible to me, a redundancy so the aircraft operates reliably.
10. If you could leave engineers and product teams working in critical infrastructure with one key takeaway about building secure and safe systems, what would it be?
Patrick: Know your customer’s actual problem, not just the requirement they gave you. Sometimes the requirement is a proxy for something deeper. Sometimes the customer doesn’t even know how to articulate it yet. For me, that means talking directly with customers, attending industry conferences, asking hard questions, and actively listening.
What’s your threat model today? How are you thinking about long-term sustainability? What architecture decisions are constraining you? Be honest about tradeoffs. You can’t optimize for everything, but if you understand your customer’s actual priorities, you can make product feature choices that strike the right balance.
Designing for Safety, Security, and Longevity
In aerospace and defense systems, safety and security directly overlap. The same design choices that protect flight safety also determine cyber resilience. Architectural separation, modularity, and supply chain transparency are prerequisites for survivability in the digital battlespace.
RunSafe Security and Lynx have partnered to advance this mission through technical collaboration. The integration of LYNX MOSA.ic and RunSafe Protect delivers the industry’s first DAL-A certifiable, memory-safe RTOS platform, uniting safety, security, and operational efficiency in a single solution.
Read our joint white paper for more on this partnership: Integrating RunSafe Protect with the LYNX MOSA.ic RTOS
