Securing IoT Devices in Smart Cities

Overview

A modern city runs on devices most residents never notice: traffic sensors, water and electricity meters, air-quality monitors, surveillance cameras, and connected streetlights. Each is a small computer sitting on the public internet, and each is a potential door. This paper makes one central argument: because the weakest link in a smart city is the cheap, mass-purchased, rarely-updated device, the single highest-leverage security control is not end-user education but procurement, cities and national regulators should make independently verified security standards a condition of buying and selling connected devices. Security is still a shared responsibility among manufacturers, users, and city agencies, as it must be. But that responsibility should be front-loaded onto manufacturers and buyers through binding rules, rather than pushed downstream onto citizens who cannot inspect the firmware inside a streetlight.

The stakes are no longer hypothetical. There were about 21.1 billion connected IoT devices worldwide in 2025, growing roughly 14% a year toward a projected 39 billion by 2030, a figure that deliberately excludes phones, tablets and PCs, which means almost every one of those endpoints is a fixed-function device with weak or no built-in security (IoT Analytics, 2025). Singapore alone plans an interconnected network of about 110,000 sensor-fitted lampposts under its Smart Nation Sensor Platform (Smart Nation, 2018). When devices at that scale ship insecure, the blast radius is an entire city.

What makes an IoT device vulnerable?

Device-level weaknesses. Many IoT devices ship with default passwords, no automatic updates, and firmware the manufacturer stops supporting within a few years. The clearest proof of how dangerous this is came from the Mirai botnet, which spread in 2016 simply by trying a short list of factory-default usernames and passwords against internet-connected cameras and routers. A seven-month study found Mirai grew to a peak of roughly 600,000 infected devices (Antonakakis et al., USENIX 2017). This required no sophisticated hacking, only devices shipped with predictable credentials.

Network threats. Two classic attacks apply. A Man-in-the-Middle (MITM) attack intercepts traffic between a device and its server; a Distributed Denial of Service (DDoS) attack floods a target with junk traffic until it collapses. On 21 October 2016, a Mirai-powered botnet of hijacked IP cameras, DVRs and home routers overwhelmed the DNS provider Dyn, knocking Twitter, Spotify, Reddit and SoundCloud offline for hours (Krebs on Security, 2016). The devices were not the target, they were the weapon. Apply that same weakness to a traffic-signal controller or a substation sensor and it stops being an inconvenience and becomes a public-safety threat.

Privacy risks. Smart-city devices continuously collect surveillance footage, meter readings, and location data. Governing that data is inseparable from securing the device: Singapore's own lamppost programme drew public concern precisely because sensors capable of facial recognition sit on tens of thousands of poles (Smart Nation, 2018). Securing the box and governing the data it produces are two halves of the same problem.

When insecure devices scale: the real stakes

The reason procurement matters more than any single user's vigilance is arithmetic. With more than 21 billion endpoints today and 39 billion projected by 2030 (IoT Analytics, 2025), even a tiny percentage of insecure devices becomes an army, Mirai turned 600,000 ordinary cameras into one. And the cost of failure is highest in exactly the systems smart cities depend on. Industrial-sector data breaches averaged about USD 5.56 million, roughly 13% above the USD 4.88 million global average (IBM, 2024), and smart-grid, water, and transport systems sit squarely in that safety-critical, high-cost category. A breach there is measured not only in money but in stalled traffic, dark streets, or an interrupted water supply.

The shared-responsibility model, and its weak link

Responsibility for IoT security is genuinely shared:

• Manufacturers must build security in from the start, no default passwords, timely patches, honest end-of-support dates, and a clear channel to report vulnerabilities.
• Organizations (city governments, utilities) must encrypt and authenticate their networks, segment them, and monitor continuously for abnormal device behaviour.
• Users should change default passwords, keep firmware updated, and switch on automatic updates.

All three matter. But they are not equally powerful, and treating them as interchangeable is the mistake this paper argues against. End-user education is the weakest lever, for three reasons. First, a resident cannot patch a city's streetlight or traffic sensor, the devices that matter most are not in anyone's living room. Second, Mirai showed that attackers exploit the manufacturer's default, not the user's carelessness. Third, at 21 billion devices, expecting hundreds of millions of non-experts to each configure security correctly is not a plan. The leverage is upstream, where the number of decision-makers is small and the decisions are binding: manufacturers who must meet a standard before they can sell, and city buyers who must require that standard before they can purchase.

The regulatory landscape

Several frameworks shape IoT security. Global standards include ISO/IEC 27001 (information-security management), the NIST Cybersecurity Framework (a risk-management roadmap), and ETSI EN 303 645, Europe's baseline consumer-IoT standard, which bans universal default passwords and requires a way to keep software updated. National approaches vary: the EU pairs the GDPR's data rules with a move toward mandatory device-security requirements; the United States passed the IoT Cybersecurity Improvement Act, which uses federal procurement as its lever by barring agencies from buying devices that fail NIST's guidance.

The pattern worth noticing is that the measures with real teeth are tied to sale or purchase, not to user behaviour. That is the design principle the rest of this paper builds on, and Singapore has taken it furthest.

Singapore in depth: labelling plus deployment

Singapore is worth studying because it does two things at once: it labels devices and it deploys them at city scale.

On labelling, the Cyber Security Agency of Singapore (CSA) launched the Cybersecurity Labelling Scheme (CLS) in 2020, the first of its kind in the Asia-Pacific (CSA). It rates a consumer device on a four-level scale:

• Level 1, baseline requirements from ETSI EN 303 645 (no default passwords, security updates available), shown by the maker's own declaration.
• Level 2, compliance with the full set of ETSI EN 303 645 mandatory requirements, again by declaration.
• Level 3, secure development-lifecycle requirements plus independent software binary analysis by a test laboratory to confirm there are no known critical vulnerabilities or malware.
• Level 4, independent penetration testing by a test laboratory (CSA).

