RunSafe Security’s 2025 AI in Embedded Systems Report, based on a survey of over 200 professionals throughout the US, UK, and Germany working on embedded systems in critical infrastructure, captures the scale of this shift: 80.5% use AI in development, and 83.5% already have AI-generated code running in production.

As AI-generated code becomes a permanent part of embedded software pipelines, embedded systems teams need a clear view of where vulnerabilities are most likely to emerge.

According to respondents, six risks stand out as the most urgent for embedded security in 2025.

Listen to the Audio Overview

The 6 Most Critical Risks of AI-Generated Code

1. Security of AI-Generated Code (53% of respondents)

Security vulnerabilities in AI-generated code remain the single most significant concern among embedded systems professionals. More than half of survey respondents identified this as their primary worry.

AI models are trained on vast repositories of existing code, much of which contains security flaws. When AI generates code, it can replicate and scale these vulnerabilities across multiple systems simultaneously. Unlike human developers, who might introduce a single bug in a single module, AI can reproduce the same flawed pattern across entire codebases.

The challenge is particularly acute in embedded systems, where code often runs on safety-critical devices with limited ability to patch after deployment. A vulnerability in an industrial control system or medical device can persist for years, creating long-term exposure. Traditional code review processes, designed to catch human errors at human speed, struggle to keep pace with the volume and velocity of AI-generated code.

2. Debugging and Maintainability Challenges (45.5% of respondents)

Nearly half of embedded systems professionals worry about the difficulty of debugging and maintaining AI-generated code. When a human engineer writes code, they understand the logic and intent behind every decision. When AI generates code, that understanding often doesn’t transfer.

When bugs appear, tracing their root cause becomes significantly harder. Engineers must reverse-engineer the AI’s logic rather than reviewing their own design decisions. When modifications are needed—whether for new features or security patches—developers must understand code they didn’t write and may struggle to modify without introducing new issues.

In embedded systems, where code often has a lifespan measured in decades, maintainability is critical. If the original code is AI-generated and poorly documented, each maintenance cycle becomes progressively more difficult and error-prone.

3. Regulatory and Compliance Uncertainty (41% of respondents)

41% of survey respondents flagged regulatory and compliance uncertainty as a major concern with AI-generated code. Yet the certification processes organizations rely on today weren’t designed to account for AI-generated code. In regulated industries such as medical devices or aerospace, obtaining code certification requires extensive documentation of design decisions and validation procedures. When AI generates the code, much of that documentation doesn’t exist in traditional forms.

This creates several challenges. Organizations must make their own determinations about what constitutes adequate validation for AI-generated code, with limited regulatory guidance. When incidents occur, the question of liability becomes murky: Who is responsible when AI-generated code fails?

4. Reuse of Insecure Patterns (27.5% of respondents)

AI models learn from existing code, and that code is often flawed. More than a quarter of embedded systems professionals worry that AI tools will perpetuate and scale insecure coding patterns across their systems.

This risk is particularly concerning because it’s systemic rather than isolated. If an AI model is trained on C/C++ code that commonly contains memory safety issues—and C/C++ historically dominates embedded systems—the AI will likely generate code with similar vulnerabilities.

This risk isn’t just theoretical. Memory safety vulnerabilities such as buffer overflows and use-after-free errors account for roughly 60-70% of all security vulnerabilities in embedded software. If AI tools perpetuate these patterns at scale, the industry could see a multiplication of one of its most persistent and exploitable vulnerability classes.

5. Lack of Transparency and Explainability (26% of respondents)

AI-generated code often functions as a black box. The code works, but understanding why it works or why it fails can be extraordinarily difficult. 26% of embedded systems professionals cite this lack of transparency as a significant concern.

In embedded systems, where reliability and safety are paramount, this opacity creates serious problems. Engineers need to understand not just what the code does, but how it handles edge cases, error conditions, and unexpected inputs. With AI-generated code, that understanding is often incomplete or absent.

The survey reveals additional concern about what happens when AI-generated code becomes increasingly bespoke. Historically, when developers used shared libraries, a vulnerability discovered in one place could be patched across an entire ecosystem. If AI generates unique implementations for each deployment, this shared vulnerability intelligence fragments, making collective defense more difficult.

6. Legal and Licensing Risks (19.5% of respondents)

Nearly one in five embedded systems professionals identifies legal and licensing risks as a concern with AI-generated code. AI models are trained on vast amounts of code, much of it open source with specific licensing requirements. When AI generates code, questions arise: Does the output constitute a derivative work? Who owns the copyright to AI-generated code?

These questions remain largely unresolved, and different jurisdictions may answer them differently. For embedded systems manufacturers, this creates software supply chain risk. If AI-generated code inadvertently reproduces proprietary algorithms or patented methods from its training data, manufacturers could face infringement claims.

For organizations in regulated industries or those serving government customers, these legal uncertainties can be deal-breakers. Defense contractors, for example, must provide clear provenance and licensing information for all software components.

Why These Risks Matter for Embedded Systems Teams

The 2025 landscape reveals an industry at a critical juncture. AI has fundamentally changed how embedded software is developed, and that transformation is accelerating. 93.5% of survey respondents expect their use of AI-generated code to increase over the next two years.

But this acceleration is happening faster than security practices have evolved. The tools and processes that worked for human-written code at human speed aren’t designed for AI-generated patterns at machine velocity.

The good news is that awareness is high and investment is following: 91% of organizations plan to increase their embedded software security spend over the next two years.

Understanding these six critical risks provides a roadmap for where design decisions, security investments, and process changes will have the most significant impact. Organizations that address these risks proactively—through better tooling, enhanced testing, runtime protections, and clearer governance—will not only strengthen their systems but also position themselves as industry leaders.

The insights in this post are based on RunSafe Security’s 2025 AI in Embedded Systems Report, a survey of embedded systems professionals across critical infrastructure sectors. 

Explore the full report to see the data, trends, and strategic guidance shaping the future of secure embedded systems development.

The post The Top 6 Risks of AI-Generated Code in Embedded Systems appeared first on RunSafe Security.

In a recent episode of Exploited: The Cyber Truth, RunSafe Security CEO Joseph M. Saunders and Ask Sage’s Arthur Reyenger joined host Paul Ducklin to discuss how AI is transforming mission readiness. But instead of focusing on sci-fi scenarios, their conversation looked at the ways AI is supporting behind the scenes.

The post Beyond the Battlefield: How Generative AI Is Transforming Defense Readiness appeared first on RunSafe Security.

As software supply chains grow in complexity and ICS devices take on more digital functionality, operators face risk from vulnerabilities buried deep within firmware, dependencies, and proprietary code. Strengthening security and demonstrating compliance begins with improving the integrity, transparency, and resilience of that software. 

RunSafe helps industrial organizations achieve this by hardening code against exploitation, increasing visibility into software components through build-time Software Bill of Materials (SBOM) generation, and extending protection to systems that can’t easily be patched or rebuilt. 

These capabilities align directly with the technical controls required across major ICS cybersecurity standards, helping operators close gaps in their security posture.

Listen to the Audio Overview

Key ICS Cybersecurity Standards RunSafe Supports

IEC 62443 Security Requirements

IEC 62443 defines security levels (SL-1 to SL-4) to counter cyber threats to ICS systems. Security Requirement 3.4 requires mechanisms to ensure software and information integrity by detecting and preventing unauthorized modifications, which is essential for defending against zero-day exploits. 

RunSafe Security supports this with runtime code protection and automated defenses that maintain software trustworthiness in ICS devices, aligning with these IEC 62443 integrity requirements.

NIST 800-82 Control Families

NIST SP 800-82 is a specialized guidance document focused on Industrial Control Systems (ICS) and Operational Technology (OT) environments. It defines 19 control families tailored to these unique contexts, addressing operational, technical, and management controls relevant to ICS security. 

RunSafe’s Protect solution assists in meeting NIST standards by hardening software across firmware, applications, and operating systems to reduce vulnerabilities, especially memory-based and zero-day threats. This aligns with minimizing risks outlined in NIST 800-82, such as unauthorized modifications, malware infections, and system exploitation.

NERC CIP standards

NERC CIP applies to bulk electric systems and mandates stringent access control, security monitoring, and incident response to protect critical grid infrastructure.

RunSafe’s automated software hardening strengthens embedded software against vulnerabilities, including zero-day attacks, helping to meet NERC CIP mandates for cybersecurity system management and reducing the attack surface of BES Cyber Systems.

EU Cyber Resilience Act

The EU Cyber Resilience Act imposes mandatory cybersecurity requirements on manufacturers placing products with digital elements into the European market. The regulation requires comprehensive SBOM documentation, vulnerability disclosure processes, and Security by Design principles throughout the product lifecycle.

RunSafe empowers organizations to meet EU CRA requirements through automated build-time SBOM generation, embedded software hardening, and proactive vulnerability identification.

UK’s Cybersecurity and Resilience Bill

The UK’s proposed legislation extends cybersecurity obligations across critical national infrastructure sectors. The bill emphasizes supply chain security and mandates incident reporting within strict timeframes, creating accountability for operators and vendors. 

RunSafe Security supports compliance with the UK Cybersecurity and Resilience Bill by providing embedded software security designed specifically for ICS systems and software supply chain transparency through build-time SBOM generation.

How RunSafe Hardens Code & Strengthens the Software Supply Chain to Meet ICS Security Standards

RunSafe improves ICS security posture by providing:

1. Build-Time SBOM Generation: Provides complete visibility into software components and software supply chain risk, especially for C/C++ and embedded toolchains.
2. Runtime Code Protection: Protects ICS devices in the field, even before patches are available, by preventing the exploitation of memory-based vulnerabilities, including zero-day exploits.

Together, these capabilities directly support key ICS cybersecurity requirements.

The Industrial Control System Software Risk Landscape

ICS cybersecurity risks increasingly stem from software complexity. PLCs, HMIs, sensors, gateways, and controllers rely on layered stacks of compiled code, RTOS kernels, communication libraries, protocol implementations, and third-party components. As this software ecosystem expands, several categories of risk emerge:

1. Vulnerabilities in Proprietary and Third-Party Components

