Internet of things and internet of everything explained

Connect more devices. That's the standard advice, and it's wrong on its own. A building can add sensors for years and still not know who owns them, which readings belong to which room, or what anyone should do when a value changes.

The Internet of Things and Internet of Everything distinction matters because it separates collection from coordination. IoT gives you signals from physical things. IoE asks whether those signals are tied to a person, a place and a process you can trust, measure and act on. If you can't answer that, more endpoints usually mean more dashboards, more passwords and more unowned risk.

IoT and IoE Compared at a Glance

What the rows are really saying

Start with core idea and scope. IoT is the sensing layer, the meter, tracker, lock, camera or machine that reports a state. IoE keeps that layer and adds the guest in the room, the resident in the flat, the member of staff on shift, and the workflow that should respond.

Architecture follows from scope. A typical IoT estate needs a device, a connection and somewhere to store readings. An IoE estate also needs an identity layer that can say this sensor belongs to that room, this session belongs to that person, and this contractor's access ends today. Without that join, you've got telemetry, not a service.

Data flow changes too. IoT often sends one stream to one platform, which is fine for asset visibility. IoE correlates streams that were designed separately, for example access, occupancy and energy, so a pattern in one explains a cost in another. That's why questions about how many devices are connected to the internet are useful as context but weak as a strategy. A count doesn't tell you whether any of those devices can be trusted or acted on.

Every IoE estate contains IoT. Not every IoT deployment earns the wider label.

A Spectrum, Not Two Products

Cisco promoted Internet of Everything as a broader framing than the older, narrower IoT term, putting connected people and processes alongside devices. Treat that as a design lens, not a product category you buy instead of sensors. Most estates sit somewhere along the spectrum, with mature device reporting and patchy identity.

Security shows the gap most clearly. Device hardening asks whether firmware is current and traffic is segmented. IoE security asks who or what holds permission at this moment, how that permission was granted, and how quickly you can remove it. Business value shifts in parallel, from knowing an asset exists to proving an outcome such as lower energy waste or a returning guest.

Try a quick test on your own estate. If your main question is whether a device is online and reporting, you're running IoT, however many units you've installed. If your question is who or what should be trusted, where, and what should happen next, you're designing for IoE.

How data moves from sensor to decision

The five stages in order

Stage one, endpoint. A sensor captures a small fact, such as temperature, power draw, door state or location. Good endpoints are boring by design. They measure consistently, use little power and don't try to run your business logic.

Stage two, gateway or connectivity. That fact travels over WiFi, mobile, low-power radio or a wired link, often via a gateway that translates protocols and buffers data during an outage. Access control hardware is a useful everyday illustration, and resources on how cellular gate openers work show the same pattern in miniature, a local event, a network hop and a remote decision about whether to act.

Stage three, cloud platform. Readings land in storage, get time-stamped, routed and retained. Many deployments stop here and call the dashboard the product. You've gained visibility, but nobody has yet decided whether the source is entitled to trigger anything.

Stage four, identity check. The platform verifies the device, the user, the application and, where relevant, the location. This is the hinge between IoT and IoE. A valid reading from an unknown sensor in the wrong room shouldn't drive a bill, open a door or raise a job.

Stage five, analytics and workflow. Correlated, trusted data triggers an action. That might be a maintenance ticket, a heating adjustment, a housekeeping task or a report a client can invoice against. If stage five is a person exporting a spreadsheet each Friday, the system hasn't finished the journey.

What UK traffic patterns tell you

Scale doesn't behave the way broadband intuition suggests. The Ofcom Connected Nations UK Report 2025 put the UK's mobile-network IoT estate at approximately 27.7 million active connections in 2025, growing 4% year over year, while monthly IoT traffic increased only 2% to about 2 petabytes.

The year before shows the same shape at a different pace. The Ofcom Connected Nations UK Report 2024 reported active IoT connections on UK mobile-network operator networks exceeded 26.5 million in 2024, representing a 6.5% increase from the previous year, and IoT data traffic increased by 11% to 1.96 petabytes per month.

Most sensors send small, periodic measurements, while gateways or cloud platforms handle aggregation and analytics. Plan for connection density, signalling overhead, coverage, battery life and failover separately from peak Mbps. A venue doesn't fail because a thousand sensors need smartphone bandwidth. It fails because they all wake, authenticate and retry at once in a concrete stairwell with weak coverage.

