The growth of urbanization and technology has reshaped transportation, bringing about shared micro-mobility services like e-scooters and e-bikes as sustainable solutions for short urban trips, mitigating trafic and pollution issues. However, the rapid expansion of this market has outpaced the development of standardized security measures. Our research aims to analyze theoretically and empirically the security landscape of shared micromobility services, focusing on client components. We present a reference architecture and a detailed threat model to identify and address the most pressing security challenges. Additionally, we design a set of experiments to evaluate existing services and assess their security implementations. Finally, we propose guidelines and best practices to enhance the security of shared micro-mobility services, highlighting the need for a standardized security approach and ofering a foundation for future research.
Micro-mobility has recently emerged as a significant trend in urban transportation, characterized by
the use of lightweight electric vehicles such as e-scooters and e-bikes [
Despite their benefits, the rapid growth of shared micro-mobility services has introduced new security challenges, mostly due to integration with technologies such as GPS, GSM, and Bluetooth, along with their dependence on mobile applications, all of which significantly expand the attack surface. Additionally, the sharing framework requires the vehicles to be constantly accessible to the public, making it dificult to protect them from external threats.
While existing research has addressed general mobile or IoT security, it has largely overlooked the
micro-mobility context. Although these fields are akin to the main micro-mobility aspects, few studies –
none of them beyond the theoretical level – tackle the security challenges of the entire system. To the
best of our knowledge, the most comprehensive threat model available in the literature is [
This landscape lacks both a holistic study evaluating the system as a whole – rather than focusing on its individual components – and an experimental evaluation of the system and its real-world industry implementations. These gaps have resulted in the lack of domain-specific security guidelines designed for shared micro-mobility services.
In this work, we begin by slightly refining the reference architecture in [
With this research in the shared micro-mobility field, our contributions are: • The creation of a comprehensive threat model for the system, considering both cyber and physical threats • The evaluation of the security measures and architectural patterns currently implemented in the industry • The formulation of tailored guidelines aimed at enhancing the system’s security
This section provides an overview of the existing challenges and explores solutions in the two key areas relevant to this study: micro-mobility security and mobile application security.
Micro-mobility security area is far from being thoroughly explored, however, Vinayaga-Sureshkanth
et al. [
The first category is vehicle tampering, which could lead to firmware alterations [
Since our work focuses on the mobile ecosystem as the attack surface, we deem it necessary to present
some research in the areas of our interest. As opposed to micro-mobility security, mobile application
security is a well-studied field with many established guidelines and practical studies. OWASP [
Our work diferentiates from prior studies in shared micro-mobility security by employing a hands-on analysis methodology. While previous research, such as that by Vinayaga-Sureshkanth et al., proposed countermeasures for threats identified by theoretical studies, our approach starts with the observation and evaluation of the current security measures to retain efective practices and propose solutions for the identified weaknesses.
Building upon the existing studies, our threat model focuses on vulnerabilities imported into the system
by the presence of a mobile application. The first step (in Section 3.1) is to identify the components and
their way of communicating. Section 3.2 identifies assets and threat agents; subsequently Section 3.3
categorizes the threats using the STRIDE framework [
The shared micro-mobility system’s architecture contains three components: the electric vehicle, mobile application, and API server. A schematized version is presented in Figure 1.
Vehicle. Usually an e-scooter or an e-bike with a removable battery. It contains motion sensor, GSM, and GNSS modules. Some also communicate over short distances using BLE.
Mobile Application. The interface between the user and the system. It allows users to locate available vehicles, initiate and close rental sessions, and manage payment.
Server. Coordinates all the system’s operations and stores all the service’s data. It processes the clients’ requests and may act as an intermediary between the application and the vehicle.
With three components, only three communication channels are possible: server-app, server-vehicle, and app-vehicle. While observations show that the server always communicates with the other components, the application and vehicle do not communicate directly in all cases.
The communication between client and server uses HTTPS protocol to prevent MITM attacks. The vehicle usually employs a GSM module to report its position and receive commands. Any discussions regarding the content of this communication are hypothetical since our research focuses on the client application, leaving the direct analysis of this channel beyond our scope.
The presence of a communication channel between client and vehicle distinguishes the two
architectural approaches we observed in micro-mobility services: centralized and decentralized services.
Even though Vinayaga-Sureshkanth et al. [
(a) Centralized Architecture.
(b) Decentralized Architecture.
The diference between these two variations lies in the server’s role. In centralized architectures, the server acts as a broker while, in decentralized architectures, the server registers and responds to the client’s requests, then commands are relayed to the vehicle by the client itself.
Micro-mobility systems present valuable assets that can become targets for various security threats.
Key assets include the vehicle itself, susceptible to vandalism, theft, or tampering. User safety is at
risk, especially if an attacker interferes with vehicle operations, for example, by uploading malicious
ifrmware or damaging the vehicle itself [
Various threat agents can target these assets, each with specific motivations and capabilities. Cybercriminals may seek to steal data for ransom or resale and/or disrupt service operations. Competitors might try to damage reputation and service reliability with the goal of drawing users away. Illegitimate users bypass payment mechanisms, leading to revenue loss, while legitimate users may breach terms by misusing vehicles. Service providers might exploit collected data beyond its intended use while company employees, especially those with privileged access, pose an inside threat of data manipulation or tampering with the system’s behavior. Vandals, without specific motives, threaten the physical integrity of vehicles.
In our threat model, we use the STRIDE framework [
The vehicle is a key component of the micro-mobility system and presents important security challenges since anyone can physically access the target. While it is possible to mitigate some of the problems associated with this exposure, some threats cannot be completely mitigated.
The threats include potential spoofing attacks for the vehicle ( PS1) or its GPS location (PS2). Tampering poses further risks, with attackers altering firmware ( PT1), disrupting communication with the server (PT2) or the app (PT3), or modifying the vehicle’s hardware (PT4). Finally, DoS attacks like battery draining (PD1) or vehicle breakdowns (PD2) can cause the interruption of the service.
Cyber threats in micro-mobility systems present significant security challenges due to the widespread use of mobile applications and their inherent vulnerabilities. Spoofing can allow attackers to manipulate users’ GPS locations (CS1). Tampering risks involve malicious activities such as APK repackaging (CT1) or exploiting application vulnerabilities stemming from outdated libraries, weak cryptographic practices, or insecure code (CT2). Repudiation is another concern, as users may alter logs (CR1) or deny actions like ride creation (CR2). Information disclosure threats include a cyber-criminal extracting PII or tracking data from a device’s memory (CI1) as well as the provider company monitoring users even when the app is inactive (CI2). Denial of Service attacks can be performed by tricking the server into misinterpreting the status of vehicles’ battery (CD1), leading to service disruption. Lastly, elevation of privilege threats could enable attackers to access higher-level functions, such as unlocking vehicles without payment (CE1), thereby bypassing standard security and payment protocols.
Our approach to the analysis is composed of three steps: preliminary analysis, manual static analysis, and dynamic analysis. The preliminary analysis explores the sample of applications and employs automatic tools to identify the most common weaknesses and bad practices. The static analysis involves the manual inspection of the applications to detect diferent patterns in the service’s structure. Finally, dynamic analysis monitored a subsample applications’ runtime behavior and interaction with the other components of the system.
Our study focused on Android applications for several reasons. Android’s open-source nature, and
the possibility to install a rooted OS, make it particularly convenient for in-depth analysis. It is also
the most appealing target for cyber-criminals [
First, we selected a sample of highly downloaded micro-mobility rental applications from the Google Store. The initial exploration involved identifying each app’s main features and implementation technology.
We unpacked and decompiled APKs using JADX [
As outlined in Section 3.1, shared micro-mobility services can follow two distinct system architectures. This step aims to identify their average implementation structure and understand the diferences through manual static analysis.
The analysis starts by decompiling the native apps – twenty out of the original sample. This step mainly focuses on the model and controller components, which define the application’s internal logic. Moreover, we prioritized analyzing less obfuscated apps for a clearer understanding of the general micro-mobility apps’ structure, before diving into the most complex ones.
The next phase involves the examination of the API endpoints called by the client application. In doing so, we seek to understand the diferences in the server’s role, in both the diferent architectural designs, analyzing the set of functions ofered by the server.
Finally, for decentralized applications, the analysis concluded with the examination of the BLE communication between the app and the vehicle, to completely evaluate the whole communication chain that relays the commands from the server to the vehicles.
The sample consisted of real-world micro-mobility applications characterized by extensive features, sophisticated security measures, and detailed graphical interfaces. In 60% of the cases, this results in obfuscated codebases containing thousands of Java classes, many dedicated solely to graphical presentation. Therefore, static analysis alone is insuficient to fully comprehend the system, especially since the application has only partial knowledge of the system’s state. To address these limitations, we incorporated dynamic analysis techniques and integration testing.
Firstly, we monitor the applications’ communications and reconstruct the key sequences for the most common use case: purchasing a ride. This approach proved particularly valuable for highly obfuscated applications, where static analysis was less efective.
Finally, we conducted targeted field tests to address the verifiable threats outlined in Section 3.3 – more on this in Section 5.4. Given resource constraints, it was not feasible to examine all physical and digital threats. Instead, we prioritize the most critical threats centered on the client application.
To respect the boundaries of the applications in the sample, we restricted our testing to only the cyber threats CS1, CT1, CT2, CI1, CI2, and partially CE1. Moreover, we present the results in an anonymous form to avoid potential harm to the applications or their users.
The recent proliferation of micro-mobility applications provides a wide range of options for our study. We prioritized the most downloaded services in Europe and North America focusing on e-scooter shared mobility, which is the most prevalent market. The final sample includes Beam, Bird, Bit, Bolt, Bounce, Dott, Ginger, Goon, Helbiz, Jet, Lime, MVGO, Neuron, Ridemovi, Ryde, Skip, Spin, Superpedestrian, Tier, Voi, Whee, Wind, Yango, Yoio, and Zwings.
Our selection results in a sample of twenty-four applications, all ofering e-scooter rental, alongside other services (e.g., e-bike rental, ride-hailing, and food delivery). Out of the twenty-four analyzed applications, twenty are native Android apps, three are developed with Flutter, and one with React Native.
In the preliminary phase of the analysis, we test the whole sample for the threats CT1 and CT2. The
most significant identified issue is the use of outdated TPL in numerous applications, many of which are
afected by active CVEs. On the other hand, several applications have root detection capabilities as well
as anti-repackaging measures. We also identified a few custom OAuth implementation schemes, which
could introduce vulnerabilities like account takeovers [
The results of the preliminary analysis are presented in Figure 2.
25 20 sp 15 p A # 10 5 0 9 15 TPL 3 21 2 22 t Roo epack R 22 2 uth A 16
16 8
8 Cipher
_SP WW
Yes Partial
No
The static analysis examined the subsample of native applications. We observe that decentralized applications – implemented exclusively via BLE – are generally more obfuscated, likely due to the client being more central in this architecture. The API endpoints analysis reveals substantial variations at the implementation level but no distinct patterns can be observed between the two architectural types. At a high level, all applications exhibit similar functionalities.
We identified seven decentralized applications and, in each, note a common process: the client registers a ride on the server, pairs with the vehicle, requests a token to unlock it, and forwards the token to the vehicle over BLE. Unfortunately, we could not observe the token generation mechanism, plausible methods include static tokens, OTP, or distribution by the server. Since the use of static tokens would be a serious vulnerability, we evaluate the possibility in Section 5.4.
For the dynamic analysis phase, we developed a setup using a rooted Nexus 5X smartphone running
Android 8.1.0. During the tests, the device is connected to a laptop using the USB debugging feature
while the Frida server is running. We monitor the communications with Burp (for internet protocols)
and the Bluetooth HCI Snoop log feature functionality (for Bluetooth). All the applications are launched
with Frida [
The first step is to dump the client communication sequences of the six centralized and decentralized services available in our region. The observed sequences show significant similarity for services with the same architecture; hereafter we present a generalization in figure 3.
App
Server
Vehicle
App
Server
Vehicle Scanned QR code
Vehicle details
Create ride Ride details Start ride OK/KO
Unlock OK/KO
Scanned QR code
Vehicle details
Create ride
Token
BLE Pair Unlock(token)
OK (a) Sequence of centralized applications (b) Sequence of decentralized applications
Since the manual static analysis is not enough to fully assess the threats CS1, CI1, CI2, and CE1, we design a set of specific tests covering each of these threats. In the following sections, we present the tests designed for each threat and the corresponding results. Additional procedural details are provided in the Appendices.
CS1 - Smartphone GPS Spoofing. During our analysis, we observe that many applications share the user’s position with the server at a very high frequency, which produces two questions: • Do the micro-mobility services rely completely on the client’s position for vehicle tracking? (instead on the vehicle’s position) • Is it possible to misguide the vehicle’s behavior using the smartphone’s location? (Either during the ride or after it ends).
To verify the first question, we move the vehicles without starting a ride to check if their position remains up to date on the app. As expected, all the vehicles in the subsample contain a GPS tracker and keep their position updated. However, we notice that some services take as long as 30 minutes to update the position.
Since this delay is substantial, we suspect that the system prefers using the smartphone’s position during a ride to save the vehicle’s energy. This approach allows a user to exit the geographical boundaries or ignore the speed limits in specific areas (e.g., pedestrian zones).
Therefore, we conduct new tests by spoofing the smartphone’s GPS position and evaluate the server’s behavior both during the ride and immediately at its end. Both tests yield negative results for the entire subsample, proving that servers use the vehicle’s location—which is more reliable—instead of the smartphone’s.
CI1 - Memory Analysis. With the amount of data handled by shared mobility applications, the threat of data leakage remains significant. This test verifies whether the information stored in the phone’s memory is accessible to anyone with physical access to the device.
After using the application, we scan the device’s public and private memory and inspect the files connected to the application for any PII and tracking data. The results reveal that one-third of the subsample does not expose any relevant data, another third exposes incomplete tracking data, and the ifnal third exposes both PII and partial tracking information.
CI2 - User Tracking. Service providers may misuse their permissions to constantly track users if the permissions are inaccurately configured. To verify this, we test whether the application continues transmitting the user’s position to the server even when inactive and running in the background. The results show that only one of the six tested applications keeps tracking the user. While it may be used for profiling, the purpose of the tracking remains unclear.
CE1 - Illicit Unlock in Decentralized Architectures. In decentralized applications, the user’s smartphone—the most untrusted component of the system—directly sends the vehicle the unlock command (see Figure 3b). We do not fully investigate the specifics of token generation nor attempt to heavily attack the system to gain a deeper understanding of this process. However, we test whether the token changes or remains the same.
Only one of the six field-tested services employs a decentralized architecture, restricting this test to a single application. However, we confirm that the token consistently changes between diferent vehicles and between separate rides of the same vehicle.
While this test does not conclusively verify sound token generation in decentralized services, it suggests that any vulnerability in this domain is more likely due to an implementation flaw rather than poor design.
In this section, we present a set of guidelines and best practices for the development of shared micromobility services. These recommendations are derived from our analysis and informed by existing industry solutions. While companies have implemented various strategies to address such challenges, these approaches often lack formal evaluation.
Physical threats target the system’s most exposed component: the vehicle. The vehicle faces constant attack risk, making it particularly dificult to defend. Companies cannot fully eliminate these risks but must aim to mitigate them. In some cases (e.g., vandalism), not even threat mitigation is feasible. Our guidelines address various threats to the vehicle, emphasizing protection mechanisms that reduce the risk of successful attacks.
Threats PS2, PT2, PT3. Weak encryption in communications could allow an attacker to perform MITM attacks and tamper with data exchanges, while the absence of GPS spoofing detection permits fake location data to compromise system operations.
Threats PT1, PT4, PD1. Protecting the vehicle’s board and battery requires both software and physical security measures. Firmware should be secured by disabling unused ports on the motherboard, signing the updates, and authenticating their source. On the hardware side, locking the motherboard and battery with tamper-resistant lids and custom keys can reduce the risk of physical tampering. Threat PS1. Implementing robust authentication protocols for vehicles is essential to prevent unauthorized entities from impersonating legitimate ones or accessing sensitive network data. Such measures mitigate various attack vectors, including MITM and replay attacks, ensuring the security and integrity of the vehicle’s communications.
Cyber threats leverage vulnerabilities in the micro-mobility system’s mobile components to compromise either the vehicle or the server. Addressing these threats efectively requires a multi-layered approach that encompasses data validation, secure development practices, robust logging mechanisms, and a strong commitment to user privacy.
Threats CS1, CD1. Ensuring data originating from the client application, such as GPS coordinates or battery status, are always validated against data generated by the vehicle is critical. Since the vehicle’s data is harder to tamper with, this approach helps mitigate risks such as unauthorized movements outside designated zones or bypassing speed limits.
Threats CT1, CT2. Securing the application code by employing secure signature mechanisms ensures its integrity by preventing unauthorized modifications or insertions. Regular updates to third-party libraries address known vulnerabilities, while code obfuscation, although not a definitive solution, helps deter reverse engineering. Avoiding storing sensitive data directly within the application limits the attack surface.
Threat CR1. Implementing a robust logging mechanism in an immutable format ensures tamperevident records of actions. Strong access controls restrict access so that only authorized personnel can view or manage these logs, while integrity checks verify logs are unaltered.
Threat CI1. Sensitive information stored on the mobile device must be encrypted, ensuring its security even in cases of theft or loss. Private memory should be preferred over shared memory and all communications between the client and server must utilize secure protocols.
Threat CI2. Service providers should limit data collection to essential data needed to deliver the service, avoiding misuse of tracking information. Moreover, explicit consent must always be sought before collecting data.
Cyber threat CE1 is particularly complex and cannot be directly addressed by the guidelines provided earlier. This privilege escalation threat relies on exploiting an existing vulnerability and is strongly influenced by the system’s architecture. There are two possible attack vectors: tricking the server into believing a ride has started or forging new commands for the vehicle.
In the first scenario, an attacker would need to directly exploit the server, which is out of our scope. The second scenario is more relevant to our study but applies specifically to decentralized services, where the smartphone relays commands to the vehicle.
Our recommendation would be to use a centralized architecture, which reduces the system complexity and minimizes the attack surface. However, decentralized architecture is not inherently insecure, provided it includes measures to prevent MITM and brute-force attacks.
One drawback of centralized architecture is its reliance on constant vehicle connectivity. This limitation can be mitigated by carefully restricting the service area to avoid locations with weak connectivity. Additionally, vehicles in decentralized services use BLE instead of GSM, ofering higher energy eficiency and reducing the strain on the vehicle’s battery.
In conclusion, while centralized architecture is simpler and has reduced risk, the choice should ultimately depend on the specific goals of the service.
In this study, we developed a comprehensive shared micro-mobility threat model, grounded in experimental observations of the most popular services. Through the analysis of a representative sample of mobile applications, we identified existing industrial security measures and potential vulnerabilities. Finally, we proposed practical guidelines and best practices to support the design and implementation of safe shared micro-mobility platforms. Our analysis revealed several common issues, such as the use of outdated TPLs and weak ciphers. However, we also observed adequate security in internet communications – handled with proper protocols – and verified that neither centralized nor decentralized architectures are inherently vulnerable by design. Building on industry practices, our guidelines introduce targeted recommendations to address specific vulnerabilities we identified. Furthermore, we address security considerations at an architectural level, highlighting the strengths and weaknesses of both centralized and decentralized solutions.
Future research could involve collaboration with industry partners to evaluate the proposed threat model across the whole system, including physical threats to the vehicle and attacks on the server. Additionally, investigating the risks posed by cyber-criminals and insiders, aiming to steal data stored on servers, would provide valuable insights into protecting sensitive information.
In conclusion, while shared micro-mobility systems show reasonable protection against mobilespecific threats, our research highlights the need for a security assessment of the complete system. Such evaluations are essential for designing standardized security practices to safeguard user privacy, ensure safety, and protect the provider’s business.
During the preparation of this work, the authors used GPT-4o and Google Gemini in order to: paraphrase, reword, and improve the writing style. After using these tools, the authors reviewed and edited the content as needed and take full responsibility for the publication’s content.
This appendix provides a structured overview of the identified threats to the shared micro-mobility systems, categorized into physical threats and cyber threats. Table 1 outlines physical threats, that involve direct interaction with the vehicle, while Table 2 details cyber threats targeting the mobile application, backend systems, and user data. The assigned IDs identify each threat macro-category (Physical/Cyber) and category mnemonic in the STRIDE security framework.
Altering the vehicle’s firmware to gain unauthorized access or cause malfunctions.
Disrupting communication between the vehicle and the server.
Interfering with communication between the vehicle and the mobile app.
Physically modifying the vehicle’s hardware to disrupt functionality.
Manipulating users’ GPS locations via the mobile application.
Modifying and redistributing the mobile application for malicious purposes. Leveraging outdated libraries, weak cryptography, or insecure code to compromise the system.
Extracting Personal Identifiable Information or tracking data from a device’s memory.
Monitoring users even when the app is unused in background.
Tricking the server into misinterpreting vehicle battery status to disrupt the service.
Gaining unauthorized access to high-level functions, such as unlocking vehicles without payment.
Log Alteration
Tampering with logs to falsify records.
Ride Repudiation
Denying actions such as ride creation.
This appendix provides the detailed description of the field tests we performed. For all tests involving active smartphone use, we consistently disabled SSL pinning using Frida and monitored the communications with Burp and Bluetooth HCI Snoop Log, even if not explicitly mentioned each time. Understand whether or not the services rely exclusively on the GPS information given by the user’s smartphone. • Open the app and choose a vehicle • Move the vehicle while locked to another location • Check whether the position on the map changes or not If the position changes, it means that the vehicle uses its own GPS tracker module. If not, it means that the service relies only on the locations provided by the client device.
Every vehicle independently updated its location.
Almost every vehicle had an update time of 2-10 minutes. One app updated the position after about 30 minutes.
Understand if the server acts according to fake data fed from the smartphone to the server during the ride. • Spoof the location of the smartphone onto the actual position • Open the app • Select and unlock a vehicle • Move slowly the false position outside the pedestrian zone (We did this with a plausible speed to avoid some plausible checks against an abrupt change of location) • Try the vehicle inside and outside the pedestrian zone If the speed can go higher than 6km/h inside the pedestrian zone, then the service relies on fake data. Otherwise, the service uses the correct GPS data coming from the vehicle. Every target service maintained the correct behavior and enforced the correct speed limit. In all the services, at the end of the ride, the application shows the correct route, even though the device position was elsewhere. We can deduce that the tested services completely ignore the client’s position, at least in important matters.
Goal
Understand if the server acts according to fake data fed from the smartphone to the server at the end of the ride. • Spoof the location of the smartphone on the actual position • Open the app • Select and unlock a vehicle • Move the vehicle inside a no-parking zone • Try to lock the vehicle If it’s possible to lock the vehicle, then the service trusts the fake data coming from the client. Otherwise, it uses the GPS data coming from the vehicle.
Every target service maintained the correct behavior and refused to lock the vehicle in a forbidden area.
Verify whether or not the client application exposes personal information or tracking data in the phone memory. • Download the application • Register to the service • Use the service at least once, to create tracking data • Snapshot the memory and explore it One-third of the applications did not expose any relevant data, one-third exposed partial tracking information, and the remaining exposed PII and partial tracking information. All the target applications did not save important information on public memory, so an attacker cannot access them from a malicious application. The attacker would need to infect the OS of the target device or have physical access to the data.
Verify whether the unlock token is fixed for the vehicles. • Open the app and choose a vehicle • Start and end a ride • Start and end a second ride • Compare the tokens Understand whether or not the target applications trace the user even when the application is running in the background and has no active rides. • Open the app and ensure it is sending real-time location to the server • Move the app to the background • Check whether it keeps sending real-time position to the server or not Only one application kept sharing the user’s location with the server.
Verify whether the unlock token is fixed. • Open the app • Choose a vehicle, start a ride, and end it • Choose another vehicle, start a ride, and end it • Compare the tokens As expected, the token changes for diferent vehicles.