Industrial devices often incorporate dozens or hundreds of software elements, both internally developed and externally sourced. Many of these components lack update mechanisms or clear lifecycle management. When vulnerabilities are disclosed, asset owners frequently lack the visibility needed to determine whether their systems are exposed.

2. Memory Safety Issues as a Persistent ICS Threat

Memory safety remains one of the most common contributors to ICS vulnerabilities. Buffer overflows, use-after-free flaws, and out-of-bounds writes still account for a significant portion of CVEs in industrial and embedded software. These weaknesses persist in critical infrastructure because:

• Many devices use older programming languages (e.g., C/C++)
• Patching may be infeasible due to uptime requirements
• Legacy firmware often cannot be rebuilt or re-verified
• Third-party components introduce memory safety risks through the software supply chain.

Andy Kling, VP of Cybersecurity at Schneider Electric, a major player in the ICS/OT space, found that “memory safety was easily the largest percentage of recorded security issues that we had.” 94% of these weaknesses come from third-party components.

While memory safety is not the only category of ICS risk, it remains one of the most damaging, often enabling remote code execution or multi-stage exploit chains.

3. Software Supply Chain Blind Spots

Software supply chain cyberattacks frequently target the software dependencies and build environments behind industrial products. Without reliable SBOMs, operators cannot:

• Determine which libraries exist in a given binary
• Rapidly assess exposure to new vulnerabilities
• Confidently evaluate vendor-supplied code or firmware

The lack of software transparency turns compliance into guesswork and slows incident response.

4. Operational Constraints That Block Traditional Security Measures

Industrial environments face major deployment challenges:

• Air-gapped or intermittently connected networks
• Decades-old firmware with no vendor support
• Real-time performance requirements that limit scanning or patching
• Multi-vendor PLC fleets with inconsistent update workflows

These realities make it difficult to rely solely on patch management, network segmentation, or perimeter defenses.

5. Physical and Operational Consequences

Because ICS software interacts directly with physical equipment, software vulnerabilities can lead to:

• Manipulation of process parameters
• Shutdown of production lines
• Damage to equipment or the environment
• Safety incidents impacting human operators

Software risk in ICS is therefore both digital and physical, with potentially severe outcomes.

Three Steps to Deploy RunSafe in Existing ICS Security Programs

Given the depth of software risk in modern ICS environments, organizations need solutions that both reduce exploitability and produce the evidence required for rising compliance standards. 

RunSafe delivers this by integrating directly into existing development and maintenance workflows, making it possible to improve security posture without operational disruption.

1. Integrate & Automate SBOM Generation at Build Time

Begin by embedding RunSafe’s SBOM generation directly into your CI/CD pipeline or offline build environment. Whether you’re working with embedded Linux, Yocto/Buildroot builds, or legacy RTOS toolchains, RunSafe’s Identify capability produces CycloneDX-compliant SBOMs and supports all mandatory NTIA fields.

You’ll gain full component visibility—down to libraries, files, and versions, including proprietary components—so you can quickly assess exposure, audit supplier code, enforce license policy, and meet SBOM-mandate requirements for ICS environments.

2. Apply Binary Hardening and Runtime Protection

Protecting your software with RunSafe Protect is as easy as installing the packages from our repositories and making a one-line change to your build environment. Once installed, you can automatically integrate Protect into your existing build process.

RunSafe Protect hardens compiled binaries against memory-based exploits and zero-day attacks by applying Load-time Function Randomization (LFR). Even legacy PLC firmware, vendor-supplied binaries, or devices in air-gapped networks can benefit from exploit mitigation. Because the protection works independently of patch status, you’re reducing risk proactively while maintaining operational continuity.

3. Monitor Protected Devices

Deploy RunSafe’s Monitor capability across your hardened device fleet to capture crash indicators, detect unusual behavior patterns, and differentiate between benign failures and potential exploit attempts.

Next Steps to Secure Your ICS Environment

Securing industrial control systems requires more than perimeter defenses or periodic patch cycles. It demands protections that operate inside the software itself—across legacy devices, modern embedded platforms, and complex software supply chains. 

RunSafe provides that foundation by hardening binaries against exploitation, generating accurate SBOMs at build time, and delivering operational insight through lightweight monitoring. Together, these capabilities give ICS operators a practical path to strengthen system integrity, reduce exploitability, and demonstrate compliance with the world’s most important cybersecurity standards. 

With the right protections applied directly to the software running your critical processes, resilience becomes achievable rather than aspirational.

Request a consultation to get started with RunSafe or to assess your embedded software security and risk reduction opportunities.

The post Meeting ICS Cybersecurity Standards With RunSafe appeared first on RunSafe Security.

Key Takeaways:

• Legacy medical devices running old code create growing cybersecurity and patient safety risks
• Ransomware attacks on hospitals show how downtime directly impacts clinical care
• Security transparency and SBOMs are now key to winning healthcare procurement deals
• Cyber resilience—not just compliance—will define the next era of connected healthcare

Hospitals and medical device manufacturers are facing a quiet crisis rooted not in cutting-edge exploits or nation-state hackers, but in old software.

Across healthcare, legacy code is turning routine cybersecurity weaknesses into real-world patient safety risks. The problem is simple to explain and hard to solve: devices built to last for decades are now connected to modern networks, yet run on outdated and difficult-to-patch code.

As connected devices become the norm, this technical debt has become a liability that extends to patient care.

In a discussion on the business realities of medical device cybersecurity, Shane Fry, CTO of RunSafe Security, Patrick Garrity, Security Researcher at VulnCheck, and Phil Englert, VP of Medical Device Security Health-ISAC, discussed the vulnerability and compliance landscape and where software security comes into play.

Watch the full webinar for more on medical device cybersecurity here.

When “Forever Devices” Become Forever Vulnerable

A medical device can remain in use for 15-20 years. That longevity might make sense for hospitals managing costs, but it means the software inside those devices is often frozen in time. Meanwhile, the threat landscape moves forward.

“These devices can be used for decades,” said Patrick Garrity, Security Researcher at VulnCheck. “That becomes a real challenge. Manufacturers have to be mindful of that.”

Imagine a connected infusion pump or imaging system that still relies on a Windows 7 or even XP base. Patches stop, drivers go unsupported, and over time, the device becomes a soft target on an otherwise modern network.

And because medical systems are tightly integrated—feeding data into hospital EMRs, remote dashboards, and cloud platforms—an outdated component in one corner of the network can expose an entire healthcare operation.

When Cyber Weaknesses Become a Patient Safety Risk

The stakes became clear during the Black Basta ransomware attack on Ascension Health earlier this year. Hospitals were forced to revert to paper-based systems. Electronic medical records, scheduling systems, and digital imaging were suddenly inaccessible.

RunSafe Security CTO Shane Fry summed up the real-world impact: “If your network’s down, you can’t do surgery.”

Beyond the immediate operational disruption, the consequences for patients were serious. Doctors faced delays accessing treatment histories. Pharmacists couldn’t verify prescriptions electronically. In some facilities, even infusion pumps and lab equipment had to be taken offline as a precaution.

Ransomware may be the headline, but the underlying vulnerability is the same—cybersecurity weaknesses left unaddressed.

As Phil Englert, VP of Medical Device Security at Health-ISAC, noted: “Cyber is a failure mode. It’s a way for things not to work or not to work as intended when you want them to.”

When software failures and weak security controls ripple into care delivery, cybersecurity is a patient safety imperative.

Where Exploitation Starts

Most healthcare breaches don’t start with exotic zero-days. They start with vulnerabilities everyone already knows about.

Attackers target what’s common: outdated Microsoft servers, unpatched remote access tools, misconfigured network gateways, and open-source components left to age quietly inside medical devices.

Garrity pointed to examples such as NextGen Healthcare’s Mirth Connect, a popular data exchange system exploited in ransomware campaigns. The flaw wasn’t obscure, as it had been publicly documented and patched. Yet more than a year later, vulnerable systems remained exposed online, still running unpatched versions.

“Threat actors are going to opportunistically target anything and everything. And… they’re just using what’s already published and off-the-shelf,” Garrity said. “Even outdated remote management tools or cloud connectors can become attack surfaces.”

Legacy software turns these well-known weaknesses into long-term liabilities. Once a system goes unpatched, every new connection—every piece of cloud integration or remote monitoring—adds to the risk.

The Business Risk of Standing Still

The consequences of cybersecurity weaknesses aren’t limited to downtime or headlines—they directly affect revenue and market access.

According to RunSafe Security’s 2025 Medical Device Cybersecurity Index, 83% of healthcare buyers now include cybersecurity standards in their RFPs, and 46% have declined to purchase medical devices due to security concerns. Outdated or insecure software doesn’t just pose a technical problem; it can cost sales.

For device manufacturers, the message from buyers is unmistakable: security maturity equals market readiness. Procurement teams are treating cybersecurity posture as a business criterion alongside clinical performance and cost.

Hospitals, too, are taking notice. Many are implementing procurement checklists requiring vendors to provide Software Bills of Materials (SBOMs), vulnerability response plans, and clear lifecycle support documentation. Without those, even innovative technologies struggle to clear the contracting stage.

Modernizing Security for Long Device Lifespans

Managing legacy code in a regulated, high-stakes industry isn’t easy, but it’s not impossible. The most resilient organizations are taking pragmatic, layered steps to reduce risk without overhauling every device.

1. Build-Time SBOMs

Create and maintain Software Bills of Materials (SBOMs) during the build process, not after. This ensures visibility into every dependency and allows for continuous monitoring of vulnerabilities over time.

2. Exploit-Based Prioritization

Focus patching on vulnerabilities with known exploitation in the wild, not just those with high CVSS scores.

3. Compensating Controls

Where patches aren’t possible, use segmentation, strict access controls, and runtime protections to reduce exposure.

4. Design for the Next Decade

Reserve processing and storage capacity for future updates and plan for cryptographic agility so devices remain secure over their full lifespan.

5. Transparent End-of-Life Policies

Communicate openly about support timelines and risk mitigation options. Buyers and regulators increasingly view transparency as part of good cybersecurity hygiene.

From Compliance to Resilience

Healthcare is shifting from a “check-the-box” approach to one centered on resilience. Regulators are reinforcing that shift: the FDA’s premarket guidance now requires SBOMs and vulnerability management plans, while the EU’s Cyber Resilience Act pushes similar expectations globally.

