The Fifteen-Year IoT Challenge: Can Connected Systems Remain Secure, Resilient and Economically Useful?

An IoT system installed today may still be monitoring a pumping station, controlling a building, reporting from a railway asset or protecting an electricity network in 2041. During those fifteen years, mobile networks will change, cryptographic standards will be replaced, artificial intelligence will transform operations and cyberattacks, suppliers may disappear, software dependencies will become obsolete and the economics of cloud processing may look completely different.

In 2015, connecting a machine, vehicle, meter or public asset to the Internet could still be presented as innovation in itself. A working sensor, communications link and cloud dashboard were often enough to demonstrate success.

That phase is over.

Connectivity is now routinely embedded within industrial gateways, routers, cameras, energy systems, environmental monitors, medical devices and building controls. Cellular networks, Ethernet, Wi-Fi, low-power wide-area technologies, private mobile networks and satellite services provide more communications options than any previous generation of engineers could access.

The difficult part is no longer establishing the first connection.

This question matters because IoT has moved from experimentation into infrastructure. Connected devices now monitor or influence electricity, water, transportation, telecommunications, health, manufacturing, logistics, renewable energy and public buildings.

In these environments, a failed connection is not always a minor inconvenience. It can remove operational visibility, prevent a remote command, suppress an alarm, delay maintenance or affect a physical process.

A device that works perfectly during a three-month pilot may therefore still be a poor infrastructure investment if it cannot be patched in year five, migrated away from a discontinued cloud in year eight or connected after a network closure in year twelve.

Fifteen Years Is a Normal Industrial Lifespan

Fifteen years sounds like an ambitious planning horizon only when viewed through the lifecycle of consumer electronics.

Industrial equipment, utility assets, transport systems, building controls and public infrastructure are commonly expected to remain operational for far longer than a smartphone, laptop or cloud software subscription.

The communications and computing layer is increasingly being attached to assets whose physical lifespan may be measured in decades. This creates a mismatch.

Designing a fifteen-year connected system does not mean predicting every technology that will exist in 2041. It means designing boundaries, interfaces and ownership arrangements that allow change without replacing the whole system.

Critical Infrastructure Changes the Consequences

The UK National Cyber Security Centre describes critical national infrastructure as the national assets essential to the functioning of society, including energy, water, transport, health and telecommunications.

Many connected systems sit below the level of a national operator but still support essential processes. A cellular router at a reservoir, telemetry unit beside a railway, edge computer in a factory or gateway inside a hospital building may appear to be a small component. Its failure can still remove visibility or control from a much larger system.

Cybersecurity in these settings must therefore consider physical consequences as well as data confidentiality.

This is why operational technology cannot simply inherit every assumption from office IT.

An IT security team may regard rapid patching and frequent replacement as normal. An OT operator may be unable to stop a production line, close a pumping station or replace a certified controller whenever a new software release appears.

Availability and safety may take priority over immediate change, but postponing change indefinitely creates accumulating technical and security debt.

Security Is a Lifecycle, Not a Product Feature

Security is often reduced to a list of product features: VPN support, a firewall, encrypted management, signed firmware, secure boot or role-based access.

Those features matter, but none of them guarantees that a system will remain secure for fifteen years.

Long-term security depends on continuing activities:

• maintaining an accurate asset inventory;
• knowing which software and firmware versions are deployed;
• tracking vulnerabilities and supplier advisories;
• rotating credentials and certificates;
• controlling remote access;
• reviewing network exposure;
• monitoring logs and unusual traffic;
• testing backups and recovery procedures;
• reassessing suppliers and dependencies;
• retiring equipment before it becomes indefensible.

The NCSC’s operational-technology guidance emphasises the need to understand connectivity, limit exposure, harden boundaries, control remote access and monitor activity. It also points organisations towards the IEC 62443 zones-and-conduits model, which groups assets with similar security requirements and controls the communications paths between them.

Resilience Is What Happens After Prevention Fails

