In early 2025, a security researcher discovered that the firmware powering a popular series of microcontrollers—used in everything from consumer electronics to industrial sensors—was maintained by exactly one person. That person held the sole copy of the signing keys on a single laptop. If that laptop were lost, stolen, or encrypted by ransomware, the entire supply chain for that chip would grind to a halt. A hardware recall might be the only path forward. This is not an edge case. It is a structural feature of the embedded ecosystem.

The Laptop and the Line: One Person Holding a Chip's Fate

The maintainer in question, who asked to remain anonymous for fear of backlash, inherited the project from a former colleague who left the company abruptly. The codebase was undocumented. The build environment lived on a single virtual machine. The signing keys—used to authenticate firmware updates—were stored in an encrypted directory on that VM, with no backup. The maintainer told me, "If my laptop dies, the chip is dead."

This is not a startup story. The microcontroller is produced by a mid-sized semiconductor firm with hundreds of employees. The firmware itself is open source, hosted on GitHub, with dozens of contributors. But the release process—the actual signing and publishing of binaries—is gated by one person. The company has no formal bus factor policy. The project has no documented handover protocol.

Bus factor is a measure of how many people can be hit by a bus before a project collapses. In this case, the number is one. The risk is not hypothetical. In 2024, a similar project lost its sole maintainer to a prolonged illness. For six months, no firmware updates were released. Critical security patches sat in pull requests. Users were left exposed to known vulnerabilities.

The embedded world is full of such stories. A 2023 survey by the Eclipse Foundation found that roughly 40% of open-source IoT projects had no more than two active maintainers. For firmware projects, the number is likely higher. The reasons are structural: low-level software is hard to fund, hard to learn, and easy to ignore—until it breaks.

Bus Factor One: How Firmware Became a Single-Point Failure

Firmware occupies a strange place in the software stack. It is not quite hardware, not quite application code. It runs on bare metal, often with no operating system, and its failures can brick devices. Yet it is rarely treated as critical infrastructure. Hardware companies often view firmware as a cost center, a necessary evil to ship chips. Open-source firmware projects, in particular, struggle to attract sustained funding.

Maintainer burnout is endemic. The work is detail-intensive, poorly documented, and often invisible. A firmware bug might not manifest for years, only to cause a recall. The pressure is high, the recognition low. Many maintainers work alone, in their spare time, with no institutional support. The result is a fragile ecosystem where key projects depend on the goodwill of a handful of people.

In 2024, a widely-used bootloader project was locked for weeks because the maintainer forgot the password to the signing server. The server was a cloud instance tied to a personal email account that had been compromised. The maintainer had to reset the account through a lengthy support process, during which no signed updates could be issued. The incident was not malicious, but the impact was the same: a single point of failure brought the project to a standstill.

The cost of a bus factor event is measured in months of patching delays. For a chip used in medical devices, that can mean patient risk. For a chip used in industrial controllers, it can mean production downtime. The supply chain is only as strong as its weakest maintainer.

Consider also the case of a real-time operating system (RTOS) for automotive controllers. In 2022, the sole maintainer of a critical memory management component left the project without notice. It took the community roughly four months to find a replacement and bring them up to speed. During that period, two CVEs were reported and remained unpatched. The delay forced several automakers to deploy workarounds that increased cost and complexity. The bus factor was one, and the entire automotive supply chain felt the ripple effects.

The Funding Gap: Why Nobody Pays for Firmware Maintenance

Hardware companies rarely fund upstream firmware work. They benefit from open-source bootloaders, real-time operating systems, and driver stacks, but they see little incentive to pay for their maintenance. Crowdfunding campaigns cover initial development—a new board, a novel feature—but not the years of bug fixes, security updates, and documentation that follow.

The Linux Foundation's Zephyr project is an exception. It has corporate backing from Intel, NXP, and others, and employs a small team of maintainers. But Zephyr is a full RTOS. Most firmware projects are smaller: a USB stack, a cryptographic library, a bootloader. These projects often have no funding at all.

Enterprise users are the worst offenders. A company might deploy a chip in thousands of devices, relying on its firmware for security-critical functions, yet never contribute a dollar to its maintenance. The maintainer of a common cryptographic library for microcontrollers told me, "I get emails from Fortune 500 companies asking for urgent fixes. They don't offer to pay. They expect free labor."

The plea is familiar: "We need a sustainable model." Some projects have turned to foundations like the OpenHW Group, which provides shared infrastructure and legal support. Others have tried sponsorship programs, with mixed results. The core problem is that firmware maintenance is invisible work. It doesn't ship new features. It doesn't generate press. It just keeps the lights on.

There is a counter-argument worth considering: some hardware vendors argue that funding upstream firmware maintenance is not cost-effective because they already pay for internal validation and certification. They see open-source firmware as a free component that they can customize as needed. But this view ignores the fact that without healthy upstream projects, the entire ecosystem suffers. A single unpatched vulnerability in a shared bootloader can affect dozens of downstream products. The cost of collective inaction is far higher than the cost of shared maintenance.

Security at the Boundary: When One Person Controls the Boot Chain

Firmware vulnerabilities are a growing attack surface. The LogoFAIL exploit (CVE-2023-40238) showed how a malicious image could compromise the UEFI boot chain. The vulnerability affected millions of devices and required coordinated patching across multiple vendors. But many firmware projects lack the resources to respond quickly to such threats.

A single maintainer means slow response to critical CVEs. The maintainer must triage the report, reproduce the bug, develop a fix, test it across multiple hardware variants, sign the update, and publish it. If the maintainer is on vacation, sick, or overwhelmed, the fix sits. In the meantime, attackers have a window of opportunity.