Use the gap as a commercial test. If connections grow faster than traffic, you're probably adding genuine endpoints. If traffic grows faster, inspect the design first, because chatty firmware, oversized payloads or constant polling can hide poor engineering behind a rising data bill.

Why IoE adds people and processes to devices

A smart thermostat on its own is IoT. It reports temperature and accepts a set point. Useful, but it doesn't know whether the room is sold, occupied, being cleaned or empty for a week.

Now place that thermostat in a hotel where the door lock, booking system, housekeeping app and guest profile share one identity layer. Check-in warms the room. Check-out sets it back, ends WiFi access and raises a housekeeping task. That's IoE, not because the hotel bought cleverer hardware, but because each signal has an owner and a consequence.

Three layers, four additions

The first layer is connected endpoints, such as sensors, locks and meters. The second is people and places, including guests, staff, residents and rooms. The third is process, the rule that turns a vacated-room event into a cleaned room rather than a red dot on a screen.

• Identity: Each device and person has a known owner, so access can be granted and withdrawn deliberately.
• Context: Readings are tied to a room, unit or site, not floating as serial numbers.
• Workflow: Data triggers a task with an owner, a deadline and a completion state.
• Measurement: Each use case carries an outcome metric, so you can tell whether the connection earned its keep.

The term comes with inflated history. The UK government digital economy phase 2 report records that UK-focused analysis of Cisco's Internet of Everything concept in 2014 projected 50 billion things would be connected globally by 2020, estimated a potential worldwide economic opportunity of £19 trillion, and stated only about 1% of things were connected at the time. Those were global projections, useful for understanding how the idea was sold, not as a planning baseline for your next site.

The same government framework estimated 2024 digital-economy gross value added at £286.325 billion, approximately 13% of total UK gross value added, with 311,800 enterprises active in the digital economy. That scale explains why the framing survived its forecasts. The difference between IoT and IoE lies in what the system is used for, not in how many devices it contains.

Securing devices, people and permissions together

Patch the device and you're secure. That assumption is where estates get hurt. A hardened sensor with a permanent, over-broad credential is still a standing invitation if nobody can prove who owns it, where it belongs or when its access should end.

The UK Government collection on cyber security in enterprise connected devices says connected devices are commonplace in organisations, vulnerabilities are regularly found, and many organisations lack clarity about how to monitor and protect them. It also warns that a compromised enterprise device can provide access to the wider corporate network. In plain terms, the printer, controller or building sensor you forgot can become the route in.

From hardening to trust decisions

IoT security concentrates on the endpoint. Update firmware, change default credentials, segment traffic and monitor for faults. You still need all of that. It just doesn't answer the wider question.

IoE security decides which person, device, application and location should be trusted at a given moment. A cleaner's tablet may be legitimate at midday in one block and suspicious at midnight in another. A third-party heating controller may need telemetry access and nothing else. Trust becomes conditional, time-bound and reviewable, which is the practical logic behind a zero trust approach to network access.

Working rule: If you can't revoke it, you haven't governed it. You've merely installed it.

Four questions with a test for each

1. How are identities provisioned and revoked? Every person and device needs a named owner, a start condition and an end condition. Test it by creating one test device identity, revoking it, and timing how long its access takes to disappear from every system, not just the console where you clicked delete. If the answer is unclear, your leaver process is a hope.

2. How do you isolate a device without disrupting operations? Quarantine should narrow a suspect endpoint to a safe segment while the room, ward or production line keeps working. Test it during a quiet period by isolating a non-critical sensor and confirming that neighbouring services, alerts and staff access behave as documented. Don't discover your isolation plan during an incident.

3. How are guest, staff and machine identities kept separate? These groups have different lifecycles, risk and support needs, so they shouldn't share one flat network or one shared password. Test separation by joining as a guest and attempting, with permission, to discover a staff device and a machine endpoint. Any visibility you didn't intend is a finding, not a curiosity.

4. Who is responsible when a third-party sensor or building system is compromised? Contracts and runbooks should name who can disconnect it, who patches it, who informs affected users and who pays for the workaround. Test ownership with a tabletop exercise using one real supplier device. If three teams assume another team owns it, you've found the vulnerability before an attacker does.

Governance You Can Measure

