How an E-Bike Is Made: Motors, Batteries, Controllers and Firmware

An e-bike is made by building an ordinary bicycle frame and adding an electrical system: a brushless motor in the wheel hub or at the pedals, a lithium-ion battery pack assembled from many small cells and watched over by a battery management system, a motor controller that turns battery current into three phase drive, sensors that read pedalling, and a display. Firmware runs on the controller, the battery management system and the display, and most of it is flashed and tested at the factory and updated later through a phone app over Bluetooth Low Energy. The safety of the finished bike depends as much on that firmware and those cells as on the welds in the frame.

This goes one level deeper than our builds of lithium-ion batteries from mine to cell to pack and a smartwatch and its phone pairing. For the wireless side see Bluetooth LE GATT, pairing, bonding and attribute security, and for the wired bus that links parts inside many bikes see why CAN bus has no authentication.

E-bike makers do not publish yields, cell contracts or firmware signing designs, so we cite standards, regulators and official project documents and label any arithmetic illustrative. This post does not explain how to remove speed limits or how to modify or rebuild battery packs. Both are dangerous, and the first is unlawful in many places.

Key takeaways

• On top of the bicycle, an e-bike adds a hub or mid-drive motor, a battery pack with a battery management system (BMS), a motor controller, torque, cadence and speed sensors, a display, a harness and a charger.
• E-bike motors are brushless permanent magnet machines, mostly with neodymium iron boron magnets from a concentrated rare earth supply chain.
• The controller is a three phase inverter run by a microcontroller, often using field oriented control to regulate torque producing current directly.
• A pack is matched cylindrical cells in series and parallel, welded together, wired to a BMS and sealed. UL 2849 defines the BMS as an "electrical, electronic and software" system, so BMS firmware is part of the safety case.
• UL 2849 covers the whole e-bike electrical system, UL 2271 light electric vehicle batteries, EN 15194 European pedal assisted cycles up to 250 W and 25 km/h, and EN 50604-1 removable light EV packs.
• Battery fires come from thermal runaway. On 24 June 2026 the US CPSC proposed a mandatory rule built on UL 2849, UL 2272 and UL 2271 with added tests, citing 227 incidents with 39 deaths and 181 injuries. New York City has required certification since September 2023 under Local Law 39 of 2023.
• Assistance limits live in firmware: three US classes (20 mph pedal assist, 20 mph throttle, 28 mph pedal assist) and the EU's 250 W, 25 km/h exemption. Tuning devices defeat them, and model laws prohibit that tampering.
• Apps talk to the bike over Bluetooth LE; inside, many bikes use CAN, sometimes with the CANopen based EnergyBus profile (CiA 454). Over the air updates are only as safe as the bootloader's signature check.

Raw materials to a paired e-bike: the step table

This is the map for the rest of the post. It names the check at each stage rather than a pass rate, because no maker we could find publishes one.

Steps 1 to 4 and 12 look much like any bicycle or small motor factory. Steps 5 to 10 are where most of the safety risk lives, and steps 8, 10, 11 and 14 are where software enters.

A dated timeline of e-bike rules and standards

What are the main parts of an e-bike?

Strip the electrical system off an e-bike and what is left is a bicycle, usually with a heavier frame and stronger brakes. The electrical system is what UL 2849 describes. Its scope clause says that, as a minimum, the system "consists of the drive unit, battery, battery management system (BMS), interconnecting wiring, and power inlet", and that dedicated off board chargers are included. It also says the standard does not cover the bike's mechanical structure unless it says otherwise, which is why frame and brake testing sits in separate bicycle standards.

Frame and fork

Most frames are aluminium alloy, with carbon fibre on expensive models and steel on some cargo bikes. Many hide the battery in a deep down tube, which protects it from knocks but makes it harder to remove, inspect and cool. EN 15194 sets mechanical requirements alongside the electrical ones.

Motor or drive unit

The motor sits in a wheel hub or in a drive unit at the bottom bracket. UL 2849 calls it the drive unit.

Battery pack

A pack of lithium-ion cells, typically 36 V or 48 V nominal on bikes sold under the 250 W rules and the US class system, carried on the down tube, in the frame or on a rear rack. EN 15194 covers electrical systems with rated voltages up to 48 V DC.

Battery management system

A board inside the pack that watches every series group of cells, current and temperatures, and switches charge and discharge on or off. UL 2849 defines it as the "electrical, electronic and software monitoring and control system of a battery" relied on to keep cells in their safe operating region.

