Skip to content
The Cyber Security Place

Defence

IoT security in 2026: the estate kept growing after everyone stopped talking about it

Connected devices stopped being interesting around 2019 and carried on multiplying. The gap between how much attention the subject gets and how many of these things are now plugged in is where the problem lives.

Last reviewed August 25, 2026

Connected devices passed 18.5 billion in 2024 and are heading for about 39 billion by 2030. Roughly 35% still ship with default credentials and about 33% have no update mechanism at all, while around 70% carry unpatched firmware flaws. Botnet activity grew about fivefold in a year, from roughly 200,000 compromised devices to near 1 million, and one botnet produced a denial-of-service attack measured at29.7 Tbps. The EU Cyber Resilience Act starts a 24-hour vulnerability reporting clock for manufacturers in September 2026, with penalties up to €15m or 2.5% of turnover. Three malware families — Mirai, Mozi and Gafgyt — account for around 75% of what runs on compromised devices. The control that works without the manufacturer is segmentation.

Why are these things so reliably insecure?

Not through incompetence, and understanding why matters because it tells you which remedies are available. The economics of a connected device point away from security at every stage, and no amount of engineering goodwill inside the manufacturer overcomes that on its own.

A camera or a sensor is sold on price and features into a market where nobody compares firmware support. It is bought once, outright, with no ongoing relationship — which means there is no revenue attached to maintaining it. The product line is discontinued after three or four years while the hardware stays installed for fifteen. And the buyer is frequently a facilities contractor rather than anyone in technology, so the purchase never passes a security review.

The results are measurable and have barely moved in a decade. Roughly a third of devices arrive with default credentials. A similar share have no working update path. Around seven in ten carry firmware flaws that are already published. This section was reporting hundreds of unsecured devices openly reachable in March 2015, and the proportions today are close enough to be discouraging.

What follows from that is a defensive posture rather than a purchasing one. If the device cannot be trusted to be patched, cannot be trusted to have unique credentials and cannot run your monitoring agent, then every control has to live outside it — in the network, in what it is permitted to reach, and in knowing it is there at all.

Attention peaked; the estate did not

Two lines on the same years. One is how much this subject was written about; the other is how many of these devices existed. They stop agreeing in 2019.

2015201620172018201920202021coveragedevicesreports per year (red) against installed devices in billions (grey)
Report counts computed at build time. Device estimates rounded from published market figures; the two series use separate scales, so only their shapes are comparable.

What a million trivial devices add up to

Individually these things are worth almost nothing to an attacker. A camera has no interesting data, a thermostat has no credentials worth stealing, a printer holds nothing anybody wants. Collectively they are one of the most powerful weapons available, because they are numerous, always on, and connected to networks with good upstream capacity.

The demonstration arrived in late 2016, when a botnet built from consumer devices was rented out and then used to make a large part of the web unreachable. Nothing about the technique was sophisticated. It logged into devices using the default passwords printed in their manuals.

A decade later the same approach works better than ever. Compromised device counts grew roughly fivefold in a single recent year, into the region of a million active nodes, and one botnet generated an attack measured at nearly thirty terabits per second — a figure that would have been implausible from any source a few years ago. Three malware families account for something like three-quarters of what runs on these devices, all of them descendants of that 2016 approach.

The uncomfortable asymmetry is that the owner of the device experiences nothing. A compromised camera keeps showing the corridor. There is no ransom note, no performance complaint, no reason for anyone to look. The cost lands entirely on whoever is on the receiving end of the traffic, which is why this problem has never generated the pressure that would fix it.

Where should a given device actually sit?

"Is this device secure?" has no answer. "Where can it be, and under what conditions?" does, and it turns on four facts anyone can establish in ten minutes.

Four questionsShould this device be on your network?

Can anything outside your network reach it directly?

Port forwarding, a public address, or its own cellular or vendor-cloud connection that you do not control.

Is the vendor still shipping firmware updates for this model?

Check the support page for a release in the last twelve months, not whether an update mechanism exists.

Have the default credentials been changed — on every account it has?

Many devices carry a second service or maintenance account that the setup wizard never mentions.

Is it on the same network segment as business systems?