Turn each answer into a number. Time to revoke, percentage of endpoints with a named owner, number of orphaned identities found per review, and time to isolate are all measurable. Report them alongside uptime and ticket volume so governance competes for attention on equal terms.

Adding devices doesn't add value by itself, and it certainly doesn't add trust. Data can't support a decision unless each identity behind it has a clear owner. Governance is therefore the condition for any IoE benefit, not paperwork you complete after the benefits arrive.

Where IoE pays off in four sectors

Read each row as a buying test. The first column names the estate, the second names what you'd connect, the third forces you to state the proof, and the fourth names the failure that can erase the gain. None of these pays off because a device got connected. Each pays off when an identity, a permission and an owner line up around a decision. The table below sets out where IoE questions tend to arise and what to measure in each case, and the sectors we support through partners page covers the venue, housing and managed-network markets Purple serves.

Hotels and restaurants

A hotel earns IoE value when a guest session, a room and a transaction can be understood as one stay, with consent. Guest WiFi shows arrival and return patterns, room systems show comfort and energy use, and point-of-sale data shows whether a visit produced revenue. Track repeat visits and spend per guest, because raw session counts flatter busy lobbies full of people who never buy anything.

Restaurants can run a smaller version of the same join. A returning diner who uses WiFi, books again and spends more over time is evidence. A large database of email addresses with no visit history is just storage, plus a consent obligation you've taken on for no return.

The join only works if the same guest is recognised as the same identity across all three sources. Three disconnected records produce three wrong answers that look like data.

Multi-Tenant housing and student accommodation

Here the product is a private home network at building scale. Each resident expects their phone, laptop, console and smart TV to find each other, and expects the flat next door to see none of them. Building systems such as door entry, heating and laundry sit alongside that expectation, not inside it.

Measure support workload and resident satisfaction together. Fewer tickets mean little if residents have stopped reporting problems and started leaving bad reviews. The main risk, cross-unit access if isolation fails, is existential for trust, so test it per unit rather than sampling a show flat and generalising.

Retail and venues

Footfall sensors count movement, guest WiFi can distinguish a first visit from a return, and signage can react to time, queue length or event schedules. The useful metrics are dwell time and return rate, because a crowd that passes through once tells a different story from a smaller group that stays and comes back. Agree data ownership with sensor suppliers before installation. If a third party can withhold the feed at renewal, your reporting history has a landlord.

Network carriers and managed connectivity

Carriers and managed providers sell the substrate everyone else builds on. Their discipline is active connections and traffic per device, watched together so endpoint growth and data growth don't get confused. The risk is overload from unmanaged endpoints, devices nobody inventoried that still authenticate, retry and consume support time. A managed offer that includes identity and lifecycle control is easier to renew than bare connectivity a client can price against any SIM.

Why Correlation beats another sensor

UK built-environment research hosted by the University of Salford repository finds that combining smart-meter data with complementary IoT streams, such as indoor temperature, weather, and occupancy, substantially improves digital energy-performance analytics. Consumption shows what energy was used. Occupancy explains why demand occurred. Environmental measurements help you separate a building defect from normal variation.

That combination can flag an occupied room with abnormal heating demand and trigger a maintenance workflow, rather than leaving an energy manager to spot a spike weeks later. The gain comes from joining identities and permissions across streams, not from the extra sensors. Where a site has no baseline yet, treat the first period as the test. Inventing a savings figure before you've measured one is how IoE projects lose credibility at the first finance review.

How to roll out IoE without creating silos

Connecting more systems makes an organisation less efficient when each device, tenant, contractor or platform creates another silo, another unclear owner or another manual onboarding process. That isn't a pessimistic view. It's what UK deployment evidence keeps pointing at.

UK-focused smart city and built-environment research indexed by Western Sydney University researchers identifies data interoperability, industry readiness, cybersecurity and data governance as major barriers to integrating BIM and IoT under the Digital Built Britain agenda. Connectivity is on the list, but it isn't the hard part. Agreement on identifiers, owners and permissions is.

Six steps in an order that protects you

1. Map every endpoint and name an owner for each. Walk the estate physically and logically, including the contractor-installed controller nobody put on the asset register. The common slip is recording a department instead of a person. Departments don't patch devices at 2 a.m., people do.