The result is a new baseline where cyber hygiene and secure design aren’t just best practices, they’re business necessities.

“If you don’t know what’s in the software you’re deploying to your networks, then how can you know that a vulnerability affects you?” Fry said. “Without that Software Bill of Materials, you’re going to be very limited.”

For manufacturers and healthcare providers alike, addressing legacy code is about security and trust. It’s about maintaining operational continuity. And ultimately, it’s about keeping patients safe in a world where every connected device is part of the care equation.

As Fry put it: “Everything that we should be doing in cybersecurity should be viewed through … the lens of making sure the patient can get the best care they need as quickly as they can.”

For more on medical device challenges and defenses, listen to our panel discussion: From Ransomware to Regulation: The New Business Reality for Medical Device Cybersecurity.

The post From Black Basta to Mirth Connect: Why Legacy Software Is Healthcare’s Hidden Risk appeared first on RunSafe Security.

Key Takeaways:

• AI will transform aerospace cybersecurity, helping find vulnerabilities faster but also creating new ones
• Collaboration among government, primes, and vendors is needed to protect connected systems
• Disposable and low-cost UAVs still require strong security to ensure mission success
• Cyber resilience and modular architectures will define the next decade of secure aerospace operations

The aerospace and defense sector is entering a new chapter. With networked systems, distributed architectures, and mission-critical connectivity, cybersecurity is as vital as physical shielding. 

In a recent discussion on aerospace cybersecurity strategy, Shane Fry, CTO of RunSafe Security, and Patrick Miller, Product Manager at Lynx, discussed how the next five to ten years will reshape how we defend aerospace assets. 

What follows are four key trends that highlight where the industry is headed.

Watch the full webinar for more on aerospace cybersecurity here.

1. AI’s Dual-Edged Role in Cyber and Operations

Artificial intelligence is emerging as both a revolutionary tool and a potential liability in aerospace cybersecurity. Shane noted how AI is reshaping nearly every aspect of defense systems, from vulnerability detection to operational optimization.

“There’s a lot of really cool research being done in penetration testing and finding vulnerabilities and using AI to assist operators in security,” he said.

AI is now helping engineers and analysts identify weaknesses faster and automate portions of cyber defense previously handled manually. But as Shane pointed out, the same technology that accelerates innovation can also magnify risks.

“One of the things that is a negative,” he warned, “is many of these new capabilities are trained on software that’s not secure.”

Large language models and AI code-generation tools often learn from open-source repositories riddled with known flaws. That means they might produce software that appears sound but hides vulnerabilities—like memory corruption or buffer overflows—deep within the codebase.

“We’re going to see a rise in software vulnerabilities,” Shane predicted, “as more developers use these code-assistants to produce faster code that looks good but may actually have subtle memory corruption vulnerabilities in them.”

For a sector where software directly underpins mission safety and national defense, that’s a sobering reality. The next phase of AI integration, Shane cautioned, may bring turbulence before it delivers real progress.

“The next six months to a year or two years might be really rough,” he admitted, “but ultimately, the progress will be for the overall good.”

2. Disposable Weapons & UAVs: Security at Speed and Scale

One of the most striking shifts Shane highlighted was the rise of low-cost, “disposable” weapon systems, particularly unmanned aerial vehicles (UAVs). In a time where speed and affordability are driving procurement decisions, these assets are designed to complete their mission, but not necessarily to return.

“When we talk about disposable UAVs,” Shane explained, “there’s a lot of interest in having lower-cost solutions that we don’t care if they survive the mission. We just need them to accomplish the mission.”

That philosophy is reshaping how system owners think about design and risk. Yet, Shane cautioned that the push for cheaper, faster production can come at a dangerous price.

“As we strive to cut as much as we can to bring costs down,” he said, “we’ve got to make sure that we’re still doing enough security, enough safety so that we can accomplish the mission.”

In a world where digital compromise can have physical consequences, even a minor software flaw could be catastrophic. “We don’t want to end up in a situation where a UAV flying overhead has a trivial vulnerability that gets exploited, and the drone turns around and bombs an allied target,” Shane said.

That vivid example underscores a growing tension in modern defense programs: how to balance affordability and agility with assurance and control. The Department of Defense’s efforts to modernize its software approval and certification processes for future readiness will be critical.

A core component of that, Shane noted, is “having good, accurate SBOMs and being able to understand what the risk is in your software that you’re shipping.” 

Additionally, this will help ensure that even low-cost or disposable systems can be deployed responsibly.

In short, the aerospace industry is entering an era where scale and security must coexist. Disposable systems may not be built to last, but their cybersecurity must endure long enough to protect the mission, the data, and the allies they serve.

3. Ecosystem Collaboration: Government, Primes & Vendors

Cyber defense of aerospace is not a solo endeavor. Governments, aerospace primes, and vendors will need to align to defend complex systems.

Shane observed that modern systems integrate legacy code, which is becoming increasingly interconnected, heightening risk. To manage this complexity, the industry is leaning into partnerships and certified deployment paths. 

For example, Lynx’s secure hypervisor technology, when paired with RunSafe’s memory protection, delivers a layered, modular architecture that strengthens system isolation and resilience in the field.

When discussing future integration of AI, Patrick noted: “Lynx has taken the approach of enabling those safety-focused or non-critical applications to run alongside, but totally separate from, the safety-critical applications and subjects within that same hardware.”

This collaborative, layered approach is one example of working together to reduce overall risk.

4. Cyber Resilience: The Imperative for Operational Continuity

Overarching all of these trends is the principle of resilience. In an environment where AI may introduce new vulnerabilities, collaboration expands the ecosystem, geopolitics raises the stakes, and disposable systems proliferate, aerospace defenders must build platforms that can endure, adapt, and recover. 

As Shane explained: “You’re going to get the most out of your hardware and your systems by having a more robust and modular system, with security baked in.”

He continued: “Having a modular system lets you get new software, new features, new capabilities onto your platforms faster.”

Patrick noted that the partnership model between Lynx and RunSafe demonstrates what “defense-in-depth” looks like in practice. 

“With the Lynx and RunSafe partnership,” Patrick said, “pairing that with RunSafe’s memory protection, you’re able to remove a whole category of exploits you’d otherwise have to defend against.”

The Decade Ahead

The next decade for aerospace cybersecurity will be defined by convergence between AI and assurance, collaboration and software supply chain transparency, pre-emptive design and agile operations. 

Building resilience and adopting safety-focused engineering will enable faster innovation without leaving cybersecurity by the wayside.

For more on RunSafe and Lynx’s work in aerospace cybersecurity, read our white paper on “Integrating RunSafe Protect with the LYNX MOSA.ic RTOS.”

The post The Decade Ahead in Aerospace Cybersecurity: AI, Resilience, and Disposable Weapons Systems appeared first on RunSafe Security.

That’s the question host Paul Ducklin explored with Joseph M. Saunders, CEO and Founder of RunSafe Security, in an episode of Exploited: The Cyber Truth.

From the limitations of traditional security models to the growing importance of software quality, this conversation revealed why the cybersecurity playbook for industrial automation needs a re-write for today’s threats.

The post Defending the Factory Floor: How to Outsmart Attackers in Smart Manufacturing appeared first on RunSafe Security.

Key Takeaways:

• Legacy devices can’t be patched easily, but compensating controls provide alternatives.
• SBOMs are critical for transparency and accountability.
• The FDA now mandates secure development and life cycle planning.
• Cybersecurity and patient safety are inseparable—breaches harm care.
• Collaboration is the only sustainable path forward.

In healthcare cybersecurity, one of the biggest challenges is protecting medical devices that are difficult to patch and written in memory unsafe languages. Unlike web applications or mobile software, which can be updated overnight, medical devices are often built to last 10–15 years and aredesigned for reliability and patient safety—not constant code revisions.

Yet cyber threats are growing, and FDA regulations are tightening. Manufacturers and healthcare providers are now under pressure to secure legacy systems while keeping patients safe. The question is: how can this be done without rewriting a single line of code?

This was the focus of a recent episode of Exploited: The Cyber Truth, featuring Phil Englert (VP of Medical Device Security at Health-ISAC) and Joseph M. Saunders (Founder & CEO of RunSafe Security). Their insights offer a practical roadmap that blends compensating controls, regulatory awareness, and industry collaboration.

The post Beyond Patching: How to Secure Medical Devices and Meet FDA Compliance Without Changing Code appeared first on RunSafe Security.

In a recent episode of Exploited: The Cyber Truth, RunSafe Security CEO Joe Saunders joined Gabriel Gonzalez of IOActive to discuss the real-world vulnerabilities threatening connected cars and, more importantly, how the industry can build resilience from the ground up. Their insights shed light on both the dangers and the opportunities shaping the future of mobility.

As Joe puts it: “Vehicles are loaded with software. If you think about it, they are software systems with wheels as opposed to cars with individual components.”

The post Why Securing Autonomous Vehicles Must Start Now appeared first on RunSafe Security.

As reported by healthcare executives across the U.S., UK, and Germany in RunSafe Security’s 2025 Medical Device Cybersecurity Index, the most critical vulnerabilities in medical devices fall into seven categories: malware infections, network intrusions, ransomware targeting device operations, remote access exploitation, supply chain compromises, vendor-identified vulnerabilities, and data exfiltration.

These are the weaknesses shaping the medical device cybersecurity landscape in 2025.

Listen to the Audio Overview

The 7 Most Critical Medical Device Cybersecurity Risks

1. Malware Infections (51% of Organizations Affected)

Malware remains the most widespread vulnerability in medical devices, as reported by healthcare leaders. 51% listed malware infections requiring device quarantine as the most significant medical device cybersecurity incident at their organization.

Often, malware infections are targeted campaigns that force organizations to quarantine devices and disconnect systems. For example, malware can force radiology departments to take entire imaging systems offline to prevent spread, leading to delays in diagnostics. In some cases, malware has been used to wipe device firmware or corrupt system files, requiring full reinstallation before devices can be put back into service.

The consequence is not just about downtime, but also about cascading disruption—if a key device type, such as ventilators or pumps, is quarantined, entire treatment processes can be delayed.

2. Network Intrusions (44% of Organizations Affected)

