What Was IoTUK? The Story of the UK’s National Internet of Things Programme

If you search for “IoTUK”, you may encounter two different things. One is this independent website, which covers industrial IoT, connectivity, edge computing and the practical deployment of connected technology. The other was IoTUK, a government-backed national programme created to accelerate the development and adoption of the Internet of Things in Britain.

The original programme operated during a formative period for the Internet of Things. Connected devices had moved beyond specialist machine-to-machine communications, but the commercial and social implications of connecting millions of sensors, appliances, vehicles, machines and public assets were still being explored.

IoTUK brought together government, research institutions, technology companies, startups, local authorities, health organisations and universities. Its portfolio included a large smart-city demonstrator in Manchester, health and social-care test beds, cybersecurity research, startup accelerators and work intended to encourage collaboration across the emerging UK IoT ecosystem.

Some of the projects ended with the programme. Others evolved, influenced later policy or continued under different identities. Meanwhile, the technology itself moved on. The modern discussion is less concerned with proving that ordinary objects can be connected and more concerned with security, interoperability, edge processing, resilient communications and delivering an economic return from large operational deployments.

So, what was IoTUK, why was it created, what did it do and what happened after the programme finished?

What Was IoTUK?

IoTUK was a national research and innovation programme intended to help advance the UK’s development and adoption of Internet of Things technology for economic and social benefit.

It was not one single trial, one funding competition or one government department. It was an umbrella programme containing several substantial projects, supported by coordination, communications and ecosystem-building activity.

The programme’s formal evaluation documents described five principal components:

• the CityVerve smart-city demonstrator in Manchester;
• a health and social-care test bed focused on dementia;
• a health test bed focused on diabetes management;
• the PETRAS IoT Research Hub, concentrating on privacy, ethics, trust, reliability, acceptability and security;
• central programme coordination intended to connect projects, disseminate knowledge and make the whole programme greater than a collection of unrelated initiatives.

Two startup accelerator schemes were also delivered by R/GA and Startupbootcamp. Each worked with nine IoT businesses, supporting 18 companies in total through intensive three-month programmes.

Digital Catapult and Future Cities Catapult played central roles in coordinating, communicating and connecting the programme. The Catapults were designed to bridge gaps between research, industry and commercial deployment, which made them natural organisations to support an initiative spanning universities, startups, public services and major technology companies.

Before IoTUK: Britain Already Had Connected Machines

The Internet of Things did not begin when the term became fashionable. Long before IoTUK, British utilities, manufacturers, transport operators, security companies and infrastructure providers were already using remote telemetry and machine-to-machine communications.

A water company could monitor a pumping station through a radio or telephone link. An alarm panel could report an event over the mobile network. A vending machine could send stock or fault information. A fleet-management unit could combine GPS with GSM data. Industrial systems could exchange status information through SCADA networks.

These systems were connected, but they were rarely described as part of a universal Internet of Things.

Telemetry came before IoT

Traditional telemetry concentrated on moving a relatively small number of operational measurements from a remote asset to a central system. The communications path might use private radio, leased lines, dial-up modems, packet radio or early cellular data.

The systems were often highly specialised. A utility’s telemetry network was not expected to share a common application platform with a retailer, hospital or smart-building operator.

GSM and GPRS expanded machine-to-machine communications

The arrival of widespread digital mobile coverage made it easier to connect unattended equipment without installing fixed communications infrastructure.

GSM data, SMS and later GPRS allowed devices to report from locations that would previously have required a telephone line or private radio system. This helped create the commercial machine-to-machine market that preceded modern cellular IoT.

The terminology was practical: telemetry units, GSM modems, data loggers, remote terminal units and M2M SIM cards. Much of the work now placed beneath the IoT label was already happening, but usually inside separate industry silos.

Cloud computing changed the scale of the idea

What transformed M2M into the broader IoT movement was not simply a new name. Cloud platforms made it possible to ingest and analyse information from large numbers of devices without every organisation constructing its own central infrastructure.

Smartphones normalised connected sensors and applications. The cost of processing, storage, radio modules and small computing platforms fell. APIs made it easier for systems to exchange information. Investors and governments began to see the possibility of connected technology becoming a general economic platform rather than a collection of specialist engineering applications.

Why the UK Government Created IoTUK

By the middle of the 2010s, the Internet of Things had become a strategic technology issue. The opportunity extended beyond selling devices. Connected systems appeared capable of changing healthcare, transport, energy, manufacturing, urban services and the management of public infrastructure.

