Your Battery Is Now an Attack Surface: Solid-State, EVs, and a Very Real Cyber Risk

Bygaz

Why this matters right now

Solid-state batteries are not just a chemistry upgrade. They’re a system architecture change that turns power storage into:

  • A deeply integrated cyber-physical subsystem
  • A remotely updatable, networked component in EVs and grid-scale storage
  • A safety-critical device whose failure mode is “thermal event,” not just “service degradation”

If your org touches EVs, charging infrastructure, BMS firmware, or grid-scale battery systems, the move from liquid-electrolyte lithium-ion to solid-state batteries changes your threat model:

  • Higher energy density ⇒ Higher consequence of loss of control
  • More complex Battery Management Systems (BMS) ⇒ Larger attack surface (firmware, calibration logic, telematics)
  • Tighter integration with vehicle and grid orchestration ⇒ More lateral movement paths for attackers

Solid-state is arriving unevenly, but it’s no longer a 2035 problem. Early commercial deployments are starting in:

  • Premium EVs and hybrids
  • High-value drones and robotics
  • Pilot grid storage projects

You don’t need to bet on exact timelines to prepare. You do need to assume that:

“Battery = segmented, safety-critical, software-defined system that can be attacked.”

What’s actually changed (not the press release)

Ignore the “2x range” marketing. The security-relevant changes are more subtle.

1. Tighter coupling between chemistry and software

Solid-state cells behave very differently from traditional lithium-ion:

  • Different charge curves
  • Different temperature envelopes
  • Different degradation patterns (e.g., dendrite formation, interface resistance)

Result: BMS firmware becomes more complex and more proprietary to extract performance and lifetime. That means:

  • More custom algorithms for state-of-charge / state-of-health
  • More calibration data and lookup tables
  • More over-the-air (OTA) tuning pressure from product and ops teams

Complexity and updatability are great for performance, bad for security if not treated as safety-critical firmware.

2. New supply chain and manufacturing stack

Solid-state manufacturing is not just “same lines, better slurry”:

  • New material suppliers (solid electrolytes, interfacial layers)
  • New equipment vendors (dry-coating, high-precision stacking, sintering)
  • More in-line metrology and test equipment, often networked
  • New contract manufacturers specializing in these cells and packs

Security impact:

  • Expanded vendor graph with immature security practices
  • More OT/ICS systems exposed to corporate IT for analytics and remote support
  • New firmware sources (from tooling vendors, pack assemblers, and integration partners)

3. Higher pressure for remote optimization

Early solid-state deployments will be expensive and over-instrumented:

  • Dense telemetry from packs (cell-level data, temps, impedance, etc.)
  • Remote parameter tweaks to balance lifetime vs performance vs safety
  • Cloud-based analytics feeding back into BMS updates

This creates a feedback loop: more cloud connectivity ⇔ more frequent firmware / config updates ⇔ more opportunity for compromise.

4. Commercial reality check

Most public projections are optimistic. What matters for you:

  • 2025–2028: Niche / premium deployments in vehicles and stationary storage.
  • 2028–2035: Gradual shift into mainstream EV SKUs and more grid projects, assuming no major manufacturing showstopper.

From a cybersecurity planning perspective, this is “design for it now, defend it in the next 3–7 years,” not “we’ll reevaluate in 2040.”

How it works (simple mental model)

Keep a security-oriented mental model of a solid-state battery system as three layers:

1. Chemistry + mechanics (physical layer)

  • Solid electrolyte instead of flammable liquid
  • New failure modes: interface degradation, internal shorts, thermal runaway (still possible)
  • Safety constraints are narrow and can be violated quickly if control loops go wrong

From a security lens: this is the “physics API” your software must respect. Any cyber compromise that pushes operations outside allowed envelopes is a safety issue.

2. BMS + firmware (control layer)

This is where it gets interesting:

  • Hardware:

    • Measurement ICs (voltages, currents, temps)
    • Switching elements (contactors, FETs)
    • Safety hardware (fuses, hardware cutoff paths)

  • Firmware functionality:

    • Cell-level monitoring and balancing
    • Charge/discharge rate enforcement
    • Thermal management coordination
    • Safety interlocks and error handling
    • Logging and fault diagnosis

For solid-state, BMS often needs:

  • More sophisticated models (e.g., physics-informed or ML-based estimation of internal state)
  • More finely tuned limits that evolve as the pack ages
  • Higher update pressure to capture new chemistry data and field experience

3. Integration + connectivity (system layer)

This is where conventional IT and security teams touch the system:

  • Vehicle integration:
    • CAN / LIN / automotive Ethernet connectivity
    • Interfaces to drive system, charger, telematics, OTA modules
  • Grid integration:
    • Modbus, DNP3, IEC 61850, proprietary protocols
    • Gateway devices to SCADA / EMS / cloud control planes
  • Management:
    • OTA update pipelines
    • Remote monitoring dashboards
    • Data ingestion and analytics platforms

Combined, this stack means:

Your “battery” is a distributed system with constrained, safety-critical embedded nodes sitting behind gateways that talk to your cloud.

Treat it accordingly.

Where teams get burned (failure modes + anti-patterns)

1. “It’s just power hardware” mindset

Pattern: Security reviews focus on:

  • Infotainment, user apps, and cloud APIs, but
  • Treat the battery and BMS like a sealed hardware component.

Failure mode:

  • No threat modeling around BMS commands over CAN / grid protocols
  • Inadequate authN/authZ for anything that can adjust limits, modes, or firmware
  • Over-trust of vendor security claims without verification