Nearly half of organizations experienced intrusions into networks hosting medical devices. Network intrusions targeting medical devices are among the most severe forms of attack, as they often remain undetected for extended periods. Attackers can gain unauthorized access through poorly segmented networks, default credentials, or outdated communication protocols.

An example is when adversaries pivot from compromised IT systems into clinical device networks, gaining visibility into—and sometimes control over—networked equipment such as monitoring systems or infusion pumps. Intruders may then install backdoors, capture sensitive data in transit, or manipulate device functions.

Unlike IT breaches focused on stealing files, network intrusions into medical devices often create silent footholds that persist until they are specifically identified and removed.

3. Ransomware Targeting Device Operations (37% of Organizations Affected)

More than one-third of organizations reported ransomware specifically disrupting device operations. Unlike traditional ransomware, these campaigns target availability rather than just data.

For example, ransomware designed to target imaging systems can lock operators out of MRI or CT machines, effectively halting diagnostic capabilities until ransom demands are met. Similarly, ransomware targeting infusion pumps or surgical robots can force organizations to suspend treatment procedures.

The distinguishing factor here is intent: attackers understand that the availability of these devices is essential, making disruption itself the pressure point rather than data encryption alone.

4. Remote Access Exploitation (28% of Organizations Affected)

Remote access is vital for servicing, diagnostics, and software updates—but it has also become a primary entry point for attackers. Nearly three in ten organizations reported that remote access was exploited to compromise devices.

This typically occurs when attackers identify unsecured remote desktop sessions, weak VPN configurations, or vendor accounts with excessive privileges. Once inside, adversaries can move laterally across device networks or alter system settings.

A common scenario is the exploitation of default or reused credentials for remote maintenance tools, which grants attackers the same level of control as authorized technicians.

5. Supply Chain Compromises (26% of Organizations Affected)

Software supply chain attacks introduce vulnerabilities long before devices are deployed in hospitals. One in four organizations experienced compromises traced back to third-party software, libraries, or hardware components embedded in their devices.

A well-known example outside healthcare is the SolarWinds compromise, but similar attacks in the medical sector can introduce malicious code into firmware or software updates distributed by a trusted vendor. When those updates are applied, every customer organization inherits the vulnerability.

Due to their scale, software supply chain compromises can impact thousands of devices across multiple healthcare systems simultaneously, making them particularly challenging to contain.

6. Vendor-Identified Vulnerabilities Requiring Updates (24% of Organizations Affected)

Nearly a quarter of organizations faced critical vulnerabilities identified and disclosed by their device vendors. While transparency is essential, patching medical devices poses unique challenges compared to traditional IT.

Devices often require downtime for testing and validation before updates can be applied, and in regulated environments, some patches may trigger re-certification processes. For example, if an imaging device firmware update conflicts with existing calibration protocols, the device must be retested before it can be returned to service.

This means that even when fixes are available, the process of applying them can be slow and disruptive, leaving exploitable windows open for attackers.

7. Data Exfiltration from Devices (23% of Organizations Affected)

Data theft remains a significant issue, with nearly one in four organizations reporting exfiltration from medical devices. These devices often process highly sensitive patient information, including imaging results, diagnostic data, and treatment histories.

For example, compromised cardiology devices can leak continuous heart monitoring data, or imaging systems can be used to extract thousands of patient scans. In some attacks, stolen data is packaged and sold on underground markets, where medical records often fetch higher prices than financial information.

As devices become more interconnected and data-rich, they expand the potential attack surface for adversaries seeking to capture and monetize sensitive healthcare information.

Download our guide to securing medical device software throughout its lifecycle, from development through deployment.

What Medical Devices Are Being Targeted in 2025?

Attackers are going after the backbone of patient care. Cybercriminals are successfully targeting the very systems healthcare providers depend on most for patient diagnosis, treatment, and monitoring, including:

• Imaging Systems (41%) – CT, MRI, X-ray
• Patient Monitoring Devices (40%) – ICU and emergency care essentials
• Laboratory/Diagnostic Equipment (34%) – Core to diagnosis and treatment
• Infusion Pumps (23%) – Life-sustaining medication delivery
• Networked Surgical Equipment (19%) – Operating room systems
• Implantable Devices (19%) – Pacemakers, insulin pumps, and more 

Why These Vulnerabilities Matter for Medical Device Manufacturers

The 2025 landscape makes one thing clear: medical devices are now at the center of the cybersecurity conversation. From malware and ransomware to supply chain compromises, attackers are finding multiple pathways to exploit weaknesses that directly affect device reliability and trust.

For manufacturers, the implications are significant. Healthcare providers, regulators, and procurement teams are scrutinizing device cybersecurity more closely than ever. Vulnerabilities are no longer viewed as isolated technical flaws but are seen as risks to adoption, compliance, and long-term market success.

Understanding these seven critical vulnerabilities provides a roadmap for where design choices, testing protocols, and security investments will have the greatest impact. Manufacturers that take these threats seriously will not only strengthen their products but also differentiate themselves in a market where resilience is becoming a baseline requirement.

The insights in this post are based on RunSafe Security’s 2025 Medical Device Cybersecurity Index, a comprehensive survey of healthcare decision-makers on medical device cybersecurity. For manufacturers, it’s a clear signal of where to focus security efforts and how to meet the expectations of regulators and healthcare buyers. 

Explore the full report to see the data, trends, and guidance shaping the future of secure medical devices.

The post The Top 7 Medical Device Vulnerabilities of 2025 appeared first on RunSafe Security.

RunSafe Security’s new 2025 Connected Car Cyber Safety & Security Index reveals that consumers are more aware of cybersecurity risks than ever before and they’re ready to make buying decisions based on how automakers respond.

Listen to the Audio Overview

Consumer Awareness Has Outpaced Automaker Action

For years, automotive cybersecurity was treated as a technical issue best left to engineers. Today, it’s become a mainstream consumer concern. In our survey of 2,000 connected car owners across the U.S., the UK, and Germany, 65% of drivers believe remote hacking of a vehicle is possible, yet only 19% feel “very confident” that their car is protected.

That confidence gap is profound. Drivers perceive their vehicles as more vulnerable than other connected devices, such as smartphones, which receive regular security updates. And they’re right to be concerned. Recent years have seen everything from mass remote recalls to exploits that allowed researchers to take control of vehicles from miles away.

Safety, Not Privacy, Drives Concern

One of the most striking findings is that drivers now view connected car security as a matter of life and death. An overwhelming 79% say protecting their physical safety from cyberattacks is more important than safeguarding the personal data inside their cars.

Unlike traditional cybersecurity breaches that expose sensitive data, automotive hacks can directly compromise safety-critical systems like steering, braking, and acceleration. Consumers understand this risk and expect automakers to treat it with the seriousness it deserves.

Software Supply Chain Risks in the Spotlight

Modern vehicles aren’t built by a single company; they’re the product of a complex ecosystem of suppliers. Our survey found 77% of drivers recognize third-party components as cybersecurity risks, and 83% want transparency about software origins.

This demand for disclosure puts new pressure on automakers. Consumers don’t want vague assurances about safety and security. They want to know what’s inside their vehicles, where it came from, and how it’s being protected.

Automotive Cybersecurity as a Competitive Advantage

Perhaps the most important finding of all: cybersecurity now has the power to make—or break—a sale. Eighty-seven percent of consumers say strong protections influence their buying decisions, with 35% willing to pay premium prices for enhanced security.

That’s a stunning shift in the way drivers view their cars. Security has moved from a behind-the-scenes technical feature to a frontline differentiator, on par with performance, comfort, and fuel economy. 

Automakers that ignore this reality risk losing customers to more security-conscious competitors—or worse, driving them toward older, less profitable vehicles. In fact, 70% of drivers said they would consider buying an older, less connected car just to reduce cyber risk.

Automotive Cybersecurity Is a Defining Market Force

The 2025 Connected Car Cyber Safety & Security Index shows that automotive cybersecurity is a business imperative that directly impacts brand loyalty, market share, and revenue potential.

The message from consumers is clear: build security in, be transparent about software supply chains, and treat cybersecurity as seriously as safety. Those who act now will gain a durable competitive edge.

Download the full 2025 Connected Car Cyber Safety & Security Index to see the complete findings and insights for automakers and suppliers.

The post Connected Cars, Connected Risks: Automotive Cybersecurity Is in High Demand appeared first on RunSafe Security.

The regulatory landscape for product security has fundamentally shifted. What was once a “nice-to-have” consideration has become mandatory compliance across industries, with cybersecurity now sitting at the center of product development, risk management, and go-to-market strategies.

Product leaders today face mounting pressure from multiple regulations—the EU Cyber Resilience Act (CRA), FDA cybersecurity requirements, and a growing list of industry-specific mandates—while still needing to maintain innovation speed and profitability. The stakes couldn’t be higher: non-compliance risks include fines up to €15 million or 2.5% of global turnover under the CRA, market access restrictions, and potentially devastating reputational damage.

But here’s the critical insight that forward-thinking product leaders are discovering: these regulations don’t have to be a burden. When approached strategically, regulatory compliance can become a competitive differentiator that strengthens products, builds customer trust, and creates sustainable business advantages.

Listen to the Audio Overview

The Product Compliance Tidal Wave: Understanding the Forces at Play

The 2024-2025 period has seen new cybersecurity regulations appear across sectors, representing a fundamental shift in how responsibility for product security is assigned and enforced.

The most significant change is the shift in liability. Under traditional models, end users often bore responsibility for securing the products they purchased. Today’s regulations flip this dynamic, making manufacturers the primary guardians of product security throughout the entire lifecycle. The CRA rebalances responsibility toward manufacturers and sets new standards across product lifecycles, fundamentally changing how companies must approach product development and support.

Supply chain transparency has become another critical factor. New requirements for Software Bills of Materials (SBOMs) and vulnerability disclosure mean that product leaders can no longer treat their supply chains as black boxes. Every component, every dependency, and every potential vulnerability must be catalogued, monitored, and managed.

As RunSafe Founder and CEO Joe Saunders has emphasized, “If a vendor can’t tell you what’s in their product, chances are, they don’t know either.” This lack of knowledge will no longer fly with consumers, regulators, or internal risk management teams.