Motor controller

Power electronics that turn DC into three phase current: a separate box on many hub motor bikes, inside the drive unit on mid-drives.

Torque, cadence and speed sensors

A cadence sensor reports whether and how fast the cranks turn, usually with a ring of magnets and a Hall effect sensor. A torque sensor measures how hard the rider pushes, using strain gauges or a magnetostrictive sensor around the crank axle. A wheel speed sensor, often a spoke magnet and a sensor on the frame, gives the controller the road speed it uses to stop assistance at the legal limit.

Display and controls

UL 2849 groups the throttle, display and switches under "operator interface". The display is a small computer that often holds the Bluetooth radio.

Charger

An off board charger converts mains power to the pack's charging voltage and current. UL 2849 includes dedicated chargers in scope, and using a charger not designed for the pack is a hazard pattern regulators keep citing.

How are hub and mid-drive motors built?

Brushless DC and permanent magnet synchronous motors

E-bike motors are brushless: copper windings on the stationary stator, permanent magnets on the rotor, and electronics that switch current through the windings so the stator's field pulls the magnets around. With no brushes to wear, they last. The same machine is called a brushless DC motor (BLDC) when driven with switched current blocks and a permanent magnet synchronous motor (PMSM) when driven with sine shaped currents, as in Microchip's field oriented control note AN1078.

Stators: steel laminations and copper

The stator core is a stack of thin, insulated electrical steel laminations stamped into a toothed ring, which limits eddy currents. Copper is wound on the teeth in three phases; turns and wire gauge trade torque against top speed. The factory then checks winding resistance and insulation between copper and steel.

Rotors and rare earth magnets

Rotor magnets are nearly always neodymium iron boron, the strongest for their weight, pressed and sintered or bonded, machined, coated and magnetised. The US Geological Survey's 2025 rare earths summary notes that significant amounts of rare earths are imported into the United States "as permanent magnets embedded in finished goods", and that for 2020 to 2023 about 70 percent of imported rare earth compounds and metals came from China.

Hub motors: direct drive and geared

In a direct drive hub, the stator is fixed to the axle and the hub shell is the rotor, turning at wheel speed; many poles and a large diameter make it heavy but quiet and durable. A geared hub uses a smaller, faster motor, a planetary gear set and a freewheel clutch: lighter, but with gears that wear.

Mid-drive units

A mid-drive puts a small, fast motor at the bottom bracket and drives the chainring through reduction gearing, so it climbs well through the bike's own gears. The housing usually also holds the torque sensor and the controller, which makes it a sealed, firmware driven module.

Hall sensors and sensorless control

The controller has to know where the rotor is. Many e-bike motors carry three Hall effect sensors that report rotor position in coarse steps. Sensorless designs, like the one in AN1078, estimate position from the back EMF the magnets induce in the windings; e-bikes often keep Hall sensors because they need torque from a standstill, where back EMF is too small to measure.

How does the controller drive the motor?

The inverter

The power stage is a three phase inverter: six MOSFETs in three half bridges, switched by gate drivers with pulse width modulation so each phase's average voltage follows the control code. Shunt resistors or Hall effect current sensors report what flows, and a microcontroller runs the loop.

Six step commutation

The simplest method is six step, or trapezoidal, commutation: two phases carry current, one floats, and the controller steps through six combinations as the Hall sensors report the rotor moving. It is cheap and adequate for many hub motor bikes, but torque ripples at each step.

Field oriented control

Field oriented control (FOC) drives the motor with smooth sine currents and controls torque directly. Microchip's AN1078 lays out the standard chain:

1. Measure two phase currents (the third follows, because the three sum to zero).
2. Apply the Clarke transform to turn the three phase currents into two currents on fixed, perpendicular axes.
3. Apply the Park transform, using the rotor angle, to express them on axes that rotate with the rotor: direct (Id), along the magnet's field, and quadrature (Iq), at right angles.
4. Run two PI controllers: Iq tracks the requested torque, Id is held near zero for a surface magnet motor.
5. Transform the controller outputs back to three phase voltages and generate the PWM.
6. Update the rotor angle from Hall sensors, an encoder or a sensorless estimator, and repeat every PWM cycle.

The result is quieter, smoother drive. It is also more code, with current calibration, angle estimation and fault detection, so the controller is a real software product with real bugs and updates.