Example:
An EV OEM let a vendor deliver a “secure BMS” but never validated message handling on internal buses. A research team later demonstrated that sending specific malformed control frames from a compromised telematics unit could disable key safety checks. The pack never exploded in testing, but it did operate far outside spec without logging proper alerts.

2. OTA updates slapped onto safety-critical firmware

Pattern:

  • Product org wants the ability to “improve range and lifetime via OTA updates.”
  • Engineering exposes direct BMS firmware update paths through existing OTA infrastructure.

Failure modes:

  • Reuse of web token auth at the edge of a safety-critical path
  • Inadequate rollback and failsafe logic
  • Poor separation between “config tweaks” and “firmware image changes”

Example:
A stationary storage provider pushed a BMS firmware update that applied only to a newer cell variant. Due to mis-tagging in the OTA pipeline, some older packs received it. The firmware tried to operate them at solid-state-like high C-rates. The system’s thermal controls limited the damage, but it triggered frequent emergency shutdowns—essentially a self-inflicted denial-of-service.

3. Flat networks in manufacturing and test

Pattern:

  • New solid-state manufacturing line added to an existing plant network
  • Vendors demand remote access for support
  • OT security practices lag corporate IT

Failure modes:

  • Single-ransomware event halts production for weeks
  • Manipulated test/calibration data leading to unsafe packs leaving the factory
  • Firmware signing keys or golden images stolen from poorly segmented build systems

Example:
A battery integrator had both their pack test benches and corporate file servers on the same VLAN for “convenience.” A malware incident on office workstations propagated to test benches, corrupting test scripts and mislabeling packs as “passed.” Later, field failures traced back to packs that had never actually run full safety checks.

4. Treating safety validation as a one-time event

Pattern:

  • Initial qualification of BMS + chemistry stack is thorough.
  • Subsequent firmware iterations are fast-tracked under schedule pressure.

Failure modes:

  • Safety functions accidentally weakened or bypassed in “minor” updates
  • Updated control logic not re-run through worst-case test matrices
  • No differential verification between firmware versions

In a solid-state context, where our empirical dataset is small, this is particularly dangerous. The control envelope is still being discovered.

Practical playbook (what to do in the next 7 days)

You don’t need to redesign your entire architecture this week. You do need to set direction and flush out blind spots.

1. Clarify ownership and risk classification

  • Explicitly classify:
    • BMS firmware
    • Pack config/parameters
    • Manufacturing test/calibration data

As: safety-critical, high-impact assets in your risk register.

  • Make one team clearly accountable:
    • For EVs: usually platform or vehicle control + security architecture
    • For grid systems: OT/ICS security lead + product security lead

2. Draw the actual data/command graph

In a half-day workshop, get engineering, battery, and security together and map:

  • All paths by which:
    • Commands reach the BMS (internal buses, diagnostics ports, remote commands)
    • Firmware/config images reach the BMS (OTA, local service tools, manufacturing)
    • Telemetry leaves the BMS (for analytics, dashboards, logs)

Mark:

  • Which nodes are internet-connected
  • Where authentication and encryption actually happen (not just “in theory”)
  • What can change:
    • Limits (voltage, current, temp windows)
    • Operating modes
    • Firmware images
    • Safety overrides/diagnostics

You will likely discover at least one surprising control path.

3. Set hard safety boundaries for software changes

With your battery and safety teams, define a small set of invariants:

  • E.g., “These maximum C-rates and temperatures may not be changed by remote commands or OTA, only by physical reprogramming in a secure facility.”

Then:

  • Enforce them in firmware as hardcoded, non-configurable limits
  • Reflect them in documentation, test plans, and APIs
  • Block any roadmap items that violate them without a formal safety review

4. Shore up OTA and manufacturing basics

For OTA:

  • Require:
    • End-to-end signing of firmware and config bundles
    • Device-unique identity and mutual auth
    • A/B images with verifiable rollback if boot-time checks fail
    • Separation of “telemetry path” and “update path” at the protocol and service level

For manufacturing & test:

  • Segment the network:
    • Production lines and test benches in separate zones from corporate IT
    • Remote vendor access via tightly controlled bastions, not flat VPN into OT
  • Protect build artifacts and keys:
    • Offline or HSM-backed signing keys for BMS firmware
    • Controlled, audited access to “golden” firmware and calibration data

5. Add batteries to your threat modeling canon

In your next threat modeling session for:

  • A new EV platform
  • A grid storage deployment
  • A major firmware platform upgrade

Explicitly add:

  • “Abuse of BMS commands to cause unsafe operation”
  • “Compromise of OTA update pipeline for BMS”
  • “Tampering with calibration/test data in manufacturing”

For each, identify:

  • Entry points (which networks, which interfaces, which credentials)
  • Mitigations you already have
  • Gaps you’re willing to accept vs must-close

Bottom line

Solid-state batteries don’t magically fix fire risk; they change how and when you can lose control.

The critical shifts for security and reliability:

  • Higher energy density and narrower safe operating windows mean control logic is more consequential.
  • BMS firmware goes from “simple guardrails” to “sophisticated, frequently updated control software tightly coupled to novel chemistry.”
  • New supply chains and manufacturing processes expand your attack surface in OT and firmware distribution.

If you’re building or operating EVs or grid storage, treat solid-state as a forcing function to modernize your cyber-physical security posture:

  • Model the battery as a networked, safety-critical embedded system with OTA updates, not a passive component.
  • Lock in non-negotiable safety invariants that no remote update can bypass.
  • Clean up OTA, manufacturing, and internal network practices before these packs scale.

The orgs that get this wrong will experience failures that look like “physics problems” but are, at root, software and security failures in a new, high-consequence attack surface.

Similar Posts