Perhaps most importantly, these regulations demand a cultural transformation within organizations. As noted by cybersecurity experts at IMD Business School in a June 2025 Qt Group analysis, “the EU Cyber Resilience Act demands a fundamental cultural and leadership shift in organizations,” moving away from security as a bolt-on feature to security as a foundational element of product design.

The EU Cyber Resilience Act: A New Paradigm for Product Security

The CRA represents the most comprehensive product security regulation to date, with implications that extend far beyond European borders. Understanding its requirements isn’t just about compliance, it’s about understanding where the entire industry is heading.

Timeline and Strategic Implications

The CRA entered into force on December 10, 2024, but the most critical date for product leaders is December 11, 2027, when most obligations become enforceable. This timeline creates both urgency and opportunity: companies that start preparing now will have significant advantages over competitors who wait until the last minute.

The regulation’s scope is deliberately broad, covering all connected products and software sold in the EU, regardless of where the manufacturer is located. This means that any company selling digital products globally needs to consider CRA compliance as a baseline requirement.

Core Requirements That Change Everything

The CRA’s “Secure-by-Design” mandate isn’t just regulatory language but a complete shift in how products must be conceived, developed, and maintained. Security can no longer be retrofitted; it must be integral from the earliest design phases.

Vulnerability management under the CRA requires manufacturers to report vulnerabilities within 24 hours of discovery and implement coordinated disclosure processes. This creates new operational requirements but also opportunities for companies that excel at rapid response and transparent communication.

The documentation requirements are extensive, covering security documentation, risk assessments, and conformity declarations. While this creates an administrative burden, it also forces companies to develop more rigorous security practices that typically result in higher-quality, more resilient products.

Post-market obligations represent perhaps the biggest shift, requiring ongoing security updates for a minimum of five years or the expected product lifetime. This transforms the economics of product development, making long-term security support a core business consideration rather than an afterthought.

FDA Cybersecurity Requirements: Medical Devices Lead the Way

The FDA’s 2025 cybersecurity guidance updates represent a maturation of medical device security requirements, but their implications extend beyond healthcare. As one of the most regulated industries, medical devices often preview compliance approaches that eventually spread to other sectors.

The New Enforcement Reality

The FDA’s latest guidance mandates that cybersecurity must be demonstrated from pre-market design through post-market support, with strong documentation on vulnerabilities and supply chain transparency for all device components. This lifecycle approach mirrors the CRA’s philosophy and suggests a convergence toward comprehensive product security requirements across industries.

The emphasis on SBOM requirements for connected medical devices creates new transparency obligations but also opportunities for companies that can demonstrate superior supply chain security. Companies that proactively implement robust component tracking and vulnerability management will find themselves better positioned for both regulatory compliance and customer trust.

Strategic Impact on Product Development

The FDA’s approach changes go-to-market strategies for medical technology companies. Security documentation is now part of the regulatory submission process, meaning that security considerations must be built into product development timelines from the beginning.

This creates new resource allocation challenges, as companies need dedicated cybersecurity expertise within product teams. However, it also creates competitive advantages for companies that develop this expertise early and can demonstrate superior security practices to customers and regulators.

Learn more about navigating vulnerability identification and postmarket cybersecurity for medical devices in this video: On-Demand Webinar: Medical Device Cybersecurity Challenges

Strategic Focus Areas: Maximizing ROI on Security Investments

With limited resources and expanding regulatory requirements, product leaders must prioritize their security investments strategically. The most successful companies focus on areas that provide both regulatory compliance and business value.

Supply Chain Security and SBOM Management

SBOM requirements appear across multiple regulations—the CRA, FDA guidance, and emerging requirements in other sectors. This makes supply chain transparency a high-leverage investment that addresses multiple compliance requirements simultaneously.

The business case extends beyond compliance. Companies with comprehensive SBOM capabilities can respond faster to supply chain vulnerabilities, reduce incident response costs, and demonstrate superior risk management to customers and partners. The key is implementing automated SBOM generation and continuous component monitoring rather than treating it as a one-time documentation exercise.

Vulnerability Management Excellence

Both the CRA’s 24-hour reporting requirement and the FDA’s lifecycle security obligations demand sophisticated vulnerability management capabilities. Companies that excel in this area gain competitive advantages that extend far beyond compliance.

Proactive vulnerability management reduces breach costs significantly—studies show comprehensive vulnerability management programs can reduce incident costs by millions of dollars. Research indicates that the average cost of a data breach reached $4.88 million in 2024, according to IBM’s Cost of a Data Breach Report. More importantly, companies known for rapid, transparent vulnerability response build trust with customers and partners that translates into business growth.

The implementation challenge is building systems that can automatically detect, assess, and respond to vulnerabilities across complex product portfolios. This requires integration between threat intelligence, asset management, and incident response processes.

Secure Development as Competitive Advantage

The CRA’s Secure-by-Design requirements and the FDA’s lifecycle approach both emphasize building security into products from the ground up. Companies that master secure development practices don’t just achieve compliance—they build products that customers trust and competitors struggle to match.

Key elements include integrated threat modeling, secure coding standards, and security testing throughout the development lifecycle. The goal isn’t just to pass security audits but to build products that are inherently more resilient and trustworthy.

The Benefits of Proactive Product Compliance

The most successful product leaders are discovering that proactive product compliance creates business value that far exceeds the investment required.

Competitive Differentiation Through Security

In increasingly security-conscious markets, products with built-in security capabilities command premium pricing and win more procurement decisions. This trend is particularly pronounced in healthcare, where RunSafe Security’s 2025 Medical Device Cybersecurity Index found that 60% of healthcare organizations prioritize built-in cybersecurity protections when selecting vendors, with 79% willing to pay a premium for devices with advanced runtime protection.

Security-first product positioning also builds long-term customer relationships. Companies that can demonstrate transparent security practices and rapid vulnerability response develop customer loyalty that extends beyond individual product transactions.

Operational Excellence and Risk Reduction

Secure-by-Design development practices reduce technical debt by preventing security issues rather than retrofitting solutions. This approach typically results in lower long-term development and maintenance costs, even accounting for upfront security investments.

Good security practices also streamline regulatory audits and compliance verification. Companies with mature security programs spend less time and resources on compliance activities because their standard practices already meet or exceed regulatory requirements.

Financial Returns and Investment Attraction

The financial benefits of proactive security extend beyond cost reduction. Healthcare organizations demonstrate this market reality clearly, as seen in RunSafe’s 2025 Medical Device Cybersecurity Index. 79% of healthcare buyers are willing to pay a premium for devices with advanced runtime protection, with 41% willing to pay up to 15% more for enhanced security. Additionally, 83% of healthcare organizations now integrate cybersecurity standards directly into their RFPs, while 46% have declined to purchase medical devices due to cybersecurity concerns.

Risk reduction creates additional financial value through lower incident response costs, reduced legal exposure, and improved cyber insurance rates. Companies with strong security programs often achieve significantly lower insurance premiums and better coverage terms. The documented financial impact of attacks like WannaCry, which cost the NHS £92 million, demonstrates that prevention is far more cost-effective than recovery.

What’s Next: Preparing for the Evolving Landscape

The regulatory landscape will continue to evolve, with several emerging trends that product leaders should monitor and prepare for.

1. AI and machine learning governance represent the next frontier of product regulation. As AI capabilities become embedded in more products, expect new requirements for AI security, transparency, and accountability.
2. Quantum-safe cryptography is another emerging area. As quantum computing capabilities advance, current cryptographic standards will become vulnerable, creating new requirements for post-quantum security measures.
3. Cross-border data flow regulations continue to evolve, with new privacy and data localization requirements affecting how products handle and store user data.

Strategic Recommendations for Product Leaders

Based on the regulatory trends and business opportunities outlined above, several strategic recommendations emerge for product leaders navigating this complex landscape:

1. Invest heavily in automation capabilities

Manual compliance processes are unsustainable given the complexity and pace of regulatory change. Companies that build automated compliance capabilities will have significant advantages over competitors still relying on manual processes for monitoring, reporting, and verification.

2. Build strategic security partnerships

Few companies have all the expertise needed to excel across the full spectrum of security and compliance requirements. Strategic partnerships with specialized security vendors can provide access to expertise and capabilities that would be expensive to develop internally while accelerating time-to-market for compliant products.

3. Focus on security solutions that eliminate entire vulnerability classes

Rather than playing defense against individual threats, prioritize technologies that can eliminate broad categories of vulnerabilities. Runtime protection solutions that prevent exploitation at the device level represent this approach—they provide comprehensive protection without requiring constant updates or patches. This strategy significantly reduces risk while simplifying compliance management across product portfolios.

4. Stay informed about regulatory developments through structured processes

The regulatory landscape continues to evolve rapidly, and companies that can anticipate changes rather than just react to them will maintain competitive advantages. Establish dedicated resources for monitoring regulatory trends and translating them into product development requirements.

5. Design for global compliance standards from the start

Rather than building separate compliance programs for different markets, design for the most stringent requirements across all target markets. This approach reduces complexity while ensuring products can be sold in any market without additional compliance engineering.

Product Compliance as a Competitive Advantage

The convergence of the EU Cyber Resilience Act, FDA cybersecurity requirements, and other emerging regulations represents both the greatest challenge and the greatest opportunity facing product leaders today. The companies that view these requirements as innovation drivers rather than compliance burdens will build more secure, resilient, and successful products.

The critical insight is that waiting is not a viable strategy. The December 2027 CRA deadline and evolving FDA requirements create urgency, but companies that start building security capabilities now will discover that the benefits extend far beyond regulatory compliance.

For product leaders ready to turn cybersecurity compliance into a competitive advantage, the path forward is clear: embrace security as a core product differentiator, invest in the capabilities needed to excel at both security and compliance, and build the partnerships needed to stay ahead. The companies that make these investments today will be the market leaders of tomorrow.

Learn more about how to safeguard your code to up your product compliance. Get the white paper: “Safeguarding Code: A Comprehensive Guide to Addressing the Memory Safety Crisis.” 

The post What Product Leaders Need to Know About EU CRA, FDA, and Cyber Regulations appeared first on RunSafe Security.

Even with decades of hard-earned security wisdom and modern verification tools, embedded software encounters the same kinds of bugs. Why do these mistakes keep showing up in code written by seasoned engineers? How do you write software that’s both secure and shippable, especially when staring down a deadline?