No serious infrastructure operator should assume that every cyberattack will be prevented, every network will remain available or every cloud service will function continuously.

Security tries to reduce the likelihood of compromise. Resilience limits the consequences and supports recovery.

A resilient connected system should be designed to enter a known, safe and useful state when part of its architecture fails.

Redundancy should not be confused with resilience. Two connections that depend on the same mast, backhaul, power source, cloud region or core platform may provide less independence than their labels suggest.

Likewise, a multi-network SIM may improve access to available radio networks, but it does not automatically protect against every failure in the connectivity provider’s platform, private network, roaming hub or authentication chain.

True resilience requires understanding shared dependencies.

Supportability Is the Forgotten Requirement

A system can remain technically functional while becoming operationally unsupportable.

This happens when nobody can obtain firmware, rebuild the software environment, renew a certificate, explain the configuration or contact a supplier with the knowledge needed to restore service.

Supportability depends on more than a warranty period.

The most supportable architecture is not necessarily the one with the fewest components. It is the one whose components have clear responsibilities, documented interfaces and realistic replacement paths.

Artificial Intelligence Changes Both Sides of the Equation

AI will shape the next fifteen years of connected infrastructure in two opposing ways.

It can improve monitoring, anomaly detection, predictive maintenance, computer vision and automated response. It can also increase the scale, speed and accessibility of cyberattacks.

AI as an operational capability

Edge AI allows devices and gateways to analyse information close to the physical process. A camera can identify an event without streaming every frame to a remote cloud. A vibration sensor can classify abnormal behaviour locally. A gateway can detect changes in industrial telemetry and transmit only relevant events.

This can reduce bandwidth, latency and cloud processing costs. It can also improve resilience because essential analysis can continue during a communications outage.

However, an AI model introduces another lifecycle dependency.

• Who trained it?
• Which data was used?
• How is its performance measured after deployment?
• Can the model be updated without replacing the device?
• How are false positives and false negatives handled?
• Can operators understand why it produced an alert?
• What happens when environmental conditions change?

An AI model that worked during commissioning may drift as machinery wears, operating conditions change or new equipment is introduced.

AI as a cyber threat multiplier

AI can help attackers generate convincing social-engineering messages, analyse stolen documentation, automate vulnerability discovery and adapt malicious activity more quickly.

For critical infrastructure, the concern is not simply a fictional autonomous hacker. It is the reduction in time, cost and expertise required to conduct reconnaissance and build targeted campaigns.

Defenders will also use AI to analyse network behaviour, identify anomalies and prioritise alerts. This creates an increasingly automated contest between detection and evasion.

AI Models Need Their Own Lifecycle Management

Traditional asset management records hardware, firmware, software and network settings. Long-life AI-enabled systems must also record model identity and provenance.

This is particularly important where AI can trigger automated action rather than merely advise an operator.

A fifteen-year system should not assume that the model installed at commissioning will remain suitable throughout the life of the hardware.

Quantum Computing Creates a Migration Problem Today

Quantum computing is often discussed as either an imminent revolution or distant science fiction. Neither extreme is helpful for infrastructure planning.

There is no need to assume that a cryptographically relevant quantum computer will suddenly appear next year. There is also no justification for ignoring quantum risk in systems expected to remain active into the 2040s.

Many widely used public-key cryptographic mechanisms depend on mathematical problems that sufficiently capable quantum computers could solve far more efficiently than conventional machines.

The practical challenge is not only when quantum computers become capable. It is how long migration takes.

NIST finalised its first three principal post-quantum cryptography standards in 2024 and advises organisations to begin transitioning towards quantum-resistant cryptography.

Harvest now, decrypt later

Attackers may collect encrypted information today in the hope of decrypting it when more capable technology becomes available.

This is most relevant where information must remain confidential for many years. Not all industrial telemetry has that requirement, but credentials, network designs, security records, personal information and sensitive infrastructure data may retain value long after interception.

Cryptographic agility matters more than prediction

