IoT platforms have come a long way from the days when connecting a device to the cloud was an achievement in itself. Today the conversation has moved to digital twins, edge AI, and AI agents that can recommend or even take operational actions. Yet many organizations still run platforms that do little more than collect telemetry and draw charts. The gap between what is possible and what is deployed is wide, and it is growing.
A maturity model helps close that gap by giving teams a shared language for where they are, where they want to be, and what has to change in between. This article sets out a five-level model for IoT platforms, offers self-assessment questions for each level, and looks ahead to the forces that will shape platforms between 2027 and 2030.
Why a Maturity Model, and Why Now
The scale of connected infrastructure keeps rising. IoT Analytics, in its State of IoT report published in October 2025, estimated 18.5 billion connected IoT devices in 2024, projected growth to 21.1 billion by the end of 2025, and forecast 39 billion by 2030. Wi-Fi, Bluetooth, and cellular together accounted for nearly 80% of connections. More devices mean more data, more security exposure, and more opportunity.
At the same time, three shifts are raising expectations of what a platform must do. Regulation such as the EU Cyber Resilience Act, whose main obligations apply from December 2027, makes lifecycle security and vulnerability handling mandatory for connected products. Edge platforms now provide Kubernetes-based data planes close to equipment. And AI, from anomaly detection models to large language model assistants and agents, depends on contextualized, trustworthy data that many IoT platforms were never designed to provide. A maturity model makes these demands concrete.
The Five Levels at a Glance
- Level 1, Connected: devices send telemetry to a platform; data is used mainly for monitoring and basic alerts.
- Level 2, Managed: the fleet is managed as a system, with identity, inventory, remote configuration, and secure updates.
- Level 3, Contextualized: device data is modeled, enriched with asset and business context, and integrated with enterprise systems and analytics platforms.
- Level 4, Twinned and Predictive: digital twins combine live data with models to simulate, predict, and optimize; machine learning runs in the cloud and at the edge.
- Level 5, Autonomous with Guardrails: AI agents and closed-loop controls recommend or execute actions within defined policies, with human oversight and full traceability.
Levels are cumulative. An organization cannot sustainably operate at level 4 if level 2 capabilities such as inventory and update management are weak. Most organizations also sit at different levels for different product lines or sites.
Level 1: Connected
At level 1, devices connect securely to a platform and stream telemetry. Dashboards show current values and simple threshold alerts notify operators. Data is often stored in time-series databases with limited retention, and integration with other systems is ad hoc.
Level 1 delivers visibility, which is valuable, but it rarely changes how the business operates. Typical signs of being stuck here include dashboards that few people look at, alerts that are ignored because of noise, and every new use case requiring a custom data export.
Self-Assessment Questions
- Do all devices authenticate with unique credentials rather than shared keys?
- Is telemetry flowing reliably, with known latency and loss rates?
- Are alerts reviewed and tuned regularly?
Level 2: Managed
Level 2 treats the fleet as a managed system. Every device has a strong identity and a record in a live inventory that includes hardware revision, firmware version, and configuration. Remote configuration and over-the-air updates are signed, staged, observable, and reversible. Device health is monitored, and security telemetry reaches security operations.
This level has become a regulatory baseline for many manufacturers. The European Commission describes the Cyber Resilience Act as requiring manufacturers to handle vulnerabilities throughout a product’s lifecycle and to report actively exploited vulnerabilities, with reporting obligations applying since September 2026. Meeting those obligations is very difficult without level 2 capabilities.
Self-Assessment Questions
- Can you list, within an hour, every device running a given firmware version or software component?
- Can you roll out an update in stages, monitor success, and roll back automatically?
- Are software bills of materials linked to the devices running each build?
- Is device security telemetry monitored alongside other enterprise security signals?
Level 3: Contextualized
At level 3, raw signals become meaningful information. Data is modeled using an asset hierarchy and semantic definitions, enriched with context such as location, product, batch, and customer, and integrated with enterprise systems like ERP, MES, CRM, and service management. Event-driven patterns such as a unified namespace replace point-to-point integrations, and curated IoT data lands in the lakehouse in open formats for analytics and AI.
Edge platforms increasingly support this level directly. Microsoft’s documentation for Azure IoT Operations, for example, describes an edge-native MQTT broker, connectors for OPC UA and HTTP, data flows that contextualize data and route it to destinations including Microsoft Fabric OneLake and Azure Data Explorer, a schema registry, and a device registry. Other vendors and open-source stacks offer comparable capabilities.
Self-Assessment Questions
- Is there a documented asset model and naming standard used consistently across sites or products?
- Do payloads follow versioned schemas with units and quality flags?
- Can analysts join IoT data with business data in the lakehouse using shared identifiers?
- Can a new consumer get the data it needs without a custom integration project?
IoT maturity is cumulative: autonomous operations rest on digital twins, twins rest on contextualized data, and contextualized data rests on a well-managed fleet. Skipping levels produces impressive demos and fragile production systems.
Level 4: Twinned and Predictive
Level 4 introduces digital twins and predictive models. The Digital Twin Consortium defines a digital twin as an integrated, data-driven virtual representation of real-world entities and processes, with synchronized interaction at a specified frequency and fidelity. That definition is useful because it forces teams to state how current and how detailed a twin must be for its purpose, rather than chasing photorealistic 3D models for their own sake.
At this level, twins combine live data from level 3 with physics-based or data-driven models to answer questions such as when an asset is likely to fail, how a change in setpoints will affect energy use, or what throughput a line can achieve under a new product mix. Machine learning models run both in the cloud and at the edge, with an MLOps process that monitors drift and retrains as conditions change.
Self-Assessment Questions
- Have you defined the purpose, frequency, and fidelity required for each twin?
- Do predictive models have measured accuracy in production and a retraining process?
- Are edge models deployed and updated through the same managed pipelines as firmware?
- Do operational teams act on predictions, and is the business impact tracked?
Level 5: Autonomous With Guardrails
Level 5 is where AI moves from insight to action. AI agents use twins, live data, and enterprise systems to recommend actions, create work orders, adjust schedules, or change setpoints within defined limits. Closed-loop optimization may run continuously for well-understood processes. Large language model assistants help operators and technicians query the state of assets and procedures in natural language.
The defining feature of level 5 is not autonomy itself but governed autonomy. Every action is constrained by policies that define what may be changed, by whom or what, within which limits, and with which approvals. Safety-relevant actions remain under human control or deterministic safety systems. Every recommendation and action is logged with the data and model versions that produced it, so that outcomes can be audited and learned from.
Self-Assessment Questions
- Are there explicit policies defining which actions AI may recommend, which it may execute, and which require human approval?
- Is every AI action traceable to its input data, model version, and policy decision?
- Are safety functions isolated from AI-driven control paths?
- Is there a process to review AI-driven outcomes and adjust policies?
Using the Model: From Assessment to Roadmap
A maturity assessment is only useful if it leads to decisions. A practical approach:
- Assess by domain. Score each product line, site, or business unit separately; averages hide the real picture.
- Tie targets to value. Decide which level each domain needs based on business cases, not ambition. A low-value sensor network may never need level 4.
- Fix foundations first. Address level 2 gaps, especially inventory, updates, and security, before investing heavily in twins or agents.
- Pick lighthouse use cases. Choose one or two use cases that require the next level and use them to build reusable capabilities.
- Reassess annually. Technology and regulation move quickly; refresh the assessment and roadmap each year.
Capabilities and Teams Needed at Each Step
Moving up a level is as much about people and process as about technology. The move from level 1 to level 2 usually requires a dedicated fleet operations function with clear ownership of firmware releases, update rollouts, and device security. The move to level 3 brings data engineers and domain experts together to define asset models and schemas, and it requires collaboration between OT and IT teams that may have worked separately. Level 4 adds data scientists, simulation engineers, and MLOps practices. Level 5 adds governance roles: people who define and review the policies under which AI agents operate, and safety engineers who ensure that automated actions cannot compromise protective systems. Planning these skills early, whether through hiring, training, or partners, avoids roadmaps that stall for lack of capacity.
A Hypothetical Example: A Commercial HVAC Service Provider
Consider a hypothetical company that installs and services commercial heating, ventilation, and air conditioning systems across several countries. It has connected equipment for years, and its platform shows live temperatures and fault codes. An assessment places it at level 1 for older equipment and level 2 for newer models with managed updates.
The company sets a target of level 3 across the fleet and level 4 for its largest customers. It first closes level 2 gaps on older gateways by upgrading firmware and linking components to inventory, partly in preparation for Cyber Resilience Act obligations. It then defines an asset model for buildings, systems, and components, and lands contextualized data in its lakehouse alongside service history. With that foundation, it builds equipment twins at a fidelity sufficient to predict compressor failures and optimize energy use. A pilot assistant lets technicians ask about a unit’s history and likely faults before arriving on site, and proposes work orders that a dispatcher approves. Autonomous setpoint changes remain out of scope until policies and customer agreements are in place.
Outlook: Forces Shaping IoT Platforms From 2027 to 2030
- Regulated lifecycle security. With Cyber Resilience Act obligations fully applying from December 2027, level 2 capabilities become table stakes for anyone selling connected products in the EU.
- Edge platforms as standard. Kubernetes-based edge data planes with brokers, connectors, and data flows will become the default way to deploy industrial IoT, reducing custom gateway software.
- Open data foundations. IoT data will increasingly land in open table formats and lakehouses, making it easier to combine with business data for AI.
- Purpose-built twins. Twins will be scoped by frequency and fidelity for specific decisions rather than built as general-purpose replicas.
- Agents with policies. AI agents will take on more operational tasks, but adoption will hinge on policy frameworks, traceability, and safety separation.
- Continued growth. If IoT Analytics’ forecast of 39 billion devices by 2030 holds, fleet management and data volume challenges will intensify, rewarding automation at every level.
Common Pitfalls
- Jumping to twins and AI. Advanced use cases built on unmanaged fleets and inconsistent data fail in production.
- One score for the whole company. Maturity varies by domain; a single number obscures where to invest.
- Technology-led targets. Aiming for level 5 everywhere wastes money where level 3 would deliver the value.
- Ignoring operations. Predictions and recommendations only matter if processes and people act on them.
- Ungoverned autonomy. Allowing AI to act without explicit policies and traceability creates safety and liability risk.
Conclusion
The journey from connected devices to digital twins and AI agents is real, but it is a staircase, not an elevator. A clear maturity model helps organizations see which steps they have climbed, which they have skipped, and which deliver value for each part of the business. Strengthen fleet management and security, contextualize data, build twins with a defined purpose, and introduce AI agents with strong guardrails. Organizations that follow that sequence will be well placed for the larger, more regulated, and more intelligent IoT landscape of 2030.
How Hanoi Technology Can Help
Hanoi Technology assesses IoT platform maturity and builds the managed fleet, contextualized data, digital twin and AI capabilities needed for the next level.