A battery management system does much more than monitor a battery. It continuously collects information such as voltage, current, temperature, state of charge, and fault conditions, while also communicating with external applications and managing firmware that controls the system.
That makes security an important part of the BMS architecture.
For us, securing a BMS is not just about encrypting a communication frame. It starts at the device level with a secure boot process, continues through firmware updates, and extends to communication between the BMS and client applications.
Why Security Matters in a BMS
A BMS is connected to hardware that directly interacts with a battery pack. An unauthorized firmware image or a manipulated command can therefore have consequences beyond simply displaying incorrect data.
A secure BMS needs to answer a few basic questions:
Is the firmware running on the device from a trusted source?
Has the firmware been modified?
Can an unauthorized firmware image be installed?
Can an old, vulnerable firmware version be loaded again?
Can communication between the BMS and a client be monitored or modified?
These questions lead to two closely related areas of security: secure boot and secure communication.
Building a Root of Trust with Hardware Security
A traditional bootloader is responsible for starting the application firmware. A secure bootloader adds another important responsibility: verifying that the firmware is trusted before allowing it to run.
Software alone can provide some security controls, but the foundation of the security mechanism should be protected from the application itself.
This is where hardware-assisted security becomes important.
Our BMS platform uses the Hardware Security Engine (HSE). The HSE provides hardware-backed security functions and forms an important part of the system's root of trust.
Instead of treating security as another software module running alongside the application, the bootloader can rely on the dedicated security hardware when performing security-critical operations.
What Happens When the BMS Starts?
When the MCU resets, the bootloader starts before the main application.
At a high level, the process looks like this:
MCU Reset → Bootloader → HSE Initialization → Firmware Verification → Application
The bootloader first initializes the required security services through the HSE. It then checks the firmware image before allowing the application to execute.
If the image passes verification, the bootloader transfers control to the application.
If verification fails, the application is not trusted, and the bootloader follows the defined failure or recovery path.
This creates a simple but important security boundary:
The application does not get to decide whether it is trusted. The boot process makes that decision before the application starts.
Secure Firmware Updates
Security also needs to continue after the BMS leaves the factory.
Firmware updates are an important part of maintaining a BMS, but accepting arbitrary firmware would effectively bypass the protection provided by secure boot.
Our update flow therefore treats a firmware image as untrusted until it has been verified.
A simplified update process looks like this:
Receive Firmware → Store Update Image → Verify Using HSE → Install → Boot Verified Firmware
The new firmware is first received and stored in the designated update region.
Before installation, the bootloader uses the HSE-supported security mechanisms to verify the image.
Only after the verification succeeds is the new firmware accepted.
The update process also needs to account for situations such as an interrupted transfer, unexpected reset, or failed verification. A partially received or invalid image should never leave the system in an undefined state.
This is particularly important in BMS applications, where firmware updates can involve a device that is connected to an operating battery system.
Protecting Against Unauthorized Firmware
Secure boot and secure firmware updates work together.
Secure boot answers:
"Can this firmware be trusted?"
The update mechanism answers:
"Can this new firmware be installed?"
Both depend on protecting the cryptographic keys and the root of trust.
This includes secure key provisioning, protecting security-related configuration, controlling access to debug interfaces during production, and preventing unauthorized firmware from being accepted.
Rollback protection is another important consideration. If a device accepts any previously valid firmware version, an attacker could potentially attempt to install an older version containing a known vulnerability.
A secure firmware lifecycle therefore needs to consider not only whether an image is authentic, but also whether that version is permitted to run.
Securing Communication Between the BMS and Client Applications
Firmware security protects what runs inside the BMS. Communication security protects the information exchanged with the BMS.
BMS communicates with client applications over interfaces such as UART. Without protection, communication on a physically accessible interface can potentially be observed or manipulated.
The data exchanged can include battery measurements, diagnostics, configuration parameters, and commands.
For protected communication, our implementation uses AES-based encryption. In our current implementation, AES-CBC is used for the encryption layer.
The important point, however, is that encryption is only one part of the communication security design.
A secure communication protocol also needs to define how messages are framed, how keys are provisioned, how sessions are established, and how invalid or unexpected messages are handled.
For example, a client command should not simply be accepted because it can be decrypted. The BMS should also validate the command and its parameters against the current operating conditions and safety limits.
This creates another important boundary:
Encrypted message → Authentication/validation → Command checks → BMS action
The exact mechanisms used for authentication and integrity depend on the communication protocol and system architecture.
Security at Multiple Layers
One of the key lessons from building a secure BMS is that there is no single security feature that solves the entire problem.
The layers work together:
1. Hardware security
The HSE provides hardware-assisted security capabilities and forms part of the root of trust.
2. Secure boot
The bootloader verifies firmware before allowing it to execute.
3. Secure firmware updates
New firmware is verified before installation, with mechanisms to handle failed or interrupted updates.
4. Secure communication
Communication between the BMS and client applications is protected using cryptographic mechanisms such as AES.
5. Application-level validation
Even a valid and trusted command must still pass BMS-specific safety and parameter checks before it can affect the system.
This layered approach is important because compromising one layer should not automatically mean that every other security boundary is bypassed.
From Security Design to Real Implementation
Implementing these mechanisms on an embedded system is different from simply adding a cryptographic library to an application.
The bootloader has limited memory and processing resources, while security operations need to be performed reliably during startup and firmware updates.
The integration with the HSE also introduces its own development and debugging considerations. The bootloader needs to correctly communicate with the security subsystem, handle verification results, manage firmware images, and recover safely when an operation fails.
At the same time, the communication layer needs to handle real-world conditions such as incomplete frames, communication errors, device resets, and invalid commands.
These details are where much of the engineering effort goes. A secure architecture is only useful when the implementation behaves predictably under both normal and failure conditions.
A Secure Firmware Lifecycle
Ultimately, BMS security is not a single feature that can be added at the end of development.
It begins with the hardware root of trust and continues throughout the firmware lifecycle:
Hardware Root of Trust → Secure Boot → Verified Firmware → Secure Updates → Protected Communication → Validated Commands
Each layer addresses a different part of the security problem.
Secure boot helps ensure that only trusted firmware executes. Hardware security provides a protected foundation for security-critical operations. Secure firmware updates help maintain that trust as the product evolves. And protected communication helps ensure that the BMS and its client applications can exchange information without simply trusting everything that arrives over the interface.
For a BMS, security ultimately has to be treated as part of the system architecture rather than as an isolated encryption feature.
That is the approach we are taking as we build the security layer of our BMS platform.
Frequently Asked Questions
1. What is secure boot in a BMS? Secure boot is a process where the BMS verifies the authenticity and integrity of firmware before allowing it to execute. This prevents unauthorized or modified firmware from running on the device.
2. How does the HSE improve BMS security? The Hardware Security Engine (HSE) in the NXP S32K358 provides hardware-assisted security functions and helps establish a root of trust. It can support security-critical operations such as cryptographic processing and firmware verification.
3. How are firmware updates secured in the BMS? Firmware updates are treated as untrusted until they are verified. The update image is received and stored, then verified using the available security mechanisms before it is accepted and installed. Failed, incomplete, or invalid updates should not be allowed to execute.
4. Is encrypting BMS communication enough to make it secure? No. Encryption protects the confidentiality of data, but a secure communication protocol also needs mechanisms for authentication, integrity, key management, message validation, and protection against invalid or replayed commands.
5. Why is security important for a battery management system? A BMS controls and monitors hardware connected directly to a battery pack. Unauthorized firmware or manipulated commands could therefore affect system behaviour, diagnostics, or safety-related functions. A layered security architecture helps protect the BMS throughout its firmware and communication lifecycle.
