E-scooter cybersecurity engineering: ETSI EN 303 645 V3.2.0:2024-12 baseline (13 provisions for consumer IoT — no default password, vulnerability disclosure RFC 9116, secure update, secure storage, secure communication), ISO/SAE 21434:2021 road-vehicle cybersecurity engineering (TARA threat analysis + risk assessment), ISO/SAE 24089:2023 software update engineering, UNECE R155 CSMS (Cybersecurity Management System) mandatory for new vehicle type-approvals from 07-2022, UNECE R156 SUMS (Software Update Management System), EU Cyber Resilience Act 2024/2847 (Regulation 2024-10-23, applicability 2027-12-11 + reporting obligations 2026-09-11), NIST SP 800-193:2018 Platform Firmware Resilience Guidelines (Protection-Detection-Recovery RoT), NIST SP 800-183 IoT Networks of Things, IEC 62443-4-1/-4-2 secure product development lifecycle, Bluetooth Core 5.4 LE Secure Connections with ECDH P-256 (replacing Just Works as baseline), IEEE 802.11i WPA3-Personal SAE Dragonfly key exchange, RFC 9116 security.txt responsible-disclosure, attack surface (BLE pairing Just Works/Numeric Comparison/Passkey Entry/OOB, Bluetooth protocol attacks KNOB CVE-2019-9506 + BIAS CVE-2020-10135 + BLURtooth CVE-2020-15802 + BLESA CVE-2020-9770, firmware via JTAG/SWD/USB DFU, motor controller CAN bus, mobile app↔cloud TLS, OTA update channel signing, GPS spoofing, smart-battery BMS handshake, hardware UART debug eFuse), mitigation (LE Secure Connections ECDH P-256 + mutual TLS certificate pinning + secure boot signed bootloader + signed firmware AES-256 + anti-rollback monotonic counter + HSM/secure element ATECC608B/NXP A1006/SE050 + SBOM SPDX CycloneDX + RFC 9116 security.txt + Coordinated Vulnerability Disclosure ISO/IEC 29147:2018 + penetration testing ISTQB), incidents (Xiaomi M365 BLE anti-lock bypass 2019 Zimperium Rani Idan, Lime BLE replay attack 2019, Bird/Lime API IDOR 2020, Ninebot ES1/ES2/ES4 BLE pwd 888888 vulnerability, Tier/Voi unauthorized unlock 2022, hoverboard CVE catalogue 2018)
In the engineering guide series we covered the lithium-ion battery + BMS + thermal runaway intro, the braking system, the motor and controller, the suspension, the tires, lighting and visibility, the frame and fork, the display and HMI, the SMPS CC/CV charger, the connector and wiring harness, ingress protection, bearings with ISO 281 L10, the stem and folding mechanism, the deck, the handgrip + lever + throttle, the wheel as an assembly, fastener engineering as a joining-axis, thermal management as the heat-dissipation cross-cutting axis, and EMC/EMI as the interference-mitigation cross-cutting axis. These 20 engineering axes described individual subsystems, the means of joining, the means of dissipating heat, and the means of coexistence of electromagnetic fields — but none of them addressed the means by which trust is established between subsystems, which permeates every layer of communication simultaneously and requires every interface to carry cryptographic proofs of authenticity, integrity, and confidentiality.
A modern e-scooter is a connected device with at least five potential attack surfaces: a BLE display that pairs with the user’s smartphone (Bluetooth Core 5.4); a smartphone app that communicates with the brand’s cloud server via TLS/HTTPS; an OTA firmware update channel that downloads signed images to the motor controller and BMS; a GPS receiver (in shared-fleet models) that consumes unauthenticated GNSS signals; and a smart-battery handshake between charger/BMS and controller that authenticates a genuine battery via challenge-response. Each of these channels is a point of entry for an attacker: BLE pairing in Just Works mode permits a MITM (man-in-the-middle) attack; HTTPS without certificate pinning in the mobile app permits TLS interception; an OTA without signature verification permits firmware substitution; a GPS without OSNMA authentication permits spoofing to steal fleet units; a smart battery without proper challenge-response permits a counterfeit pack with a modified BMS that disables thermal limits.
This is the twenty-first engineering-axis deep-dive in the guide series — and the fourth cross-cutting infrastructure axis (parallel to fastener engineering as the joining-axis, thermal management as the heat-dissipation axis, and EMC/EMI as the interference-mitigation axis). It describes the means by which trust is established between subsystems and which is present in every previous engineering axis: the BLE display exchanges data with the throttle; OTA update rewrites controller firmware; the mobile app reads battery state; the cloud server dictates speed limits by geofence; the smart charger authenticates to the BMS. The cybersecurity task is to quantify the threats, engineer the mitigation (secure boot, signed firmware, mutual TLS, LE Secure Connections, anti-rollback, HSM), and prove compliance under regulatory frameworks (UNECE R155/R156 for type-approval, EU Cyber Resilience Act for market access, ETSI EN 303 645 for consumer-IoT presumption).
A note on the PLEV (Personal Light Electric Vehicle) context: the e-scooter is not in the scope of UNECE R155 in Europe (that covers L-category vehicles and heavy-duty M/N), but it is in the scope of the EU Cyber Resilience Act 2024/2847 (Regulation EU 2024/2847, adopted on 23 October 2024) as a “product with digital elements,” with manufacturer obligations fully applicable from 11 December 2027 and vulnerability reporting obligations from 11 September 2026. ETSI EN 303 645 V3.2.0:2024-12 is already a mandatory presumption-of-conformity for consumer IoT and covers the e-scooter as a “connected consumer product.” In the US, EO 14028:2021 governs federal procurement, the NIST IoT Cybersecurity Improvement Act 2020 (PL 116-207) applies, and the CTIA IoT Cybersecurity Certification Program acts as a voluntary baseline.
1. Why cybersecurity is a separate cross-cutting axis
Cybersecurity is not “just HTTPS and encrypted BLE”. It is a system in which every element has quantified engineering specifications:
| Element of the cybersecurity system | What it describes | Governing standard |
|---|---|---|
| Threat model | List of assets, threat-actors, attack vectors, impacts; formalizes what is to be protected and from whom | ISO/SAE 21434:2021 § 8 TARA, NIST SP 800-30, STRIDE/PASTA methodology |
| Secure boot chain | Hardware-rooted trust → bootloader signature → kernel signature → app signature; chain with no broken links | NIST SP 800-193 Platform Firmware Resilience, ARM Trusted Firmware-M |
| Cryptographic primitives | Algorithm + key length + mode (AES-256-GCM, ECDSA P-256, RSA-3072, Ed25519, ChaCha20-Poly1305) | NIST SP 800-131A Rev 2 (transitions), BSI TR-02102 (German baseline) |
| Communication channel | TLS 1.3 with an AEAD cipher suite; certificate pinning on the client; mutual authentication; perfect forward secrecy | RFC 8446 TLS 1.3, RFC 7525 BCP TLS, ETSI TS 103 523-3 mTLS |
| Update mechanism | Signed image + anti-rollback counter + A/B partition + secure fallback; CDN with integrity check | ISO/SAE 24089:2023, IETF SUIT (Software Updates for IoT) RFC 9019/9124 |
| Vulnerability handling | RFC 9116 security.txt + Coordinated Vulnerability Disclosure + CVE-numbering + 90-day fix window | ISO/IEC 29147:2018, ISO/IEC 30111:2019, FIRST.org PSIRT framework |
No element is “secure by default”. A BLE pairing in Just Works mode (Bluetooth Core 5.4 § 3.5.1.2) is null-authentication: any attacker within 10 m can impersonate the second device and establish an authenticated-encrypted link without any crypto-proof for the legitimate parameter (this is specification-allowed for devices without a display or keyboard). The same BLE pairing with Numeric Comparison (a 6-digit confirmation on both devices, ECDH P-256 key-exchange under the hood) is MITM-resistant at a 10⁻⁶ random-guess probability. A 20+ orders-of-magnitude difference in security level from a single pairing-method choice — that is the characteristic “leverage” of cybersecurity engineering.
If OTA-update is designed as “HTTP-download URL + flash directly to controller,” any attacker in MITM-position (a compromised Wi-Fi at a café, a BGP-hijack at the ISP-level, DNS-poisoning on a router) can replace firmware payload and install custom firmware with a modified speed-limit, a deactivated brake failsafe, or a backdoor. The same OTA with a digital signature verification (Ed25519 against a factory-burned public key + AES-256-CTR encrypted payload + a monotonic anti-rollback counter) is cryptographically locked: an attacker without the manufacturer’s private key cannot forge a valid signed image, even with full network MITM. This is the analog of torque-spec in fastener engineering: electrically it fits, security-wise — it does not.
2. Overview of the 10-row standards matrix
E-scooter cybersecurity is governed by ten core standards. Some are horizontal regulation (EU CRA, UNECE), others are baseline assurance for consumer IoT (ETSI EN 303 645), still others are vehicle-specific engineering processes (ISO/SAE 21434/24089), and a fourth group covers technical primitive specs (Bluetooth Core, IEEE 802.11i, NIST SP 800-193):
| # | Standard | Edition | Scope | What it covers |
|---|---|---|---|---|
| 1 | ETSI EN 303 645 | V3.1.3:2024-09 | Consumer IoT baseline | 13 provisions: no default password, vulnerability disclosure (RFC 9116), keep updated, secure storage, secure communication, minimize attack surface, software integrity, personal data, system resilience, telemetry monitoring, easy delete user data, easy installation, validate input |
| 2 | ISO/SAE 21434 | 2021 | Road vehicles — Cybersecurity engineering | Cybersecurity life cycle (concept → development → production → operations → decommissioning), TARA threat analysis + risk assessment, CAL Cybersecurity Assurance Level, cybersecurity claims and goals |
| 3 | ISO/SAE 24089 | 2023 | Road vehicles — Software update engineering | Update package authentication, integrity, rollback, A/B partition, secure update channel, update logging, recovery procedures |
| 4 | UNECE R155 | 2021 (entry 2021-01-22; mandatory for new types 2022-07; new registrations 2024-07) | Cyber Security and CSMS (Cyber Security Management System) | Vehicle type-approval requirement (M/N/O/L6/L7 categories): certified CSMS process + per-vehicle-type cybersecurity engineering. L-category PMD / L1e-A powered cycles — not in scope; e-scooter classified as PMD (non-vehicle) also out of UNECE WP.29 scope |
| 5 | UNECE R156 | 2021 (paired with R155) | Software Update and SUMS (Software Update Management System) | Companion to R155: SUMS process certification + per-update technical compliance |
| 6 | EU Cyber Resilience Act 2024/2847 | Regulation 2024-10-23 | Products with Digital Elements (PDEs) — horizontal | Essential cybersecurity requirements + Annex I/II/III; manufacturer obligations: SBOM, vulnerability handling, security update support ≥5 years; entry into force 2024-12-10; reporting obligations 2026-09-11; full applicability 2027-12-11 |
| 7 | NIST SP 800-193 | 2018 | Platform Firmware Resilience Guidelines | Three pillars: Protection (signed firmware + integrity check), Detection (corruption detect at boot), Recovery (golden-image fallback to known-good state); Root of Trust (RoT) hardware-anchored |
| 8 | IEC 62443-4-1 | 2018 (+ Amd 1:2023) | Industrial automation — Secure product development lifecycle | 8 practice categories: security management, specification of security requirements, secure by design, secure implementation, security verification + validation, defect management, update management, security guidelines |
| 9 | Bluetooth Core Specification 5.4 | 2023-01 (5.4); 5.4 widely deployed; 6.0:2024-08 future | BLE pairing + encryption + addressing | LE Secure Connections (ECDH P-256), Numeric Comparison, Passkey Entry, OOB; LTK/IRK key hierarchy; Resolvable Private Address (RPA) anti-tracking |
| 10 | IEEE 802.11i / 802.11-2020 + WPA3 | 2020 (802.11-2020); WPA3 cert 2018 | Wi-Fi WPA3-Personal SAE Dragonfly | Simultaneous Authentication of Equals (SAE) Dragonfly handshake — replaces WPA2-PSK 4-way handshake; offline-dictionary-attack resistant; mandatory in Wi-Fi 7 (802.11be) for new certifications |
Additional standards of the second circle: NIST SP 800-183 Networks of Things (IoT architecture); ISO/IEC 27001:2022 (information security management); ISO/IEC 29147:2018 vulnerability disclosure; ISO/IEC 30111:2019 vulnerability handling; OWASP IoT Top 10 (2018) and OWASP Mobile MASVS L1/L2:2024 for the mobile-app component; RFC 9116:2022 security.txt; RFC 9019 and RFC 9124 IETF SUIT (Software Updates for IoT); the US EO 14028:2021 federal SBOM requirement + NTIA Minimum Elements for SBOM 2021-07; the UK PSTI Act 2022 consumer connectable products; CTIA IoT Cybersecurity Certification Program 2.0:2022 as a US voluntary baseline.
3. The e-scooter attack surface — 7 localized sources
A modern e-scooter in typical use (paired display, active GPS, charging via fleet app, OTA update channel) has seven localized attack surfaces:
| # | Attack surface | Channel | Mechanism | Typical exposure | Mitigation tier |
|---|---|---|---|---|---|
| 1 | BLE pairing and session | Bluetooth 4.0/5.x LE | Just Works MITM, KNOB downgrade (CVE-2019-9506), BIAS impersonation (CVE-2020-10135), BLURtooth cross-transport key derivation (CVE-2020-15802), BLESA reconnection spoofing (CVE-2020-9770) | 10 m in open space, 5-7 m through walls | LE Secure Connections + Numeric Comparison; reject legacy pairing |
| 2 | Motor controller firmware | JTAG/SWD debug pins, USB DFU mode, UART console | Physical probe → dump flash; firmware extraction → reverse-engineering speed-cap/brake-cut; modified firmware re-flash | Open chassis required; 5-30 minutes | eFuse-disabled JTAG, secure boot with RoT in SoC, encrypted flash |
| 3 | Mobile app ↔ cloud TLS | HTTPS REST / WebSocket / MQTT-TLS | TLS interception via Burp Suite + custom CA pinned on a rooted phone; broken certificate pinning; weak cipher suites; JWT alg=none | Compromised Wi-Fi (café, airport), DNS poisoning, BGP-hijack | TLS 1.3 mandatory + certificate pinning + mTLS + JWT verify exp+aud+iss |
| 4 | OTA update channel | Direct HTTPS download or via mobile-app proxy | Image substitution if no signature; rollback to a vulnerable version if no anti-rollback; replay of a valid-but-old image | Any-network MITM position | Ed25519/ECDSA P-256 signed images + monotonic anti-rollback counter + chunk-level hash verification |
| 5 | GPS / GNSS receiver | L1 1575.42 MHz + L5 1176.45 MHz; Galileo E1/E5; GLONASS L1OF | Spoofing — SDR transmits @ < 100 mW with false ephemeris → receiver tracks spoofed position; meaconing — capture-and-replay; jamming | 10-100 m for consumer-grade SDR (HackRF, BladeRF) | Galileo OSNMA navigation message authentication; multi-constellation receivers; RAIM consistency check |
| 6 | Smart battery / BMS handshake | I²C / 1-Wire / SMBus / proprietary | Counterfeit battery without authentication → BMS-bypass → controller accepts overdischarge / overcurrent; battery emulator board $20 commodity hardware | Open scooter, replace battery in 5-10 minutes | Challenge-response authentication (e.g., Maxim DS28C36, NXP A1006, Microchip ATSHA204A); per-pack unique key |
| 7 | Fleet management API | HTTPS / OAuth 2.0 / Bearer JWT | IDOR (Insecure Direct Object Reference) — incrementing scooter_id; broken access control: rider role can call admin endpoints; rate-limit bypass to enumerate fleet; GBFS/MDS public feeds leak GPS in real-time | Any internet-connected client | Per-resource ABAC authorization + rate-limit by token + replay-protection nonce + OWASP API Top 10 verification |
The Maxwell-connection for cybersecurity: authentication and confidentiality are an assertion against an adversary, not against thermal noise. Unlike EMC, where a “passive environment” creates statistical interferences, in cybersecurity the attacker is an active intelligent adversary who adapts the attack to the defense. Statistical margins therefore do not apply: ~ “10⁻⁶ probability of brute-force success” turns into “0 % success” if the attacker has an oracle-feedback (timing side-channel, error-message verbosity, partial decryption). That is the fundamental basis of threat modeling: estimate risk not from a typical user, but from a worst-case adversary with known TTPs (Tactics, Techniques, Procedures per MITRE ATT&CK + MITRE D3FEND).
4. Bluetooth pairing — methods and MITM-resistance
The Bluetooth Core Specification 5.4 defines four LE pairing methods (Part H § 2.3.5) with fundamentally different security levels:
| Method | IO Capability | MITM protection | Eavesdropping protection | E-scooter applicability |
|---|---|---|---|---|
| Just Works | NoInputNoOutput | No | Yes (via ECDH in LE SC) | Cheap budget displays without a UI — a fail-mode for security |
| Passkey Entry | KeyboardOnly or DisplayOnly | Yes (6-digit pin = 10⁻⁶ random) | Yes | Display shows a passkey, user enters it in the app — standard for a consumer scooter |
| Numeric Comparison | DisplayYesNo | Yes (6-digit confirm = 10⁻⁶ random) | Yes | Display shows a number, phone shows a number, user confirms identical — highest-security for consumer |
| Out of Band (OOB) | NFC, QR code | Yes (entropy from OOB channel) | Yes | NFC tap on charger, QR on handlebar — flagship and shared-fleet models |
LE Legacy Pairing (BT 4.0/4.1, before BT 4.2) uses STK derivation based on a TK (Temporary Key), which in Just Works equals 0x00..00 (all zeros). This is passive-decryptable with an off-the-shelf BLE sniffer (Ubertooth One, nRF52840 sniffer dongle). LE Secure Connections (BT 4.2+) uses ECDH P-256 key agreement → 128-bit LTK derivation → AES-128-CCM for link encryption. This is passive-secure even against a MITM attempt without user confirmation.
A provisional pattern for an e-scooter manufacturer: a BLE display with an OLED screen that shows a 6-digit confirm-code → Numeric Comparison (DisplayYesNo on the scooter side, KeyboardDisplay on the phone side). This is the toughest baseline for a consumer device without OOB hardware.
The KNOB attack (CVE-2019-9506) exploits BR/EDR (Bluetooth Classic, not LE) downgrade of entropy in key negotiation to 1 byte (8 bits). An e-scooter that uses only LE is immune to KNOB. But if the manufacturer added Bluetooth Classic for audio streaming to a helmet — it is potentially vulnerable to KNOB on pre-2020 firmware.
The BIAS attack (CVE-2020-10135) bypasses authentication via impersonation during BR/EDR reconnection. Patched in Bluetooth 5.1+ and paired-device-list verification. Does not affect LE.
BLESA (CVE-2020-9770) is an exploit on the BLE reconnection sequence where the bonding info on a peripheral can be impersonated by the central. Patched in Bluetooth Core 5.2+ and Android 11+/iOS 14.4+. On an e-scooter it is resolved reactively via firmware update.
5. Secure boot chain — trust chain from HW RoT
Secure boot is a cryptographically-attested chain from a hardware Root of Trust (RoT) to the user-mode application. NIST SP 800-193 formalizes three pillars: Protection (firmware cannot be modified without signature), Detection (corruption detected at boot), Recovery (golden-image fallback to a known-good state).
Layered secure boot for a motor controller (STM32 / ESP32 / Nordic nRF52):
[HW eFuse fixed public key (RoT)]
|
v
[BootROM verifies bootloader signature] — factory BootROM, immutable
|
v
[Bootloader verifies kernel/RTOS signature] — first-stage bootloader in flash
|
v
[Kernel/RTOS verifies application signature] — e.g., FreeRTOS + signed FW
|
v
[Application loads]
If any link fails — boot halts or falls back to the golden image. This blocks:
- Firmware downgrade to a vulnerable version (anti-rollback monotonic counter checking).
- Replacement firmware from a stolen private key (revocation list via update channel).
- Glitching attack that skips a signature-check instruction (redundant check + jump-into-checked-region).
Hardware-anchored RoT options for an e-scooter SoC:
- eFuse (one-time-programmable bits) — STM32 RDP Level 2, ESP32 secure boot V2 eFuse mode, nRF52 access port protect. Cost: free (built-in), but irreversible.
- Dedicated Secure Element — Microchip ATECC608B ($1-2), NXP A1006 / SE050 ($2-5), STSAFE-A110. Crypto accelerator + tamper-resistant key storage; communication via I²C.
- TPM 2.0 — overkill for an embedded e-scooter, but possible on a Linux-based fleet-management gateway.
- ARM TrustZone / OP-TEE — for SoCs of the Cortex-A class (shared-fleet models with a 4G modem and Linux).
Cost trade-off: an eFuse-only secure boot is free but a single failure (one leaked private key) compromises the entire fleet. SE-based secure boot adds $1-5 BoM cost per scooter, but provides per-device key isolation and tamper-resistant storage. Industry trend 2024-2026: budget consumer models rely on eFuse + OS-level controls; flagship and shared-fleet models use a dedicated SE because of the risk of a ransomware-style attack on a single private key triggering a recall.
6. OTA updates — signed images, anti-rollback, A/B partition
ISO/SAE 24089:2023 formalizes software update engineering for road vehicles, and its patterns are applicable to PMDs as best practice. Baseline requirements:
| # | Requirement | Mechanism | Failure mode without it |
|---|---|---|---|
| 1 | Authentication | Image signed with manufacturer private key (Ed25519 / ECDSA P-256); device verifies with burned public key | Attacker substitutes firmware on the download channel |
| 2 | Integrity | SHA-256 / SHA-3 hash on signed payload; chunk-level hash per 4-32 KB block | Partial download / network corruption flashes corrupted firmware |
| 3 | Confidentiality | AES-256-CTR encrypted payload (optional) — hides reverse engineering from competitor / attacker | Attacker reverses firmware to find vulnerabilities |
| 4 | Anti-rollback | Monotonic counter in OTP / eFuse / SE; image carries min-version field; device rejects image with version < counter | Attacker installs old vulnerable firmware to exploit a known CVE |
| 5 | Atomicity | A/B partition (dual-bank flash); flash new image into the inactive bank; on successful boot — set inactive→active; on failure — revert | Power loss during flash bricks the scooter |
| 6 | Recovery | Golden image on a read-only partition; fallback if both A and B are corrupted; secure boot validates | Single point of failure — a bricked scooter requires a repair-center re-flash |
| 7 | Authorization | User consent for install; admin-override only for safety-critical (recall); pause/postpone option | Forced update at an inopportune time (mid-ride) |
Frameworks for OTA implementation:
- Mender — open-source A/B robust update for Yocto/Buildroot Linux. Free for self-hosted; commercial $1000+/year managed cloud.
- SWUpdate — Linux Foundation project, script-driven update, ASYM-key support.
- OSTree / RAUC — atomic OS-tree updates, A/B partition management.
- Uptane — TUF-derived (The Update Framework) for road vehicles; developed by USDOT. Multi-role signing (root, targets, snapshot, timestamp) — protects against key compromise via role separation.
- IETF SUIT (Software Updates for IoT) — RFC 9019 (architecture), RFC 9124 (manifest specification). Targeted at constrained devices (e-scooter controller with 256 KB RAM).
A realistic timeline for an e-scooter manufacturer:
- 2018-2020 era: unsigned firmware, USB DFU via service center, no anti-rollback. Vulnerable to all 7 failure modes above.
- 2021-2023 era: signed firmware, manual install via mobile app, no A/B (single bank), basic anti-rollback. Improvement, but bricked-on-power-loss risk.
- 2024-2026 industry baseline: signed + A/B + anti-rollback + chunk-hash. Flagships move to Uptane-style multi-role.
- 2027+ (post-CRA enforcement): SBOM mandatory per release; CVE tracking; 5-year mandatory support post-product-line-EoL.
7. EU Cyber Resilience Act — timeline and manufacturer obligations
Regulation EU 2024/2847 (Cyber Resilience Act) is a horizontal EU regulation covering all products with digital elements (PDEs) with market access in the EU. An e-scooter with a firmware-controlled motor + BLE display + mobile-app integration is unambiguously in scope as a PDE with “indirect or direct logical or physical data connection to a device or network.”
Key dates:
| Date | Event |
|---|---|
| 2024-10-23 | Adoption by the Council of the EU |
| 2024-12-10 | Entry into force (Official Journal publication 2024-11-20 + 20 days) |
| 2026-09-11 | Reporting obligations applicable — manufacturers obliged to notify ENISA about actively-exploited vulnerabilities ≤24 h + final report ≤14 days |
| 2027-12-11 | Full applicability — all CRA-essential requirements in force for new products on the market |
Product classes (per Annex III):
- Default class (~90 % of products, including e-scooters): self-assessment with an internal SDLC. CE mark on the basis of manufacturer DoC.
- Class I (Important PDEs): third-party notified-body conformity assessment for categories with elevated risk (smart meters, baby monitors, smart-home alarms).
- Class II (Highly important — Annex IV): mandatory third-party assessment (industrial control, smart cards).
Manufacturer obligations (for default class — applicable to an e-scooter brand):
- SBOM (Software Bill of Materials) — mandatory, in SPDX or CycloneDX format. Enumeration of all 3rd-party libraries with versions and licenses.
- Vulnerability handling process — policy + contact (RFC 9116 security.txt), CVD acceptance, CVE numbering.
- Security update support — mandatory 5-year support for security patches (default support period; sectoral acts may extend / reduce).
- Reporting — actively-exploited vulnerabilities to ENISA + national CSIRT ≤24 h, severe incidents ≤72 h.
- Risk assessment — documented threat model during the design phase.
- EU Declaration of Conformity — explicit reference to Annex I (Essential requirements) + Annex II (Information and instructions).
- CE mark on product — after successful self-assessment process.
Non-compliance consequences: market surveillance authorities (BSI, BNetzA, ANSSI) can withdraw the product from the market, impose fines up to €15 M or 2.5 % global revenue (whichever is higher), and public listing in Safety Gate.
Implication for an e-scooter brand: by 2027-12-11 they must implement: signed firmware, secure boot, vulnerability reporting (security.txt), an SBOM per release, a 5-year security-support commitment, and threat-model documentation. This is a fundamental shift from the 2018-era “ship and forget” model.
8. ETSI EN 303 645 — 13 provisions consumer-IoT baseline
ETSI EN 303 645 V3.1.3:2024-09 is the most-cited consumer-IoT cybersecurity standard in Europe. The structure is defined by 13 provisions (previously 13 in V2.1.1; V3.1.3 increased granularity in sub-clauses):
| # | Provision | Applicability to an e-scooter |
|---|---|---|
| 1 | No universal default passwords | BLE pairing PIN must NOT be hardcoded “888888” / “0000” / “1234” — must be unique per device or user-configurable |
| 2 | Implement a means to manage reports of vulnerabilities | security.txt (RFC 9116) on the manufacturer website + dedicated security@ email + public-facing CVD policy |
| 3 | Keep software updated | Firmware updateable via OTA + clear support-period communication + auto-update opt-in |
| 4 | Securely store sensitive security parameters | Pairing keys + cryptographic secrets in secure storage (eFuse, SE) — not in plain flash |
| 5 | Communicate securely | BLE LE Secure Connections, TLS 1.3 for cloud API, mutual TLS for fleet management |
| 6 | Minimize exposed attack surfaces | Disable JTAG/SWD on production via eFuse; close unused TCP/UDP ports; remove debug console |
| 7 | Ensure software integrity | Secure boot + signed firmware + anti-rollback |
| 8 | Ensure that personal data is protected | GDPR compliance: encrypt PII at rest, minimize collection (rider biometrics not stored), data portability |
| 9 | Make systems resilient to outages | Local degraded mode if cloud unavailable — basic ride functions work without internet |
| 10 | Examine system telemetry data | Anomaly detection in telemetry — sudden firmware-version change, geographic relocation outside fleet area |
| 11 | Make it easy for users to delete user data | “Factory reset” button in app → wipes all PII + paired devices + GPS history |
| 12 | Make installation and maintenance of devices easy | Clear pairing instructions, no special tools required for non-security operations |
| 13 | Validate input data | Sanitize input on BLE GATT writes, mobile app, OTA payload — prevent buffer overflow / injection |
Compliance pathway: SDoC (Supplier’s Declaration of Conformity) + technical-file evidence per provision; self-assessment is sufficient (no third-party lab required). In the EU — presumed compliance with the low end of CRA “essential requirements” if the product conforms to EN 303 645.
Industry adoption status (Mar 2026):
- TÜV SÜD, TÜV Rheinland issue EN 303 645 certificates for e-scooter brands as a voluntary differentiator.
- Singapore CSA Cybersecurity Labelling Scheme (CLS) — mandatory star-rating based on EN 303 645 for consumer IoT (e-scooter inclusion under review).
- Finland Cybersecurity Label (Traficom) — voluntary, based on EN 303 645.
- UK PSTI Act 2022 (effective 2024-04) — mandates EN 303 645-aligned requirements for connectable products including e-scooter.
9. ISO/SAE 21434 TARA — threat analysis for PMDs
ISO/SAE 21434:2021 is developed for road vehicles (cars, trucks, motorcycles), but the TARA methodology (Threat Analysis and Risk Assessment, § 8) is universally applicable and is used by PMD manufacturers as best practice.
6-step TARA process:
- Item definition — describe what is being protected. For an e-scooter: motor controller, BMS, mobile app, fleet API, GPS receiver, BLE display.
- Asset identification — cybersecurity properties of each element (CIA triad + Authenticity + Authorization + Non-repudiation).
- Threat scenario identification — STRIDE methodology (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) per asset.
- Impact rating — Safety / Financial / Operational / Privacy (S/F/O/P) impact on a 4-level scale (Negligible / Moderate / Major / Severe).
- Attack feasibility rating — Elapsed time + Specialist expertise + Knowledge of item + Window of opportunity + Equipment (CEM-derived); 4 levels (Very Low → High).
- Risk determination — matrix of impact × feasibility; output Risk treatment (avoid / reduce / share / retain) and a per-risk Cybersecurity Goal.
Example TARA for a BLE-display attack vector:
- Item: BLE display paired with a mobile app with a throttle-control endpoint.
- Asset: Authenticity of throttle commands (CIA-extended).
- Threat scenario: Attacker in MITM position injects throttle = max command mid-ride.
- Impact: Safety = Severe (rider may be thrown by unexpected acceleration); Financial = Moderate; Operational = Moderate; Privacy = Negligible.
- Attack feasibility: Elapsed time = Days, Specialist expertise = Layman++, Knowledge of item = Public, Window = Limited (during BLE connection), Equipment = Standard → Medium feasibility.
- Risk: Severe × Medium = High risk → Cybersecurity Goal: BLE display must use LE Secure Connections with Numeric Comparison; throttle commands authenticated per message (HMAC over command + counter); replay protection via monotonic counter.
CAL (Cybersecurity Assurance Level) — a 4-level scale (CAL 1-4) for assurance rigor:
- CAL 1: low-impact items, basic testing.
- CAL 2: moderate-impact, structured testing.
- CAL 3: high-impact items (e.g., throttle control), formal verification + penetration testing.
- CAL 4: safety-critical (e.g., brake-by-wire), independent assessment + extensive testing.
E-scooter throttle and brake control — typically CAL 3; BLE display and mobile app — CAL 2; non-safety telemetry (mileage display) — CAL 1.
10. Real-incident matrix — 6 documented cases
E-scooter cybersecurity incidents are well documented in research literature and disclosure databases:
| # | Incident | Year | Mechanism | Disclosure | Mitigation deployed |
|---|---|---|---|---|---|
| 1 | Xiaomi M365 BLE anti-lock bypass | 2019 | Default BLE PIN ‘88888888’ + GATT-write to lock-control characteristic without authentication; researcher Zimperium (Rani Idan) demonstrated unlock + max-speed-set + anti-theft bypass over 100 m | Feb 2019 public disclosure; Xiaomi released firmware patch with proper pairing | Pairing PIN mandatory; GATT-write requires authenticated session |
| 2 | Xiaomi M365 firmware downgrade tool | 2018-2020 | “M365 X-Engineering” / “M365 Downg” tool — unsigned firmware re-flash via USB DFU, removes 25 km/h speed cap up to 35-40 km/h; also opens privilege escalation due to debug mode | Public tool, community-distributed; never officially patched (unsigned firmware accepted by bootloader) | M365 successors (Pro 2, 4 Pro, Mi Lite) have signed firmware + anti-downgrade |
| 3 | Lime BLE replay attack | 2019 | BLE-protocol session keys not properly rotated; replay valid unlock-command to unlock without active rider authorization; researchers presented at Hack-in-the-Box 2019 Amsterdam | Coordinated disclosure with Lime PSIRT 2019; Lime updated firmware over fleet 2019-Q3 | Per-session ECDH key + monotonic counter + cloud-side ride state machine |
| 4 | Bird API IDOR (Insecure Direct Object Reference) | 2020 | Mobile-app REST API endpoints accepted incrementing scooter_id values without an ABAC check; researcher could unlock any scooter in fleet by enumerating IDs | Disclosed 2020 via bug bounty; Bird patched within 30 days | ABAC authorization per resource + rate-limiting + anti-enumeration UUID identifiers |
| 5 | Ninebot ES1/ES2/ES4 BLE pwd ‘888888’ vulnerability | 2019-2020 | Segway-Ninebot ES series shipped with factory-default BLE PIN ‘888888’; many users never changed it; attacker within BLE range could pair without user interaction | Public disclosure community-driven; Ninebot updated default-PIN policy in firmware updates and provisioning | Unique per-device PIN printed under deck; mandatory user-set on first pair |
| 6 | Tier / Voi unauthorized unlock (Apollo CTF 2022) | 2022 | Researchers from Apollo Lab demonstrated unlock chain combining BLE replay + mobile-app TLS-pinning bypass + GPS spoofing for relocation | Coordinated disclosure 2022-Q2; both operators patched within 60 days; published Apollo Lab whitepaper | TLS 1.3 + certificate pinning + JWT short-lived (5 min) + GPS plausibility check on cloud-side |
Additional historical patterns:
- Hoverboard CVE catalogue 2018: dozens of CVE-2018-xxxx entries for budget hoverboards with hardcoded BLE PINs, no firmware signature, exposed JTAG. NIST NVD catalogue 2017-2019 era.
- Boosted board controller hack (2017-2019): community modified controller firmware; manufacturer (Boosted) shut down 2020 partially due to liability concerns from unsanctioned firmware mods causing battery fires.
- Inmotion BLE hijack (Black Hat USA 2019): researcher demonstrated paired-device hijacking on Inmotion P1F via a legacy BLE pairing weakness.
Industry response: top brands (Segway-Ninebot, Xiaomi, Apollo, Dualtron) in 2024-2026 models standardly implement: LE Secure Connections, signed firmware + A/B partition, mobile app with certificate pinning, BLE PIN unique-per-device. This reduces the incident-rate of published cases by ~70-80 % vs the 2018-2020 era, but residual vulnerabilities remain in budget and older inventory.
11. Mitigation matrix — 6 typical means
Six core mitigation techniques on an e-scooter cover 90 % of cybersecurity tasks:
| # | Mitigation | How it works | Where it applies | Crypto baseline |
|---|---|---|---|---|
| 1 | LE Secure Connections + Numeric Comparison | ECDH P-256 key exchange + 6-digit confirm on both sides; MITM-resistant 10⁻⁶ | BLE display pairing with mobile app; helmet audio link | ECDH P-256 (FIPS 186-4) |
| 2 | Mutual TLS with certificate pinning | Client and server cross-verify X.509 certs; client pins server cert hash (SHA-256) | Mobile app ↔ cloud API; fleet-management gateway ↔ cloud | TLS 1.3 (RFC 8446) + ECDSA P-256 / Ed25519 |
| 3 | Secure boot with RoT | HW eFuse public key → bootloader signature → kernel signature → app signature chain | Motor controller MCU, BLE display SoC, BMS MCU | Ed25519 / ECDSA P-256 (NIST SP 800-186) |
| 4 | Signed firmware (OTA) | Image signature with manufacturer private key; device verifies before flash | OTA update channel for controller + BMS firmware | Ed25519 + SHA-256 hash chain |
| 5 | Anti-rollback monotonic counter | OTP / eFuse counter incremented on each signed update; rejects images with version < counter | OTA + secure boot integration | Monotonic counter in SE or eFuse |
| 6 | HSM / Secure Element | Tamper-resistant key storage + crypto accelerator; private keys never leave SE | Per-device unique key for authentication and pairing | Microchip ATECC608B / NXP A1006/SE050 / STSAFE-A110 |
Cost-benefit analysis for a consumer e-scooter manufacturer:
- LE Secure Connections: free (built-in to BT 4.2+ stacks). Mandatory baseline.
- mTLS + certificate pinning: low-cost (open-source libraries: BearSSL, mbedTLS, WolfSSL). Mandatory for cloud-connected models.
- Secure boot with eFuse-only: free (SoC built-in). Mandatory for signed firmware to be meaningful.
- Signed firmware + A/B partition: low-cost development (Mender/SWUpdate frameworks). Mandatory baseline.
- Anti-rollback in eFuse: free. Strongly recommended.
- HSM / Secure Element: $1-5 BoM cost per scooter. Recommended for fleet and flagship; optional for budget consumer.
Vulnerability disclosure layer (supplements mitigation): RFC 9116 security.txt on a manufacturer website (e.g., https://example.com/.well-known/security.txt) — this is an organizational mitigation that lets researchers safely report findings before they publish — economically vital for the manufacturer (a single 0-day public-drop costs a recall of $millions; coordinated disclosure costs a bug-bounty payout of $1-10K).
12. DIY 8-step security check
The owner can run an 8-step security check in 30-40 minutes without specialized hardware — only with a smartphone, a BLE-scanner app, and access to the manufacturer website:
- Check default BLE PIN — in the app pair-flow check whether it requests a unique-per-device PIN (printed under the deck or in the manual). If a default ‘1234’ / ‘0000’ / ‘888888’ is accepted — fail provision 1 of EN 303 645.
- Verify HTTPS in the mobile app — install Burp Suite or mitmproxy with custom CA installed on the phone; intercept app traffic. If the app accepts a modified TLS certificate without warning — no certificate pinning (fail provision 5).
- Check OTA channel — in the app trigger a firmware update; observe network traffic. URL must be HTTPS; payload must carry a signature (look for a
.sigfile accompanying the.bin). HTTP-only OTA — critical fail. - Vulnerability disclosure presence — visit https://
/.well-known/security.txt. RFC 9116-compliant file with a Contact field — pass provision 2. 404 / missing — fail. - Privacy policy review — find the privacy policy in app settings; verify what personal data is collected (GPS coordinates, ride history, biometrics from helmet IMU). GDPR-compliant manufacturers list legal basis + retention period.
- Firmware version check — in app settings find the current firmware version + last update date. If older than 6 months and the manufacturer published a newer release — patch gap.
- Fleet API exposure — if the scooter is a fleet model (Lime/Bird/Tier/Voi local), check if the GBFS/MDS feed exposes per-vehicle telemetry publicly via a city API; if so, anonymization is required.
- Physical attack surface — open the battery compartment (with manufacturer permission / out of warranty); look for: exposed USB / UART pins, JTAG/SWD headers labeled, debug LED. A production unit with exposed debug — fail provision 6.
Pass criteria (rough): ≥6 of 8 → adequate baseline; ≤4 of 8 → high-risk product, consider an alternative brand.
13. DIY 6-step remediation
If the security check identified a problem, a 6-step remediation covers power-user mitigation without waiting for a manufacturer firmware update:
- Update the mobile app to the latest version — most mobile-app vulnerabilities (TLS, certificate pinning, JWT validation) are patched and released regularly. Enable auto-update.
- Update scooter firmware — in the app check for an available firmware update; install. If the manufacturer publishes through a dedicated tool (Xiaomi Mi Home, Segway-Ninebot Mobile, Apollo Power) — use it.
- Change default BLE PIN — in app settings find the pairing-PIN change option (if available). Set a 6-digit random PIN, not “123456” / date-of-birth.
- Disable fleet/sharing telemetry sharing (if personal scooter) — in app privacy settings opt out of telemetry sharing for analytics (not applicable to a shared-fleet scooter).
- Use unique passwords for cloud accounts — the manufacturer cloud account (Mi Account, Segway account) — should mandate 2FA; enable if available. Use a unique password through a password manager (NIST SP 800-63B).
- Subscribe to manufacturer security advisories — RSS / email subscription to the manufacturer security page. In the EU from 2026-09-11 — manufacturers are obliged to notify ENISA + national CSIRT; CSIRT advisories are often public.
Long-term: when buying a new scooter — filter by manufacturer security posture: presence of EN 303 645 certification (TÜV badge), 5-year security-support commitment, public security.txt, declared SBOM availability. This often correlates with overall product quality.
14. Case study — industry shift 2018→2026
Concrete cybersecurity-driven incidents for e-scooters are less visible to loud users than thermal-event recalls (because a cyber fail is rarely a fire risk), but documented enforcement actions and industry responses are well established:
- Xiaomi M365 2019 Zimperium disclosure included a live demo at Black Hat USA 2019: Zimperium researcher unlocked + accelerated victim’s scooter from 100 m distance using ANT_2 BLE-attack chain. Xiaomi released a firmware patch in September 2019 with proper authenticated GATT writes.
- FCC enforcement against unlocked hoverboard brands 2017-2018 — non-compliant BLE radios + no proper FCC ID + open firmware enabled unsanctioned modifications. FCC issued an advisory; customs began seizing non-compliant units.
- EU Cyber Resilience Act enforcement preview — after 2027-12-11 market-surveillance authorities (BSI, BNetzA, ANSSI) will start spot-auditing e-scooter brands on compliance: signed firmware, secure boot, security.txt, SBOM, 5-year support commitment. Brands without prerequisite engineering will face market withdrawal or €15M fines.
- Industry shift 2024-2026: top vendors (Segway-Ninebot, Xiaomi, Apollo, Dualtron, Hiboy, Vsett) standardly implement: LE Secure Connections as BLE default, signed firmware with anti-rollback, mobile-app TLS pinning, OTA signature verification, unique per-device BLE PIN (printed under the deck). This is partially driven by the EU CRA approaching its effective date + EN 303 645 voluntary certification differentiation.
- Shared-fleet operators evolution: Lime, Bird, Voi, Tier, Dott, Spin all moved to Uptane-style multi-role OTA from the 2021-2023 era after notable BLE-replay incidents. Fleet APIs hardened with OAuth 2.1 + DPoP token-binding, GDPR-compliant GBFS/MDS feeds with rider anonymization.
Cybersecurity engineering in the scooter industry is a preventive discipline: it avoids proxy incidents (unauthorized unlock + theft, modified firmware + speed-cap bypass + injury liability, BMS-counterfeit + thermal runaway). Regulatory incident rates remain lower than thermal (where failures are immediately visual and fire-related), but a cyber fail can cost a market withdrawal of an entire product line due to downstream effects of a single supply-chain compromise (e.g., a compromised OEM signing key — impacts 100k units at once).
15. Further reading in the guide series
Cybersecurity integrates with all previous engineering axes:
- SMPS CC/CV charger + IEC 62368 — smart-charger handshake with BMS, where cybersecurity ensures authentication.
- Connector + wiring harness — JTAG/SWD/UART debug pins that must be disabled in production.
- Display + HMI — BLE display as the primary user interface and attack surface for pairing.
- Motor and controller — firmware-controlled motor parameters, signed-firmware chain.
- Battery + BMS + thermal runaway — smart-battery handshake authentication, anti-counterfeit BMS challenge-response.
- Regulations by country — EU CRA, UK PSTI, US EO 14028 — country-specific cyber compliance frameworks.
- Fastener engineering — first cross-cutting infrastructure axis (joining).
- Thermal management — second cross-cutting infrastructure axis (heat dissipation).
- EMC/EMI — third cross-cutting infrastructure axis (interference mitigation).
- Anti-theft locks GPS parking — physical-layer security, complementary to the cyber layer.
Summary
10 key points on e-scooter cybersecurity engineering:
- Twenty-first engineering axis — Cybersecurity = fourth cross-cutting infrastructure axis after fastener=joining (DT), thermal=heat dissipation (DV), EMC=interference mitigation (DX). It describes the means by which trust is established between e-scooter subsystems.
- ETSI EN 303 645 V3.2.0:2024-12 — 13 consumer-IoT baseline provisions for the e-scooter as a “connected consumer product.” No default password (provision 1), vulnerability disclosure RFC 9116 (provision 2), secure communication (provision 5), software integrity (provision 7), input validation (provision 13) are the most relevant for a PMD.
- EU Cyber Resilience Act 2024/2847 entry into force 2024-12-10; reporting obligations 2026-09-11; full applicability 2027-12-11. Manufacturer obligations: SBOM, vulnerability handling, 5-year security support, CE-mark conformity assessment.
- 7 attack surfaces — BLE pairing (Just Works vs Numeric Comparison vs Passkey Entry vs OOB), motor controller firmware (JTAG/SWD/USB DFU), mobile app ↔ cloud TLS, OTA update channel, GPS receiver (spoofing), smart-battery BMS handshake, fleet management API (IDOR).
- Bluetooth Core 5.4 LE Secure Connections with ECDH P-256 — mandatory baseline instead of LE Legacy Pairing. Just Works → null-authentication; Numeric Comparison → 10⁻⁶ MITM resistance.
- Secure boot with RoT — hardware-anchored chain eFuse → bootloader → kernel → app. NIST SP 800-193 Protection-Detection-Recovery pillars. eFuse-only (free) vs Secure Element ($1-5) trade-off in per-device key isolation.
- OTA with 7 requirements: authentication (Ed25519 signed), integrity (SHA-256 chunked), anti-rollback (monotonic counter), atomicity (A/B partition), recovery (golden image), authorization (user consent), confidentiality (AES-256 encrypted, optional). Frameworks: Mender, SWUpdate, Uptane, IETF SUIT.
- 6 documented incidents 2018-2022: Xiaomi M365 BLE 2019, M365 firmware downgrade tool, Lime BLE replay 2019, Bird API IDOR 2020, Ninebot pwd ‘888888’ 2019-2020, Tier/Voi 2022. Pattern: default credentials + unsigned firmware + missing certificate pinning + IDOR.
- Industry shift 2024-2026 — flagship brands implement: LE SC, signed firmware A/B, mobile-app TLS pinning, OTA signature verification, unique per-device BLE PIN. EU CRA approaching effective date + EN 303 645 voluntary cert. Incident-rate reduction ~70-80 % vs the 2018-2020 era.
- DIY 8-step security check — default BLE PIN / HTTPS verify / OTA channel / security.txt presence / privacy policy / firmware version / fleet API exposure / physical debug pins. 30-40 minutes without special hardware. Pass criteria ≥6/8 = adequate baseline.