Worked example: from rider effort to motor current (illustrative)

Suppose a torque sensing mid-drive is set to an assist level that adds 150 percent of the rider's effort. The rider pushes 40 N·m at the cranks at 70 rpm. Rider power is torque times angular speed: 40 × (70 × 2π ÷ 60) ≈ 40 × 7.33 ≈ 293 W. The assistance target is 1.5 × 293 ≈ 440 W, which the firmware clips to the unit's peak output and, under EU rules, to an average no higher than the 250 W continuous rating. The controller turns that into an Iq target and, as road speed nears the market's limit, ramps it to zero. Makers set assist curves in firmware and do not publish them.

Protection inside the controller

The controller firmware also watches for overcurrent, over temperature of the MOSFETs and the motor, undervoltage from the pack, stalled motors and sensor faults. UL 2849 calls circuits like this "protective circuits" and says they include "firmware, and software-based control systems" that prevent or detect hazards. Where a protective circuit is relied on for safety, the standard expects either redundancy, a fail safe design, or evaluation to a functional safety standard: it lists UL 991 with UL 1998 (software in programmable components), UL 60730-1, IEC 61508 at Safety Integrity Level 2, or ISO 13849 at Performance Level c.

How is a battery pack built from cylindrical cells?

Cells

Most packs use cylindrical 18650 (18 mm by 65 mm) or 21700 (21 mm by 70 mm) cells bought from specialist cell makers; our lithium-ion battery build covers the cell itself. The pack maker inspects incoming lots and designs around the datasheet's voltage, current and temperature limits.

Series and parallel layout

A lithium-ion cell has a nominal voltage around 3.6 V. To reach pack voltage, cells are grouped in series; to reach capacity and current, cells are wired in parallel within each group. A "13S4P" pack has 13 series groups of 4 parallel cells, 52 cells in all.

Worked example (illustrative): with 3.6 V nominal cells of 3.5 Ah each, a 13S4P pack has a nominal voltage of 13 × 3.6 = 46.8 V (sold as 48 V) and a capacity of 4 × 3.5 = 14 Ah. Its nominal energy is 46.8 × 14 ≈ 655 Wh. A 10S4P pack of the same cells gives 36 V nominal and about 504 Wh. If one parallel group in the 13S4P pack has a weak cell, that group holds less charge than the others, and it reaches its upper and lower voltage limits first. That is why matching and BMS monitoring are per group, not per pack.

Cell matching

Cells are sorted by capacity and internal resistance so every group behaves alike. Mismatched cells drift apart over cycles and push some cells to their limits while the pack voltage still looks normal. Matching tolerances are not published.

Welding the interconnects

Cells sit in plastic holders and are joined with nickel or nickel plated steel strip, or busbars, resistance or laser welded to the terminals; soldering is avoided because heat damages cells. Factories pull test sample welds and measure joint resistance, since a high resistance weld heats under load.

Wiring the BMS

Each series group gets a sense wire, and thermistors sit between cells. A cell monitoring chip reads each group's voltage, a current sensor watches the main path, and MOSFETs cut charge or discharge. Near full charge the BMS bleeds a little current from the highest groups through resistors, called passive balancing.

BMS firmware also estimates state of charge, counts cycles, logs faults and often reports them to the display and app. UL 2849 notes the BMS may be the "source of memory of the battery operation throughout its life": data as well as protection.

Enclosure and connector

The pack is padded or potted and sealed in a plastic or aluminium housing whose connector carries power and often a data line. The CPSC proposal would add tamper resistant enclosure requirements to UL 2849 and UL 2271.

End of line test

Finished packs are cycled on a test rig that checks capacity, BMS cut offs and communication, and the BMS firmware version is recorded against the serial number for later recalls and updates.

What do UL 2849, UL 2271, EN 15194 and EN 50604-1 cover?

UL 2272, which covers personal e-mobility devices such as scooters and hoverboards, is a sibling standard. The CPSC proposal would apply UL 2849 to e-bikes, UL 2272 to other micromobility products and UL 2271 to user replaceable packs, each with modifications.

A certified battery and a UL 2849 certified e-bike are different claims: one covers a pack, the other the whole system with charger and protective firmware. New York City's Local Law 39 names UL 2849 for powered bicycles but also accepts "such other safety standard as the department has established by rule in consultation with the fire department", so check the city's current rules rather than assuming only one mark counts.

Why do micromobility battery fires happen?

Thermal runaway