To dig into these questions, we spoke with Rolland Dudemaine, Director of Field Engineering at TrustInSoft. Rolland has spent more than 25 years in the embedded software world, working on the design and development of safety-critical and security-sensitive systems. He’s a regular open-source and AUTOSAR contributor, and he’s seen the industry’s best practices evolve alongside the pitfalls that stubbornly refuse to disappear.

In this Q&A, Rolland offers a straight-from-the-trenches look at secure coding, from the easy-to-miss mistakes that cause the biggest headaches, to the right way to layer security tools, to what “memory safety” really means in practice. Whether you’re writing firmware every day or steering an organization’s embedded security strategy, you’ll find insights here you can put to work.

1. What are the most common coding mistakes that introduce vulnerabilities in embedded software and why do they persist despite decades of security guidance?

Rolland Dudemaine: ​​In general, the remaining coding mistakes relate to the corner cases of the software. These often lead to runtime errors that can cause crashes, or worse, silent data corruption that may be exploitable.

Among those that remain, off-by-one errors (leading to buffer overflow/underflow) and computation overflow/underflow are the most typical, because they are not necessarily easy to reach during functional testing. When using a programming language that requires manual memory allocation, use-after-free remains a very visible cause of trouble. MITRE does a good job of listing such issues.

One of the reasons why these issues remain is that it is not possible to functionally test for these corner cases: there is an almost infinite number of ways to corrupt data. Instead, using appropriate tools is the only way to detect these kinds of issues.

2. In your experience, what’s the most overlooked aspect of secure coding in embedded C/C++?

Rolland: For projects reusing code, projects always underestimate the cost of ownership of open-source libraries. It’s not that these libraries inherently have lower quality; instead, the specific use of such libraries within the project may not be the same as the original intended usage, and it happens often that projects reach buggy corner cases. If you use third-party code, you become responsible for it.

For project-specific software, processes often focus on form over function. While using coding rules is the best way to improve maintenance cost, and well-tested, consistent code is likely to have fewer bugs, this doesn’t mean such bugs are eliminated! It’s only risk reduction, without guarantee.

During testing and code audits, using appropriate tools to check for mistakes is important. This includes static analysis, coverage tools and sanitizers. TrustInSoft Analyzer is one such tool that covers all of this in one go, but using separate tools is already a start.

3. Static analysis, formal verification, fuzzing, runtime protections—there are lots of tools out there. How should teams think about layering these techniques to get the best coverage?

Rolland: Security is all about layering. Much like serious network security always advises applying multiple network encryption schemes, code security goes through examination of the code through different angles and levels of protection.

“Security is all about layering. … Code security goes through examination of the code through different angles and levels of protection.”

That said, good security (and safety!) planning tries to avoid failures, and also plans for swift reaction in case of error after deployment. Similarly, static analysis, formal verification, and fuzzing are great examples of tools to be used during development, while runtime protection is efficient to ensure that any remaining failures will still be caught and handled gracefully in the field. RunSafe’s runtime protection is a state-of-the-art example of such a scheme that will detect and report any failure observed in production.

4. When evaluating code quality and security, how do you balance “perfect” code with what’s practical in the context of tight deadlines and limited resources?

Rolland: Perfection doesn’t exist in this world. What remains is how close the project needs to approach perfection. From there, various decisions can be made to focus on the pain points and dire consequences of field failures. And the effort to avoid them will have to be adapted in consequence.

“Perfection doesn’t exist in this world. What remains is how close the project needs to approach perfection.”

A similar pattern is to make or buy: Do you reuse third-party code? Open-source code? Use free or commercial tools to work?

When you start to get serious about your job, it quickly becomes visible that a thorough, reviewed, and if possible exhaustive approach should be used. Again, this can range from simply following coding guidelines and using systematic and formal verification tools to conducting an independent vulnerability analysis.

A heavy but interesting worldwide reference is the Common Criteria specification. Unless one has an extremely critical asset (think nation-level top-secret) to protect, the list is too extreme to be reasonably applied as is. However, it is a fantastic description of the methods to develop and verify software: selecting the right level for your needs and challenge will always push things in the right direction.

5. Can you share an example (anonymized or general) of how rigorous software verification caught a potentially serious bug before it made it to production?

Rolland: Based on feedback from our customers, the most common “potentially serious bugs” are accesses to uninitialized variables, as well as off-by-one errors. Since they are caught ahead of production, the true damage they could have caused is hard to predict, but can range from a mere malfunction to a potentially devastating bypassable security gate. 

Another example that we/TrustInSoft recently advertised at the CYSAT Paris event is a series of bugs that we found in the NASA cFE (Control Flight Executive). That open-source piece has been used in many space devices in production (James Webb telescope, among others), yet we recently managed to find a few runtime errors that could be damaging, including access to uninitialized variables.

6. What role does memory safety play in modern embedded security, and how are you seeing teams address these risks differently today than five years ago?

Rolland: The adoption of systematic security audits, sanitizers, and other formal verification tools, such as TrustInSoft Analyzer, has helped raise the bar and limit the amount and types of bugs that pass through.

That said, everyone working on C or C++ language code has started to look at Rust and other “memory-safe” languages. We’re actually adding Rust support to TrustInSoft Analyzer and it will ship in our next release. 

However, early analyses on customer projects using Rust show that, in fact, runtime errors persist, at a lower but visible level. One of the reasons is that the definition of memory safety in Rust isn’t that there is no risk anymore; rather, if a failure is detected at runtime, the code may deterministically panic instead of doing something unpredictable. It’s much better, but it will not prevent a DoS (Denial-of-Service), for instance.

All in all, adopting a new language presents an opportunity to transition to more modern practices: code is rewritten with enhanced experience, improved design, refined coding practices, improved testing, and more precise specification. The new language itself isn’t the sole cause of improvement, but it’s a pretext for change for the better, and an opportunity to use efficient verification tools.

7. Software supply chain risks have become top-of-mind for embedded teams. How important is it to have visibility into all software components, and how do you view SBOMs within the embedded security picture?

Rolland: The European CRA (Cyber Resilience Act), the US Cyber Trust Mark, and the Chinese CSL (CyberSecurity Law) all mandate SBOM for a reason: it’s the minimum security hygiene to list what you are using and shipping. If you don’t even know what you’re shipping, how could you even start to evaluate the risks?

Once such a list is established, it becomes possible, mapped to the system and software architecture, to determine which are the risky items in terms of attack surface, and consequently identify where the verification effort should be focused.

SBOM does not make the system inherently secure: it allows projects to gauge risks. So, it definitely goes in the right direction, even when this just looks like paperwork at first.

8. Looking ahead, what trends or technologies do you think will reshape how we write secure embedded code over the next 3–5 years?

Rolland: It’s all too easy to answer AI to this question, as AI is seen as the answer to everything these days. However, AI in this specific case is a risk: humans using AI for coding are no longer the designer/logician/artist of the code, but merely reviewers. There is consequently a higher risk of subtle security implications when adopting AI-generated code; it becomes truly important, consequently, to use either formal verification tools to verify, more thorough human reviews, or both.

On a more positive note, the move to memory safe programming languages is opening the eyes of many developers and managers to the fact that good practices lead to much better code quality. We see more interest in formal verification tools, and TrustInSoft Analyzer is being trusted more than ever to verify critical code, regardless of the origin.

“Good practices lead to much better code quality.”

Building Resilient Embedded Software with the Right Tools and Partners

Securing embedded systems is an ongoing process that demands rigor, the right tools, and a willingness to adapt as threats evolve. As Rolland Dudemaine’s insights show, achieving meaningful improvements in software security requires both technical discipline and strategic planning, from catching elusive corner-case bugs to layering defenses that protect systems long after deployment.

If your team is looking to strengthen its approach to embedded security, RunSafe Security offers solutions designed to neutralize the entire class of memory safety vulnerabilities and protect against runtime exploits without disrupting your development workflow. 

Learn how our runtime code hardening eliminates memory corruption risks and see how we help organizations in critical industries ship safer, more resilient systems.

Explore RunSafe Protect.

The post Secure Coding Practices: A Q&A with Industry Expert Rolland Dudemaine appeared first on RunSafe Security.

With modern vehicles containing over 100 million lines of code and dozens of software components, attack surfaces are expanding. And as Joe points out early in the episode, today’s vehicles aren’t just “computers on wheels”—they’re entire software ecosystems in motion.

Listen the full episode:

Automotive Cybersecurity Risks in Software-Defined Vehicles

The convenience of real-time navigation, remote keyless entry, and seamless phone integration comes with a hidden cost: exposure. According to Joe, 92% of cyberattacks in the automotive space in 2024 were conducted remotely—many affecting millions of vehicles at once. Attackers are increasingly leveraging the very protocols that enhance user experience to manipulate vehicle systems, including brakes, steering, and door locks.

Complicating matters further is the long-standing reliance on the CAN bus protocol for in-vehicle messaging. While essential for transmitting signals between components like brake pedals and wheel systems, the CAN bus was never designed with security in mind, and its widespread use makes replacing it a monumental task.

“The traditional protocol and networking through the CAN bus does feel like a bit of a dinosaur in the automotive industry, and unfortunately, we can’t just get rid of it.” — Joe Saunders

Safety and Security: Two Sides of the Same Coin

When it comes to compliance, frameworks like ISO 26262 and its Automotive Safety Integrity Level (ASIL) classifications are essential. These standards guide manufacturers in assessing and minimizing the risks associated with both hardware and software failures, especially in systems where human safety is on the line.

From ASIL A (least critical) to ASIL D (most critical), these classifications help developers determine the necessary level of rigor required for different components. Joe uses the example of backup lights (ASIL A) versus fully autonomous driving controls (ASIL D) to illustrate how cybersecurity is increasingly being embedded into broader safety discussions.

Memory Safety and Real-Time Operating Systems

A key focus of the episode is the importance of memory safety in securing embedded systems like ECUs and infotainment units. Vulnerabilities in these systems can lead to catastrophic outcomes, especially when attackers exploit low-level memory bugs to gain control of vehicle operations.

RunSafe’s platform addresses this challenge head-on by hardening binaries against memory-based attacks without requiring changes to source code. This is especially relevant for real-time operating systems (RTOS) such as QNX and embedded Linux, which are commonly used across millions of vehicles.