No procurement team can guarantee which algorithm will be preferred in 2035. It can require that systems support controlled replacement of cryptographic mechanisms.

Cryptographic agility means avoiding the permanent embedding of one algorithm, certificate structure or key-management process where it cannot later be changed.

The correct response to quantum uncertainty is therefore not panic. It is inventory, prioritisation and architectural flexibility.

Connectivity Will Change Before the Asset Does

A fifteen-year deployment beginning in 2026 may experience several changes in public mobile networks, available radio technologies and operator priorities.

The UK’s 3G shutdown has already shown that network generations do not remain available indefinitely. The future of 2G, the evolution of 4G, wider 5G standalone deployment, RedCap, eRedCap, non-terrestrial networks and private mobile infrastructure will all affect device choices.

No one can promise today exactly when every network will close. The architecture should therefore avoid making the whole asset dependent on one non-replaceable modem or radio generation.

Design for modem replacement

Where practical, the communications module should be separable from the sensor, controller or machine it connects.

An external or modular router can often be replaced more easily than a modem permanently embedded in an expensive industrial asset.

Use multiple technologies for genuine requirements

Not every site needs dual cellular, fibre, satellite and private 5G. Resilience should be proportional to the consequence of failure.

For high-consequence locations, diverse technologies may provide stronger resilience than two services of the same type.

Treat SIMs and eSIM profiles as managed assets

Connectivity identity should be included in asset management. Operators need to know which device contains which SIM or eSIM profile, its provider, permitted networks, APN, addressing model, contract terms and migration options.

SGP.32 and other eSIM lifecycle approaches may make provider change easier for constrained IoT devices, but only where commercial control, profile availability and management rights are properly understood.

The Cloud Must Be Optional for Safe Local Operation

Cloud platforms provide enormous value. They support aggregation, fleet management, analytics, remote access, collaboration and scalable storage.

The danger begins when a physical process cannot remain safe or useful without continuous access to a remote service.

Long-life systems should distinguish between functions that require the cloud and functions that must continue locally.

Industrial edge computing makes this separation practical. Local applications can process data, translate protocols, run rules, buffer information and perform AI inference while cloud systems provide management and broader analysis.

The edge is not a replacement for the cloud. It is a way to prevent the cloud from becoming a single point of operational dependency.

Software Dependencies Age Faster Than Hardware

A rugged gateway may remain physically healthy for fifteen years while its operating system, libraries, container images or management agents become unsupported.

This is especially relevant as industrial devices increasingly run Linux, Docker, Python, Node-RED, MQTT brokers and third-party applications.

These capabilities create flexibility, but they also expand the software supply chain.

A long-life software strategy should include:

• a software bill of materials;
• supported operating-system versions;
• signed and authenticated updates;
• a controlled application repository;
• dependency and vulnerability monitoring;
• tested rollback;
• offline recovery images;
• clear end-of-support dates;
• a funded replacement plan.

Containers make applications portable, but a container image is not automatically maintainable. Its base image, libraries and runtime must still receive attention.

Regulation Is Moving Towards Lifecycle Responsibility

Cybersecurity regulation increasingly reflects the principle that digital products must remain protected after sale rather than being treated as finished at shipment.

The EU Cyber Resilience Act establishes horizontal cybersecurity requirements for products with digital elements and places emphasis on secure-by-design development, vulnerability handling and continuing protection through the product lifecycle.

NIS2 creates a wider cybersecurity framework across critical and important sectors in the European Union, covering risk management, governance and incident reporting.

These rules do not apply identically to every UK deployment, and UK organisations must assess their own legal position. However, they influence international manufacturers, supply chains and customer expectations.

For infrastructure owners, the direction of travel is clear: buyers will increasingly expect evidence that connected products have been designed, maintained and supported securely throughout an explicit support period.

Economic Usefulness Is More Than Device Price

Many IoT business cases are built around the purchase price of a sensor, gateway or subscription.

That is rarely the largest cost over fifteen years.

Total cost of ownership can include:

• surveying and installation;
• antennas, enclosures and power;
• SIM and connectivity charges;
• cloud storage and compute;
• device-management licences;
• software development and integration;
• cybersecurity monitoring;
• certificate and credential management;
• firmware testing and deployment;
• site visits and engineer travel;
• replacement stock;
• compliance and auditing;
• migration from obsolete services.

A cheap device that causes two unnecessary site visits can cost more than a higher-quality device with remote diagnostics and recovery.

Likewise, an apparently inexpensive cloud platform can become costly if data volumes grow continuously or if the system cannot be moved elsewhere without redevelopment.

The Cost of Inaction Must Also Be Measured

Lifecycle cost should not be used as an argument against connecting infrastructure.

The correct comparison is between the cost of the connected system and the value it produces or protects.

That value may include:

• avoided breakdowns;
• fewer site visits;
• reduced energy consumption;
• lower water loss;
• improved asset utilisation;
• earlier fault detection;
• better safety;
• regulatory evidence;
• reduced service interruption;
• longer equipment life.

A system remains economically useful when these benefits continue to exceed its operational, support and risk costs.

That calculation should be repeated during the lifecycle rather than performed only before procurement.

Vendor Lock-In Becomes More Expensive With Time

Vendor lock-in is not always avoidable or inherently wrong. Integrated platforms can reduce complexity, improve accountability and deliver better initial performance.

The risk is unmanaged lock-in: discovering years later that data cannot be exported, devices cannot be reconfigured, certificates are controlled by the supplier or integrations depend on undocumented interfaces.

Long-term procurement should distinguish between deliberate dependency and accidental captivity.

The Fifteen-Year Architecture

No single product can guarantee fifteen years of security and value. The objective is an architecture capable of controlled renewal.

That means separating components according to how quickly they are likely to change.

The result is not a static system intended to remain unchanged until 2041. It is a system that can evolve in manageable sections.

New Procurement Questions for Long-Life IoT

Buyers often focus on specifications that are easy to compare: radio category, processor, memory, ingress protection, interface count and purchase price.

Those specifications matter, but they do not answer whether the solution can remain viable.

A Practical Fifteen-Year Readiness Checklist

What Success Should Mean in 2041

A connected system should not be judged successful simply because it transmitted data during commissioning.

Fifteen-year success means that the organisation retained control as technology changed.

The modem may have been replaced. The original cloud dashboard may have disappeared. The AI model may have been retrained several times. Certificates and cryptographic algorithms may have changed. A new integrator may be supporting the deployment.

Yet the physical process remains visible, safe and economically useful because the system was designed for controlled evolution.

From IoT Demonstration to Infrastructure Stewardship

The history of IoTUK illustrates why this matters. As our ten-year assessment of the IoTUK programme found, public innovation programmes were often stronger at funding demonstrations than at creating the operational and commercial structures needed to keep systems running after a pilot ended.

The next generation of connected infrastructure requires a different mindset.

Organisations are no longer merely adopting IoT. They are becoming long-term stewards of distributed computing systems attached to physical assets.

That stewardship includes security, communications, data, software, AI, cryptography, suppliers, skills, compliance and economics.

No one department can own the whole challenge. Engineering, operations, cybersecurity, IT, procurement, finance and senior leadership must share responsibility.

Final Answer: Can Connected Systems Last Fifteen Years?

Yes, but not by accident.

They can remain secure if security is treated as a continuing process rather than a feature selected at purchase.

They can remain resilient if essential functions continue through network, cloud, supplier and cyber failures.

They can remain supportable if configurations, interfaces, software dependencies, credentials and responsibilities are documented and transferable.

They can remain economically useful if lifecycle costs are measured against real operational value rather than hidden behind a low initial device price.

They can adapt to AI and quantum computing if models and cryptographic mechanisms are treated as replaceable parts of the architecture rather than permanent assumptions.

In 2015, proving that a connected device could work was an achievement.

In 2041, the achievement will be proving that it never became an unsupported liability.

Frequently Asked Questions