A lithium-ion cell stores a lot of energy next to a flammable electrolyte. A damaged, overcharged, overheated or internally shorted cell can heat itself faster than it sheds heat. This thermal runaway vents flammable gas, can ignite and can spread to neighbouring cells. The CPSC's proposal describes the hazards as "thermal runaway of lithium cells, which can lead to fires, explosions, gas releases, burns, overheating, and smoke inhalation", and notes that smoke inhalation and burns are the main causes of death and injury in these fires.

The common causes

The same patterns recur in regulators' analyses:

• Low quality or mismatched cells. Cells that are counterfeit, recycled from other products or poorly matched drift apart and stress the weakest ones.
• Incompatible chargers. A charger with the wrong voltage or without the right communication can overcharge a pack. The CPSC proposal adds a reverse polarity test for this reason.
• Missing or weak BMS protection. A BMS that does not stop charging when cells are too hot or too low lets damage build. The CPSC proposal would add a post discharge charge test so the BMS refuses to charge when cell surface temperature is above the upper limit.
• Physical damage and water can short cells or damage the BMS.
• Homemade and modified packs. The CPSC proposal names homemade batteries among the hazard patterns its labelling changes address.

What the US CPSC has proposed

On 24 June 2026 the CPSC published a notice of proposed rulemaking titled "Safety Standard for Lithium-Ion Batteries Used in Micromobility Products and Electrical Systems of Micromobility Products Containing Such Batteries" at 91 FR 38162. It proposes that electrical systems in micromobility products comply with ANSI/CAN/UL 2849:2020 for e-bikes, ANSI/CAN/UL 2272:2024 for other personal e-mobility devices and UL 2271:2023 for user replaceable packs, with modifications. Comments closed on 24 August 2026; the rule is not final at the time of writing.

Its data cover 227 incidents, 90 of them with 39 deaths and 181 injuries in total. The Commission's preliminary view is that the voluntary standards are "inadequate" alone and that products do not substantially comply with them. Proposed modifications include:

• tamper resistant battery enclosure requirements added to UL 2849 and UL 2271;
• a post discharge charge test that requires the BMS to block charging when the cell surface is too hot;
• a reverse polarity test across all three standards, to prevent damage from an incompatible charger;
• revised labels that warn about electric shock, thermal runaway, homemade batteries and unsafe charging.

What New York City requires

New York City's Local Law 39 of 2023 was passed by the City Council on 2 March 2023, approved by the Mayor on 20 March 2023 and took effect 180 days later, in September 2023. It added a section to the city's administrative code that bars anyone from distributing, selling, leasing or renting a powered bicycle unless its electrical system "has been certified by an accredited testing laboratory" for compliance with UL 2849, or another standard the city's consumer protection department sets by rule with the fire department. Powered mobility devices such as scooters are tied to UL 2272 in the same way, and storage batteries for these devices are covered too. The certification, or the lab's logo, wordmark or name, has to appear on the product, its packaging or the documentation provided at sale. In October 2024 the city announced Local Laws 49 and 50 of 2024, which strengthen enforcement, let the city close repeat violators and give the FDNY concurrent authority to enforce the certification law.

What owners can do

Following the hazard patterns above: buy bikes and batteries certified to a recognised standard, use the manufacturer's charger, charge on a hard surface away from exits and not unattended for long periods, stop using a pack that is swollen, hot, leaking or smells, and never use a pack that has been opened or rebuilt by someone other than the maker.

What firmware runs on an e-bike, and how are assistance limits enforced?

Three or more computers

A typical e-bike has at least three programmable devices:

• Controller or drive unit firmware: the motor control loop, the assistance curves, the speed limit, sensor handling and protections.
• BMS firmware: cell monitoring, protection limits, balancing, state of charge, logs, and the communication protocol to the rest of the bike and the charger.
• Display firmware: user interface, settings, trip data and, often, the Bluetooth LE radio stack that talks to the phone.

Trackers, smart locks and electronic shifting add more firmware. Much of it runs on a real time operating system or vendor SDK with open source components inside, and the Bluetooth stack alone is a large piece of software.

Legal assistance limits

The limit a bike enforces depends on where it is sold.

Every one of these limits is enforced in firmware. The controller reads the wheel speed sensor, compares road speed with the configured limit and tapers assistance to zero. It reads the cadence or torque sensor to decide whether the rider is pedalling. The continuous power rating is a property of the motor and its thermal design, but the peak power and the assist curves are firmware settings.

