<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Publishing DTD v1.1d1 20130915//EN" "http://jats.nlm.nih.gov/publishing/1.2/JATS-journalpublishing1.dtd">
<article article-type="research-article" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:mml="http://www.w3.org/1998/Math/MathML" xml:lang="en">
<front>
<journal-meta>
<journal-id journal-id-type="publisher-id">PECE</journal-id>
<journal-title-group>
<journal-title>Progress in Electronics and Communication Engineering</journal-title>
<abbrev-journal-title>PECE</abbrev-journal-title>
</journal-title-group>
<issn pub-type="epub">3048-7625</issn>
<publisher>
<publisher-name>Progress in Electronics and Communication Engineering</publisher-name>
</publisher>
</journal-meta>
<article-meta>
<article-id pub-id-type="publisher-id">ECE-3-1</article-id>
<article-id pub-id-type="doi">10.31838/ECE/03.02.01</article-id>
<article-categories>
<subj-group subj-group-type="heading">
<subject>Research Paper</subject>
</subj-group>
</article-categories>
<title-group>
<article-title>Secure Boot and Firmware Update Framework for ARM Cortex-M Embedded IoT Devices</article-title>
</title-group>
<contrib-group content-type="authors">
<contrib contrib-type="author" corresp="yes"><name><surname>Cheng</surname> <given-names>Lau W.</given-names></name><xref ref-type="aff" rid="aff1">1</xref> <email>nmuetmicro&#x0040;gmail.com</email></contrib>
<contrib contrib-type="author"><name><surname>Wei</surname> <given-names>Beh L.</given-names></name><xref ref-type="aff" rid="aff2">2</xref></contrib>
<aff id="aff1"><label>1</label>Electrical and Electronic Engineering Department, University of Ibadan, Nigeria</aff>
<aff id="aff2"><label>2</label>Environment and Biotechnology DivisionIndustrial Technology Development Institute, Philippines</aff>
</contrib-group>
<pub-date pub-type="epub">
<day>21</day>
<month>02</month>
<year>2026</year>
</pub-date>
<pub-date pub-type="collection"><year>2026</year></pub-date>
<volume>3</volume>
<issue>2</issue>
<fpage>1</fpage>
<lpage>9</lpage>
<history>
<date date-type="received"><day>10</day>.<month>10</month>.<year>2025</year></date>
<date date-type="rev-recd"><day>15</day>.<month>01</month>.<year>2026</year></date>
<date date-type="accepted"><day>21</day>.<month>02</month>.<year>2026</year></date>
</history>
<permissions>
<copyright-statement>&#x00A9; 2026 Progress in Electronics and Communication Engineering</copyright-statement>
<copyright-year>2026</copyright-year>
</permissions>
<abstract>
<p>The paper presents a lightweight and well-impervious security framework suitable to ARM Cortex-M-based IOEs embedded devices, which will serve an important purpose of presenting secure boot and firmware update operations in resource-constrained systems. As IoT implementations and applications in sensitive parts of our life like healthcare, smart infrastructure, and industrial control systems increase exponentially, embedded devices become more exposed to firmware tampering, write malicious code and update securities. The framework that is proposed addresses such threats by employing a multilayered cryptographic approach, suitable to the framework by symmetric encryption with the use of AES-GCM, offering confidentiality, elliptic curve digital signature algorithm (ECDSA) providing authentication, and the SHA-256 hash to provide integrity verification. A trusted bootloader (&#x00AB; a procedure incorporating cryptographic functions used to secure a bootloader implementation &#x00BB;,) in a trusted ROM who administers cryptographic verification of the firmware signature with the help of a hardware-based root of trust prior to handing off control to the application firmware. As an additional measure the rollback protection is implemented with the help of version control to avoid firmware downgrade until known vulnerabilities are eliminated. The firmware update process allows encrypted over-the-air ( OTA ) update process to execute safe remote updates, storing the data maliciously and risking transmission. An atomic and fail safe update process is achieved through double-buffering. The experimental system was used and tested on STM32F429 Cortex-M4 microcontroller, and it successfully detected unauthorized modification of the firmware and was able to withstand rollback attacks. Performance evaluation with the bootloader as the benchmark shows the latency was only 10 milliseconds and the number of Flash memory usage was less than 0.05 percent. These outcomes confirm the application of the framework in the low-power and memory-constrained embedded systems without undermining state-of-the-art security assurances. The approach is compared to the current solutions in security to show a very usable set of efficiency, scalability and ease of implementation, which makes the presented approach an optimal one to be used in production IoT systems. A discussion on future improvements is provided wherein they would want to integrate it with hardware security modules and supporting quantum-resilient cryptographic primitives that would make the system secure in the long term.</p>
</abstract>
<kwd-group>
<kwd>Secure Boot</kwd>
<kwd>Firmware Update</kwd>
<kwd>ARM Cortex-M</kwd>
<kwd>Embedded Security</kwd>
<kwd>Io</kwd>
<kwd>OTA</kwd>
<kwd>Cryptography</kwd>
<kwd>STM3</kwd>
<kwd>Root of Trust</kwd>
</kwd-group>
</article-meta>
</front>
<body>
<sec id="S1">
<title>Introduction</title>
<p>With the numerous benefits of the technology, the exponential increase in the Internet of Things (IoT) has transformed many industries such as in the healthcare sector, in the transportation industry, smart grids and industrial automation. Billions of connected devices have been installed into consumer as well as missioncritical settings and the integrity and security of the embedded systems have emerged as the priority.</p>
<p>An embedded system has a lot of different components, one of them being the firmware layer, a set of very low-level control logic controlling how the hardware operates, that is both highly important, and both highly targeted. The compromise of the firmware may lead to disastrous situations like hijacking of systems where the systems are controlled remotely to execute given code, leakage of data or just creation of back doors that defy detectability using traditional security systems.</p>
<p>Since the sophistication of security attacks on embedded systems is still on the increase, two basic defensive mechanisms have been found to be requirements of trustworthy computing; that is the secure boot and the secure firmware update. The functionality of secure boot will display that the system will run only authenticated, verified firmware, which have non-modification, and this prevents running of unauthorized or malicious code on startup. The integrity of the device through the device lifecycle with respect to updates, on the other hand, is the responsibility of secure firmware update mechanisms so that updates are obtained out of sources that are legitimate, they are untouched and they cannot be rolled back to its previous versions with vulnerabilities.</p>
<p>The Cortex-M microcontrollers have had a significant market share of the embedded processor in the world market due to their low power consumptions, cheapness, and high performances. Edge devices like sensors, controllers and wearable systems have wide applications with such processors. They are usually deployed with very limited capacity in terms of computational resources, memory and power. Such constraints are troublesome to the integration of effective security solutions and most especially in the use of cryptographic processes. Moreover, lacking in most of the low-cost Cortex-M variants are any dedicated security hardware, necessitating software-based solutions that are efficient, but small enough to meet space constraints.</p>
<fig id="F1" orientation="portrait" position="float">
<label>Fig. 1:</label>
<caption>
<p>Overview of the Proposed Lightweight Security Framework for ARM Cortex-M IoT Devices</p></caption>
<graphic xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="PECE-3-2-g001.tif"/>
</fig>
<p>Although industry-driven standards, e.g., ARM Platform Security Architecture (PSA) and open-source efforts, e.g., Trusted Firmware-M (TF-M), do exist and act as blueprints of secure embedded systems, e.g., requiring hardware support, recent initiatives have a large implementation overhead. As a result, security is not always implemented in real-world deployments, or, in case of implementation, it is very sporadic and in a piecemeal fashion, and thus devices leave themselves exposed to a variety of attacks.</p>
<p>This paper presents a lightweight, modular, and practical security framework that is optimized to ARM Cortex -M based IoT devices, but focus will be on STM32 family. The scheme uses symmetric and asymmetric encryption primitives, integrity verification and version management to realize secure boot-up and over-theair (OTA) firmware upgrades. It is optimized to be efficient, so the load on device performance and device memory is negligible and the security profile is high. The solution will be designed in a widely applicable way to the Cortex-M ecosystem and have minimal hardware requirements and will be easy to adopt in new as well as existing embedded systems.</p>
<p>The rest of the paper is structured in the following way: Section 2 involves related work in this field; Section 3 describes the system architecture; Section 4 provides the methodology; Section 5 details the implementation specifics; Section 6 describes results of the experiment; Section 7 provides the analysis of results and discussion; Section 8 involves security considerations; and Section 9 provides conclusion and further research.</p>
</sec>
<sec id="S2">
<title>Related Work</title>
<p>Authentication of Firmware and safe increase routines in embedded gadgets have been of huge interest in the recent years because of the widespread implementation of IoT gadgets with the facts of security-sensitive applications. Multiple works have discussed the requirement of secure boot and update procedure, using in many cases hardware specific solutions or cryptographic systems.</p>
<p>In,<xref ref-type="bibr" rid="ref1">1</xref> the authors present a secure boot infrastructure where cryptographic keys are stored into the hardware security modules (HSMs) and used to validate during boot time. Such solutions, though being effective in high-end microprocessor systems, are not adequately applicable to the low-cost, resource-constrained ARM Cortex-M devices because they necessitate extra silicon and more consumption of power. Likewise, in,<xref ref-type="bibr" rid="ref2">2</xref> code integrity and secure key storage using Trusted Execution Environments (TEE)s hardware-assisted solution were described. The complexity of implementation and its dependency on hardware however makes it difficult to be adopted on restrictive compact embedded platforms.</p>
<p>The well-developed guidelines written by ARM on secure execution and update of embedded firmware are known as Platform Security Architecture (PSA)<xref ref-type="bibr" rid="ref3">3</xref> in and Trusted Firmware-M (TF-M).<xref ref-type="bibr" rid="ref4">4</xref> These structures have security primitives, threat models and hardware abstraction layers. Nonetheless, in the real world use of such solutions it may be critical to develop substantial amounts of code, involving TrustZone-enabled hardware, and an elaborate secure provisioning framework, all of which are not normally part of off-the-shelf Cortex-M connected IoT devices.</p>
<p>A number of light weighted, software based secure boot involving microcontrollers have been suggested. As an instance, in,<xref ref-type="bibr" rid="ref5">5</xref> a minimalist bootloader has been developed by employing cryptographic hash as well as the RSA-based signatures validation. Although the method does offer secure authentication, it does not have any measures against the use of encrypted firmwares or against rollback attacks. In<xref ref-type="bibr" rid="ref6">6</xref> another work is done on the secure firmware updates over the air channels (OTA) through symmetric cryptography. Despite good performance with limited resources, the system does not manage end-to-end authentication, as well as version control leaving the update mechanism vulnerables to downgrade attacks and man in the middle attacks.</p>
<p>The recent project described in<xref ref-type="bibr" rid="ref7">7</xref> combines cryptographic verification and secure OTA update of ARM Cortex-M chips, however, it presupposes a secure element used to store keys and this component is not available in some environments. In addition to that, the above works all focus on rollback protection, image encryption and boot-time verification separately, with no unified framework that is optimized to be implemented on lowcost microcontrollers.</p>
<p>On the contrary, the framework in this paper can fill this gapp by offering a software-based, lightweight, and holistic solution that can use secure boot, encrypted OTA firmware upgrade, and rollback protection of ARM Cortex-M chipsets without the need of third-party secure hardware. The system suggested shows good trade-off between security, performance, and implementation complexity which is checked on STM32 microcontrollers.</p>
</sec>
<sec id="S3">
<title>System Architecture</title>
<sec id="S3_1">
<title>Hardware Assumptions</title>
<p>The recommended design of secure boot and firmware update solution will be deployed on the ARM Cortex-M4 family of microcontrollers since the STM32F4xx is widely used in IoT and embedded applications. These microcontrollers present an optimized trade-off between processing capability, memory storage and energy consumption thus they are the best choices when it comes to secure embedded implementations. The system presumes the availability of the on-chip Flash memory that has the read protection features turned on and this allows blocking unauthorized access to the firmware and sensitive data stored in the memory allocations. The framework is mostly software-based in order to maintain a wide compatibility, although theoretically it may also make use of any cryptographic hardware accelerators available-including the integrated AES, RNG, and HASH cores of the STM32 line itself in order to offload and accelerate the more intensive computation-heavy cryptographic applications, like hashing and encryption. Further, the architecture depends upon a write-once, tamper-resistant region of ROM (usually implemented as system memory or Flash sectors with protection) to pad the public key used in firmware signature verification safely. Such an unchangeable source of faith is necessary to make sure that genuine and unmodified firmware images are run by the device during the boot-up stage. This hardware compatibility ensures strict optimization of the framework on the one hand and high security guarantee on the other hand, as well as practicality of application in Cortex-M based systems with minimal system resources.</p>
</sec>
<sec id="S3_2">
<title>Bootloader Design</title>
<p>The essence of proposed security scheme is a readonly stage-one bootloader installed into a secure area of the microcontroller ROM or Flash memory, with write-protection disabled to eliminate the possibility of unauthorized changes. This boot loader is the root of trust of the secure boot process on the device and is the component that provides a measure of correctness and genuineness of the firmware prior to the execution. When a system starts up, the bootloader cryptographically verifies the firmware image with Elliptic Curve Digital Signature Algorithm (ECDSA) based on a pre-computed Elliptic Curve Digital Signature Algorithm (ECDSA) public key stored in non-modifiable portion of the ROM. As a measure of integrity, the bootloader calculates a signed SHA-256 hash of the firmware binary, and compares it with that of the firmware metadata. With this, any unauthorized modification in the firmware either out of corruption or out of malicious injection will reliably be detected. Also, to avoid rollback attack -In which a signed-but-still-vulnerable version of the firmware is restored by reinstalling itthe bootloader implements some version control by checking the firmware version embedded in the update package against the version on non-volatile persistent store. Only firmware of higher version is allowed to run and the lower version with exploitable coding cannot be restored. This multitiered verification preserves a performance-efficient verified execution environment, and is a natural fit to be used on resource constrained ARM Cortex-M microcontrollers used in the safest IoT systems.</p>
<table-wrap id="T1" position="float" orientation="portrait">
<label>Table 1:</label>
<caption>
<title>Hardware Assumptions and Their Functional Roles in the Secure Boot and Firmware Update Framework</title>
</caption>
<table frame="border" rules="groups">
<thead valign="top">
<tr>
<th align="center" valign="top">Hardware Component</th>
<th align="center" valign="top">Function/Role in Framework</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="left" valign="top">ARM Cortex-M4 MCU (STM32F4xx)</td>
<td align="left" valign="top">Target platform for secure boot and firmware updates</td>
</tr>
<tr>
<td align="left" valign="top">On-chip Flash with Read Protection</td>
<td align="left" valign="top">Prevents unauthorized firmware/data access</td>
</tr>
<tr>
<td align="left" valign="top">Cryptographic Accelerators (AES, RNG)</td>
<td align="left" valign="top">Optional offloading for faster encryption, hashing, and key generation</td>
</tr>
<tr>
<td align="left" valign="top">Write-Once ROM / Protected Flash</td>
<td align="left" valign="top">Stores immutable public key for signature verification (Root of Trust)</td>
</tr>
<tr>
<td align="left" valign="top">Secure Bootloader Region</td>
<td align="left" valign="top">Resides in protected memory to ensure tamper-resistant secure boot execution</td>
</tr>
</tbody>
</table>
</table-wrap>
<fig id="F2" orientation="portrait" position="float">
<label>Fig. 2:</label>
<caption>
<p>Secure Bootloader Workflow for Firmware Verification and Rollback Protection in ARM Cortex-M Devices</p></caption>
<graphic xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="PECE-3-2-g002.tif"/>
</fig>
</sec>
<sec id="S3_3">
<title>Firmware Update Protocol</title>
<p>In the proposed framework, the firmware update protocol aims at providing a secure, reliable and authenticated updating and firmware installation process (especially in the case of over-the-air (OTA) updates). To guard the privacy and authenticity of their own firmware by transmitting the update payload, encryption is performed in the context of the AES-GCM (Galois/Counter Mode) algorithm, which is not only useful in its encrypting capabilities, but also in authentication of messages, referred to as message authentication codes (MACs). After downloading the encrypted firmware image, the device then uses a pre-shared symmetric key or negotiates a session key as part of a secure provisioning procedure and then decrypts the firmware image. Prior to installation of the decrypted firmware, the version number embedded in the firmware metadata is validated by the bootloader or updating handler the image being updated should not be newer than the installed version thus providing rollback protection. The system moves to the next step that is re-verification encrypted integrity of the firmware only when the version is valid. This is done by remodelling the SHA-256 hash of the firmware and checking it against the attached ECDSA signature with the aid of the public key stored in the secure ROM. This post-update signature verification makes sure that the firmware is not tampered during transfer as well as storage. In case even one verification operation fails, the system discards the update and either keeps the current firmware or destroys it cleanly and starts a safe crucial rescue method. Such secure update protocol not only protects devices against unauthorized or modified firmware installations, but also allows robustness against network-based attacks and compromises of the update channel, and is therefore particularly appropriate to scalable secure deployment in embedded Internet of Things.</p>
<fig id="F3" orientation="portrait" position="float">
<label>Fig. 3:</label>
<caption>
<p>Secure Firmware Update Protocol Flow for Encrypted OTA Delivery and Integrity Verification</p></caption>
<graphic xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="PECE-3-2-g003.tif"/>
</fig>
</sec>
</sec>
<sec id="S4">
<title>Methodology</title>
<p>The deployment of the secure boot and firmware update framework is done on a modular design and is divided in four major stages:</p>
<sec id="S4_1">
<title>Bootloader Development</title>
<p>The bootloader, which can be considered as the core of the secure execution environment, was designed to work with the ARM CortexM 4 micro-controller board. The set of used libraries includes STM32 HAL (Hardware Abstraction Layer) and mbedTLS cryptography library. STM32 HAL will guarantee low level compatibility of the hardware, efficient peripheral usage and portability to other STM32 devices, whereas mbedTLS will offer a lightweight designed, well maintained, and embedded optimized implementation of cryptographic algorithms such as SHA-256 and ECDSA. We have placed it there (the bootloader) in a special, protected zone of the on chip Flash memory which has read and write protection enabled to make it tamper resistant. This segment is permanent all through the lifecycle of the device in order to provide integrity of the secure boot process.</p>
<p>The bootloader is the init code that runs first at run time after the device restart or reset. It begins a secure verification procedure by determining the SHA-256 hash of the firmware image in external or internal memory in the first place. Such hash is then matched to a previously computed digital signature, which is appended to the firmware image. The verification of signature is conducted by the Elliptic Curve Digital Signature Algorithm (ECDSA) with the bootloader applying a public key safely embedded on the ROM during provisioning. The hash is only compared against the signed digest hence by the time it matches, they pass control to the application firmware through the bootloader. This cryptographic check will protect against a compromised firmware by letting the users know that the firmware is not modified and is coming directly out of a trusted source. When hardware protections are coupled with powerful cryptographic verifications the implementation of the bootloader offers a bootstrap secure source of trust with low memory and performance overhead as needed by real-time and resources constrained IoT use cases.</p>
<fig id="F4" orientation="portrait" position="float">
<label>Fig. 4:</label>
<caption>
<p>Bootloader Architecture and Cryptographic Verification Flow for Secure Firmware Execution</p></caption>
<graphic xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="PECE-3-2-g004.tif"/>
</fig>
</sec>
<sec id="S4_2">
<title>Firmware Image Signing</title>
<p>Firmware image signing is a very important process in assuring the authenticity and integrity of the executed code/code therein a mobile device. All the firmware images in the proposed framework are offline signed by a secure development workstation which has the private ECDSA key. The private key is never disclosed to the embedded device itself or via an unwanted transmission channel, hence, avoiding the possibility of compromise of the key. The signing is done by first calculating a SHA256 hash on the end binary of the compilation firmware. The content in this digest is a representation of said firmware in a special manner and a flip of only one bit in the binary would result in a harshly different hash output.</p>
<p>After the computation of the hash, it is then digitally signed using the developers copy of the ECDSA private key resulting in a signature which can be later-verified using the corresponding developers copy of the public key stored in the secure ROM or Flash during the provisioning process. The firmware image has additional metadata including its version number and the size of the executable never-ending binary (number of bytes) added, along with the signature. Such metadata is applied in secure boot and update mechanism to implement version control (rollback protection) and it checks the integrity of the received image.</p>
<p>The fully signed image (the binary of firmware plus version metadata, plus the signed digital image) is then ready to be securely shipped. In over-the-air (OTA) case, this package is encrypted with AES-GCM and sent to the device. The system does this by carrying out its signing processes entirely offline and never leaving the secret key exposed on any secure build environment; hence the firmware cannot be modified or falsely signed by any parties without the specific authority to do so. Combined with post-update and boot-time verification this signing mechanism provides the basis of the trusted execution pipeline of the device.</p>
<fig id="F5" orientation="portrait" position="float">
<label>Fig. 5:</label>
<caption>
<p>Firmware Image Signing and Secure Packaging Workflow for OTA Deployment and Device Verification</p></caption>
<graphic xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="PECE-3-2-g005.tif"/>
</fig>
</sec>
<sec id="S4_3">
<title>OTA Update Implementation</title>
<p>To facilitate safe and robust firmware updates the proposed framework expands a standard UART-based loader to support reception of an AES-GCM encrypted firmware image, and facilitate confidentiality and authenticity Over-the-Air (OTA) update capabilities. The UART interface that is supported by many devices and often utilized in provisioning and communicating with the devices was chosen because of its simplicity and compatibility with the existing infrastructure, i.e., Bluetooth, LoRa, or Wi-Fi-to-UART bridge.</p>
<p>The device to which the firmware needs to be loaded accepts the encrypted firmware image which was produced and signed off-line and sent using the UART interface. AES-GCM (Galois/Counter Mode) is used because it accomplishes both encryption and authentication in a single pass so that the firmware image can be transmitted without being eavesdropped upon and tampered with. The received firmware gets encrypted and never instantly ran or written instantly over the base firmware in the main application memory. Rather, it is cached in a secondary staging space of Flash memory so that it can be pre-installed tested.</p>
<p>Execution of the signature verification of the new firmware with the ECDSA public key stored in the nonmodifiable memory of the device is performed before the new firmware is promoted to active status. The hash of the image in form of SHA-256 is computed and is compared to the appended signature to verify authenticity and integrity. Provided that this check has passed and new sufficient firmware version is specified in the metadata, an image is accepted and the bootloader flags it as active. Once a system has been reset, the newly verified firmware assumes execution.</p>
<p>This staged design makes sure that a firmware is never deployed without full verification and gives robustness against failures between stages (e.g. power loss) in the update. This will allow the system to restore to the latest known good operating system in case of failure, corruption, and therefore keep the devices available, and be safe to operate.</p>
<fig id="F6" orientation="portrait" position="float">
<label>Fig. 6:</label>
<caption>
<p>Secure OTA Firmware Update Workflow with Encrypted Image Reception, Validation, and Activation</p></caption>
<graphic xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="PECE-3-2-g006.tif"/>
</fig>
</sec>
<sec id="S4_4">
<title>Security Validation Testing</title>
<p>In order to determine the strength and viability of the suggested secure boot and firmware update infrastructure, an extensive set of security validation tests were performed. The tests were to be conducted in order to simulate the attacks in the real environment, checking the cryptographic integrity and examining the performance effect on the embedded system.</p>
<p>To begin with, tampering with the firmware was calculated and the tampering effect conducted by means of just deliberately altering bytes in the signed firmware binary but not just the main code area but also the attached metadata. In each of the test cases, inconsistencies reported by the hashing (SHA-256) and signature verification (ECDSA) functions in the bootloader repeatedly identified discrepancies between the calculated hash and signed digest. This lead to automatic discarding of the spoofed firmware and thus it will not be executed and the code could be harmful.</p>
<p>Second, OTA update attack emulations, such as replay attacks and version downgrade attacks, were done on the system. In the case of replay, an update image that was sent previously and that was valid was resent to the device. Nonetheless, the version-checking mechanism of the framework which depends on the embedded metadata and a non-volatile firmware version counter, was able to prevent reinstallation of obsolete firmware. Equally, any effort to decrease the security of the firmware by manually manipulating version metadata in other than a valid image was defeated, because the bootloader invalidated the digital signature as a result of the hash bucket inconsistency that occurred upon metadata manipulation.</p>
<p>Besides these operating tests of security, performance profiling was also undertaken to get the computation and memory overhead cost brought in by security mechanisms. The time of execution was recorded, boot up, calculation of firmware hashes, verification of signature, and decryption of updates using AES-GCM. The outcome indicated that the total secure boot took less than 10 milliseconds of delay and less than 5 percent of flash and RAM available at STM32F429ZI platform. These indicators support the viability of the framework in lowpower resource-constrained embedded IoT devices, and in the processes, they verify its robustness in security and system performance in a realistic deployment scenario.</p>
</sec>
</sec>
<sec id="S5">
<title>Result and Discussion</title>
<p>The framework proposed was vigorously validated in view of determining its capability in accomplishing the dual objective of surpassing sound security and low usage of resources. The mechanism, the secure boot, which is based on the cryptographic integrity checks, was verified, and this was done by simulating many attack scenarios. Bootloader was always capable of rejecting tampered firmware images by using very specific hashing sha-256 and verification of ecdsa signature meaning that only untampered and legitimate firmware could be run. There was also a rollback protection, which worked well on the basis of version metadata included in the firmware header. Any attempt to install older firmware, including authentic or fake, was duly rejected; this indicated that the framework ensures only forward-only firmware upgrade, a significant prerequisite in secure firmware lifecycle management.</p>
<fig id="F7" orientation="portrait" position="float">
<label>Fig. 7:</label>
<caption>
<p>Resource Impact of Secure Boot and Firmware Update Framework on STM32F429ZI MCU</p></caption>
<graphic xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="PECE-3-2-g007.tif"/>
</fig>
<p>The system added minimal overheads as far as its performance is concerned which is why it can be used in real-time embedded applications. This generated an overall impact of exceeding 9.2 milliseconds to the overall boot time, which is reasonable considering the cryptographic operations take a majority of resources and time, but it is not a factor during most of the IoT applications that do not require ultra-low startup time. The memory footprint was also maintained at a expectable limit. Totally bootloader and crypto libraries (mbedTLS) used approximately 18 KB of Flash memory, or only about 5 percent of the capacity granting by the STM32F429ZI microcontroller. Memory consumption was kept low and there was an optional AES and SHA hardware accelerators to enhance efficiency. These findings indicate that the suggested implementation can offer a desirable balance between system performance and security assurance and that such can be deployed on most of the Cortex-M based microcontrollers without having to make substantial changes in the hardware.</p>
<p>Relating to the reliability aspect, the firmware update process was robust in relation to different negative events such as power failur0e and partial transfer among others. The strategy of the double-buffering strategy protected the system by storing and validating the new firmware on a secondary region prior to activation thus keeping the system stable even upon a failed update or abortive update. When compared to a more complex solution like ARM PSA Certified platforms, proposed framework achieved more or less the same levels of cryptographic protection and critical assurance, but did not demand as many system resources and did not make integration so complex. This is especially appealing to low-power, costconstrained IoT systems. In general, the findings reveal that the framework can provide a powerful and end2end security of firmware with a reasonable practicality used to deploy in embedded systems with limited memory, power, and computing resources.</p>
<table-wrap id="T2" position="float" orientation="portrait">
<label>Table 2:</label>
<caption>
<title>Summary of Security Validation Tests and Outcomes</title>
</caption>
<table frame="border" rules="groups">
<thead align="left" valign="top">
<tr>
<th align="center" valign="top">Test Category</th>
<th align="center" valign="top">Evaluation Method</th>
<th align="center" valign="top">Result / Outcome</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="left" valign="top"><bold>Firmware Tampering</bold></td>
<td align="left" valign="top">Modified firmware binary and metadata</td>
<td align="left" valign="top">Successfully detected and rejected by SHA-256 and ECDSA verification</td>
</tr>
<tr>
<td align="left" valign="top"><bold>Replay Attack</bold></td>
<td align="left" valign="top">Reused a previously valid encrypted firmware image</td>
<td align="left" valign="top">Blocked using firmware version validation logic</td>
</tr>
<tr>
<td align="left" valign="top"><bold>Version Downgrade</bold></td>
<td align="left" valign="top">Lower version metadata in otherwise valid image</td>
<td align="left" valign="top">Signature check failed due to hash mismatch; update rejected</td>
</tr>
<tr>
<td align="left" valign="top"><bold>Boot Time Overhead</bold></td>
<td align="left" valign="top">Measured time added during secure boot phase</td>
<td align="left" valign="top">&#x003C; 10 ms increase observed</td>
</tr>
<tr>
<td align="left" valign="top"><bold>Memory Overhead</bold></td>
<td align="left" valign="top">Measured Flash and RAM usage of added security components</td>
<td align="left" valign="top">&#x003C; 5&#x0025; resource usage on STM32F429ZI</td>
</tr>
</tbody>
</table>
</table-wrap>
<table-wrap id="T3" position="float" orientation="portrait">
<label>Table 3:</label>
<caption>
<title>Summary of Performance, Security, and Reliability Metrics for the Proposed Secure Firmware Framework</title>
</caption>
<table frame="border" rules="groups">
<thead align="left" valign="top">
<tr>
<th align="center" valign="top">Metric</th>
<th align="center" valign="top">Description</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="left" valign="top">Boot Time Overhead</td>
<td align="left" valign="top">Approximately 9.2 ms additional boot time due to cryptographic operations</td>
</tr>
<tr>
<td align="left" valign="top">Flash Memory Usage</td>
<td align="left" valign="top">Bootloader and crypto libs consume ~18 KB (~&#x003C;5&#x0025; of 512 KB flash)</td>
</tr>
<tr>
<td align="left" valign="top">RAM Usage</td>
<td align="left" valign="top">Remains modest, optimized with optional hardware accelerators</td>
</tr>
<tr>
<td align="left" valign="top">Firmware Integrity Check</td>
<td align="left" valign="top">Ensures authenticity via SHA-256 and ECDSA signature verification</td>
</tr>
<tr>
<td align="left" valign="top">Rollback Protection</td>
<td align="left" valign="top">Prevents outdated firmware installation using version metadata</td>
</tr>
<tr>
<td align="left" valign="top">Firmware Update Resilience</td>
<td align="left" valign="top">Double-buffering allows safe updates even during power loss</td>
</tr>
<tr>
<td align="left" valign="top">Hardware Acceleration Support</td>
<td align="left" valign="top">Uses AES/SHA hardware accelerators to boost efficiency</td>
</tr>
<tr>
<td align="left" valign="top">Compatibility with Cortex-M MCUs</td>
<td align="left" valign="top">No significant hardware upgrades required for deployment</td>
</tr>
<tr>
<td align="left" valign="top">Comparison with ARM PSA</td>
<td align="left" valign="top">Comparable security with reduced complexity and resource usage</td>
</tr>
</tbody>
</table>
</table-wrap>
<sec id="S6">
<title>Conclusion</title>
<p>The current paper will introduce lightweight, nondescript security solution able to maintain firmware integrity as well as update mechanism applied to ARM Cortex-M based IoT embedded devices. Due to the identified limitations of resource-poor microcontrollers, it is feasible to construct a secure boot and encrypted over-the-air (OTA) firmware update with well-known cryptographic primitives (SHA-256, ECDSA, and AESGCM). Bootloader blocks at startup and requires authenticity and integrity checks and once the rollback protection is enabled, it forces the removal of old or possibly vulnerable versions of firmwares. OTA update protocol ensures safe delivery of image and atomic update management delivered in the form of a doubled buffered memory design, protecting the device even in the event of adverse situations like power loss in the middle of updates. On the STM32F429ZI reference platform, verification of the solution demonstrated it to be capable of minimising performance and memory overhead, and effectively mitigate against common attack vectors, including tampering, replay and downgrade attacks. The proposed framework offers equally high protection levels as architectures that apply dedicated hardware or secure elements, at an implementation complexity that is greatly reduced. This turns it into a convenient and expandable solution of IoT applications in the real-life environment where cost, power, and memory limitations are vital. Additional improvements in future features could involve the incorporation of secure elements or post-quantum cryptographic primitives along with remote attestation capability with further enhancing the trust and longterm safety within embedded systems.</p>
</sec>
</sec>
</body>
<back>
<fn-group>
<fn id="fn1"><p><bold>How to cite this article</bold>: Usikalua MR, Unciano N. Secure Boot and Firmware Update Framework for ARM Cortex-M Embedded IoT Devices. Progress in Electronics and Communication Engineering, Vol. 3, No. 2, 2026 (pp. 1-9).</p></fn></fn-group>
<ref-list>
<title>References</title>
<ref id="ref1"><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Alam</surname>, <given-name>M.</given-name></string-name>, <string-name><surname>Islam</surname>, <given-name>M. M.</given-name></string-name>, &#x0026; <string-name><surname>Uluagac</surname>, <given-name>A. S.</given-name></string-name></person-group> (<year>2020</year>). <article-title>A secure boot framework for IoT devices using hardware security modules</article-title>. <source>Proceedings of IEEE SECURECOMM</source>, <fpage>1</fpage>&#x2013;<lpage>10</lpage>.</mixed-citation></ref>
<ref id="ref2"><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Sadeghi</surname>, <given-name>R.</given-name></string-name>, <string-name><surname>Zeitouni</surname>, <given-name>S.</given-name></string-name>, &#x0026; <string-name><surname>Paverd</surname>, <given-name>A.</given-name></string-name></person-group> (<year>2021</year>). <article-title>TEE-based secure boot for embedded systems</article-title>. <source>IEEE Transactions on Dependable and Secure Computing</source>, <volume>18</volume>(<issue>2</issue>), <fpage>482</fpage>&#x2013;<lpage>495</lpage>. <ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1109/TDSC.2019.2892677">https://doi.org/10.1109/TDSC.2019.2892677</ext-link></mixed-citation></ref>
<ref id="ref3"><mixed-citation publication-type="journal"><collab>ARM Ltd</collab>. (<year>2021</year>). <article-title>Platform Security Architecture (PSA): Threat models and security analyses</article-title>. Retrieved from <ext-link ext-link-type="uri" xlink:href="https://developer.arm.com/psa">https://developer.arm.com/psa</ext-link></mixed-citation></ref>
<ref id="ref4"><mixed-citation publication-type="book"><collab>Trusted Firmware Project</collab>. (<year>2023</year>). <article-title>Trusted Firmware-M (TF-M) documentation</article-title>. Retrieved from <ext-link ext-link-type="uri" xlink:href="https://trustedfirmware.org/projects/tf-m/">https://trustedfirmware.org/projects/tf-m/</ext-link></mixed-citation></ref>
<ref id="ref5"><mixed-citation publication-type="book"><person-group person-group-type="author"><string-name><surname>Bhunia</surname>, <given-name>S.</given-name></string-name>, &#x0026; <string-name><surname>Tehranipoor</surname>, <given-name>M.</given-name></string-name></person-group> (<year>2018</year>). <article-title>Hardware security: A hands-on learning approach</article-title>. <source>Morgan Kaufmann</source>.</mixed-citation></ref>
<ref id="ref6"><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Das</surname>, <given-name>P.</given-name></string-name>, <string-name><surname>Dey</surname>, <given-name>S.</given-name></string-name>, &#x0026; <string-name><surname>Paul</surname>, <given-name>S.</given-name></string-name></person-group> (<year>2021</year>). <article-title>Lightweight secure firmware update for IoT devices using symmetric encryption</article-title>. <source>Proceedings of IEEE International Conference on Consumer Electronics (ICCE)</source>, <fpage>1</fpage>&#x2013;<lpage>6</lpage>. <ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1109/ ICCE2021.9362114">https://doi.org/10.1109/ ICCE2021.9362114</ext-link></mixed-citation></ref>
<ref id="ref7"><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Lin</surname>, <given-name>Y.</given-name></string-name>, <string-name><surname>Liu</surname>, <given-name>H.</given-name></string-name>, &#x0026; <string-name><surname>Wang</surname>, <given-name>M.</given-name></string-name></person-group> (<year>2021</year>). <article-title>Secure OTA update mechanism for ARM Cortex-M devices with cryptographic verification</article-title>. <source>IEEE Access</source>, <volume>9</volume>, <fpage>104711</fpage>&#x2013;<lpage>104722</lpage>. <ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1109/ACCESS.2021.3099193">https://doi.org/10.1109/ACCESS.2021.3099193</ext-link></mixed-citation></ref>
<ref id="ref8"><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Cui</surname>, <given-name>A.</given-name></string-name>, &#x0026; <string-name><surname>Stolfo</surname>, <given-name>S. J.</given-name></string-name></person-group> (<year>2010</year>). <article-title>A quantitative analysis of the insecurity of embedded network devices: Results of a wide-area scan</article-title>. <source>Proceedings of the 26th Annual Computer Security Applications Conference (ACSAC)</source>, <fpage>97</fpage>&#x2013;<lpage>106</lpage>. <ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1145/1920261.1920276">https://doi.org/10.1145/1920261.1920276</ext-link></mixed-citation></ref>
<ref id="ref9"><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Abomhara</surname>, <given-name>M.</given-name></string-name>, &#x0026; <string-name><surname>Koien</surname>, <given-name>G. M.</given-name></string-name></person-group> (<year>2015</year>). <article-title>Cyber security and the Internet of Things: Vulnerabilities, threats, intruders and attacks</article-title>. <source>Journal of Cyber Security and Mobility</source>, <volume>4</volume>(<issue>1</issue>), <fpage>65</fpage>&#x2013;<lpage>88</lpage>.</mixed-citation></ref>
<ref id="ref10"><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Neudecker</surname>, <given-name>P.</given-name></string-name>, &#x0026; <string-name><surname>Frei</surname>, <given-name>S.</given-name></string-name></person-group> (<year>2014</year>). <article-title>Unpatchable: Measuring the brokenness of embedded device firmware</article-title>. <source>Black Hat USA</source>. Retrieved from <ext-link ext-link-type="uri" xlink:href="https://www.blackhat.com/docs/ us-14/materials/us-14-Neudecker-Unpatchable-Measuring-The-Brokenness-Of-Embedded-Device-Firmware-WP.pdf">https://www.blackhat.com/docs/us-14/materials/us-14-Neudecker-Unpatchable-Measuring-The-Brokenness-Of-Embedded-Device-Firmware-WP.pdf</ext-link></mixed-citation></ref>
<ref id="ref11"><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Kumar</surname>, <given-name>T. M. S.</given-name></string-name></person-group> (<year>2024</year>). <article-title>Security challenges and solutions in RF-based IoT networks: A comprehensive review</article-title>. <source>SCCTS Journal of Embedded Systems Design and Applications</source>, <volume>1</volume>(<issue>1</issue>), <fpage>19</fpage>&#x2013;<lpage>24</lpage>. <ext-link ext-link-type="uri" xlink:href="https://doi.org/10.31838/ESA/01.01.04">https://doi.org/10.31838/ESA/01.01.04</ext-link></mixed-citation></ref>
<ref id="ref12"><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Kumar</surname>, <given-name>T. M. S.</given-name></string-name></person-group> (<year>2024</year>). <article-title>Low-power communication protocols for IoT-driven wireless sensor networks</article-title>. <source>Journal of Wireless Sensor Networks and IoT</source>, <volume>1</volume>(<issue>1</issue>), <fpage>37</fpage>&#x2013;<lpage>43</lpage>. <ext-link ext-link-type="uri" xlink:href="https://doi.org/10.31838/WSNIOT/01.01.06">https://doi.org/10.31838/WSNIOT/01.01.06</ext-link></mixed-citation></ref>
<ref id="ref13"><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Rucker</surname>, <given-name>P.</given-name></string-name>, <string-name><surname>Menick</surname>, <given-name>J.</given-name></string-name>, &#x0026; <string-name><surname>Brock</surname>, <given-name>A.</given-name></string-name></person-group> (<year>2025</year>). <article-title>Artificial intelligence techniques in biomedical signal processing</article-title>. <source>Innovative Reviews in Engineering and Science</source>, <volume>3</volume>(<issue>1</issue>), <fpage>32</fpage>&#x2013;<lpage>40</lpage>. <ext-link ext-link-type="uri" xlink:href="https://doi.org/10.31838/INES/03.01.05">https://doi.org/10.31838/INES/03.01.05</ext-link></mixed-citation></ref>
<ref id="ref14"><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Sadulla</surname>, <given-name>S.</given-name></string-name></person-group> (<year>2024</year>). <article-title>Techniques and applications for adaptive resource management in reconfigurable computing</article-title>. <source>SCCTS Transactions on Reconfigurable Computing</source>, <volume>1</volume>(<issue>1</issue>), <fpage>6</fpage>&#x2013;<lpage>10</lpage>. <ext-link ext-link-type="uri" xlink:href="https://doi.org/10.31838/RCC/01.01.02">https://doi.org/10.31838/RCC/01.01.02</ext-link></mixed-citation></ref>
<ref id="ref15"><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Geetha</surname>, <given-name>K.</given-name></string-name></person-group> (<year>2024</year>). <article-title>Advanced fault tolerance mechanisms in embedded systems for automotive safety</article-title>. <source>Journal of Integrated VLSI, Embedded and Computing Technologies</source>, <volume>1</volume>(<issue>1</issue>), <fpage>6</fpage>&#x2013;<lpage>10</lpage>. <ext-link ext-link-type="uri" xlink:href="https://doi.org/10.31838/JIVCT/01.01.02">https://doi.org/10.31838/JIVCT/01.01.02</ext-link></mixed-citation></ref>
</ref-list></back></article>