You’re probably already dealing with IoT, even if nobody in the organisation calls it that.
A hotel group has smart thermostats in rooms, connected door systems, IP cameras, digital signage, occupancy sensors, smart TVs, access points, guest WiFi onboarding, staff tablets, and a building management system from a different supplier again. A retail estate has footfall counters, kiosks, payment devices, security kit, lighting controls, and marketing tools all generating their own data and demanding their own login model.
That’s where the problem starts. Most businesses don’t struggle because they lack connected devices. They struggle because they’ve accumulated too many disconnected ones. Each device family comes with its own console, its own credentials, its own patch cycle, and its own assumptions about who should be allowed on the network.
Internet of things platforms matter because they turn that sprawl into something governable. In venue environments, that usually means three outcomes: fewer operational handoffs, cleaner data, and tighter control over who or what can connect.
The Growing Complexity of a Connected World
A facilities director for a multi-site hotel chain might have one team handling HVAC, another handling CCTV, a third handling WiFi, and an outsourced partner managing guest apps. On paper, every system is “smart”. In practice, nobody has one coherent view of identity, access, device state, or risk.
That fragmentation creates two expensive problems. Operations slow down because every change requires multiple teams. Security weakens because devices and users move between systems that were never designed to share trust.
Smart estates become messy fast
The more sites you add, the worse it gets.
A single venue can often get away with informal workarounds. Someone keeps a spreadsheet of devices. Someone else knows which shared password still works. A third person remembers which contractor installed the cameras. At estate scale, that stops working.
Internet of things platforms exist to solve that coordination problem. They don’t just connect hardware to the cloud. They give IT a way to provision devices, normalise data, enforce policy, and expose useful information to the teams that run the business.
Europe is projected to account for 23% of global IIoT-generated data in 2025, which points to a mature market for connected operations and makes platform decisions more consequential for UK organisations working across smart buildings, retail, and similar environments ( itransition on IIoT data trends ).
For venue operators, the practical issue isn’t “should we adopt IoT?”. It’s “how do we stop a growing device estate becoming an unmanaged identity problem?”
The value sits in coordination
A platform earns its place when it becomes the operational layer between connected things and business decisions.
That might mean:
- Guest access that doesn’t fight the network: authentication is aligned with policy instead of bolted on later.
- Building systems that can be monitored centrally: estates teams can spot faults and exceptions without jumping between vendor consoles.
- Data that’s usable outside engineering: marketing, operations, and compliance teams can work from the same source of truth.
If your team is also looking at how automated decisioning fits around connected systems, this guide to AI agent orchestration is a useful companion because it tackles what happens when multiple software agents need to act on real-world operational data.
For a broader sense of why the device side keeps expanding, Purple’s overview of https://www.purple.ai/en-GB/blogs/how-many-devices-connected-to-internet helps frame the scale of what network teams are being asked to support.
The hard part isn’t attaching one more device. It’s deciding how every user, device, and service should trust each other across hundreds of daily interactions.
What Exactly Is an Internet of Things Platform
The simplest definition is this. An IoT platform is the operating system for a physical environment.
Devices do the sensing and acting. Applications present reports, alerts, workflows, and dashboards. The platform sits in the middle and makes the whole system usable.
More than a device registry
A common mistake is to think an IoT platform is just a place where devices “show up”.
It’s much more than that. A proper platform handles the awkward middle layer that most businesses don’t want to build themselves:
- Provisioning: how a device is enrolled, named, grouped, and assigned policy
- Connectivity: how it communicates using the protocols it supports
- Security: how it proves identity and exchanges data safely
- Normalisation: how raw device data is made consistent enough for reporting and automation
- Integration: how that data reaches CRMs, service desks, analytics tools, and building systems
Without that layer, every project becomes a bespoke integration exercise.
The middleware that makes business outcomes possible
Think about a hotel room thermostat. On its own, it reports temperature and accepts setpoint changes. That’s useful, but limited.
Once it sits on a platform, other systems can react to it. Housekeeping status can trigger room mode. Occupancy signals can alter climate settings. A maintenance rule can raise a ticket when behaviour looks abnormal. Guest access policy can determine whether someone is treated as a resident, visitor, or staff member on the same wireless estate.
That’s where platforms stop being technical plumbing and start affecting cost, service quality, and security.
What it is not
It helps to separate an IoT platform from adjacent tools.
It is not:
- Just a cloud database: storage matters, but storage alone doesn’t manage device identity or policy.
- Just a dashboard: visualisation is one output of the platform, not the platform itself.
- Just the network: WiFi and switching provide transport. The platform provides control, context, and integration.
- Just an app from a device vendor: vendor apps often work well for one product line and poorly across mixed estates.
Working rule: if a solution can’t cope with mixed vendors, changing identities, and cross-system automation, it’s not functioning as a true platform for most enterprise estates.
The best way to judge one is to ask a blunt question. If you added a new site, a new device type, and a new identity source next quarter, would the platform absorb that change cleanly, or would your team end up stitching things together by hand?
That answer usually tells you whether you’re buying a platform or just another console.
Deconstructing the Core IoT Platform Architecture
When people say an IoT platform is “scalable”, they often mean several different layers are doing their job properly at once. If one layer is weak, the whole system feels unreliable.
The architecture below is the practical model often employed.
Device connectivity and management
This is the edge-facing layer. It deals with onboarding devices, assigning identities, handling protocol differences, and maintaining state.
In real estates, this layer has to tolerate awkward realities. Some devices are modern and certificate-friendly. Others are old, fragile, and only barely manageable. Some are fixed assets. Others move around sites. Some send tiny messages. Others stream more demanding data.
Leading cloud platforms show how this works at scale. AWS IoT Core supports over a billion devices through its Device Gateway using MQTT and WebSocket with end-to-end encryption, and its rules model supports real-time processing patterns that Ignitec links to 25% faster guest onboarding in UK venues using edge-cloud hybrids ( Ignitec’s IoT platform comparison ).
That matters because identity decisions often happen here. If this layer can’t quickly validate a device or user and route the event appropriately, everything above it becomes slower or less trustworthy.
Data ingestion and storage
Once devices connect, the next job is to ingest, clean, and store what they send.
Raw IoT data is messy. Different devices report in different formats. Time intervals vary. Naming conventions drift. Some messages are useful. Others are just noise. A decent platform filters and structures data before it lands in storage.
This layer typically has to support both short-term operational needs and longer-term analysis. Operations teams want immediate visibility. Analysts want historical patterns. Compliance teams want retention and control. Those requirements can clash if the platform treats all data the same way.
A good test is whether the platform can distinguish between telemetry that needs instant action and data that only matters later.
Rules and analytics
Connected systems become operational systems.
Rules engines watch incoming events and trigger actions. Analytics layers identify patterns, trends, and anomalies. In venue settings, that could mean a room device state changing after check-in, a sensor generating a facilities ticket, or access policy updating when a staff member changes role in the directory.
The most useful rules are narrow and deliberate. Teams get into trouble when they over-automate early and create hard-to-debug chains of actions across multiple systems.
Application enablement and APIs
No platform survives in isolation. It has to push and pull data from the rest of the business.
That means APIs, connectors, event hooks, reporting outputs, and developer tooling. The application layer is what allows operations, service desk, CRM, identity systems, and analytics tools to consume platform data without every integration becoming a custom project.
In practice, this is also the layer where commercial value becomes visible. If data can’t move cleanly into the systems your teams already use, the platform will feel technically impressive and commercially disappointing.
Security and identity sit across every layer
Security isn’t a box on the side of the diagram. It cuts through the whole stack.
A device identity decision at onboarding affects network policy. Data validation affects analytics quality. Directory integration affects staff access. Revocation affects how quickly risk can be contained.
If a supplier treats identity as a feature rather than a design principle, expect exceptions, workarounds, and more manual admin than you were promised.
That’s especially true in hospitality, healthcare, and retail estates where guests, staff, contractors, and head-office systems all meet on shared infrastructure.
Comparing IoT Platform Deployment Models
The deployment model changes the day-to-day experience more than many buyers expect. Two platforms can look similar in a demo and behave very differently once your team has to maintain them.
The basic choice usually sits between SaaS, PaaS, and on-premise or self-hosted.
What changes with each model
SaaS is the fastest way to get operating value. The supplier runs the platform, handles updates, and abstracts most infrastructure choices away from your team.
PaaS gives you more room to build. You get managed building blocks, but your team still designs and operates a meaningful part of the solution.
On-premise or self-hosted gives maximum environmental control, but it also gives you patching, resilience planning, monitoring, scaling, and the burden of getting every integration right.
IoT Platform Deployment Model Comparison
| Attribute | SaaS (Software as a Service) | PaaS (Platform as a Service) | On-Premise / Self-Hosted |
|---|---|---|---|
| Speed to deploy | Usually fastest. Good for teams that need a live service quickly. | Moderate. Faster than building from scratch, slower than SaaS. | Usually slowest because infrastructure and operations must be designed and maintained internally. |
| Operational overhead | Lowest day-to-day burden for internal IT. | Shared responsibility. Your team still owns significant architecture and integration work. | Highest. Your team runs the platform and carries the support load. |
| Customisation | Often opinionated. Strong for common use cases, less flexible at the edges. | Better for bespoke workflows and custom applications. | Highest theoretical control, but only if you have the resources to use it well. |
| Scalability | Usually straightforward if the supplier has built for multi-site growth. | Strong, but architecture decisions still matter. | Depends heavily on your in-house design and operational maturity. |
| Security responsibility | Shared. Vendor handles platform operations, but you still own policy, identity, and access design. | Shared, with more burden on your team. | Mostly yours. This includes hardening, patching, resilience, and audit readiness. |
| Cost profile | Lower initial friction, recurring subscription cost. | Mixed. Managed infrastructure plus engineering effort. | Higher upfront and ongoing internal maintenance burden. |
| Best fit | Estate teams that want outcomes without building a platform capability internally. | Organisations with development resources and distinct integration needs. | Environments with strict hosting requirements or unusual operational constraints. |
The hidden cost is admin burden
Buyers often over-focus on licence line items and under-focus on operational drag.
Ask who will handle:
- Patch cycles: especially where connected devices and identity policies intersect
- Connector maintenance: between the platform and business systems
- Policy drift: across sites, tenants, and device groups
- Resilience testing: including failure modes when cloud, edge, or identity services become unavailable
A model that looks cheaper can become expensive if your network or infrastructure team ends up acting as the vendor.
For WiFi-heavy estates, this comparison of https://www.purple.ai/en-GB/guides/cloud-managed-vs-controller-wifi is useful because the same trade-off applies. Centralised management often wins not because it’s fashionable, but because it reduces operational friction across distributed sites.
A practical rule for choosing
If your organisation sees IoT as a strategic product capability, PaaS can make sense.
If your organisation sees IoT as an operational capability supporting venues, buildings, customer access, and service delivery, SaaS often aligns better because the business usually wants outcomes, not a new platform engineering function.
Self-hosting fits narrower cases than many teams admit. It can be the right answer, but only when the need for control is real enough to justify the permanent complexity that comes with it.
Securing Your IoT Ecosystem with Identity Management
Most IoT security problems don’t start with exotic malware. They start with weak identity decisions.
A camera gets deployed with a generic credential. A staff tablet keeps access after a role change. A guest access flow is separated from the rest of the trust model. A legacy device gets shoved into a broad network segment because nobody has a better way to handle it.
That’s why perimeter-led thinking fails in connected estates. Once users, contractors, devices, and services all operate across the same physical environment, “inside” and “outside” stop being useful security categories.
Identity first beats perimeter first
An identity-first model asks a better question. Not “is this traffic on the trusted side of the firewall?”, but “what exactly is this thing, who owns it, and what should it be allowed to do right now?”
That applies to:
- Managed staff devices
- Unmanaged guest devices
- Shared devices such as kiosks
- Legacy IoT endpoints
- Service-to-service interactions inside the platform
The platform should act as the policy enforcement point, not just the transport layer.
Why provisioning and revocation matter more than slogans
Zero-trust is easy to say and hard to operationalise.
What matters in practice is whether your platform can provision identities cleanly, apply policy consistently, and revoke access quickly without manual clean-up. If a contractor leaves, if a staff role changes, or if a device fails integrity checks, your team shouldn’t be chasing multiple systems to remove trust.
The risk side is not abstract. Unpatched devices contributed to a 28% rise in IoT cybersecurity incidents reported by the UK’s NCSC in 2025, and platforms with strong OTA update and provisioning capabilities can reduce breach risk by 30%. In venue settings, that translates into safer handling of legacy devices through tools such as iPSK and stronger isolation between tenants and staff identities ( IoT For All on IoT platform components ).
Field observation: the best security control in a busy venue is often the one that removes a manual exception. Humans create workarounds when systems make safe access too hard.
What good identity design looks like
The strongest internet of things platforms usually share a few traits:
- Certificate-aware onboarding: modern devices and users should be able to authenticate without relying on shared passwords.
- Directory integration: staff access should follow the identity source your organisation already trusts.
- Granular policy: a thermostat, a POS device, and a guest handset should never inherit the same assumptions.
- Fast revocation: policy updates should take effect quickly when risk or role changes.
- Legacy containment: old devices still exist, so the platform needs controlled ways to connect them without broad network exposure.
For teams evaluating architecture options in this area, Purple’s guide to https://www.purple.ai/en-GB/guides/identity-based-networking-explained is a useful primer on applying identity-based controls across wireless estates.
One example in this market is Purple, which supports passwordless access for guests and staff, integrates with identity providers such as Entra ID and Okta, and includes multi-tenant controls such as iPSK and SSO isolation for venue environments. That kind of model is often easier to govern than shared-password guest access combined with separate staff authentication tooling.
Security controls must survive real venue conditions
Hospitality and retail environments are messy by nature. Devices arrive from multiple suppliers. Contractors need temporary access. Tenants share infrastructure. Guests expect WiFi to work immediately. Staff rotate, and not all endpoints support modern methods equally well.
That’s why clean theory often collapses on site.
A practical review of common IoT security challenges is worth reading because it reflects the kinds of weaknesses teams inherit when device growth outruns governance.
The right platform doesn’t eliminate complexity. It contains it. It gives each user and device a defensible identity, and it turns access control into an operational process rather than a collection of exceptions.
IoT Platforms in Action Across UK Industries
Most platform discussions become too abstract. The value becomes clearer when you look at how different sectors use the same building blocks for very different goals.
Hospitality
A hotel doesn’t need more disconnected “smart” features. It needs coordinated operations.
A mature setup can connect guest arrival, room state, staff identity, and building controls so that service feels smooth rather than pieced together. The useful outcome isn’t novelty. It’s fewer check-in delays, fewer room readiness issues, and fewer calls to the front desk because systems aren’t arguing with each other.
In this sector, identity matters twice. Guests need low-friction access. Staff need controlled access that changes with role and location. Multi-tenant venues add another layer because house systems, retail concessions, event operations, and guest traffic may all coexist on one estate.
Retail
Retail teams often approach IoT from two directions at once.
Operations want connected devices that improve stock visibility, store maintenance, and site consistency. Commercial teams want better insight into customer movement and dwell patterns. Both depend on a platform that can ingest signals from multiple systems and make them usable without turning the network into a security compromise.
The trap is buying point solutions that each solve one narrow problem. Smart shelves, kiosks, cameras, and WiFi analytics can all work independently while still creating a governance mess.
Healthcare
Healthcare is where “easy access” and “secure access” need the most careful balance.
Remote monitoring, connected clinical devices, and digital patient services all sound straightforward until the authentication flow excludes part of the patient population. That’s not a side issue. It can derail the whole programme.
A critical challenge in the UK is digital exclusion. An estimated 22% of UK adults lack basic digital skills, and a 2025 Deloitte UK survey found 40% of IoT pilots in UK hospitals failed due to usability barriers, which makes clumsy captive portals and smartphone-dependent workflows a genuine operational risk, not just a poor design choice ( The King’s Fund on digital exclusion in health care ).
In healthcare, a platform isn’t successful because it’s feature-rich. It’s successful when patients, visitors, clinicians, and devices can all use it safely without avoidable friction.
That has direct implications for authentication. If access assumes every patient has the same digital confidence, the platform can widen inequality while claiming to modernise care.
Residential and managed living
Build-to-rent, student housing, and other managed residential environments sit somewhere between enterprise networking and hospitality.
Residents expect home-like simplicity. Operators need estate-wide control. Contractors, staff, communal devices, and resident endpoints all need different treatment. Traditional shared credentials don’t scale well here because they blur accountability and create constant support work.
The right platform turns this into policy instead of improvisation. Resident access can feel simple while back-end controls remain segmented and auditable.
How to Evaluate and Choose the Right Platform
Buying an IoT platform is rarely a pure technology decision. It’s a long-term operating model decision.
The biggest mistakes usually happen when teams score feature lists instead of testing how the platform behaves in their actual environment. A polished demo can hide weak provisioning, awkward integrations, or security controls that break down in multi-tenant use.
Start with your operating reality
Before you compare suppliers, define the environment realistically.
List the things that usually get glossed over:
- Mixed hardware estate: include access points, legacy IoT, contractor-installed kit, and shared devices
- Identity environment: note whether you already depend on Entra ID, Okta, Google Workspace, or multiple sources
- Site model: single-tenant, multi-tenant, franchised, managed, or mixed
- Business users: who needs the data and what action they’ll take from it
- Support model: who will own incidents, policy changes, and onboarding after go-live
If you skip this step, you’ll buy for the ideal estate instead of the one you run.
Evaluate the parts that create admin load
A supplier may look strong on core connectivity while being weak on governance.
For UK hospitality in particular, multi-tenant security is a key evaluation gap despite 25% year-on-year growth in IoT adoption, and platforms need support for controls such as iPSK for legacy devices and SSO for staff in shared hotel environments. Gartner also notes that legacy RADIUS models cost twice as much to maintain, which is why passwordless approaches deserve serious scrutiny where operational simplicity affects ROI ( NIST-hosted document referencing this hospitality evaluation gap ).
That should change what you test.
Don’t just ask whether the platform supports a feature. Ask how much admin that feature creates.
The questions worth asking in vendor sessions
Use live scenarios, not generic prompts.
Ask the vendor to show:
Device onboarding for a new site
Include one modern device class and one legacy class. Watch how identity, naming, grouping, and policy are applied.
A staff role change
You want to see how access changes when directory attributes change. If revocation takes manual work, that’s a warning.
A guest or visitor flow
In venue businesses, friction at first connection becomes an operational issue quickly.
A multi-tenant policy split
Ask how the platform separates one tenant, concession, or department from another without creating VLAN sprawl and exception handling.
Integration into your existing tools
This includes service desk workflows, CRM connectors, and export or API quality.
Buying advice: if a vendor can’t demonstrate a realistic exception case, they probably expect your team to solve it after procurement.
A practical scoring checklist
You can turn procurement conversations into a workable scorecard with a short checklist.
- Identity control: Can the platform authenticate both users and devices with methods appropriate to each?
- Revocation speed: When a role or device state changes, how quickly does policy update?
- Legacy support: Can older devices be handled safely without broad shared credentials?
- Multi-tenant isolation: Can staff, guests, tenants, and operational systems coexist without policy overlap?
- Vendor interoperability: Does it work with your network estate and business systems without brittle custom work?
- Operational clarity: Can your support team understand and manage it day to day?
- Deployment effort: Is the path to production realistic for your internal resource levels?
- Reporting and insight: Can non-network teams use the outputs to make decisions?
- Support quality: Is there credible implementation help, documentation, and escalation when things go wrong?
- True cost: What will this require in internal time, maintenance, and exception handling over the life of the contract?
The right choice is usually the platform that removes the most ongoing friction while keeping identity and policy under control. That’s what protects margin, reduces support drag, and makes connected estates manageable at scale.
If your team is trying to replace shared passwords, simplify guest and staff access, and apply identity-based controls across multi-tenant venues, Purple is worth a look. It focuses on secure, passwordless WiFi authentication and identity-based networking for hospitality, retail, healthcare, transport, events, and residential environments, with support for OpenRoaming, Passpoint, directory integrations, analytics, and legacy device controls such as iPSK.