The crucial design point is the break between Levels 1 to 2 and Levels 3 to 4: the first two rely on the manufacturer's self-declaration, while the top two require an independent laboratory to actually test the device. Real assurance begins where an outside party opens the box. The scheme started with Wi-Fi routers and smart-home hubs and now covers all consumer IoT, IP cameras, smart locks, lights, and printers (CSA). Its influence has crossed borders: Singapore has signed mutual-recognition arrangements so its label is honoured by Germany (building on a 2022 agreement) and the Republic of Korea (effective 1 January 2025), cutting duplicate testing and giving a single label weight in multiple markets (CSA, 2024).

On deployment, Singapore's Smart Nation Sensor Platform plans an interconnected network of about 110,000 sensor-fitted lampposts for traffic, environmental and operational monitoring (Smart Nation, 2018). This is the pairing that makes Singapore instructive: a government that both certifies devices and installs them at national scale, and that has had to answer publicly for the privacy of a network that can, in principle, run facial recognition. Labelling and deployment are two sides of one policy.

India: a pending strategy, and a concrete fix

India is building smart cities aggressively, but its national cyber framework has not kept pace. The National Cyber Security Strategy, conceptualised by the Data Security Council of India and in the works since 2020, was drafted by 2021 but remains pending and unreleased, with no implementation deadline (NextIAS, 2022). India's operative document is still the National Cyber Security Policy of 2013, which predates the IoT boom and sets no enforceable device-security bar. The result is that a city can procure thousands of connected sensors with no legal floor for how secure they must be.

Here is the concrete, India-specific recommendation this paper argues for. India should adopt a CLS-style mandatory security label within the forthcoming national strategy, and tie public smart-city procurement to its tested tiers. Specifically:

• Any device bought for safety-critical urban infrastructure, traffic control, power and water SCADA systems, public surveillance, should be required to carry a label equivalent to Singapore's Level 3 or Level 4, meaning it has passed independent binary analysis or penetration testing rather than a vendor's self-declaration alone.
• Consumer IoT devices sold in India could start at a self-declared baseline tier and ratchet upward over time, as Singapore's scheme did.

This targets the highest-leverage control, the point of sale and purchase, instead of hoping citizens secure infrastructure they cannot reach. It is also falsifiable, which a serious thesis should be: if mandatory labelling fails to lower the rate of default-credential and unpatched-firmware compromises in labelled fleets, the claim that procurement is the highest-leverage control is wrong and should be revised.

Secure-by-design and incident response

A label is only as good as the engineering it certifies, and the two top CLS tiers essentially encode secure-by-design practice: eliminate default passwords, use cryptographically verified secure boot, apply hardware-level encryption, ship secure over-the-air updates, protect the supply chain, and run penetration testing before deployment rather than patching after. Requiring an independently tested label is a way of making those practices a condition of sale instead of a vendor promise.

No control is perfect, so cities still need a tested incident-response plan: detect unusual device behaviour through continuous monitoring, contain by isolating compromised segments, eradicate the threat and restore service, review to find the root cause, and drill regularly so the plan works under pressure. Mandates reduce the odds of a breach; a rehearsed response limits the damage when one gets through.

Emerging threats and the limits of citizen education

The threat surface keeps expanding. AI is being used to discover vulnerabilities and generate adaptive malware faster than humans can. Supply-chain attacks slip backdoors into components before a device is even sold. And sheer scale means a minor flaw, multiplied across billions of endpoints, becomes a systemic risk. Public awareness still matters, for household devices and for the trust that makes residents accept sensors on their streets. But it belongs at the end of the chain, not the front. The first line of defence is not teaching a citizen to change a password; it is not letting an insecure device be sold or bought in the first place.

Conclusion

Smart cities will only be as trustworthy as the weakest device on their network, and that device is almost always cheap, bought in bulk, and rarely updated. The response cannot rest on citizen vigilance. It has to sit where the leverage is: on manufacturers who must meet an independently verified standard to sell, and on city buyers who must require that standard to purchase. Singapore shows the model working, a four-tier label whose top rungs demand independent testing, recognised across borders, alongside a city-scale deployment. India has the ambition and the smart-city pipeline; what it lacks is the binding floor. A mandatory, CLS-style label, with independently tested Level 3/4 devices required for safety-critical procurement, would supply it. The "smartest" cities will indeed be those where technology and citizens work in partnership, but that partnership starts with a government that refuses to buy, or allow the sale of, a device it cannot trust.

Sources

1. Antonakakis, M. et al., "Understanding the Mirai Botnet," USENIX Security 2017, research.google/pubs/understanding-the-mirai-botnet
2. Krebs on Security, "DDoS on Dyn Impacts Twitter, Spotify, Reddit," 2016, krebsonsecurity.com
3. IoT Analytics, "Number of connected IoT devices," 2025, iot-analytics.com/number-connected-iot-devices
4. IBM, "Cost of a data breach: The industrial sector," 2024, ibm.com/think/insights/cost-of-a-data-breach-industrial-sector
5. Cyber Security Agency of Singapore, "About the Cybersecurity Labelling Scheme for IoT", csa.gov.sg
6. Cyber Security Agency of Singapore, "CLS(IoT) for Manufacturers", csa.gov.sg
7. Cyber Security Agency of Singapore, "Singapore Signs Mutual Recognition Arrangements with the Republic of Korea and Germany," 2024, csa.gov.sg
8. Smart Nation (Smart Nation Sensor Platform / Lamppost-as-a-Platform), en.wikipedia.org/wiki/Smart_Nation
9. NextIAS, "Status of India's National Cyber Security Strategy," 2022, nextias.com