Embedded-system intellectual property (IP) includes more than firmware: it can also include hardware implementations, signal paths, output-control designs and distinctive methods. Protecting those assets means balancing unauthorized access against legitimate updates, debugging and recovery. A restrictive flash setting alone is not a complete plan; protection has to fit the device’s update path, lifecycle and the consequences of a security failure.
What counts as embedded-system IP?
Firmware is an obvious asset, but a product’s differentiating design may also reside in its hardware implementation: analog or digital signal chains, the way components are interconnected, output-control circuitry, or an innovative method. Those elements may be exposed through physical inspection or reverse engineering, not just by reading program memory. Sachin Gupta’s 2013 article uses Cypress PSoC 1 examples to discuss both firmware access and concealment of hardware resources; these are historical illustrations, not a current survey of microcontrollers. Read the article on Embedded.com.
Concealment can add friction, not certainty
Board coatings and custom IC part numbers can make inspection or component identification harder. They do not make a design impossible to reverse-engineer, and they should not be treated as substitutes for access controls, secure update design or sound supplier practices.
Why flash protection affects updates and service
Microcontrollers differ in how they control reads and writes. A protection mode that blocks access through an external programming interface may also constrain manufacturing, field upgrades, debugging or recovery. Some devices provide block-level permissions, allowing critical code to receive stronger protection than code that must remain updateable. The relevant question is therefore not simply whether flash is “locked,” but which actors and mechanisms can read or change which regions, and when.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstall#1 Best Overall
Historical example: Cypress PSoC 1
Gupta’s 2013 article describes four PSoC 1 flash-protection modes, with settings loaded into nonvolatile bits during programming. In that device-specific model, the modes differ in external and internal access:
| Mode described for PSoC 1 | Access behavior described in the article |
|---|---|
| Unprotected | Flash is not protected from reads or writes. |
| Factory upgrade | External reads can be prohibited while some write access is retained. |
| Field upgrade | Programmer-interface reads and writes can be blocked while internal bootloader operations remain possible. |
| Full protection | Internal and external reads and writes are prevented. |
These descriptions apply to the PSoC 1 model discussed in that article. They should not be assumed to describe another PSoC family, a current device, or a different vendor’s MCU.
Rank #2
Choose boundaries that preserve the required service path
- Read and write access: Identify which external interfaces can read or modify code and which internal components retain access.
- Protection granularity: Check whether permissions apply to all flash or selected blocks, and decide which code truly needs to remain writable.
- Update route: Specify whether the product needs a factory programmer, field bootloader, customer calibration or no field modification.
- Bootloader trust: Determine whether the bootloader itself can be read or changed, and what authentication and communication protections the device documents.
- Recovery and debug: Plan for corrupted metadata, lost credentials and incorrect lock settings; also define when debug access is intentionally closed.
- Physical exposure: Assess whether board layout, component identity, signal paths or interconnections reveal the differentiating design.
Design field updates as a security trade-off
A bootloader needs enough authority to update flash, so its permissions and inputs must be carefully bounded. Protecting the bootloader itself and encrypting its communications can reduce opportunities to inspect flash or tamper with the update path, but these measures are mitigations, not guarantees. The device documentation and the product’s implementation determine what protections actually apply.
Before enabling production protection, map the entire lifecycle: development and manufacturing access, update authorization, the code regions an updater may change, failure recovery, and the point at which debug access is disabled. If a lock setting can remove the only supported route for recovery or service, it may turn a security control into an operational failure.
Use device documentation, not feature names, to decide
The Analog Devices ADuCM3027/ADuCM3029 Rev. A user guide provides a concrete example of device-specific behavior. It describes a 128-bit read-protection key hash, debugger access behavior, user-flash read/write protection, and a UART second-stage loader that must be authenticated before it receives run access. The guide also warns that read protection should be configured after development is complete if SWD access is not expected in the field. Consult the ADuCM3027/ADuCM3029 Rev. A user guide.
This example is not evidence that the parts are currently available or suitable for a particular design, and it does not represent all secure MCUs. Confirm current manufacturer documentation, production configuration, update behavior and recovery options for the exact component and revision being evaluated.
Rank #4
Make IP protection part of systems-security engineering
NIST SP 800-160 Rev. 1 treats security as an engineering concern across a system’s lifecycle, rather than as a single component setting. Its guidance calls for establishing security objectives and requirements, producing evidence, assessing implementation, and addressing security responsibilities in supplier agreements. In Appendix E, the NIST principle “Commensurate Protection” states: “The strength and type of protection provided to a system element are commensurate with the most significant adverse effect that results from a failure of that element.” This frames protection strength around the consequence of failure, rather than applying the same control indiscriminately to every component. NIST SP 800-160 Rev. 1, Engineering Trustworthy Secure Systems (November 2022).
For suppliers, document who may handle IP, how it may be used and disseminated, and how it must be destroyed when no longer needed. Those obligations complement technical controls: a device’s flash settings cannot govern how design files, keys or implementation details are handled outside the chip.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
