IoT device security: updates, keys and access control

A river gauge on a bridge pier, a rain gauge on a hilltop and a siren on a school roof have three things in common: nobody stands next to them, they talk to a server over the mobile network, and people act on what they report. So what is IoT device security in this setting? It is the design features and working practices that keep each device, its data and its commands trustworthy: only genuine firmware runs on it, only the right people and systems can talk to it, and anyone who tampers with it is noticed.

Below are the threats, the controls that answer them, what the main baselines ask for, and a checklist for tender clauses.

What is IoT device security?

IoT device security is the protection of a connected device, and the network, server and people it works with, against unauthorised access, modification and disruption. The Internet of Things (IoT) means devices with sensors or actuators that exchange data over a network without a person at the device.

NIST's core baseline for IoT devices, NISTIR 8259A, lists six capabilities a securable device should have [4]:

• Device identification: each device can be uniquely identified, logically and physically.
• Device configuration: its settings can be changed, but only by authorised entities, and it can be restored to a secure configuration.
• Data protection: it can protect stored and transmitted data from unauthorised access and modification, using standard cryptography.
• Logical access to interfaces: it can disable interfaces it does not need and restrict the others to authorised entities.
• Software update: its software can be updated by authorised entities only, through a secure mechanism that verifies each update before installing it.
• Cybersecurity state awareness: it can report its security state, so that a compromise can be noticed.

For a station or a siren, they decide whether a stranger can change its firmware or send the command that starts it.

Why is IoT security important for warning networks?

IoT security is important because a device that is easy to take over can be used against the people it serves, and one weakness is usually copied across every unit of a model. Warning stations also sit unattended for months, and their outputs (a danger-level alert, a siren) trigger public action.

India's Telecommunication Engineering Centre (TEC) lists possible consequences of attacks on IoT devices that include interruption of critical services, loss of life and property, and disruption on a national scale [2]. CERT-In, India's national agency for cyber incidents, lists "attacks on Internet of Things (IoT) devices and associated systems, networks, software, servers" among the incident types that must be reported to it [6].

IoT security threats: examples from the field

Two documented incidents show how simple the attacks can be.

Shared default passwords. The Mirai botnet of 2016 spread by scanning the internet for devices with an open Telnet login (a remote text console) and trying 10 username–password pairs drawn from a built-in list of 62 [7]. That was enough: Mirai reached a peak of about 600,000 infected devices and used them for large denial-of-service attacks; its password list was aimed mainly at IP cameras, video recorders and home routers [7]. No clever exploit was needed.

False siren triggers. Just before midnight on 7 April 2017, all 156 outdoor warning sirens in Dallas, USA, sounded for about 90 minutes. City officials said the sirens were set off through the radio control system rather than a computer network, and that "some encryption was added" when the system was restored [8]. A warning system that does not authenticate its commands can be set off by anyone able to send one.

The same failure modes apply to hydromet networks:

The OWASP IoT Top 10 (2018) covers the same ground: weak or hard-coded passwords come first, lack of a secure update mechanism fourth and lack of physical hardening tenth [5].

Why does firmware need to be updated?

Firmware needs to be updated because vulnerabilities keep being found after a device is installed, and an update is the practical way to remove them from a device already in the field. NIST gives the rationale directly: updates can remove vulnerabilities, which lowers the likelihood of compromise, and can correct operational problems, improving reliability and performance [4].

Firmware is the software on the device itself: it reads the sensor, logs data and talks to the server. An update channel that accepts any file is a direct path for tampered firmware, so the baselines ask for secure updates.

What makes an update secure?

ETSI EN 303 645, the European baseline for consumer IoT, requires a secure update mechanism (provision 5.3-2) and, where updates arrive over a network, requires the device to verify the authenticity and integrity of each update "via a trust relationship", for example a digital signature [1]. NISTIR 8259A asks for the ability to verify and authenticate any update before installing it, and to restrict updating to authorised entities [4].

The usual way to do this is a digital signature. The manufacturer signs each firmware image with a private key that never leaves a protected signing system. Every device holds the matching public key, which can check a signature but cannot create one. If even one byte of the image changes, the check fails.

Three further details separate a robust update process from a fragile one:

• Anti-rollback. An attacker who cannot forge a new image may try to install an old, genuinely signed one that has a known weakness. OWASP lists the lack of anti-rollback protection as part of an insecure update mechanism [5]. NIST also describes a separate, deliberate ability for authorised entities to roll back to a previous version when an update causes problems [4]; the two are compatible if rollback is itself controlled.
• Secure boot. Checking the update once is not enough if the stored firmware can later be altered. ETSI recommends that the device verify its software using secure boot (provision 5.7-1), so that every start-up checks the code before running it [1].
• Staged rollout. ETSI's resilience provisions give the example of notifying devices in batches so they do not all download an update at once [1]. Staging also limits the damage from a faulty release.

Worked example: a staged rollout

This example is illustrative. A district network has 150 devices (river and rain stations plus sirens). The update goes out in three waves of 5 %, 25 % and the rest:

Wave 1:  5 % of 150  = 7.5   → 8 devices
Wave 2: 25 % of 150  = 37.5  → 38 devices
Wave 3:  150 − 8 − 38       = 104 devices

If a fault shows up in wave 1, at most 8 of 150 devices
(8 / 150 = 5.3 %) are affected; the other 142 keep running.

Choose wave 1 devices that are easy to reach.

Keys and credentials: unique to every device

A credential is what a device or person presents to prove identity: a password, a key, a certificate. No two devices should share one.

ETSI requires that device passwords, in any state other than factory default, be unique per device or set by the user, and that pre-installed passwords be generated so that knowing one does not help guess another; passwords with counters such as "password1", "password2", or derived from a MAC address, are given as counter-examples [1]. ETSI also recommends that passwords not be used for machine-to-machine authentication at all, and forbids hard-coded critical security parameters in the software source code [1]. Secrets kept in persistent storage must be stored securely, for example in a secure element or the SIM card (UICC) [1].

Worked example: how far one leaked secret reaches

Again illustrative, with the same 150-device network:

Shared password on all 150 devices:
  one leak (a stolen station, a lost laptop)  → 150 / 150 = 100 % exposed
  recovery: change the secret on 150 devices, many in the field

Unique credential per device:
  one leak                                    → 1 / 150 = 0.7 % exposed
  recovery: revoke one credential on the server, re-provision one device

This also answers the stolen-SIM problem. A SIM proves only that something may use the mobile network; if the station authenticates to the server with its own credential, a SIM moved to another device does not carry the station's identity.

Encrypted transport: what TLS does and does not do

Transport Layer Security (TLS) is the standard protocol for protecting data in transit. Version 1.3 is designed to prevent eavesdropping, tampering and message forgery, and gives three properties: the data are visible only to the two endpoints, cannot be modified without detection, and the server is always authenticated [9]. Note the last point: in TLS the client side is only optionally authenticated [9]. For a field device, the device (the client) should also authenticate, normally with its own certificate, so that the server knows which station is speaking.

Encryption stops messages being altered on the way, not a tampered device sending wrong numbers through a secure channel, so plausibility checks still matter: see data quality control for hydromet time series. For the network side of the station, see telemetry link design.

Access control, least privilege and audit logs

ETSI calls the principle of least privilege, giving each person and process only the access needed for its task, "a foundation stone of good security engineering" [1]. In a warning network that means separating roles: someone who views data, someone who edits station settings, someone who can send a public alert, and someone who administers accounts. Actions with public consequences, such as triggering sirens, deserve an extra step, for example approval by a second authorised person; see early warning dissemination: sirens, SMS and CAP.

Audit logs record who did what, to which device, and when. ETSI recommends examining telemetry for security anomalies, such as an unusual rise in failed logins or updates failing their authenticity checks [1]. Logs are only useful if their time stamps can be trusted; see time stamps you can trust.

What CERT-In's 2022 Directions require

The CERT-In Directions of 28 April 2022, issued under section 70B(6) of the IT Act, 2000, apply to service providers, intermediaries, data centres, body corporate and Government organisations [6]. Among other things, they require these entities to:

• synchronise the clocks of all their ICT systems with the NTP servers of the National Informatics Centre (NIC) or National Physical Laboratory (NPL), or servers traceable to them;
• report the listed types of cyber incident, which include attacks on IoT devices, to CERT-In within 6 hours of noticing them;
• enable logs of all their ICT systems and keep them securely for a rolling 180 days within Indian jurisdiction; and
• designate a point of contact for CERT-In [6].

How these apply to a given network is for the owning organisation to decide, but its supplier's systems should support them.

Physical tamper

An unattended station can be opened. ETSI requires debug interfaces to be disabled or protected by authentication, recommends that physical debug ports be protected by the casing, and requires a hard-coded device identity used for security to resist physical, electrical or software tampering [1]. OWASP lists lack of physical hardening as a top-ten risk because physical access can yield information for a later remote attack [5]. In practice: a door switch that reports to the server, no exposed service connector, and site-visit records so that an unexplained opening stands out.

The update and vulnerability-handling lifecycle

Security is not a feature delivered once. NIST's guidance for manufacturers stresses planning for vulnerability response and flaw remediation, and telling customers how long a device will be supported and what happens at end of life [3]. ETSI requires three things of manufacturers: a public vulnerability disclosure policy with a contact and timelines for acknowledging and updating reporters, a published support period, and timely security updates [1].

A workable lifecycle: receive a report (or find the issue through monitoring); assess which devices and versions are affected; fix, test and sign; roll out in stages; confirm every device reports the new version; and inform customers, keeping the support commitment until end of life.

Which standards apply in India?