Same VLAN, same subnet, or able to reach a file server or directory controller without crossing a firewall.

All five outcomes, and the rule that produces each

Take it off the network
No updates and default credentials is the combination that built every large IoT botnet. There is no configuration that makes this safe, because the two properties defeat every control you could add around it. Replace it, or if it must stay, put it on a segment with no route anywhere and no internet access at all. Treat that as a temporary measure with a date on it, not an arrangement.
Remove the exposure today
Reachable from outside and no longer receiving fixes. Every vulnerability published against this model from now on is permanent, and scanning finds it in hours rather than weeks. Close the inbound path first — that is a firewall change you can make this afternoon. Then plan the replacement, because the device is on a clock regardless of where it sits.
Justify the exposure or close it
It is patched and reachable, which is survivable and rarely necessary. Most devices are exposed because a remote-access requirement was solved with a port forward years ago and nobody revisited it. Ask what the inbound path is for. If the answer is remote access for staff or a supplier, a VPN or a vendor-managed tunnel does the same job without publishing the device to everybody.
Segment it
Nothing here is alarming on its own. The risk is topological: a device on the same segment as business systems turns a minor compromise into a foothold with a view of everything. Move it to its own VLAN with egress rules that permit only what it genuinely needs. This is the single highest-value change on this page and it does not depend on the device improving.
Acceptable, with a review date
Patched, credentials changed, not exposed, and segmented. That is the position this exercise exists to reach, and it is a snapshot rather than a permanent state. Record the model and the date support ends. The most common way a device like this becomes a problem is that the vendor stops publishing updates and nobody notices for three years.

The verdicts converge on segmentation because segmentation is the only control here that works unilaterally. Patching depends on the manufacturer. Credential hygiene depends on the device permitting it. Monitoring depends on being able to install something. Putting the device somewhere it cannot do damage depends on nobody but you.

The second question in the triage is the one people answer wrong most often. "Does it have an update mechanism" and "is the vendor still publishing updates" are different questions, and the first is nearly always yes while the second is frequently no. Check the support page for a release in the last year rather than checking that a settings screen exists.

You cannot segment what you have not found

Every organisation that runs a passive discovery scan for the first time finds devices nobody could account for, and the reaction is consistent enough to be predictable: mild embarrassment, then a genuinely useful afternoon. The asset register describes what procurement bought. The network describes what is actually connected, and the two have never matched.

The gap has structural causes rather than sloppy ones. A facilities contractor installs door controllers as part of a building project, and the purchase order says "access control system" rather than listing thirty networked devices. A department buys a smart display for a meeting room on a corporate card. An acquisition arrives with a factory floor nobody has surveyed. None of that passes through technology procurement, and all of it ends up on the network.

Passive discovery is the right instrument because it makes no assumptions and breaks nothing. Watching traffic reveals what is talking, what it is talking to and frequently what it is — device fingerprints are distinctive enough that a good tool will name the model. Active scanning has its place and occasionally knocks over fragile equipment, which is a poor way to introduce a security programme to the facilities team.

The output that matters is not a count. It is a list with an owner against each entry, because the recurring failure is not that nobody knew the device existed — it is that nobody was responsible for it, so no one renewed its firmware, changed its password or noticed when the vendor stopped supporting it.

Ownership also settles an argument that otherwise recurs every year. Facilities, clinical engineering and technology teams each have a defensible claim that these devices are somebody else's problem, and each is partly right: the equipment is theirs, the network is not, and the vulnerability is neither. Writing a name against the entry does not resolve the philosophical question and does remove the practical one, which is all that was ever needed.

What should procurement ask before buying one?

Five questions, none of them technical, all of them answerable by a salesperson who has been asked before. The value is partly in the answers and partly in which vendors can produce them at all — a supplier who has never been asked how long firmware will ship is telling you something about their other customers.

Until when will this model receive security updates? A date, in the contract. "For the supported lifetime of the product" is not a date and means the supplier decides later.

How are updates delivered, and does anything break? A mechanism that requires someone physically at the device with a laptop will not be used after the first year, which makes its existence irrelevant.