2. Assign persistent asset and space identifiers before any analytics. A room, unit and device should keep the same identifier when tenants change and hardware is swapped. Skip this and your dashboards will double-count one room under three names. Nobody can reconcile a trend built on shifting labels.

3. Standardise time-series schemas and synchronise timestamps. Decide field names, units and sampling intervals across meters, sensors and platforms, and keep clocks aligned. Correlation collapses if one system logs midnight as another system's 11 p.m. The slip is buying analytics first and asking the tool to forgive inconsistent inputs. It won't.

4. Apply role-based access from the start. Keep resident, visitor, employee and device traffic apart, with permissions matched to each role's lifecycle. Retrofitting separation after hundreds of users have joined one shared network means re-onboarding everyone under pressure. Doing it first is an afternoon of design.

Separate first, analyse second. Reversing that order is how a pilot becomes a migration.

5. Integrate existing networks rather than replacing them. Rip-and-replace flatters vendors and punishes clients who've already paid for working infrastructure. We are hardware agnostic and deploy as a cloud-based overlay on a client's existing WiFi infrastructure, and in most cases no additional hardware is required. The wider principle holds whoever you buy from. Avoid locking the estate to one hardware ecosystem unless the client understands the exit cost.

6. Set one outcome metric per use case and review it after 90 days. Repeat visits, energy reduction or support workload, pick one and write down the baseline before go-live. Teams slip by tracking twelve metrics, which guarantees at least one improves by chance. One metric forces an honest conversation about whether the connection changed anything.

Repeatability is the Partner Advantage

A repeatable rollout is worth more than a heroic one. The same owner map, identifier scheme, access model and metric template should move from site to site with local adjustments only where the building differs significantly. That's how an IoE project becomes a practice rather than a series of bespoke rescues. Install sensors last in your thinking, even if they arrive first in the post.

Pick One Identity-Based Pilot to start

Don't launch an estate-wide programme. Pick one site and one flow where identity already hurts. A single hotel floor, one student block or one retail location is large enough to expose real behaviour and small enough that you can still name every owner involved.

Choose a flow with a clear join and leaver moment. Guest WiFi linked to a room works because occupancy starts and ends on known dates. Resident devices isolated per unit works because tenancy gives you the same clean boundary. Avoid starting with the building system nobody owns. You'll spend the pilot negotiating instead of learning.

Three questions to answer before go-live

• Who owns each identity? Name the person responsible for provisioning, review and removal for guests, staff and devices, including supplier-managed kit.
• What outcome will you measure after 90 days? One metric, one baseline, one review date in the diary before launch.
• How will access be revoked when a person or device leaves? Describe the trigger, such as check-out, tenancy end or directory removal, and prove removal with a test identity.

If any answer is vague, delay go-live rather than shrink the question. These three decisions set the scope of everything that follows, so they come before any equipment purchase. Hardware bought to force momentum usually becomes the constraint you're working around in month four.

Why Identity-Based WiFi Fits the pilot

WiFi is where people, devices and places already meet, which makes it a honest test bed for IoE governance. Multi-tenant WiFi gives each tenant their own private network, with secure per-unit isolation for residents and guests across Build-to-Rent, student accommodation, and multi-dwelling units. Run that model in one block and you're testing provisioning, isolation, revocation and support demand in a single contained place.

The monetisation route sits downstream of trust. Once each session is tied to a verified identity, operators can offer targeted guest services, loyalty offers and sponsored content, and report repeat visits and spend per guest. That only works where guests have given clear consent and the data use matches what they agreed to. Consent captured carelessly doesn't become an asset. It becomes a complaint with a paper trail.

Partner Actions in order

First, confirm the owner map and the single metric, using the same discipline you'd apply at full scale. Second, agree consent wording with the site in plain language a guest or resident would recognise as fair. Third, run the pilot for the full period without expanding its scope in ways that go unannounced. Fourth, review the outcome, including revocation and isolation test results, before extending to further sites.

A pilot that proves identity, isolation and one measured outcome gives you something a device count never will. It gives the client a reason to fund phase two, and gives you a pattern you can repeat without starting from conjecture each time.

Turn one site into an identity-based pilot with measurable guest, staff and multi-tenant outcomes, using the WiFi infrastructure your client already runs. See how Purple helps partners deliver smooth access, per-unit isolation and reporting clients can act on, then start with the floor or block that's causing the most support pain today.