Untangling the Automotive Supply Chain

One of the most pressing and complex challenges for automakers is managing their global, multi-tier supply chains. Software Bills of Materials (SBOMs) play a critical role here by offering visibility into the origin and composition of every software component.

“There are restrictions in the United States… you can’t get [automotive components] from China or Russia. How do you know that a software component is not built by an entity from one of those countries?” — Joe Saunders

The automotive supply chain doesn’t just involve hardware. It also includes firmware, embedded software, and third-party libraries. Without tools like SBOMs and strong vendor verification processes, organizations are vulnerable to both intentional backdoors and unintentional compliance violations.

 

Related Articles:

• Driving Innovation Safely: 5 Ways to Secure Software-Defined Vehicles
• Buckle Up: Addressing Embedded Systems Security in the Automotive Software Supply Chain
• Secure by Design: Building a Safer Future Through Memory Safety
• Making Secure by Design Practical: How We’re Building Resilient Software

The post Shifting Cybersecurity Left in Automotive: Why Secure by Design Is Critical for Modern Vehicles appeared first on RunSafe Security.

This year, we’re proud to sponsor the Maritime Hacking Village (MHV), the destination at DEF CON for hackers, engineers, and tinkerers who want to get their hands on real maritime tech and explore the vulnerabilities lurking beneath the surface.

The 2025 theme, “Digital Blockade in the Pacific,” draws on real-world geopolitical flashpoints to frame a gamified hacking experience built around real maritime infrastructure.

“It’s definitely not RSA, and it’s not Black Hat,” said Duncan Woodbury, Executive Director of the Maritime Hacking Village, on RunSafe’s Exploited: The Cyber Truth podcast. “There are no sponsored talks. What we do at villages is bring people together to perform security research against real-world critical infrastructure systems.”

This year’s setup includes:

• 🚤 Two unmanned surface vessels (USVs)—autonomous watercraft adapted for live RF and telemetry hacking
• 🏗️ A working crane control system—donated by one of the largest ports in the Western Hemisphere, complete with a real 8×8-foot shipping container you can “unlock” via successful exploit
• 🛰️ GPS & AIS spoofing scenarios—showcasing how easy it is to manipulate unencrypted maritime systems
• 🎯 Gamified CTF-style challenges—all wrapped in a storyline simulating a digital blockade in a contested region

“We prioritize real systems and avoid simulations,” said Woodbury. “We can produce powerful results in just 20 hours of conference time.”

“That’s why we’re excited to be part of this,” said Joe Saunders, CEO and Founder of RunSafe Security. “DEF CON is where real vulnerability research happens. The Maritime Hacking Village puts legacy systems and cutting-edge autonomous vessels in front of the best hackers in the world—and we get better for it.”

Why RunSafe Is at the Maritime Hacking Village

RunSafe is no stranger to high-consequence embedded environments. From defense to critical infrastructure to automotive, we work with teams building software that must keep running.

“Maritime infrastructure is what we call the last dinosaur,” said Woodbury. Many systems are decades old and are just now beginning to adopt digital tech and automation.

RunSafe’s core technology—RunSafe Protect—defends embedded software by neutralizing memory safety vulnerabilities at runtime, preventing exploit chains without requiring developers to rewrite code. It’s the kind of defense that matters when you’re out on the ocean, or in a factory, or controlling a satellite.

“That’s why we’re excited to be part of this,” said Joe Saunders, CEO and Founder of RunSafe Security. “DEF CON is where real vulnerability research happens. The Maritime Hacking Village puts legacy systems and cutting-edge autonomous vessels in front of the best hackers in the world—and we get better for it.”

See You in the Village

DEF CON is where the boundaries of cybersecurity get stress-tested. We’re excited to be part of a community pushing those limits not just in theory but in practice.

If you’re curious about embedded systems, maritime autonomy, or how to defend devices that can’t afford to fail, make sure the Maritime Hacking Village is on your map.

“Hiding vulns sink all ships,” said Saunders. “If you don’t probe your own systems, motivated actors will. By engaging with communities like DEF CON, you’ll benefit from the discoveries, and you’ll be better off in the long run.”

📍 DEF CON 33 | Maritime Hacking Village
🗓 August 8–11, 2025
📌 Caesars Forum, Las Vegas

Catch all the updates from the Maritime Hacking Village: https://www.linkedin.com/company/maritimehackingvillage/
Learn more about RunSafe Security: https://runsafesecurity.com

Want to connect ahead of the event? Drop us a line or flag us down in the village. We’ll be the ones near the watercraft.

The post RunSafe Security Joins the Maritime Hacking Village at DEF CON 33 appeared first on RunSafe Security.

If you’ve worked in cybersecurity for even a short time, you’ve heard the term Secure by Design. It shows up in marketing decks, compliance checklists, and industry frameworks. But beneath the jargon is something real and increasingly urgent.

In our recent episode of Exploited: The Cyber Truth, RunSafe Security Founder and CEO Joe Saunders joined host Paul Ducklin to unpack what Secure by Design really means, how it aligns with national cybersecurity priorities, and what it looks like in practice.

The post Making Secure by Design Practical: How We’re Building Resilient Software appeared first on RunSafe Security.

From medical devices and aerospace systems to industrial controls and automotive ECUs, embedded systems are the unsung heroes of modern technology. But with that ubiquity comes risk. Threat actors increasingly target embedded software, like firmware, bootloaders, OS kernels, and middleware, because it often lacks runtime protections and memory safety controls.

Embedded software security is a frontline issue in national security, critical infrastructure resilience, and commercial device integrity. So how do you secure embedded systems in a way that’s proactive, scalable, and tailored to the unique constraints of these devices?

Here’s how to strengthen your embedded software security without slowing down innovation or compromising performance.

1. Harden Software at the Binary Level

Many embedded systems are written in C or C++, which are notoriously memory-unsafe. Memory safety vulnerabilities, such as buffer overflows and use-after-free errors, are common and can enable remote code execution and other malicious actions. Traditional defenses like ASLR or stack canaries help, but they’re not foolproof and can be bypassed with enough determination.

RunSafe Security addresses this problem at its root by applying binary hardening techniques that make it dramatically harder for attackers to exploit memory vulnerabilities. Instead of just detecting bugs, RunSafe’s Protect technology randomizes binaries at build time using techniques like Load-Time Function Randomization (LFR) to break exploit chains without changing the source code.

This approach prevents entire classes of attacks before they ever reach the device and works without adding runtime overhead or requiring source code access.

2. Treat SBOMs as a Living Security Asset

A Software Bill of Materials (SBOM) is now table stakes in embedded development. But many SBOM generators miss important dependencies or generate high rates of false positives and negatives.

RunSafe enhances SBOM generation by building SBOMs during compilation, reporting on file opens, to produce rich and accurate SBOMs, especially for C and C++ code on Linux, Windows, and RTOS environments. 

While regulators are pushing for more SBOM visibility in sectors like automotive (UN R155), medical devices (FDA), and the Department of Defense (DOD), SBOMs provide more than a compliance checkbox. They are your first line of defense in software security, offering visibility into your software’s risk profile. SBOMs for embedded systems are security-focused artifacts that show what third-party libraries are potentially risky and where vulnerabilities could propagate across systems.

With SBOMs, you have insight to defend what you ship.

3. Protect Legacy Systems Without Rewrites

Securing legacy embedded systems is one of the most persistent challenges in cybersecurity. Source code is often missing. Toolchains are outdated. Patching is notoriously difficult. Yet these systems continue to run critical infrastructure, defense platforms, and life-sustaining devices.

RunSafe Protect is built for this exact scenario. It disrupts cyber exploits by relocating software functions in memory each time software is run, eliminating 100% of memory safety vulnerabilities to maintain system integrity and security. It does not require access to source code or changes to the original software, preserving functionality while significantly reducing exploitability.

This capability is vital for sectors with long product lifecycles and stringent recertification requirements, especially aerospace and defense, industrial control, and medical device manufacturers. Protect makes it possible to defend aging systems without waiting for a redesign or rewrite.

4. Build Cyber Resilience, Not Just Perimeter Defenses

Traditional embedded security tends to prioritize perimeter protections like firewalls, secure boot, and encrypted communications. However, once an attacker breaches these defenses, systems are often left vulnerable to lateral movement, privilege escalation, and remote code execution.

RunSafe Security shifts the paradigm by embedding advanced cyber resilience directly into the device. Its patented Load-time Function Randomization (LFR) technology relocates software functions in memory each time the software runs, ensuring every binary image is functionally identical but logically unique. This granular randomization at the function level disrupts memory-based exploits—such as buffer overflows and return-oriented programming (ROP)—making attacks unpredictable and unreliable even if vulnerabilities exist.

RunSafe’s approach neutralizes not only known vulnerabilities but also unknown, zero-day threats, by eliminating entire classes of memory safety flaws—the root cause of nearly 70% of embedded system vulnerabilities.

By shrinking the attack surface and hardening the system from the inside out, RunSafe ensures attackers cannot reliably exploit vulnerabilities, even if they gain initial access.

5. Make Security a Build-Time Discipline

Security shouldn’t be an afterthought. It should be part of the build system. The RunSafe Security Platform integrates directly into your DevOps and build pipelines, providing automated vulnerability identification, authoritative SBOM generation, and patented memory relocation to harden software at build time.

This keeps your engineers focused on features and performance, while security happens behind the scenes.

A Smarter Path Forward for Embedded Software Security

Embedded software security isn’t just about patching CVEs or buying a next-gen firewall. It’s about making your systems fundamentally more difficult to exploit regardless of whether you’re building a satellite, an insulin pump, or a warship.

RunSafe Security gives you the tools to:

• Stop memory-based attacks in embedded systems
• Generate high-fidelity, actionable build-time SBOMs
  
• Secure legacy code without rewrites
  
• Embed resilience into your runtime environment
  
• Shift security left, without breaking builds or slowing delivery

Whether you’re designing a next-generation avionics stack or securing an IoT device fleet, RunSafe’s approach to embedded software security helps you deliver code that’s harder to hack and easier to trust.

See how it works

Run a Risk Analysis
Learn More About Runtime Protection
View the SBOM Comparison Chart