Can every account's credentials be changed, and is there a list of them?The service account that the setup wizard never mentions is the one that ends up in a botnet, and vendors know their own devices well enough to enumerate them.

What does it connect to when it is working normally? If the answer is a vendor cloud, you have a supplier relationship rather than a device, with all the third-party questions that implies. That is not disqualifying and it is different from what was on the purchase order.

What happens when a vulnerability is published against it? Who is told, how fast, and through what channel. Under the incoming European rules a manufacturer selling into that market has twenty-four hours to notify the authorities about active exploitation, and a vendor who cannot describe their process today will be describing it to a regulator shortly.

The obligation is finally moving to the manufacturer

Every remedy discussed so far is something the buyer does about a product they cannot change. That has been the shape of this subject for a decade, and it is starting to shift — because the European Cyber Resilience Act puts duties on whoever places the product on the market rather than on whoever installs it.

Two dates matter. Vulnerability reporting obligations begin in September 2026, including a requirement to notify within twenty-four hours of learning that a flaw is being actively exploited. Full enforcement follows in December 2027. The penalties reach fifteen million euros or two and a half per cent of worldwide turnover, whichever is larger.

That last figure is the part that changes behaviour. Previous attempts at this relied on labelling schemes and voluntary baselines, which produced compliance theatre because the cost of ignoring them was zero. A percentage of global turnover is a number that reaches the people who decide how long a product line gets maintained.

For a buyer, the practical consequence arrives before the enforcement does. Manufacturers preparing for this have to state a support period, and that makes it a thing you can ask for and compare during procurement. "How long will this receive security updates" has been an unanswerable question for a decade. It is about to become a specification.

When the device is medical or industrial

The same problems with the consequences changed and the timescales stretched. An infusion pump, a building management controller or a programmable logic controller on a production line has the security properties of a cheap camera and a replacement cycle measured in decades rather than years.

Certification makes patching genuinely hard rather than merely neglected. Equipment approved for clinical or safety-critical use often cannot receive a firmware update without revalidation, which costs money and time and may require the manufacturer's involvement. This section was covering insecure medical devices as a route into hospital networks in 2016, and the structural obstacle has not moved since.

That removes most of the toolkit and leaves one thing. Segmentation is not the preferred control in these environments; it is the only one available, which raises the stakes on doing it properly. A flat network in a hospital or a plant means a compromise anywhere is a compromise of equipment that people's safety depends on.

There is a procurement lever that works even here, and it is worth using while replacement decisions are being made. Ask for the support period in the contract. Ask what happens when a vulnerability is published against the model. Vendors in these markets are unaccustomed to the questions, and the ones with good answers are distinguishable from the ones without within about two minutes.

Why did everyone stop paying attention?

The coverage curve tells a story that is easy to misread. Reporting on connected devices climbed steeply through 2017, peaked in 2019 and fell away afterwards, and the obvious inference — that the problem was solved — is contradicted by every measurement of the actual estate.

What ended was the novelty. A vulnerable camera was a story in 2016 because the idea that a camera could be a computer was still surprising. By 2020 it was neither surprising nor new, and the trade press moved to whatever was. The underlying condition did not change; it simply stopped qualifying as news, which is a property of publishing rather than of risk.

Two things filled the space. Ransomware absorbed most of the available attention from 2020 onwards, and it deserved to. And the parts of this subject that stayed interesting migrated into other categories — operational technology security, the software supply chain of embedded components, regulatory compliance — where they get covered under names that do not include the word.

For anyone responsible for an estate, the practical reading is that quiet categories deserve periodic revisiting on a schedule rather than when something prompts it. The subjects that stop generating headlines are precisely the ones where nobody will remind you that the controller installed in 2018 stopped receiving updates in 2021.

There is a version of this that applies to any organisation, not only to this subject. Risk registers are refreshed when something prompts them, and the prompt is almost always news. That means the entries most likely to be stale are the ones nobody is writing about — which inverts the usual instinct, because it makes the quiet categories the ones worth scheduling a review for rather than the noisy ones.

A programme that fits in a quarter

Nothing on this subject requires a transformation programme, which is fortunate, because none has ever been funded. Four steps get most of the available benefit and each is achievable by a small team.

