The FQA advice on:
How can I upgrade software packages if you told me that I cannot execute apt upgrade? Will there be security risks if I don’t upgrade the software?
Is that:
OTA (Over the Air)/Incremental updates/partial updates can potentially harm your OS
This misses, however, the case – as for others I expect – where Seeed Jetson devices are embedded in products that customers deploy in the field. These can be for remote locations (potentially even in another country) and not feasibly recalled for “full ROM/full updates” (via USB cable connection flash).
Can a solution be developed to enable system security updates for Seeed Jetson boards installed for such embedded applications (to make security updates feasible for remote deployments and large numbers of devices)?
1 Like
Hi there,
This is a BFD subject for sure…even on Nvidia’s board it’s a big freaking deal too. So I know a number of clients using these devices, Nvidia’s
OEM units. Like you the concern was security, it’s gotten so ridiculous that just deploying something in the field you better have a PLAN.
Seeed’s conservative stance is reasonable given the complexities of the Jetson platform. But from a product deployment and embedded systems perspective, you are also right that remote field devices need some kind of update mechanism.
The best path is not to argue “either full image only or no updates” — rather adopt a tiered update strategy:
- Minor, non-critical application updates → remote/OTA
- Security patches (in libraries/applications) → remote/OTA (with caution)
- Kernel, driver, BSP, board‐specific changes → full image update as normal
TEST EVERYTHING WELL…
By doing so you provide your users field flexibility while preserving stability and reliability.
Seeed’s caution about apt upgrade is well-founded: embedded Jetson modules involve kernel, driver, firmware, and board‐specific BSP dependencies. Without controlling the entire image, you risk system instability.”
I would Propose a hybrid strategy:
- Critical security patches: For vulnerabilities in higher‐level application layers or open source libraries, you can target remote update paths (via
apt install or container updates) only if you verify the update path does not impact kernel/driver stability.
- Major OS/BSP updates: Continue to plan full image/ROM updates (via recovery mode or reflash) when moving between major JetPack versions, adapting board support changes, etc.
- OTA image‐based update infrastructure: Invest in an OTA framework that supports your products — e.g., use a solution like Mender or similar, which is known to support Jetson platforms. Mender+1
- Design the devices for field robustness: Use A/B rootfs, rollback capability, health monitoring, staged updates, remote diagnostics.
- Document update policy: Provide your customers with clear guidance what can be updated remotely and when a field service will be required.
- Set realistic expectations:
- Emphasize that no update path is risk-free. Suggest scheduling updates during low usage windows, backing up config, testing in pilot fleets, etc.
- Make clear that occasional full reflash may still be required — and budget/plan accordingly.
- the Jetson ecosystem itself supports OTA update mechanisms. NVIDIA Docs+2Mender+2
There are ways to achieve both, But it would require additional work and infrastructure (OTA update server, image‐creation workflow, field validation and rollback strategy). It isn’t impossible, but it’s not simply running apt upgrade and calling it done.”
One good thing about it being installed inside a robot, Now way to physically infect the platform 
You can’t even get to it without disassembling the thing. 
They lean Heavy 
on the security of the network instead.
Great subject and I don’t think anyone has thought far enough ahead IMO but the seeedineers are always Working on it So , stay tuned more ahead I’m certain.
HTH
GL 
PJ 
Thank you, PJ, for your thoughtful and detailed response.
I was thinking mostly of incremental security updates and backports to the OS for the most important protections, where possible within a Jetpack release, rather than leaving these to a full Jetpack update (and a reflash requiring Force Recovery Mode).
But I have also wondered about a remote supervisor that could host Recovery Mode (and other forms of remote maintenance). We have made a start on ideas for a simple microcontroller based front end for basic support. There seem to be some powerful fleet management tools in this area, which could be a foundation (but also with expense and potential lock-in). I have not explored these in depth so far, TL;DR. BFD indeed. Thanks for the Mender reference.
In respect to testing, the different models and configurations are fully checked and run through regression testing for any updates.
And after all, the Jetson line is defined by NVIDIA as embedded-computing for Edge AI. The “Edge” can be far away, up a pole …, and embedded can be deep within a something hard to access.
1 Like
Hi there,
100 % agree. I like the sound of it too, You have a plan so You’re also NOT alone , many others want the same updatability, I believe it will catch up or ON in some root form better than what we have now
GL PJ
We keep the topic refreshed occasionally it will get some eyes too
1 Like