The UK already had recognised strengths in telecommunications, semiconductor design, cybersecurity, research, finance, creative technology and data science. The policy challenge was how to turn those capabilities into deployable products, viable companies and public benefit.

Several barriers were becoming clear.

Individual organisations could not prove the whole market alone

IoT systems depend on more than hardware. A successful project may require sensors, wireless coverage, gateways, cloud software, security, data governance, user engagement, integration and a credible commercial model.

A startup developing one component could struggle to gain access to a city, hospital or other environment large enough to demonstrate the complete proposition. Test beds were intended to provide that setting.

Public services needed evidence, not only demonstrations

Connected care, smart transport and urban sensing promised better services and lower costs, but public-sector buyers needed evidence that systems were safe, effective, inclusive and financially sustainable.

A small technical trial could prove that data moved from a sensor to a dashboard. It could not necessarily prove that the service improved a patient’s life, changed an operational process or justified investment at national scale.

Security and trust could not be left until later

The expansion of IoT created obvious questions. Who controlled the data? Could a connected device be updated? What happened when its manufacturer disappeared? How could systems be trusted in homes, streets, hospitals and critical infrastructure?

PETRAS was created within the programme to investigate these broader issues rather than treating security as a narrow networking feature.

The UK wanted to create an investable ecosystem

The programme also had an economic-development purpose. Supporting startups, increasing collaboration and demonstrating substantial applications could attract investment and help UK businesses gain credibility in domestic and international markets.

The ambition was therefore larger than deploying a collection of connected devices. IoTUK was supposed to make the UK’s fragmented capabilities work as an ecosystem.

How the IoTUK Programme Was Organised

The IoTUK structure involved multiple sponsors, delivery bodies and project partners. That reflected the range of subjects covered, but it also made governance complex.

The interim evaluation later observed that the programme’s management and governance arrangements were complex. It also recorded delays during the inception phase, including changes in departmental sponsorship and subsequent government decisions.

This is an important part of the history. National technology programmes rarely operate like a single engineering project. They must align funding, policy, procurement, delivery organisations, researchers and end users, often while government structures and priorities are changing.

IoTUK’s central challenge was to produce something greater than the sum of its constituent projects. A smart-city demonstrator in Manchester, a dementia test bed, university security research and startup support would not automatically become one coherent national programme simply because they shared the IoTUK name.

The IoTUK Timeline

CityVerve: Manchester as an IoT Demonstrator

CityVerve was the most visible smart-city element of IoTUK. Based in Manchester, it was intended to demonstrate how connected technologies could improve services and everyday urban life.

The project explored applications spanning transport, energy, culture, health and the management of the city environment. Rather than placing every application inside a closed proprietary system, the broader ambition involved creating ways for different services and data sources to interact.

This distinction matters. A smart-city project can easily become a collection of unrelated demonstrations: a connected street lamp, a parking sensor, a bus application and an environmental monitor, each operating independently.

The harder problem is creating reusable infrastructure, shared approaches and procurement lessons that make the next deployment easier than the first.

The value of a city-scale test bed

A city provides technical and social complexity that a laboratory cannot reproduce. Wireless coverage changes between streets and buildings. Devices must survive weather, interference, damage and maintenance cycles. Data affects residents who may not have chosen to participate in a technology trial.

Public infrastructure also crosses organisational boundaries. Transport, health, property, highways and emergency services may operate under different budgets, policies and legal responsibilities.

CityVerve therefore mattered not only because of the applications demonstrated, but because it exposed the organisational difficulty of turning “smart city” into an operational capability.

Smart-city lessons remain relevant

Many cities still face the same questions:

• Who owns and maintains the sensor after the pilot ends?
• Which network should connect it?
• Can another supplier use the data?
• How are security updates delivered?
• Does the project reduce cost or improve a measurable outcome?
• What happens when the original grant funding is exhausted?

The technology has improved, but these are commercial and institutional questions rather than radio-engineering problems.

The IoTUK Health and Social-Care Test Beds

Healthcare offered a compelling but difficult setting for IoT. Connected devices appeared capable of helping people manage long-term conditions, supporting carers and allowing services to respond earlier when someone’s situation changed.

The IoTUK programme included two health and social-care test beds. One focused on dementia and support within the home. The other addressed diabetes management.

Dementia and the connected home

The dementia test bed was described as a living-lab environment using combinations of connected technologies in people’s homes.

The promise was not simply remote monitoring. It was to examine whether sensors and digital services could help people remain independent, provide useful information to carers and allow health or social-care professionals to respond more effectively.

This raised questions that remain central to connected care:

• Can the technology be used without adding anxiety or complexity?
• Does it support the person or primarily observe them?
• Who sees the data and under what authority?
• How are false alarms handled?
• Who replaces batteries and investigates communication failures?
• Does the service reduce pressure elsewhere in the care system?

Diabetes management

The diabetes test bed explored how connected technologies and data could help people manage the condition and support more responsive care.

Again, the challenge extended beyond connecting a medical device. A clinically useful system must fit into everyday life, produce information that people and professionals can act upon, protect sensitive data and integrate with existing care pathways.

Healthcare IoT also demonstrates why an apparently successful technical trial may not become a national service. A sensor can work perfectly while the wider service model remains difficult to fund, integrate or operate.

PETRAS: Security, Privacy and Trust

PETRAS was one of the most significant and durable elements associated with IoTUK.

The research hub brought universities and external partners together to investigate cybersecurity, privacy, trust, safety and the wider societal implications of connected systems.

This was important because the IoT market of the mid-2010s was often driven by speed. Manufacturers wanted to connect products, demonstrate applications and reach the market quickly. Long support periods, vulnerability handling and secure-by-design principles were not always treated as commercial priorities.

IoT security is a lifecycle issue

A connected product may remain deployed long after its original software stack becomes outdated. Its credentials may be poorly protected. Its update mechanism may be absent or unreliable. A cloud service on which it depends may close. Default passwords may remain unchanged across thousands of devices.

PETRAS helped move the discussion beyond whether an individual radio link was encrypted. It considered the complete system, including people, organisations, data, hardware, software and the environments in which technology was used.

A legacy beyond the original programme

UKRI records that PETRAS was originally established in 2016 as part of the IoTUK programme and subsequently developed into a recognised national asset. Its work contributed to secure-by-design thinking and continued under later funding arrangements after the original IoTUK funding ended.

This is one of the clearest examples of the programme producing something that outlived the umbrella under which it began.

The UK government’s later consumer IoT security work drew on PETRAS expertise. That illustrates how publicly funded research can influence policy even when the connection is not immediately visible to someone buying a connected product years later.

The IoT Startup Accelerators

The IoTUK portfolio also included two accelerator programmes delivered by R/GA and Startupbootcamp. Each supported nine small IoT businesses during an intensive three-month period in 2017.

Hardware and IoT startups face challenges that do not always apply to purely digital businesses.

• They may need to design, certify and manufacture physical products.
• They must manage component availability and supply chains.
• Connectivity charges continue after the hardware has been sold.
• Field failures can require expensive site visits or product recalls.
• Customers may expect devices to remain supported for many years.
• Security vulnerabilities can affect deployed equipment that cannot easily be recovered.

An accelerator can help a company refine its commercial proposition, reach customers and attract investment. It cannot remove the fundamental difficulty of operating a long-lived connected product estate.

The inclusion of accelerators showed that IoTUK was intended to support commercial capacity as well as public-sector experimentation and academic research.

Did IoTUK Succeed?

There is no useful answer consisting only of yes or no.

IoTUK created activity, supported demonstrators, connected organisations and helped establish research capability. It also experienced governance complexity, delays and the familiar difficulty of proving what a broad innovation programme caused that would not otherwise have happened.

The official interim evaluation was appropriately cautious. It was based partly on monitoring information, consultations and participant reporting while projects were still developing. It therefore concentrated on early outputs, contribution and programme learning rather than claiming a final transformation of the UK economy.

The programme should not be judged only by surviving hardware

It would be misleading to measure IoTUK by asking how many sensors installed during its projects remain online today.

Innovation programmes can produce several forms of value:

• technical knowledge about what works and what fails;
• evidence that changes procurement or policy;
• business relationships and investment;
• research capability and trained specialists;
• open tools, standards or methods;
• lessons that prevent later projects repeating the same mistakes.

A trial that does not become a national deployment may still reveal why the commercial model, user experience or system architecture needs to change.

The “pilot problem” did not disappear

IoTUK also reflects a persistent feature of the IoT industry: it is easier to obtain approval for a visible pilot than for the long-term operating budget that follows.

A pilot can be funded as innovation. A permanent service must compete with other operational priorities. It needs maintenance, cybersecurity, connectivity, technical support, replacement hardware and people who remain accountable after the original project team has moved on.

This is why some IoT demonstrations attract considerable attention without becoming routine infrastructure.

What Happened When IoTUK Ended?

The conclusion of a government programme does not mean that its technologies, organisations or people stop working.

Some projects completed their planned delivery period. Some capabilities continued through successor organisations or further funding. Researchers moved into new programmes. Businesses continued developing products. Local authorities and health organisations carried lessons into later projects.

