A lot of teams are in the same position right now. The building has smart locks, occupancy sensors, cameras, digital signage, HVAC controls, kiosks, tablets, payment terminals, guest WiFi , staff devices, and a handful of systems bought by different departments at different times. Everything is connected, but not necessarily connected well.
That’s where internet of things architecture stops being an abstract diagram and becomes an operating model. If the architecture is weak, devices end up in silos, data arrives too late, identity is inconsistent, and security depends on luck. If the architecture is sound, the same estate becomes easier to secure, easier to support, and much more useful to the business.
What Is IoT Architecture and Why It Matters Now
A hotel director sees one problem. Guests want fast WiFi, rooms should be energy efficient, staff should move between systems without friction, and connected devices should just work. An IT director sees the underlying issue. All of those outcomes depend on whether the organisation has a coherent architecture for devices, connectivity, processing, access, and applications.
IoT architecture is the blueprint that defines how physical devices collect data, how that data moves, where it’s processed, how systems act on it, and who is allowed to interact with each part. In practice, it answers the questions that make or break operations. Which network does a thermostat join. Where is camera footage analysed. How does a legacy sensor authenticate. What happens when a contractor leaves. How do guest devices stay isolated from clinical systems or back-office tools.
The urgency is real in the UK. The growth of connected estates isn’t theoretical anymore. The UK had over 1.2 billion IoT connections in 2023, a 35% increase from 2022, and 77% of UK businesses reported cyber threats to their IoT systems, according to the cited overview of IoT architecture and UK adoption trends at GeeksforGeeks .
That combination changes the conversation. Scale without structure creates operational drag. Scale with structure creates advantage.
Architecture is what turns devices into a system
Most failed IoT programmes don’t fail because the sensors were bad. They fail because the surrounding design was weak.
A workable architecture gives you:
- Clear separation of roles: devices collect, networks transport, gateways process, applications present, and identity controls access.
- Predictable security boundaries: guest traffic, staff access, and machine traffic aren’t mixed together.
- Operational consistency: onboarding, revocation, monitoring, and troubleshooting follow a repeatable pattern.
- Business usefulness: data reaches the systems that can act on it, whether that’s a BMS, a CRM, or a service desk.
Practical rule: If a connected device can be added only by “making an exception”, the architecture isn’t mature yet.
If you want a sense of how quickly connected estates are expanding, this overview of how many devices are connected to the internet is a useful business-level reference point.
The Foundational Layers of IoT Architecture
To easily understand internet of things architecture, imagine it as a building. Each floor has a distinct purpose. If the lower floors are unstable, the penthouse doesn’t matter.
Perception layer
This is the ground floor. It contains the physical things that sense or act.
That includes occupancy sensors, thermostats, cameras, smart locks, medical monitors, environmental probes, kiosks, payment terminals, and actuators. These devices generate the raw signals the rest of the stack depends on.
The main design concern here isn’t just device choice. It’s trustworthiness. Cheap sensors with weak firmware, poor update paths, or limited identity support create problems that can’t be fully fixed later in the stack. In hospitality and retail, teams often inherit a mixed estate of modern and legacy devices. The architecture has to absorb that reality rather than assume a clean slate.
Network layer
This is the building’s wiring and plumbing. It moves data between devices, gateways, platforms, and applications.
The network layer covers the transport path, wireless and wired connectivity, gateway placement, traffic isolation, and the rules that determine which systems can talk to which. In a hospital, that might mean keeping patient monitoring flows apart from guest internet access. In retail, it might mean separating point-of-sale traffic from occupancy analytics and public WiFi.
A strong network layer does three things well:
- Connects reliably: devices stay online without constant manual intervention.
- Segments correctly: compromise in one zone doesn’t spill into another.
- Supports the right protocol mix: constrained devices and enterprise applications don’t have the same transport needs.
Edge computing layer
This is the local utility room. It sits close to the devices and handles time-sensitive or bandwidth-heavy tasks before traffic moves upstream.
Edge gateways filter noise, normalise data, apply local policy, and sometimes make immediate decisions. That matters in environments where waiting on a round trip to a distant cloud service is a bad design choice. A door controller, for example, shouldn’t depend on a slow external path to decide whether a credential is valid. A building alert shouldn’t be delayed because a gateway forwarded every raw event instead of processing locally.
Push decisions closer to the event when delay, bandwidth use, or privacy become operational risks.
Cloud and data processing layer
This is the central control room. It aggregates information from multiple sites, stores it, correlates it, and feeds analytics or business workflows.
The cloud layer is where organisations unify estate-wide visibility. It’s also where they often create accidental complexity. If every device sends everything upstream with no filtering, teams pay for unnecessary transport and storage while making dashboards noisier and incident response slower.
This layer is best used for workloads that benefit from centralisation:
- Cross-site reporting: comparing performance across venues or buildings
- Historical analysis: spotting trends in occupancy, asset usage, or service quality
- Business integrations: linking IoT events into ticketing, CRM, automation, or data platforms
Application layer
This is the part users see. Dashboards, service portals, alerts, building management interfaces, staff apps, and reporting tools all live here.
If the application layer is poor, stakeholders assume the whole programme is poor. A clean backend doesn’t help much if facilities teams can’t act on alarms, front-of-house teams can’t see room readiness, or operations managers can’t distinguish between genuine incidents and background noise.
The best application layer presents only what each audience needs. Network teams need telemetry and policy visibility. Venue managers need operational summaries. Clinical or hospitality staff need workflows, not packet-level detail.
For a related view on how platforms bring these layers together, this guide to internet of things platforms is worth reading.
Navigating IoT Communication Protocols
Protocol choice is where internet of things architecture becomes very practical. Teams don’t pick MQTT, CoAP, or AMQP because one sounds more modern than the others. They pick them because each solves a different problem.
The wrong protocol doesn’t always fail immediately. More often, it creates friction. Devices drain batteries too quickly. Gateways carry unnecessary chatter. Integrations become brittle. Security controls end up bolted on instead of built in.
Start with the operating conditions
A battery-powered occupancy sensor in a hotel room has very different needs from a backend workflow passing events into a CRM or marketing automation system. One wants a lightweight, efficient exchange. The other wants durable, reliable server-to-server messaging.
The cited protocol overview from Intetics puts the distinction clearly. MQTT is designed for low-power data collection, CoAP fits constrained devices, and AMQP is suited to server-to-server exchanges. The same source also notes that MQTT’s pub-sub model can handle thousands of concurrent connections, which matters in venues operating hundreds of access points and many connected endpoints.
Comparison of Common IoT Communication Protocols
| Protocol | Transport | Key Feature | Best For |
|---|---|---|---|
| MQTT | TCP/IP | Lightweight publish-subscribe messaging | Low-power sensors, telemetry, venue-wide device events |
| CoAP | UDP/IP | Minimal overhead for constrained devices | Memory-constrained or battery-sensitive endpoints |
| AMQP | Typically TCP/IP | Reliable asynchronous queuing and brokered delivery | Server-to-server workflows, enterprise integrations |
| DDS | Typically over IP networks | Real-time distributed communication | Environments that need fast peer-to-peer data exchange |
What works well in real deployments
MQTT is often the safest default for telemetry-heavy estates. It works well when many devices report small packets frequently and you need scalable fan-out to multiple subscribers. In a retail centre or hotel, that could include room sensors, occupancy counters, or environmental monitoring feeding multiple downstream systems.
CoAP fits devices with very limited power or memory budgets. If the estate includes simple sensors that need to conserve battery life and exchange modest data, CoAP is a logical fit. It’s less forgiving if your teams aren’t disciplined about device lifecycle management and observability, because constrained devices can be harder to troubleshoot.
AMQP belongs higher in the stack. It isn’t usually the first choice for tiny edge devices, but it makes sense for reliable asynchronous handoff between business systems. If an event needs to move from an IoT platform into booking, CRM, service management, or analytics workflows, AMQP is often easier to govern than trying to stretch a device-oriented protocol into an enterprise messaging role.
Security and scalability are protocol decisions too
Protocol selection affects more than message format. It shapes the security model and operating overhead.
A sound design usually includes:
- Encrypted transport: use TLS/SSL where the protocol and device support it.
- Segmentation by function: isolate device classes and message paths.
- Monitoring by behaviour: watch for unusual connection patterns, not just device presence.
- Broker or gateway discipline: avoid allowing every device to communicate broadly.
A protocol that is lightweight but poorly governed becomes expensive in support hours.
A common mistake is chasing standardisation too aggressively. Some teams try to force one protocol across every layer because it feels simpler. In practice, that usually moves complexity elsewhere. A mixed environment often performs better when the device layer uses a lightweight protocol and upstream integrations use a more robust messaging model.
The Critical Role of the Edge Computing Layer
Cloud-first thinking still shows up in a lot of IoT discussions, but cloud-only design doesn’t hold up well in busy physical environments. The moment your devices support operations in real time, the edge computing layer becomes part of the core architecture, not an optional enhancement.
The reason is straightforward. Local decisions are often better than distant ones. A building gateway can filter, aggregate, and act on data before it ever leaves the site. That reduces delay, limits unnecessary backhaul traffic, and keeps sensitive processing closer to where the event occurred.
Why the edge matters operationally
The UK shift towards edge-enabled design is already visible. According to the cited architecture overview at Itransition , edge-enabled architectures accounted for 52% of UK deployments in 2023, up from 28% in 2020. The same source states that the edge layer can cut bandwidth use by up to 60%, and notes that 42,000 UK hotel rooms have integrated IoT gateways.
Those numbers align with what network teams see in practice. When sites process obvious noise locally, upstream systems become cleaner and cheaper to run. They also become more useful.
Good edge design solves three common problems
Latency-sensitive actions
If a rule needs an immediate response, edge processing is usually the better choice. Door access, safety alerts, local environmental controls, and occupancy-triggered actions all benefit from short decision paths.Bandwidth waste
Not every raw event deserves a trip to the cloud. Cameras, dense sensor estates, and frequent status updates can overwhelm links if you treat every message as equally valuable.Data handling constraints
Some organisations prefer to keep certain processing close to the source for privacy, resilience, or operational reasons. Edge gateways make that possible without giving up central visibility entirely.
What not to do
A weak edge strategy usually looks like one of two extremes.
Either the gateway is treated as a dumb pass-through and adds little value, or it becomes an unmanaged mini data centre full of custom logic nobody wants to support. Both create headaches.
The better pattern is selective intelligence at the edge. Filter aggressively. Cache what must remain available during uplink disruption. Apply local policy to the flows that need it. Push summary data and meaningful events to central platforms.
If the site loses upstream connectivity for a while, the building should degrade gracefully, not become unusable.
That principle matters most in hospitality, healthcare, and retail. These environments don’t stop because a central service is slow. People are still checking in, entering rooms, moving through wards, or paying at tills. The architecture has to respect that.
Securing the Architecture with Modern Identity Patterns
Traditional perimeter security breaks down quickly in an IoT estate. Devices move. Contractors come and go. New services appear between business units. Guest access, staff access, and machine access all coexist on the same physical infrastructure. Once that happens, “inside the network” stops being a meaningful trust boundary.
That’s why modern IoT security has shifted towards identity. Not just user identity, but device identity, service identity, and policy tied to both.
The old model doesn’t fit multi-user environments
In a hotel, a single site may host guest phones, conference AV kits, room sensors, staff tablets, smart TVs, POS terminals, and engineering devices. In healthcare, the mix is even harder. Clinical systems, patient-facing access, facilities equipment, and legacy medical devices all need network access for different reasons.
Flat trust models don’t survive that level of variety. Shared passwords age badly. Broad VLAN access gets abused. Manual deprovisioning is too slow. Once a device or user gains more access than it should, lateral movement becomes much easier.
Identity is the control point that scales
A stronger model treats each connection as something to verify, classify, and constrain.
That usually means:
- Modern devices use strong identity controls: SSO, certificates, and directory-driven access make onboarding and revocation cleaner.
- Legacy devices use compensating controls: where certificate-based methods aren’t realistic, policies need to isolate and limit them tightly.
- Access follows role and context: a staff device, a guest phone, and a thermostat should never land in the same trust zone solely because they share an SSID.
- Revocation must be automatic: if a user leaves or a device changes state, access should update without a ticket queue.
The cited design-pattern discussion from Arm Developer reflects that shift. It notes that UK compliance requirements such as the Data Protection Act 2018 and PSTI 2024 are reshaping IoT security, and that standard middleware patterns are proving inadequate. The same source points to hybrid approaches combining SSO for modern devices and iPSK for legacy ones, with automatic revocation and tenant isolation, and notes that this can reduce deployment times from months to weeks on platforms such as Meraki and Aruba.
Zero trust is practical, not theoretical
Some teams hear “zero trust” and think of a multi-year transformation programme. In IoT, it’s more concrete than that.
It means asking a few strict questions every time a device or user connects:
- Who or what is this
- How was it authenticated
- What should it reach
- What should be blocked
- How quickly can access be revoked
That approach works because it matches real operating conditions. Devices are diverse. Estates are shared. Change is constant.
The goal isn’t to trust nothing. The goal is to stop trusting by default.
For IT directors, that’s the key shift in internet of things architecture security. Stop drawing a hard shell around a soft centre. Start assigning identity, least privilege, and isolation at the connection point.
Integrating IoT into Your Enterprise Network
Most IoT architecture problems don’t appear on a greenfield diagram. They appear when a live network has to absorb new devices without breaking guest access, staff workflows, or compliance rules.
That’s especially true in multi-user enterprise environments. Hotels, shopping centres, hospitals, residential buildings, and mixed-use sites all have one thing in common. Different groups share the same physical infrastructure, but they should not share the same trust boundary.
Start with coexistence, not just connectivity
A common mistake is treating IoT rollout as a simple attachment to the current WLAN. Devices connect, packets flow, and the project is declared live. Then support tickets arrive. A guest device lands somewhere it shouldn’t. A facilities supplier needs access but can’t be neatly separated. A legacy endpoint won’t support the preferred authentication method. Staff roaming becomes inconsistent between buildings.
The better question is this: how will connected devices, users, and business systems coexist on the same network without inheriting each other’s risk?
A practical integration model
For most enterprise estates, the baseline should include these design choices:
- Separate traffic by role and purpose: guest access, staff access, and IoT device traffic should follow distinct policy paths.
- Map identity to policy: where possible, use directory-backed access for staff and explicit assignment for managed devices.
- Handle legacy devices deliberately: older endpoints often need a different onboarding pattern, but they still need strong isolation.
- Plan for movement between sites: if users and devices roam, policy should move with them.
One of the clearest examples is Build to Rent or student housing. Residents expect home-like simplicity. Operators need enterprise-grade separation. The same issue shows up in hospitals with staff, patients, visitors, and medical devices, and in hospitality with guests, employees, conference organisers, and third-party suppliers.
Isolation has to be operationally simple
Architects often get segmentation right on paper and wrong in operations. The policies are sound, but onboarding is so awkward that teams create shortcuts. Shared credentials reappear. Temporary exceptions become permanent. Local admins maintain spreadsheets because the platform model is too rigid.
That’s why simple, repeatable device isolation matters. This walkthrough of IoT device segmentation on WiFi and isolating non-standard devices is a useful reference for the operational side of the problem.
What works in the field
A pragmatic integration design usually blends several access patterns rather than forcing one method onto everything.
Directory-based staff access
Staff devices should use strong identity tied to the organisation’s directory and access policies. That keeps onboarding and offboarding consistent and avoids the sprawl that comes with shared credentials.Guest and visitor access with clean separation
Guests should connect easily, but their traffic should stay firmly isolated from business and device networks. The best architectures keep user experience smooth without collapsing network boundaries.Controlled onboarding for legacy or headless IoT devices
Some devices won’t support modern identity workflows. They still need unique policy treatment, restricted reachability, and clear ownership.Roaming models that reduce friction In multi-site estates, users don’t want to re-authenticate constantly. Frictionless, secure roaming improves experience and cuts helpdesk load, but only if policy remains intact across locations.
Good integration design reduces support effort because it removes ambiguity. The network already knows what a connection is allowed to do.
The business outcome is usually bigger than the technical change. Guests connect faster. Staff lose less time. Facilities teams can add devices without asking for risky exceptions. Security teams gain cleaner boundaries. That’s the point of the architecture. It should make the live estate easier to run, not just more connected.
Conclusion Your Architectural Blueprint for Success
Internet of things architecture isn’t a diagram you file away after procurement. It’s the set of design decisions that determines whether your connected estate becomes manageable or chaotic.
The strongest architectures share a few traits. They use clear layers. They choose protocols based on operating conditions, not fashion. They treat edge processing as a practical tool for speed, resilience, and control. They secure access through identity and isolation rather than relying on a fading perimeter model.
For IT directors, that matters because the outcomes are visible to the business. Better guest access, safer device onboarding, cleaner data flows, and lower operational friction all start with architecture. Get that blueprint right and the estate becomes easier to scale, easier to secure, and far more valuable.
Frequently Asked Questions About IoT Architecture
Some of the hardest questions come up after the architecture is broadly understood. The sticking points are usually around where to begin, what to measure, and how to make trade-offs without overbuilding.
IoT Architecture FAQ
| Question | Answer |
|---|---|
| How should we start if our network already has legacy devices and mixed vendors? | Start with discovery and classification. Identify which devices support modern authentication, which need compensating controls, and which business systems they actually need to reach. Don’t begin by standardising everything at once. Begin by separating device classes, defining policy zones, and setting an onboarding path for each type. |
| What are the most useful signs that our architecture will scale? | Look for operational indicators rather than vanity metrics. Can you onboard new devices without manual exceptions. Can you revoke access quickly. Can you trace which policy a device received and why. Can sites fail gracefully if upstream links are impaired. Scalable architecture usually shows up as lower support friction and more predictable change management. |
| How do we balance cloud, edge, and security investment without overcomplicating the design? | Put processing where the business consequence makes sense. Use the edge for time-sensitive actions and local filtering. Use central platforms for cross-site visibility and analytics. Use identity-led security throughout. If a layer doesn’t improve resilience, control, or usability, it may be complexity rather than architecture. |
A practical way to evaluate decisions is to review each proposed change against three tests:
- Operational test: will site teams be able to support it consistently
- Security test: does it reduce implicit trust and tighten reachability
- Business test: does it improve user experience, data usefulness, or delivery speed
If a design only passes one of those tests, it usually needs more work.
If you're planning a connected estate across hospitality, retail, healthcare, or multi-tenant property, Purple helps bring the network and identity pieces together. Purple provides passwordless WiFi access for guests and staff, supports multi-tenant isolation, integrates with platforms such as Entra ID and Okta, and helps organisations handle legacy IoT devices with practical controls like iPSK. It’s a strong fit for teams that want secure access, simpler operations, and a better user experience without falling back on shared passwords or clunky captive portals .