Why tuning devices matter

"Tuning" products and firmware hacks raise or remove the speed limit. We will not describe how. Why it matters:

• Law. A cycle that assists beyond the 250 W and 25 km/h exemption falls back inside the EU type approval regulation, and the US model law prohibits tampering that changes motor powered speed capability.
• Safety and heat. Brakes, tyres and frames are tested for design speeds, and higher sustained power heats the motor, controller and cells beyond their envelope.

Tuning is also a lesson in trust boundaries: the controller trusts sensor signals and, on an unauthenticated bus, every message on it. Makers that detect tuning do it in firmware by cross checking signals that should agree.

How do e-bikes talk to phones and accessories?

Inside the bike: UART, CAN and EnergyBus

Cheaper bikes link display, controller and battery with simple serial (UART) lines and vendor protocols. Many premium drive systems use CAN, as cars do, because it tolerates electrical noise and lets many units share two wires. CAN frames carry no sender identity and no authentication, which our post on why CAN bus has no authentication covers in detail.

One open option is EnergyBus. CAN in Automation's CiA 454 series is a CANopen application profile for energy management systems: a DC power line controlled over a CAN network, where an energy management controller monitors every energy source and sink connected to it. CiA says the system is primarily intended for light electric vehicles but not limited to them, and uses a pedelec network as its worked example. The series runs to 14 parts, with part 4 named the EnergyBus controller and other parts covering the drive control unit, the HMI unit, sensors, gateways, load units and a security unit. A shared, documented profile makes it easier for a battery from one maker to work with a charger or drive from another. It does not, by itself, make the bus authenticated: that depends on whether a product implements the security parts and how.

To the phone: Bluetooth Low Energy

Phone apps talk to the bike over Bluetooth LE, usually to the display or a dedicated module. The Bluetooth SIG's Core Specification, now at version 6.3, defines the radio, the attribute protocol and the Generic Attribute Profile (GATT) that apps use to read and write values such as battery level, assist mode, ride data and firmware update blocks.

Security depends on how the maker uses pairing:

• LE Secure Connections pairing, added in Bluetooth 4.2, uses elliptic curve Diffie Hellman key agreement on the P-256 curve, which protects against passive eavesdroppers. NIST's Guide to Bluetooth Security (SP 800-121 Rev. 2) calls LE Security Mode 1 Level 4, authenticated Secure Connections pairing with AES-CCM encryption, the most secure of the LE modes. Whether pairing also resists an active attacker depends on the association model: Numeric Comparison, Passkey Entry and Out of Band give authenticated keys, while NIST notes that "Just Works provides no MITM protection".
• Many bike displays cannot show a six digit number, so they fall back to Just Works or to application layer pairing such as a QR code in the box.
• GATT permissions decide which characteristics need an encrypted or authenticated link; anything that changes settings or starts an update should require both.

Our Bluetooth LE GATT post explains bonding and attribute permissions step by step.

Over the air updates

Typically the app downloads an image from the maker's cloud over HTTPS and streams it to the bike over Bluetooth LE; the display may forward it over the internal bus to the controller and BMS. Each unit's bootloader writes it to a spare slot, checks it and swaps it in only if the check passes.

What makes that safe is the check, not the transport:

Open source bootloaders such as MCUboot implement the first three for microcontrollers: imgtool signs images with a version and optional security counter, and the bootloader verifies them with a built in key. Few e-bike makers publish their update design, so ask.

What data do e-bike apps and anti theft trackers collect?

What the app sees

An e-bike app usually collects:

• Account data: name, email, phone, the bike's serial number and proof of purchase.
• Ride data: distance, speed, assist mode, battery use and often a GPS track of every ride.
• Bike telemetry: firmware versions, error codes, BMS cycle counts and health logs.
• Device data: phone model, app version, crash reports and analytics identifiers.

What trackers add

Anti theft trackers add GPS and a cellular modem, or a crowd sourced Bluetooth finding network, so the bike reports its location without the phone. Timestamped locations reveal home, work and routine, and remote immobilisation means a cloud account can lock the motor.

How to limit it

• Read the privacy notice for retention and sharing.
• On Android 10 and later, background location is a separate permission, ACCESS_BACKGROUND_LOCATION, according to Android's developer documentation. Grant "only while using the app" unless you need automatic ride logging or tracking.
• Use a unique password and multi factor authentication for the bike account, since it may control an immobiliser.
• Before selling the bike, remove it from your account, factory reset the display and delete your rides.
• In the EU and UK, you can ask the maker for a copy of your data and for deletion under data protection law.