PETRAS is the clearest example of continuity. UKRI states that IoTUK funding ended in 2018 to 2019, while PETRAS continued and expanded through subsequent investment.

The Catapult landscape also evolved. Future Cities Catapult and Transport Systems Catapult later came together as Connected Places Catapult, reflecting a broader focus on connected transport, places and infrastructure.

The policy agenda moved as well. IoT became less likely to be treated as one standalone category and more likely to appear within programmes addressing manufacturing, cyber resilience, telecoms, digital infrastructure, health innovation, connected places, artificial intelligence and net zero.

This is a sign of maturity. When a technology becomes embedded across sectors, it no longer needs to appear under one universal label in every policy programme.

How the Meaning of IoT Changed After IoTUK

During the peak of early IoT enthusiasm, almost any internet-connected product could be presented as evidence of a revolution. Consumer examples, including connected appliances and home devices, dominated public discussion.

Industrial adoption developed differently. Companies did not usually need to be persuaded that remote data had value. Many had used telemetry for years. Their concerns were more practical:

• How will the equipment communicate from the actual site?
• Who will manage thousands of devices?
• Can the system continue operating when the cloud is unavailable?
• How does it integrate with existing PLCs and SCADA systems?
• Who owns the data and connectivity contract?
• How will security patches be delivered?
• What happens when a mobile network, device or supplier changes?
• Can the project demonstrate a financial or operational return?

As the market matured, several technologies became central to the practical implementation of IoT.

From Cloud-First IoT to Industrial Edge Computing

Many early IoT architectures were drawn as a simple upward flow: sensor, network, cloud, dashboard.

That model was easy to explain, but it ignored what happened when the connection failed, how much data was transmitted and whether a remote application could make a local decision.

Industrial edge computing places processing beside the machine or site. An edge gateway or industrial computer can translate protocols, filter data, run Node-RED flows, host Docker containers, maintain a local database and send selected information to the cloud.

This does not eliminate cloud platforms. It creates a more balanced architecture.

Connectivity Became Part of the Architecture

One of the practical weaknesses of early IoT discussion was the tendency to treat connectivity as a line between two boxes.

Real deployments must choose and manage an actual service. That includes radio coverage, antennas, data plans, roaming behaviour, addressing, VPNs, network security, remote access and the commercial relationship with the connectivity provider.

The growth of 4G and 5G, LPWAN technologies, NB-IoT, LTE-M, private mobile networks, satellite IoT and eSIM has created more options. It has also made design choices more complicated.

A multi-network roaming SIM may improve access to available coverage, but it does not guarantee instantaneous switching or complete resilience. Dual SIM does not necessarily mean two independent networks. A private APN can improve control, but it may also affect how devices can change provider. eSIM can simplify profile changes, but only when the provisioning architecture and recovery process are understood.

This is the modern stage of the IoT market: the industry is no longer asking whether remote equipment can communicate. It is asking how that communication can remain manageable, secure and commercially sustainable across a large estate.

IoT Security Moved from Research to Regulation

During the IoTUK period, security was widely recognised as a concern but many product categories still relied heavily on voluntary practice.

The subsequent direction has been towards clearer secure-by-design principles, defined responsibilities and regulation for connected products.

This evolution supports the original decision to include PETRAS and trust research within IoTUK. Security was not an optional technical workstream. It was one of the conditions required for IoT to move from demonstrations into ordinary homes, public services and infrastructure.

Modern buyers should expect answers to questions such as:

• Does each device have unique credentials?
• How are vulnerabilities reported and corrected?
• For how long will security updates be provided?
• Can firmware updates be authenticated and rolled back?
• Which services and ports are enabled by default?
• How are certificates and cryptographic keys protected?
• What happens to deployed products if the cloud platform closes?

The policy legacy of IoTUK is therefore visible not only in projects that retained the programme name, but in the wider expectation that connected products must be designed and supported responsibly.

The UK IoT Industry Today

The British IoT industry is now difficult to contain within one programme because it spans so many sectors and technical disciplines.

The terminology has also become more specific. Projects are more likely to be described in terms of edge computing, condition monitoring, smart buildings, machine vision, connected transport, private 5G or digital twins rather than being presented simply as “an IoT solution”.

This does not mean IoT has disappeared. It means it has become part of the underlying infrastructure.

What IoTUK Teaches Modern IoT Projects

Why This Website Is Called IoT UK

The existence of the earlier IoTUK programme creates an obvious possibility of confusion. This website is not the continuation of that government initiative and does not claim any institutional relationship with it.

