Security added after architecture is a patch. Security designed into the architecture is a property. For connected hardware, the difference is decided in the first weeks of a program—when interfaces, update paths and trust boundaries are still cheap to change.
Start from a threat model, not a checklist
Compliance checklists describe yesterday’s attacks. A threat model describes your product: what data it holds, what an attacker gains by owning it, and which interfaces—radio, debug, supply chain, cloud—expose it. Every subsequent security decision should trace back to that model.
Draw the trust boundaries in silicon
Secure boot, hardware root of trust, protected key storage and isolated execution are selection criteria for the MCU or SoC—not features to be retrofitted. The bill of materials is a security document.
Design the update path before the first unit ships
Signed, staged, revertible updates are the difference between an incident and a recall. The update mechanism deserves the same verification rigor as the product’s primary function, because in the field it becomes the primary function.
A device that cannot be updated safely is a liability with a ship date.
Plan for the whole lifecycle
Provisioning, ownership transfer, decommissioning and end-of-support all leak data if unaddressed. Security review at each lifecycle stage should be a standing item in phase gates, with evidence—not intentions—recorded.