The risk is compounded when signing keys are compromised. In 2025, a small IoT vendor discovered that a stolen firmware key had been used to sign malicious updates. The key was stored on a developer's laptop, which was infected with malware. The vendor had to revoke the key and issue a recall—a process that cost millions. The root cause was not sophisticated espionage. It was poor key management, a direct consequence of bus factor one.

Trusted Platform Module (TPM) integration can help by keeping keys in hardware, but such integration is often under-documented and under-utilized in open-source firmware projects. The expertise required to set up a proper HSM-based signing pipeline is rare. Most maintainers do what is easiest: store keys on their machine.

Furthermore, the complexity of modern firmware supply chains means that a single compromised key can have cascading effects. Consider the case of a popular IoT platform that used a shared signing key across multiple product lines. When that key was leaked, attackers could sign firmware for any device in the family. The vendor had to revoke the key and update all devices in the field—a process that took over a year. The root cause was again a single maintainer who had sole access to the key and no secure backup process.

How the Best Teams Mitigate the Bus Factor

Some teams have cracked the code. The RISC-V ecosystem's Tock project, for example, enforces peer review for all commits. No single person can merge code or sign a release. The project uses a hardware security module (HSM) for key storage, and the build pipeline is fully automated on a shared CI server. If one maintainer disappears, the others can continue.

Formal handover protocols are another best practice. A documented process for transferring signing keys, access to cloud accounts, and domain names can save weeks of recovery time. Some teams use a shared vault—like HashiCorp Vault or a physical safe—to store secrets. Access requires multiple people to authenticate.

Cross-training is essential. Two maintainers per critical component is a minimum. This means investing time in mentoring, documentation, and code review. It means accepting that a single expert is a liability. The upfront cost is real, but the alternative is a single point of failure that can halt an entire supply chain.

Regular audits of single points of failure in firmware repos can identify risks before they become crises. A simple spreadsheet listing each project, its maintainers, and their backup can reveal gaps. The act of auditing forces conversations that otherwise never happen.

Another approach is to adopt a "four-eyes" principle for all critical operations. For example, the signing process should require approval from at least two maintainers. This can be enforced through tools like Sigstore, which provides a transparent and auditable signing workflow. While Sigstore is more common in the cloud-native world, its principles apply equally to firmware. The key is to remove the dependency on any single individual.

Practical Steps for Maintainers to Protect Their Work

If you are a firmware maintainer, start by documenting every signing procedure. Write down the exact commands, the file paths, the passphrase rules. Store this document in a shared vault that at least one other person can access. Do not rely on memory or a single encrypted file.

Set up a CI/CD pipeline that does not depend on your machine. Use a cloud-based build service that can reproduce your environment. Ensure that the signing step is automated and uses an HSM or a cloud key management service. If you must use a local key, back it up in a tamper-evident envelope and store it in a safe deposit box.

Reproducible builds are your friend. If your firmware builds can be verified by anyone, the loss of your laptop does not mean the loss of the build process. Tools like the Reproducible Builds project provide guidance for embedded systems. The effort is modest; the payoff is enormous.

Create a succession plan. Name at least one person who will inherit the keys and the knowledge. Schedule a quarterly handover drill where that person actually performs a release. The drill will expose gaps in documentation and build confidence. Finally, consider joining a foundation like the OpenHW Group or the Linux Foundation's Zephyr project, which provide shared infrastructure and reduce the burden on individuals.

For maintainers who are hesitant to share keys due to trust concerns, consider using a threshold signing scheme. With threshold ECDSA, for instance, a group of maintainers can collectively sign a release without any single person holding the full private key. This approach distributes trust and eliminates the bus factor for key compromise. While the setup is more complex, it provides strong guarantees that no single laptop is a single point of failure.

The Cost of Inaction: A Cautionary Tale from the Field

In 2023, a popular bootloader project went silent for eight months. The sole maintainer had a family emergency and could not work. The project had no backup maintainer, no documented release process, and no shared signing infrastructure. Pull requests piled up. Security patches for a known vulnerability—one that allowed arbitrary code execution during boot—went unmerged.

Derivative forks appeared, each with its own set of patches. The ecosystem fragmented. Users had to choose between an unmaintained upstream and a fork of unknown quality. Some forks introduced new bugs. Others removed attribution. The trust that had taken years to build was eroded in months.

When the maintainer eventually returned, the project was in chaos. They spent weeks merging forks, reconciling divergent codebases, and apologizing to users. The incident was not malicious. It was a simple bus factor event. But the damage was real: delayed security patches, lost trust, and a fragmented community.

The lesson is clear. Bus factor is not an abstract concept. It is a concrete supply-chain risk that can delay security fixes, fragment ecosystems, and expose users to known exploits. The fix is not glamorous. It is documentation, automation, and cross-training. It is the boring operational work that prevents disasters. The next time you rely on a firmware project, ask yourself: who holds the keys? And what happens if they disappear?

There is also a positive side to this story. After the bootloader project's crisis, the community rallied to create a formal governance structure. They set up a foundation, recruited additional maintainers, and implemented a multi-signature release process. Today, the project is more resilient than ever. The bus factor went from one to five. The lesson is that recovery is possible, but it requires collective action and a willingness to invest in the boring operational work that prevents future crises.

In summary, the bus factor is a critical metric for firmware projects. It is not just about code ownership—it is about the entire release pipeline, from signing keys to build servers to documentation. By addressing these single points of failure, we can make the embedded ecosystem more secure and sustainable for everyone.