The name is used here in its broader descriptive sense: a publication about the Internet of Things in the United Kingdom.

The original programme concentrated on research, demonstrators, public-sector test beds, ecosystem development and policy-era questions surrounding an emerging technology category.

This website focuses on the practical technology now being selected, installed and operated across the UK:

• industrial cellular routers and gateways;
• 4G, 5G and LPWAN connectivity;
• edge computing and edge AI;
• MQTT, Node-RED, Docker and industrial protocols;
• LoRaWAN and remote sensor networks;
• eSIM and SGP.32;
• RedCap and emerging mobile technologies;
• private networks, VPNs and secure remote access;
• resilient deployments for utilities, transport, manufacturing and other remote assets.

There is nevertheless a natural historical connection between the subjects.

IoTUK represented the period in which Britain was exploring how connected technology might be used at national scale. The modern IoT industry is dealing with the consequences of that idea becoming real.

Did IoTUK End, or Did IoT Become Ordinary?

The original programme ended as a defined funding and coordination initiative. IoT itself did not.

Instead, connected technology became embedded in larger subjects. Industrial digitalisation, smart buildings, energy management, connected transport, remote healthcare, cybersecurity and artificial intelligence all depend on many of the capabilities once grouped broadly beneath the IoT label.

This is what successful infrastructure technologies tend to do. They become less visible as a separate novelty and more important as an ordinary layer beneath other services.

Few organisations now launch a project simply because connecting a device sounds innovative. They connect an asset because remote visibility reduces a site visit, because local analytics identifies a fault, because energy use can be optimised or because a service cannot operate effectively without timely data.

That change from possibility to purpose is one of the clearest signs that the market has matured.

Looking Ahead: The Next Phase of UK IoT

The next phase of UK IoT is likely to be shaped less by the number of connected devices and more by how intelligently and responsibly they operate.

Edge AI

Machine-learning models can now run beside cameras, machines and sensors. This makes it possible to classify events locally and transmit conclusions instead of every piece of raw data.

The opportunity is considerable, but so is the risk of deploying poorly tested models into operational environments. Performance must be assessed under real lighting, weather, vibration, temperature and workload conditions.

RedCap and more appropriate 5G devices

Not every IoT device needs the cost, power consumption or peak performance of a full 5G modem. Reduced Capability technologies are intended to occupy part of the space between high-performance 5G and lower-bandwidth cellular IoT.

This could make 5G architecture relevant to a wider range of industrial gateways, wearables and moderate-bandwidth devices.

eSIM and SGP.32

Remote SIM provisioning has the potential to separate long-lived equipment from one permanently installed connectivity profile. SGP.32 is particularly relevant to constrained IoT devices and fleet-scale management.

The benefit will depend on commercial control and interoperability as much as technical support. A device that contains an eSIM is not automatically independent of its original provider.

Satellite and non-terrestrial networks

LEO satellite systems and cellular non-terrestrial networking may extend coverage to locations where terrestrial service is weak or unavailable.

For many deployments, satellite will complement rather than replace cellular networks, providing coverage diversity or reaching especially remote assets.

Digital product security

The direction of travel is towards clearer obligations for manufacturers and better information for buyers. Long support periods, secure configuration and vulnerability management are becoming procurement requirements rather than optional assurances.

Operational technology and IT will continue to converge

Industrial assets increasingly need access to enterprise analytics and cloud platforms, while IT security teams need visibility of systems previously managed as isolated operational equipment.

Edge platforms, private networks and secure remote access sit directly at this boundary. The architecture must respect both the availability needs of operational technology and the security discipline expected in modern IT.

The Lasting Meaning of IoTUK

IoTUK belongs to a particular moment in British technology policy.

The Internet of Things was becoming a mainstream idea, but its large-scale social and economic value had not yet been established. Government, industry and academia were trying to understand which applications mattered, how businesses could grow and how connected systems could be trusted.

The programme did not settle every question. It could not. IoT was too broad, and many of the hardest barriers were not purely technical.

Its value lay in creating serious experiments, supporting collaboration and giving security, trust and public benefit a place beside commercial ambition.

CityVerve demonstrated the difficulty and potential of connected urban services. The health test beds explored technology in settings where human needs mattered more than novelty. The accelerators supported companies attempting to turn connected ideas into businesses. PETRAS built research capability that continued beyond the original funding period.

The name IoTUK may now be primarily historical, but the subjects beneath it have become more important.

Britain’s current IoT challenge is not to prove that sensors, networks and cloud platforms can be connected. It is to build systems that remain secure, supportable, interoperable and economically useful throughout their real operating lives.

Frequently Asked Questions