Manufacturers, should your firmware be encrypted to prevent AI-RE?

Manufacturers are seeing increasing AI-powered reverse engineering of their firmware. This enables communities to bootload modified firmware on their devices or even create software replicas that don't need the hardware.

Some manufacturers are leaning into this, deliberately creating hackable devices that encourage community contribution. Others see this as a risk to their Intellectual Property, device security and sales revenue.

This article summarises different viewpoints to consider in your own product strategy.

Make your firmware strategy explicit

Spoiler alert. The biggest takeaway from all this is that you should make your firmware strategy explicit. How do make your community an asset rather than a risk? What do you open and close off? And when? What are your security risks?

This article stemmed from a few LinkedIn posts where I poked the bear a bit. There's many varying and insightful viewpoints.

The red ones were the hottest debates.

If you want to read the underlying LinkedIn posts, they're here:

LinkedIn: Manufacturers encrypt their firmware.

LinkedIn: Should manufacturers safely encourage firmware modding?

My take on firmware modding

I'm more of a software guy than an smart hardware expert,  so take this with a pinch of salt.

• If you're building hardware that has elements of privacy, security and health, your firmware should be encrypted to reduce your attack surface and the subsequent chances of malicious attack. Otherwise it's worth more thought.
• If you enable community firmware modding, that can lead to longer product lifespan and upcycling, so it's more sustainable. This is a good thing for people and planet.
• Therefore, you might want to consider at least opening up your firmware for modding once your support for it ends.
• There are IP implications here that I'm not qualified to offer insights about. E.g. even though you drop support for a product and firmware, the alogorithms might live on to future products and firmware. How not to give those away?
• Rather than let the community replicate your hardware in software, you should do your own software replicas as a trojan horse to drive hardware sales. I talk about this in this webinar. 
• You might consider exploring a "Manufacturer endorsed firmware modding programme" where you partially or fully open up your firmware for extension and modifiaction. A bit like an API in the SaaS world. Or, an SDK in the apps world. This supports tinkerers but doesn't solve the product end-of-life problem for consumers, nor sustainability.

Community viewpoints on the firmware modding debate

I've asked Perplexity to summarise the LinkedIn debates below (I like how it writes). Hope you find it useful when considering your strategy for firmware encryption and product lifecycle.

The comments reveal a three-way tension between:

• intellectual property
• ownership
• safety

AI is making each harder to navigate for product managers.

For engineers and founders, firmware is core product IP. Their concern is that AI-assisted reverse engineering makes it easier for competitors to reproduce years of work: sound design, algorithms, interfaces and the decisions that tie them together. From that perspective, encryption, readout protection and integrity checks aren’t inherently anti-customer. They’re safeguards against cloning products that are still commercially active, without bearing the cost of developing them.

The right-to-repair and open-hardware camp sees the same protections differently. Buying a device, they argue, should mean being free to modify it, replace its firmware and keep it useful long after the manufacturer moves on. Community firmware for devices such as the M-VAVE FM-1 is held up as a reason people value the hardware, rather than a threat to its business. The frustration is sharpest when support ends: locked firmware can leave perfectly functional hardware stranded, with no way for its owners or a willing community to maintain it.

Running through both positions is a recognition that AI changes the economics of reverse engineering. Commenters describe tools such as Ghidra, paired with modern LLMs, as lowering the expertise and time needed to understand and modify firmware. That creates opportunities for bespoke features, revived legacy devices and improvements too niche for the original manufacturer to pursue. But it also raises a different question: not just who has the right to change a device, but how safely they can do it. AI-generated router firmware, modifications to medical equipment and self-propagating agents on poorly secured devices bring very different stakes to the same debate.

A middle ground: openness over the product lifecycle

The most constructive idea to emerge is that openness need not be a permanent, all-or-nothing choice. A manufacturer might protect proprietary firmware while a product is a core source of revenue, then deliberately unlock it or release its source as it approaches end-of-life. That would give the community a route to extend the product’s usefulness rather than leaving its future dependent on the vendor’s continued support.

For product managers, the takeaway is to make firmware strategy explicit. What actually gives the product its competitive advantage: algorithms, hardware, brand or services? What control should customers have after purchase? And what happens when the business no longer wants to maintain it?

The debate is less about choosing between "encrypt everything' and "open everything" than deciding what to protect, what owners should be able to change, and when community participation becomes an asset rather than a threat.

Pocketworks works with many hardware manufacturers, helping them develop engaging software and strategies that lead to business growth. Hit me up if you'd like to chat about this stuff.