Decathlon was building connected e-bike services: an e-bike with an integrated tracker, Decathlon app interactions, connectivity services, a cloud-based IoT platform, external suppliers, and the digital services around them — supporting tracking, anti-theft, and safety/insurance use cases. The security object was never the bike or the tracker alone. It was the full connected-mobility ecosystem, where the parts only make sense together.
Decathlon needed clear answers across that ecosystem: what had to be protected, how the service could be attacked, which risks to reduce versus accept, and which technical controls to implement — spanning the bike, tracker, app, IoT platform, and supplier chain. The regulatory backdrop was GDPR plus the cybersecurity expectations now converging on connected products, with outputs built to stay directly relevant to the Cyber Resilience Act and NIS 2.
The core difficulty was the system boundary. A connected e-bike service isn’t one product — it’s a physical bike, embedded components, a tracker, connectivity, app interactions, cloud IoT services, and supplier-provided elements, all interdependent. A vulnerability in one layer propagates to the others: compromise the tracker and you can reach user data, anti-theft functions, or the evidence that safety and insurance scenarios rely on. A generic IoT checklist can’t capture that. The project needed a system-level analysis of Decathlon’s real ecosystem, with an explicit link between assets, attack paths, residual risks, and the controls expected from product, platform, and suppliers.
01
Started from Decathlon’s real connected e-bike architecture and its priority use cases: tracking, anti-theft, and safety/insurance scenarios.
02
Mapped the key components, interfaces, sensitive assets, data flows, existing countermeasures, operational assumptions, and supplier dependencies across the whole ecosystem.
03
Built a threat model and system-level risk assessment: credible attack scenarios, affected assets, feared events, impacts, existing protections, and residual risks.
04
Translated the analysis into security objectives and technical controls, following one explicit chain: assets and data flows → threat model → attack scenarios → risk assessment → residual risks → security objectives → technical controls → supplier expectations.
05
Fed the IoT platform certification strategy, helping Decathlon identify assurance routes and the evidence to prepare for future audits or certification.
For connected mobility, the unit of security is the whole ecosystem, not any single device in it. The lesson that carries forward: risk analysis is only worth doing if it drives implementation — and a security profile is what makes that link, turning threats and residual risks into concrete controls, supplier expectations, and certification evidence. For future connected-product programmes, cybersecurity-by-design should start from the real architecture and wire threat modelling, risk assessment, security profiles, supplier management, and certification strategy together from day one — not as separate work packages.
We’ll send you access by email.