Find them. Run passive discovery for a fortnight and write down what appears. Expect the list to be longer than anyone predicted and treat that as the exercise working rather than as a finding to be embarrassed about.

Give each one an owner. A name, not a department. The absence of an owner is the root cause behind almost every neglected device, and assigning one costs nothing and survives staff changes if it is written down.

Put them somewhere. One segment for devices that need internet access, one for those that do not, and egress rules on both. This is the step that produces most of the risk reduction and the one most likely to be deferred because it touches the network team's change process.

Record the end of support. For each model, the date the vendor stops issuing updates, in the same place as the rest of the asset data. It converts a slow invisible decay into a dated item that can be budgeted for, which is the difference between a plan and a surprise.

Sequenced that way the whole thing costs a few weeks of one person's attention and some negotiation with whoever owns the network. What it does not require is a product, a consultancy engagement or an executive sponsor, which is fortunate: this subject has never commanded any of the three, and the estate keeps growing regardless of whether anyone is watching it.

Run the four steps once and the fifth follows on its own: a date in the calendar to run them again. Twelve months is about right, because that is roughly how long it takes for a building project, an acquisition or a departmental purchase to put something new on the network without telling anybody. Put the review in the same cycle as an existing obligation — the insurance renewal, the annual audit — so that it inherits a deadline somebody already respects rather than depending on the goodwill of whoever remembers. Reviews that depend on somebody caring are reviews that happen twice and then stop, and this is a subject where the interval between stopping and finding out is measured in years rather than weeks — long enough that the person who let it lapse has usually moved on before the consequence arrives.

Common questions

What counts as an IoT device?

Anything network-connected that is not a computer, a phone or a server, and that you cannot install your own security software on. Cameras, printers, door controllers, building management, medical equipment, sensors — the defining property is that you cannot inspect it from the inside.

Why are these devices so consistently insecure?

Because the incentives point elsewhere. They are sold on price and features, they are bought once with no expectation of a support contract, and the manufacturer has no commercial reason to maintain firmware for a product line it stopped selling four years ago.

How many devices ship with default credentials?

Around a third, and a similar share have no working update mechanism at all. Those two properties together — unchangeable password, unpatchable firmware — describe the population that every large botnet has been assembled from.

What is the single most useful thing to do?

Network segmentation. It works without the device improving, without the vendor cooperating and without knowing what vulnerabilities the device has. Nothing else on the subject has that property.

How large have IoT botnets become?

Compromised device counts have grown roughly fivefold in a year, into the region of a million nodes, and a single botnet produced a denial-of-service attack measured in the tens of terabits per second. The devices are individually trivial and collectively enormous.

Does the EU Cyber Resilience Act change anything?

It is the first regulation that puts an obligation on the manufacturer rather than the buyer. Reporting duties begin in September 2026, with a 24-hour clock for actively exploited vulnerabilities and full enforcement from December 2027.

What are the penalties under that regime?

Up to fifteen million euros or two and a half per cent of worldwide turnover, whichever is greater. That is the first number in this field large enough to change a manufacturer's product roadmap rather than its marketing.

Should we just avoid connected devices?

Not realistically, and not usefully. The building you occupy probably has connected access control and environmental systems already. The practical question is which ones you know about, where they sit and what they can reach.

How do we find the devices we do not know about?

Passive network discovery finds far more than an asset register does, because the devices that matter most are exactly the ones nobody recorded. A facilities contractor's camera installation is invisible to procurement records and entirely visible on the wire.

What about medical and industrial equipment?

Same problem with the safety consequences attached and much longer replacement cycles. Certified equipment often cannot be patched without revalidation, which makes segmentation the only available control rather than the preferred one.

Is a device safe once it is behind a firewall?

Safer from outside, and unchanged from inside. Most consequential compromises reach these devices from a workstation on the same network, which is why segmentation between internal zones matters more than the perimeter.

How long should we expect firmware support to last?

Ask before buying and get the answer in writing, because the honest default is shorter than the useful life of the hardware. A camera installed today may outlive its firmware support by a decade, and that mismatch is the whole problem in one sentence.

Connected device coverage

553 reports on connected devices and industrial systems, newest first.