The post How to Strengthen Your Embedded Software Security appeared first on RunSafe Security.

The consequences reach beyond network disruptions: 75% of these incidents directly compromised patient care, with nearly half compelling organizations to revert to manual processes just to maintain operations. When a cyberattack necessitates transferring patients to other facilities, which occurred in 24% of cases, the situation creates serious medical emergencies.

The convergence of IT and OT security is putting medical devices at the center of cybersecurity strategy, the report shows. Healthcare organizations can no longer protect medical devices in isolation. Securing patient-critical systems now requires defending the entire interconnected ecosystem.

Because of this, we’re seeing a changing relationship between healthcare providers and medical device manufacturers. The findings of the 2025 Index show that for healthcare buyers, cybersecurity is becoming a gatekeeper to market access.

The post What Healthcare Buyers Expect from Medical Device Manufacturers: Security Is No Longer Negotiable appeared first on RunSafe Security.

Critical infrastructure and the embedded systems that underlie it are under attack. State-sponsored threat groups, like MISSION2025 and Volt Typhoon, are specifically targeting key sectors integral to national and economic security, like aerospace and defense, healthcare systems, telecom networks, and manufacturing operations.

Embedded systems are foundational to all of these sectors. While embedded systems offer clear benefits in terms of performance, power efficiency, and specialization, they also present a distinct set of cybersecurity challenges.

1) The Trillion-Dollar Code Problem

One of the most urgent issues in securing embedded systems is the sheer amount of legacy code that is vulnerable to memory-based exploits. Most embedded applications are written in memory-unsafe languages like C and C++, which are susceptible to common memory safety vulnerabilities such as buffer overflows and use-after-free errors. These vulnerabilities account for the majority of software exploits in the embedded space.

Although security experts and government agencies, such as CISA, advocate transitioning to memory-safe languages like Rust, a complete rewrite of legacy systems is often economically and logistically unfeasible. For many industries, this would mean years of recoding and recertification, impacting time-to-market and product reliability. Not to mention the expense. The cost to rewrite the code base for embedded systems could easily run into the billions for some companies, requiring extensive testing and diverting developer and engineering resources that would otherwise be allocated to innovation and further product development.

The best way to address this challenge includes taking a hybrid approach, selectively rewriting only the most critical components in safer languages while applying runtime protections to mitigate vulnerabilities in existing binaries. This dual approach enables continued innovation and field performance without requiring full-scale code replacement.

2) Expanding the Attack Surface with Connectivity

Recently, researchers at Georgia Tech demonstrated the ability to hijack industrial control systems through nothing more than a web browser. By exploiting embedded web servers in programmable logic controllers (PLCs), they showed how attackers could gain full control over motors, power relays, and water pumps—all while remaining virtually undetectable, even after hardware resets.

The rise of connectivity in embedded devices—through IoT, 5G, edge computing, and cloud integrations—has significantly expanded the attack surface. Devices that were once isolated and secure-by-default are now exposed to remote access, data exfiltration, and distributed attacks.

Many embedded systems were not designed initially with external communication in mind, and retrofitting them for connected environments often leaves security gaps. In addition, increased reliance on third-party software, open-source libraries, and supply chain components introduces additional risks.

Addressing this challenge requires a proactive cybersecurity approach throughout the device lifecycle. This includes secure software development practices (like threat modeling and SBOM generation), continuous vulnerability assessment, and runtime threat mitigation. Embedded systems must be protected not only at the perimeter but also internally—at the firmware and binary levels—to resist exploitation even when a network breach occurs.

3) Securing Legacy Systems

Another persistent challenge is securing legacy systems that remain in active use across industries. These systems often rely on outdated hardware and software stacks that lack compatibility with modern security technologies. They may no longer receive vendor support or security patches, and yet continue to perform critical functions in sectors like manufacturing, transportation, and healthcare.

Replacing these systems is often cost-prohibitive or operationally disruptive. As a result, organizations are left with the difficult task of securing systems that were never designed with today’s threat landscape in mind.

To improve the security of legacy embedded systems, organizations should enforce cybersecurity requirements during new development, conduct regular vulnerability assessments for systems already in operation, and deploy runtime protections that can harden binaries in-place without requiring changes to source code or hardware. These measures extend the safe lifespan of legacy devices while reducing overall risk exposure.

The post 3 Challenges in Embedded Systems Security appeared first on RunSafe Security.

What Makes OT Security So Hard to Fix?

Unlike traditional IT, OT systems power critical infrastructure like energy grids, water management, manufacturing floors, and more. These devices often run on low-powered hardware with long lifespans and were never designed for modern connectivity. They were secured by locked doors, not firewalls.

Fast forward to today, and these devices are increasingly connected to the internet—and exposed.

Memory Safety: Still the Achilles’ Heel

Many vulnerabilities in common OT products are caused by buffer overflows or memory corruption flaws. While systemic, these vulnerabilities can be proactively addressed with memory safety protections.

“If you can eliminate entire classes of vulnerabilities before software hits the field, you don’t need to play whack-a-mole with patches,” says Saunders.

RunSafe’s approach focuses on preventing exploitation at the binary level, effectively making vulnerabilities non-exploitable without requiring post-deployment patching.

The Growing Complexity of the OT Software Supply Chain

Even the simplest industrial device could include thousands of open-source software components. Without visibility into the Software Bill of Materials (SBOM), organizations are left guessing about what’s inside.

“If a vendor can’t tell you what’s in their product, chances are, they don’t know either,” says Saunders.

Knowing your software’s components—and their vulnerabilities—is critical for compliance. It’s also critical for managing risk across the supply chain, identifying attack surfaces, and making smart, prioritized decisions.

Why Patching Alone Isn’t Enough

Patching in OT isn’t like clicking “update” on your phone. It can require physical access to remote locations and months of planning. Worse, many vulnerabilities go unpatched for 180+ days, leaving critical infrastructure exposed for far too long.

This makes proactive protection methods—like RunSafe’s memory randomization techniques and runtime protection—essential tools in a modern OT defense strategy.

What Should Product Manufacturers and Asset Owners Do Now?

Joe Saunders outlines a simple yet powerful framework:

For OT Product Manufacturers:

1. Generate a complete SBOM for each product.
2. Identify known vulnerabilities.
3. Prioritize fixes based on impact and exploitability.
4. Adopt Secure by Design tools that eliminate entire classes of vulnerabilities at build time.

For Asset Owners:

1. Request SBOMs from all vendors.
2. Analyze vulnerabilities across all systems—from HVAC to power to physical access.
3. Demand security transparency and memory safety protections from suppliers.

This shift toward accountability and visibility reduces operational costs and futureproofs infrastructure.

Regulation, Risk, and the Path Forward

Fixing OT security won’t happen with checklists and wishful thinking. It’ll take:

• Regulation that incentivizes change, like the Cyber Resilience Act
• Automation that scales patchless security
• Shared responsibility across the ecosystem

“The real question isn’t whether we can fix OT security,” Saunders concludes. “It’s whether we want to—and who’s willing to lead the charge.”

The post Fixing OT Security: Why Memory Safety and Supply Chain Visibility Matter More Than Ever appeared first on RunSafe Security.

What Is the CRA and Who Does It Affect?

“Software Bill of Materials is actually an essential point to help share across the ecosystem, across the value chain. It’s a new journey to elevate your security posture even higher by really knowing exactly what’s in all those components in your final product.” — Joseph M. Saunders

New Liabilities and the Cost of Non-Compliance

The CRA introduces substantial new liabilities for non-compliance, including fines of up to €10 million or 2.5% of global turnover. These penalties aim to ensure organizations take cybersecurity seriously. While some may view this as a burden, Saunders argues these “sticks” are necessary to promote best practices, improve code quality, and enhance organizational resilience.

How Are Organizations Preparing?

Forward-looking companies are already taking action to align with EU CRA requirements:

• Cross-functional planning: Security is being embedded across legal, development, marketing, and product teams.
• SBOM adoption: Organizations are building workflows to generate and update SBOMs throughout the lifecycle.
• Supply chain scrutiny: Greater transparency is being demanded from vendors and partners.
• Incident response readiness: Detection, reporting, and remediation capabilities are being strengthened.

The Role of Cyber Insurance in a Post-CRA World

Even with the best Secure by Design development practices in place, vulnerabilities will still surface. No software is flawless, and the complexity of modern digital ecosystems—particularly those reliant on third-party and open-source components—means that gaps in security are nearly unavoidable.

The EU Cyber Resilience Act (CRA) raises the stakes, holding manufacturers and developers accountable for the entire lifecycle of their products. This makes cyber insurance not just a smart investment but a strategic imperative. 

“Cyber insurance for products is a great idea,” Saunders said, explaining how you can set up engineering processes to follow certain steps to reduce risk. If you can demonstrate that you are taking steps to avoid an attack, then an insurer can provide coverage.

As compliance obligations expand and the consequences of non-conformance grow more serious, organizations need robust risk transfer mechanisms to safeguard against the financial fallout of cyber incidents and regulatory breaches.

In the post-CRA environment, insurers may begin requiring evidence of strong cybersecurity hygiene—such as regular vulnerability assessments, real-time monitoring, SBOM documentation, and incident response readiness—as prerequisites for coverage or lower premiums. By combining proactive security practices with the safety net of cyber insurance, companies can create a more resilient posture while minimizing exposure to emerging risks.

Preparing to Compete in the Cyber Resilience Economy

The EU CRA signals a fundamental shift in how security is expected to be built, managed, and demonstrated across connected products. It’s a wake-up call for organizations that have deprioritized security in favor of speed or cost savings.

By embracing Secure by Design principles, adopting Software Bill of Materials (SBOM) practices, and building security into every stage of the product lifecycle, forward-thinking organizations can prepare for regulatory compliance and gain a competitive edge. These efforts increase stakeholder trust, improve software quality, and reduce time-to-remediate when issues arise.

Rather than viewing the CRA as a burden, it should be seen as a blueprint for building trust in the digital age. Organizations that act now will not only avoid fines and reputational damage, they’ll also be better positioned to lead in a marketplace that increasingly rewards transparency, security, and resilience.

The post The EU Cyber Resilience Act (CRA) Exposed: What You Need to Know Now appeared first on RunSafe Security.