Buyers usually work from published baselines. ETSI EN 303 645 (version 3.1.3, September 2024) sets 13 groups of provisions, from "no universal default passwords" to "validate input data" [1]. Its scope is consumer IoT, and devices primarily intended for industrial applications are outside it [1], but its provisions are a sound minimum for any connected device. TEC's Code of Practice for Securing Consumer Internet of Things was first released in August 2021 (TEC 31318:2021) and revised as TEC 31318:2025 in November 2025 to follow ETSI EN 303 645 version 3.1.3; it is addressed primarily to IoT device manufacturers, IoT service providers and system integrators, and mobile application developers [2]. NISTIR 8259 and 8259A complete the set [3][4]. For writing these into a contract, see writing a technical specification for a hydromet tender.

A checklist for buyers writing specifications

Ask each bidder to answer every item in writing:

1. Unique credentials. No universal default passwords; every device has its own credential, and passwords are not used for machine-to-machine authentication.
2. No hard-coded secrets. No keys or passwords in firmware source code; secrets stored in protected hardware.
3. Signed updates. Firmware is signed; the device verifies the signature before installing and rejects older versions.
4. Secure boot. The device checks its firmware at every start-up.
5. Recovery. A failed update leaves the device running its previous firmware, without a site visit.
6. Staged remote updates. Updates go to chosen groups; every device's version is visible.
7. Encrypted, mutually authenticated transport. Current TLS (or equivalent), with the device authenticating to the server by its own credential.
8. Authenticated commands. Commands to stations and sirens are authenticated and cannot be replayed.
9. Roles and approvals. Separate roles for viewing, configuring, alerting and administration; extra approval for public alerts.
10. Audit logs and clocks. Logged user and device actions, clocks synchronised to a traceable time source, retention that meets your obligations.
11. Tamper detection. Door or enclosure alarm, protected service ports, alerts when a device goes silent.
12. Disclosure policy and support period. A published route for reporting vulnerabilities, stated response times, and a stated period of security updates.
13. Baselines. A statement of how the product meets ETSI EN 303 645 and the TEC code of practice, provision by provision.

Key points

• IoT device security keeps each device, its data and its commands trustworthy; for warning networks the stakes are public safety.
• Real attacks are often simple: shared default passwords (Mirai) and unauthenticated commands (the Dallas sirens).
• Firmware must be updatable, and every update must be signed, verified on the device, protected against rollback and rolled out in stages.
• Give every device its own credential; then one leak exposes one device, not the whole network.
• TLS protects data in transit, but the device should authenticate too, and the data still need plausibility checks.
• Least privilege, approvals for public alerts, audit logs with trusted clocks, and physical tamper detection close the remaining gaps.

Where ClimMaTech fits

We look after our monitoring stations as a fleet through Visiflow (Device Cloud), where each station reports its readings together with its own status, such as signal strength and battery, so that a station that falls silent or behaves oddly is noticed from the office rather than on the next site visit. The questions in the checklist above are the right ones to put to any supplier, including us, and we are glad to go through them with a project team.

References

1. ETSI, ETSI EN 303 645 V3.1.3 (2024-09) CYBER; Cyber Security for Consumer Internet of Things: Baseline Requirements, European Telecommunications Standards Institute, 2024. Clauses 1, 5.1–5.7, 5.9, 5.10. etsi.org PDF.
2. Telecommunication Engineering Centre, Code of Practice for Securing Consumer Internet of Things (IoT), TEC 31318:2025, Release 2.0, Department of Telecommunications, Government of India, November 2025 (first release TEC 31318:2021, August 2021). tec.gov.in PDF (2025); tec.gov.in PDF (2021)%20TEC%2031318_2021_after.pdf).
3. Fagan, M., Megas, K. N., Scarfone, K. and Smith, M., Foundational Cybersecurity Activities for IoT Device Manufacturers, NISTIR 8259, National Institute of Standards and Technology, 2020. doi:10.6028/NIST.IR.8259.
4. Fagan, M., Megas, K. N., Scarfone, K. and Smith, M., IoT Device Cybersecurity Capability Core Baseline, NISTIR 8259A, National Institute of Standards and Technology, 2020. doi:10.6028/NIST.IR.8259A.
5. OWASP Internet of Things Project, OWASP IoT Top 10 2018, Open Web Application Security Project, 2018. owasp.org PDF.
6. Indian Computer Emergency Response Team (CERT-In), Directions under sub-section (6) of section 70B of the Information Technology Act, 2000 relating to information security practices, procedure, prevention, response and reporting of cyber incidents for Safe & Trusted Internet, No. 20(3)/2022-CERT-In, Ministry of Electronics and Information Technology, 28 April 2022. cert-in.org.in PDF.
7. Antonakakis, M. et al., Understanding the Mirai Botnet, Proceedings of the 26th USENIX Security Symposium, pp. 1093–1110, USENIX Association, 2017. usenix.org.
8. Van Wagenen, J., Dallas Reveals Radio Signals, Not Network Hack, Triggered Emergency Sirens, StateTech Magazine, 13 April 2017. statetechmagazine.com.
9. Rescorla, E., The Transport Layer Security (TLS) Protocol Version 1.3, RFC 8446, Internet Engineering Task Force, 2018. rfc-editor.org.