The European Union’s manufacturing sector stands at a crossroads. As Smart Buildings, Smart Grids, and Industrial 4.0 deployments accelerate across the continent, millions of organizations face a critical architectural choice that will determine whether they build resilient, innovative ecosystems — or become trapped in vendor lock-in for a decade.
The problem isn’t a technology gap. It’s a fundamental architectural mismatch between how the Internet was designed and how IoT actually needs to work.
Today’s IoT relies on host-centric networking — a model that’s been the Internet’s foundation for 40 years. But when you deploy thousands of battery-driven sensors, edge devices, and autonomous systems, the host-centric approach becomes your enemy. And one popular alternative — LoRaWAN — creates a different kind of problem: lock-in to American corporate control in an era when Europe is fighting for digital sovereignty.
The solution is already here. It’s called Information-Centric Networking (ICN). And it changes everything.
The Fundamental Mismatch: Why IP Breaks IoT
The Internet Protocol was designed for a simple premise: connect named computers, route data between them. A user on Computer A requests data from Computer B. The network finds B, the computers establish a connection, and data flows between two points. Done.
This works brilliantly for the Internet’s original purpose: connecting servers and personal computers with reliable power, persistent connectivity, and constant availability.
IoT is the opposite.
The Three Critical Problems with Host-Centric Architecture
1. Devices That Sleep
In IoT, battery life is everything. A temperature sensor in a commercial building might wake for 100 milliseconds every 15 minutes to report data. The rest of the time, it sleeps to preserve power.
Host-centric networking requires persistent connections. TCP/IP maintains state — the connection stays open. If a sensor is asleep when data arrives, it misses it. Solutions like CoAP Observe get around this by having servers track individual sleeping devices and buffer messages, but this creates a nightmare: the server must maintain knowledge of thousands of individual sleeping devices, their schedules, and their state.
Data-centric networking inverts this. Information is published to a named topic: “building-4/floor-3/meetingroom-2/temperature” and the network caches the data. When the requesting sensors wakes up, they just requests the data they need. The network doesn’t care about device states—only about content names.
No state to track. No connections to maintain. No battery drain.
2. Multiple Applications Need the Same Data
In a modern building, the temperature sensor serves dozens of purposes simultaneously:
- HVAC control (real-time actuation)
- Energy analytics (historical trends)
- Predictive maintenance (anomaly detection)
- Facility management (compliance reporting, cleaning optimization, leak detection)
- Tenant apps (comfort optimization, room- or desk availability)
In host-centric networking, each of these applications requires its own point-to-point connection to the sensor. The sensor publishes to five different cloud systems. Integration happens in the cloud. Data flows in and out and back again.
In data-centric networking, the data is named once: “building-4/floor-3/meetingroom-2/temperature”. Any application that holds the encryption key for that topic can subscribe independently. The network automatically distributes the same data to all consumers. One publisher. Multiple consumers. Native support.
This is not a minor optimization. This is architectural elegance.
3. The Security Illusion
IP-based IoT secures the connection between devices: TLS/DTLS. The problem? This requires expensive cryptographic handshakes that drain battery and assumes both endpoints are awake and available. For sleeping devices, it’s impractical.
More fundamentally: host-centric security secures the pipe, not the data. Once data reaches an application, the application owns it. If you want to share that data with another application, it either needs direct access to the original connection (impossible) or the first application must copy and forward the data (integration hell). There’s no way to say: “This data object can be read by these applications, cached by these gateways, but forwarded by anyone.”
Data-centric security is the inverse. The encryption key travels with the data. A gateway can cache encrypted temperature readings without knowing what they contain. Any device with the key can decrypt and use the data. Devices without the key can’t. The security travels with the information, not the connection.
According to the IETF’s Information-Centric Networking for IoT research group, this object-based security model ensures “data integrity through named-data integrity”—meaning the requesting client is guaranteed that data hasn’t been tampered with, regardless of whether it was delivered from the original sensor, an intermediate cache, or a backup source. No matter who forwards the data, the security is built-in.
LoRaWAN: The Proprietary Trap
If IP-based IoT has architectural problems, LoRaWAN attempted to solve them differently. And it works — for specific use cases. Long-range coverage. Ultra-low power consumption. Wide area networks.
But there’s a structural problem: LoRaWAN is controlled by Semtech, an American company. The LoRa PHY (physical layer) is proprietary and patented. European organizations deploying LoRaWAN across their infrastructure are, by definition, dependent on IP and business decisions made by a California corporation.
In 2024, this matters more than ever.
The EU is building digital sovereignty. GDPR, NIS2, the Cyber Resilience Act—European regulations increasingly demand ownership and control of critical infrastructure. Deploying LoRaWAN creates a structural vulnerability: if Semtech decides to change licensing terms, end support, or prioritize a different market, European deployments are exposed.
Moreover, LoRaWAN has technical limitations that reveal its proprietary DNA:
- No efficient OTA firmware updates for battery devices. A full firmware update consumes 20% of battery (potentially taking 11 days depending on network conditions)
- Gateway architecture lock-in. Each LoRaWAN network requires a gateway (cloud provider); data flows through centralized network servers before reaching applications
- No multi-application data sharing. If you need the same sensor data for two different cloud platforms, you need two separate integrations through the network server
- Vendor lock-in at the core. You can’t swap gateways or network servers without rebuilding the system
For European enterprises, this is the wrong bet for 2025 and beyond.
Data-Centric Zero-Trust: A Paradigm Shift
Information-Centric Networking flips the model. Instead of asking “How do we connect these devices?” it asks “How do we securely distribute and access information?”
This enables Data-Centric Zero-Trust networking:
- No device knows which other devices exist. A HVAC controller doesn’t know there are 50 sensors in the building. It subscribes to the “temperature” topic. Any sensor publishing to that topic (with the right encryption key) is implicitly trusted.
- Every piece of information carries its own security. Applications can cache, forward, and process data without ever decrypting it (for routing) or needing trust relationships with intermediate nodes.
- Devices are minimally named; data is richly named. Instead of “sensor #47 in building 2,” the information is “building-4/floor-3/meetingroom-2/temperature.” Applications can subscribe to entire hierarchies of information without knowing specific device names.
The IETF research consensus is clear: “Data consumers usually need the data sensed from the environment without any reference to the subset of sensors that can provide the requested information.” ICN-based architecture provides this natively.
The Simplicity Advantage: Modular Applications, Not Monolithic Silos
Today’s IoT applications are monolithic. A Smart Building platform ingests data, stores it in proprietary databases, exposes it through proprietary APIs. If you want that data in an analytics system, you extract it and rebuild the schema. If you want it in a facility management tool, you extract it again. Every new application requires custom integration.
Result: Vendor lock-in. Slow innovation. Fragmented data.
In a data-centric architecture, applications are simple consumers of named information. A building analytics app subscribes to “building/temperature/” and receives real-time data. A predictive maintenance app subscribes to “building/hvac/diagnostics.” Neither app cares how many other applications are consuming the same data. Neither requires integration logic.
New applications attach to the network topology without modifying existing systems. They don’t need special APIs. They don’t need custom database schemas. They request or subscribe to information by name and receive it with built-in security and integrity guarantees.
Innovation accelerates. Vendor lock-in evaporates.
Better Data Integration, Better Visibility
Here’s where it gets powerful: multiple applications accessing the same data in real time creates emergent intelligence.
Imagine a Smart Building where:
- HVAC system subscribes to real-time temperature, occupancy, and weather data
- Energy system subscribes to HVAC state, lighting, and appliance data
- Facility team subscribes to equipment diagnostics, maintenance history, and anomaly alerts
- Tenant apps subscribe to comfort metrics, air quality, and personal preferences
- City grid integration subscribes to aggregate building load and demand-response signals
In a monolithic, siloed architecture, each system maintains its own copy of data. Inconsistencies emerge. Changes propagate slowly. Opportunities for optimization are invisible.
In a data-centric architecture, all systems access the same source of truth in real time. The HVAC system can see what the facility team is planning. The energy system can predict demand based on occupancy patterns the facility system is tracking. The city grid can coordinate load-balancing with dozens of buildings simultaneously.
One network. Multiple perspectives. Unified intelligence.
Why Interoperability Matters More Than You Think
The IETF’s research group emphasizes that IoT systems need “open APIs as opposed to proprietary APIs that are common in today’s systems.” Yet most IoT protocols—whether host-centric or otherwise—leave interoperability to chance.
A data-centric protocol standardizes the fundamental layer: how named information is published, discovered, cached, and consumed. Every application speaks the same language. Every device understands the same security model. Gateways from different vendors can coexist. New protocols can be bolted on without breaking existing systems.
This is where Z-Mesh — a royalty-free, open-source implementation of data-centric IoT — becomes strategically important. Unlike LoRaWAN (proprietary), MQTT (broker-dependent), CoAP (point-to-point), or Thread (single-layer bound), Z-Mesh is:
- Royalty-free and open-source. No licensing fees. No corporate control. The architecture belongs to the ecosystem.
- Multi-layer compatible. The same named-information model works over sub-GHz, 2.4GHz, WiFi, Ethernet, or any transport layer.
- Built-in data and device management. Security, topic subscriptions, device onboarding—standardized, not left to implementers.
- Edge-native (AI). Because encryption targets the data, not connections, devices can cache, process, and act on information at the edge without trusting intermediate nodes.
- Future-proof for regulatory compliance. When the EU Cyber Resilience Act mandates OTA firmware updates, Z-Mesh’s data-centric model enables efficient updates for even the lowest-power devices — something neither LoRaWAN nor IP-based solutions support.
The Strategic Choice for Europe
Europe’s enterprises face a choice: keep building on American-controlled infrastructure and host-centric protocols designed 40 years ago. Or adopt a new architecture aligned with digital sovereignty, regulatory requirements, and the actual nature of IoT systems.
The shift from host-centric to data-centric is not incremental. It’s a paradigm change that makes applications simpler, integration faster, and innovation accelerated. It breaks vendor lock-in. It distributes control back to the network operators instead of concentrating it in cloud providers and proprietary protocol owners.
The IETF has validated this approach. Deployments in Smart Buildings, Smart Grids, and Industrial Automation have proven its feasibility. The only question remaining is whether organizations will move fast enough to avoid being locked into yesterday’s architecture.