Step by step: checking an e-bike's app, pairing and firmware

This walkthrough is for owners, fleet managers and teams who build e-bike companion apps or firmware. Nothing here changes motor limits or battery behaviour, and nothing here opens the pack.

1. Record what you have

Note the model, drive system, display, battery serial number and each unit's firmware version from the app; that is your bill of materials for updates and recalls. Check the label for the certification mark (UL 2849 in the US and Canada; EN 15194 and EN 50604-1 in Europe).

2. See what the bike advertises over Bluetooth LE (Linux)

On a Linux laptop with BlueZ, you can see the bike's advertising name and services without pairing:

bluetoothctl
[bluetooth]# power on
[bluetooth]# scan le
# note the address of your bike's display, then
[bluetooth]# scan off
[bluetooth]# info AA:BB:CC:DD:EE:FF

info shows the advertised name, the service UUIDs and whether the device is paired and bonded. If your bike advertises all the time, even while parked and locked, anyone nearby can see that a bike of that model is present. That is a privacy point, not a fault, but it is worth knowing.

3. Check the app's permissions on Android

With USB debugging enabled and adb installed, list the permissions the app holds (replace the package name with the real one from the app's store listing):

adb shell dumpsys package com.example.ebikeapp | grep -E "permission|granted=true"
adb shell appops get com.example.ebikeapp

If the app holds background location and you do not need it, revoke it:

adb shell pm revoke com.example.ebikeapp android.permission.ACCESS_BACKGROUND_LOCATION

4. For app teams: scan the companion app's dependencies

A companion app is a mobile project with dozens or hundreds of open source dependencies: Bluetooth helpers, map SDKs, analytics, crash reporting, networking. Scan it the same way you would any other repository:

# from the root of the app repository
safeguard scan --dir .
# results are written as JSON under ./output

Then pin versions with the build system's lockfile (for example a Gradle version catalog with dependency locking, or CocoaPods and Swift Package Manager resolved files) so the app you test is the app you ship.

5. For firmware teams: sign and verify images

If your controller or display uses MCUboot, sign each image with a version and a security counter, and verify it before release:

# sign a firmware image for the primary slot (example values)
imgtool sign --key release-key.pem --header-size 0x200 --align 8 \
  --version 1.4.2 --security-counter 7 --slot-size 0x60000 \
  build/display.bin build/display.signed.bin

# confirm the signature and metadata match the release key
imgtool verify --key release-key.pem build/display.signed.bin

Keep the private key in a hardware security module or an offline signer, not on a build agent, and record the image hash in your release notes so service centres can check what they install.

6. Generate an SBOM for each firmware build

Firmware on a vendor SDK or RTOS pulls in open source code such as a Bluetooth stack and a crypto library. Keep an SBOM per build, next to the signed image, so you can tell which firmware versions carry a component when an advisory lands.

7. Test the update path end to end

On a test bike, check that the app refuses an image with a bad signature, refuses an older version, recovers from an interrupted transfer, and that the assistance limit still matches the bike's class or market after the update. Keep the results with the release.

Common mistakes

• Treating "UL listed battery" as "certified e-bike". A certified pack in an uncertified system with an unknown charger is not a UL 2849 system.
• Using any charger with the right plug. Voltage, current and communication have to match the pack and its BMS.
• Buying replacement packs from unknown sellers. Counterfeit and recycled cells are a known fire pattern.
• Assuming the speed limit is in the motor. It is in firmware, and firmware changes with every update. Check the class or market setting after updates.
• Pairing with Just Works and assuming encryption equals authentication. An encrypted link to the wrong device is still the wrong device.
• Granting background location by default. Most riders only need location while the app is open.
• Shipping firmware without an SBOM. When a Bluetooth stack or crypto library advisory lands, you will not know which bikes carry it.

FAQ

How is an e-bike battery made?

Cylindrical cells are inspected, matched, arranged in series and parallel, welded together with nickel strip, wired to a BMS and sealed. Each pack is cycled on a test rig and its BMS firmware version recorded.

What is the difference between a hub motor and a mid-drive motor?

A hub motor sits in the wheel and drives it directly or through planetary gears. A mid-drive sits at the pedals and drives the chainring, so it works through the bike's gears. Mid-drives usually include a torque sensor and the controller in one housing.

What is UL 2849?

The US and Canadian safety standard for the electrical system of e-bikes with lithium-based batteries, including the charger and functional safety of protective firmware. It does not cover the frame.

Is UL 2849 required by law?

In New York City, yes, for e-bikes sold, leased or rented there under Local Law 39 of 2023. At federal level, the CPSC proposed in June 2026 to make UL 2849 with modifications mandatory for e-bikes, but that rule was not final when this post was written.

What is EN 15194?

The European standard for pedal assisted cycles of up to 250 W that cut off at 25 km/h; the current version is EN 15194:2017+A1:2023.

What are class 1, 2 and 3 e-bikes?

Under the PeopleForBikes model law used by many states, class 1 assists only while pedalling up to 20 mph, class 2 adds a throttle with a 20 mph limit, and class 3 assists while pedalling up to 28 mph and needs a speedometer. Motors must be under 750 W.

Why do e-bike batteries catch fire?

Damaged, overcharged or poor quality cells enter thermal runaway, often triggered by incompatible chargers, weak BMS protection, crashes or rebuilt packs.

Can e-bike firmware be updated over the air?

Many bikes accept updates through the maker's app over Bluetooth LE. A safe design verifies a digital signature in the bootloader, blocks older versions and keeps the previous image until the new one boots.

Where Safeguard fits, honestly

Safeguard does not test batteries, motors or chargers, does not certify e-bikes, does not scan firmware binaries and does not analyse hardware. Its fit is the software around the bike: the companion app, the cloud service that delivers updates and stores ride data, and the build tooling and source repositories of firmware teams. Safeguard scans those repositories, container images and SBOM files for known vulnerable open source components, shows which projects contain a given component and version, ranks findings with reachability analysis, and can open fix pull requests when autonomous remediation is switched on.

The software supply chain still matters here because an e-bike app and its update service are ordinary software projects built from open source packages, and the firmware on the controller, display and BMS ships open source stacks of its own. A vulnerable dependency in the app or the update service is a way in to a rider's location history or to the path that installs code on the bike.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session asked to fix a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. The same flow fits the web dashboard or backend service behind an e-bike app, where a vulnerable JavaScript dependency sits next to rider location data.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Firmware and app teams who keep their source and build scripts on internal machines can scan those repositories locally in the same way.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: send work to a computer running the CLI and approve each command on the phone with Allow once, Allow for turn or Deny. A fleet engineer away from a desk can approve a dependency fix in the fleet tooling repository without anything running unattended.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• UL Standards and Engagement, ANSI/CAN/UL 2849:2022A Standard for Safety for Electrical Systems for eBikes (incorporated by reference copy)
• Federal Register, Safety Standard for Lithium-Ion Batteries Used in Micromobility Products (91 FR 38162, 24 June 2026), document metadata
• GovInfo, Federal Register PDF of the CPSC proposed rule 2026-12749
• US Code, 15 U.S.C. 2085, Low-speed electric bicycles (Cornell LII)
• City of New York, Office of the Mayor, new enforcement powers to prevent the sale of dangerous e-bikes and batteries (2024)
• New York City Local Law 39 of 2023, enacted text (PDF via intro.nyc)
• Publications Office of the EU, Regulation (EU) No 168/2013 of 15 January 2013 (CELEX 32013R0168)
• Genorma standards catalogue, EN 15194:2017+A1:2023 Cycles, Electrically power assisted cycles, EPAC bicycles
• Genorma standards catalogue, EN 50604-1:2016/A1:2021 Secondary lithium batteries for light EV applications, Part 1
• NIST, SP 800-121 Rev. 2 (update 1), Guide to Bluetooth Security (PDF)
• MCUboot project, imgtool source (verify and sign commands)
• PeopleForBikes, Policies and Laws for electric bikes
• PeopleForBikes, Model Electric Bicycle Legislation (January 2020, PDF)
• GOV.UK, Electric bike rules
• CAN in Automation, CiA 454 series: CANopen application profile for energy management systems
• Bluetooth SIG, Core Specification
• Microchip Technology, AN1078 Sensorless Field Oriented Control of a PMSM (2010, PDF)
• US Geological Survey, Mineral Commodity Summaries 2025: Rare Earths (PDF)
• MCUboot documentation, imgtool
• Android Developers, Request location permissions

Last reviewed: 24 October 2026.