Why Safety‑Critical Software Is Becoming a Cornerstone of the IoT Revolution

The proliferation of connected devices brings fresh, often unforeseen, safety challenges to the IoT landscape.

Safety‑critical applications have relied on software for decades. For example, the Apollo flight program launched by President John F. Kennedy in 1961 incorporated onboard flight software to guide the moon‑landing missions.

While cybersecurity frequently dominates headlines, software quality—particularly for safety—often remains under‑examined. "I think the software world has woken up to security. I don’t think they’ve woken up yet to safety constraints," said Kate Stewart, senior director of strategic programs at the Linux Foundation and a finalist for the IoT World Leader of the Year Award.

[IoT World is North America’s largest IoT event where strategists, technologists and implementers connect, putting IoT, AI, 5G and edge into action across industry verticals. Book your ticket now.]

In IoT, the convergence of digital and physical realms transforms operations across sectors—from medical devices to military gear. Yet this innovation also fuels a collision between development paradigms, as cybersecurity expert Bruce Schneier explains in “Click Here to Kill Everybody: Security and Survival in a Hyper‑connected World.”

Agile development prioritizes speed and adaptability, whereas aerospace, industrial, and medical domains require rigorous testing, certification, and licensed engineering—a contrast highlighted by Schneier.

At the Linux Foundation, Stewart champions the Zephyr Project, a real‑time operating system designed for safety and security on resource‑constrained devices.

"In Internet of Things, people focus their lens on what they’re comfortable with," Stewart said. "I focus on the deep embedded side and collecting data safely and securely." She adds that many safety standards are 20–30 years old and often lag behind modern software practices.

A key challenge is assessing how a software update might inadvertently create safety problems. "When you are doing a lot of security updates to that software, does that invalidate your initial analysis? What do you need to do to make sure that by applying a bug or security fix that you’re not going to be making things worse? We don’t necessarily have the best tools right now for figuring that out," Stewart explained.

Closed safety standards add another layer of difficulty. "There are a whole series of [safety] standards right now that everyone looks to, and the interesting challenge from an open source perspective is that these standards are all closed," Stewart noted. "Open source developers don’t necessarily want to be paying $3,000 to look at the standards."

These hurdles highlight the need for tighter collaboration between safety regulators, certification authorities, and software developers. "We’re working right now with people who specialize in safety and at the various certification authorities, as well as potentially some of the regulations to understand what’s really important, and how we make safe software development practical for everyone," Stewart said.