22 September 2026 · security-leadership

Product security has to work with the product

Security has to be engineered as part of the system, not bolted on as a checklist — with functional proof, resource-impact proof, and deployment evidence as the definition of done.

Embedded product security can easily become a checklist: secure boot, SBOM, vulnerability scanning, hardening, monitoring and signed updates. All of those can be useful, but an embedded device still has a primary job to perform.

A security mechanism that materially interferes with that job needs to be reconsidered.

Start with the system, not the security tool

Embedded products may have limited CPU, RAM, storage and bandwidth. They may also have timing requirements, restricted maintenance windows, power constraints or high availability requirements. Some interact directly with a physical process.

Those constraints do not make security less important. They mean security has to be engineered as part of the system.

The first question therefore should not be “which security features can we add?” but “what does this product need to keep doing safely and reliably?”

From there it becomes possible to decide which controls are appropriate and what resource budget they can consume.

Security belongs in the lifecycle

For an embedded Linux platform, much of the useful security information already exists in the engineering process. The build knows which packages are included. It knows the configuration, kernel, services and versions. The release process knows which artifacts were shipped.

That gives us a natural lifecycle:

Build → Inventory → Vulnerability signal → Product context → Decision → Update or mitigation → Verification

Build-time checks can prevent obvious mistakes such as default credentials. The release can produce an SBOM. Vulnerability information can be compared with the actual image. Updates can deliver remediation. Monitoring can help when remediation cannot happen immediately.

The important part is that these capabilities become normal engineering activities instead of separate exercises performed once before an audit.

Measure what security costs

This is particularly important for runtime monitoring and detection. Calling something “lightweight” is not enough.

We should be able to measure its effect on CPU usage, memory, storage, network traffic, boot time and — most importantly — the application itself.

For an embedded product, a useful definition of done is therefore:

Functional proof + resource-impact proof + deployment evidence

The control works. Its effect on the device is acceptable. And we can show what was actually deployed.

That leads to a simple principle behind the work we are doing at JustEmbed:

Security must protect the product without preventing the product from doing its job.

See what that looks like in practice on our vulnerability management page.