An opened LoRaWAN sensor, a few connections to its circuit board, and access to information that should be secret. Trend Micro’s 2021 hardware study describes how an unprotected UART interface can make it possible to extract secrets from a sensor. It also examines how programming interfaces, memory protection and the storage of cryptographic keys affect security. The attacks require physical access, which matters when sensors are installed in public or unattended places.

That should influence how we buy and manage connected products.

We readily discuss encryption, range and ten-year battery life. But how well are the keys behind that encryption protected? And what happens if a weakness is discovered after a thousand sensors have already been installed at the customer’s sites?

For me, that is where the security discussion becomes interesting. It continues long after someone selected “encrypted communication” in the procurement requirements.

When physical access puts keys at risk

A programming interface is often needed during development and manufacturing. It may also be needed for servicing. But the ability to program a device, read its memory and access its keys must be treated as separate permissions. A legitimate service function should not automatically provide unrestricted access to a device’s secrets.

For example, Dragino documents firmware updates for several STM32-based products using UART or ST-Link. The documentation shows which service routes exist. It does not, by itself, prove a vulnerability. It does, however, give us reason to ask how the interfaces and memory are protected in the products being delivered.

Those are the questions I want answered with test results for the correct hardware revision. The presence of debug connections on a circuit board tells us too little. What matters is what an unauthorised person can actually do through them.

The question remains relevant, as Milesight’s 2026 security advisory shows. The manufacturer describes how unauthorised NFC access to certain sensor models and firmware versions can expose LoRaWAN session keys used with ABP, as well as keys for Milesight’s D2D communication. The attack requires physical proximity. Depending on how the devices are used, the consequences may include reading traffic, falsifying data or sending unauthorised D2D commands. Milesight states that devices operating in OTAA mode are not affected by this particular vulnerability.

A patch cannot make copied keys secret again

We need to keep two questions in mind at the same time: how do we close the weakness, and how do we restore trust in a device whose keys may have been exposed?

A firmware update can close an access route. It cannot make keys that have already been copied secret again. The response may therefore need to include new keys, changed configuration and a check of which devices should still be trusted. Some hardware weaknesses may also require physical intervention or replacement.

FUOTA has to work in the customer’s environment

That is why FUOTA belongs in the discussion about security maintenance. Firmware Update Over-the-Air can let us deliver fixes to installed devices without visiting every site. But the feature must be supported by the specific product and work with the infrastructure the customer uses.

Seeing LoRaWAN on a datasheet does not automatically mean the product supports FUOTA. The LoRa Alliance’s technical recommendation on FUOTA describes the mechanisms and steps involved in delivering firmware to end devices. The update itself must also be verified and installed securely.

OTA may still require work on site

Even the term OTA calls for follow-up questions. Dragino describes a wireless update method for the LHT65N/S and several other models. It uses a private LoRa protocol and an LA66 adapter connected to a computer or phone. The documented workflow also involves resetting the device or pressing a button on it. This is a useful service function, but the documentation does not show that a customer can distribute security updates centrally through an existing LoRaWAN network.

That distinction has practical consequences. I want to know whether the operations team can initiate an update, which devices it can reach and how we verify that installation succeeded. I also want to know what happens if power fails, a transfer is interrupted or the firmware file is wrong.

An update function that has never been tested in the customer’s environment is a shaky foundation for a security commitment lasting several years.

When every update requires a visit

Then there are products that have to be updated locally. Milesight, for example, documents updating the AM300 series through the ToolBox app or USB, while AM307 is listed without OTA support in the Milesight Development Platform. The latter describes the platform’s support for the model; it is not, by itself, a test of every conceivable update method.

USB is valuable for servicing and recovery. But when the practical response requires a visit to every sensor, someone has to plan, staff and pay for that work.

Take a thousand sensors and, purely as an example, fifteen minutes of work per device. That is 250 working hours before travel, access to premises or repeat visits have been counted. Meanwhile, the customer still has to manage the risk posed by devices that have not yet been fixed.

That cost should be visible at the purchasing stage. Long battery life tells us nothing about how much manual security maintenance the product will require.

What do a thousand home visits cost?

So what does a security update requiring home visits actually cost?

Suppose a property owner has a thousand sensors in a thousand apartments. Every update requires notifying residents, gaining access, doing the work on site and documenting the result. At one hour of total work per apartment, a labour cost of €65 per hour and €15 for a vehicle and parking, a single round of updates comes to €80,000.

The firmware transfer itself might take only a few minutes. The visit still costs money.

Three such rounds of updates over ten years add €240,000 in extra costs. Five rounds add €400,000. That is €400 per sensor, on top of purchase, installation and normal operation. These are illustrative figures in today’s money. Coordinating visits with other work reduces the cost, while failed access attempts and return visits increase it.

That puts the purchase price in a different light. A sensor with working remote updates that costs €30 more adds €30,000 to the initial cost of a thousand devices. In this example, avoiding just one round of home visits could cover that entire price difference and leave €50,000 for the work and infrastructure needed to update remotely.

I think that calculation belongs on the table when products are compared.

A security fix that needs a budget of nearly €100.000 may also have to wait for approval, staff and access to the premises. The problem remains in the meantime. The ability to update therefore affects both the total cost of ownership and how quickly a property owner can act when a vulnerability is discovered.

Ten-year battery life is attractive. But if the sensor needs five additional home visits over the same period, those visits also belong in the sales calculation.

Who can deliver the security fix?

Even the best update function depends on someone discovering the problem, analysing it and developing a fix.

That makes dependence on the manufacturer central. When importing from China, the development team, build environment, signing keys and knowledge of the product’s internal components may all sit with a company far from the Swedish customer. The importer therefore needs to assess the manufacturer’s actual ability to monitor vulnerabilities, respond to reports and maintain older products.

Country of manufacture is not a test result. But the supplier’s jurisdiction, visibility into the development process and the ability to enforce agreements are relevant parts of the risk assessment. A Swedish brand name on an invoice does not automatically move technical control to Sweden.

The CRA and the ability to act

The Cyber Resilience Act makes that question more concrete. According to the European Commission’s guidance on reporting obligations, since 11 September 2026 manufacturers have had to report actively exploited vulnerabilities and severe security incidents affecting their products when they become aware of them. Most of the regulation’s other requirements start to apply on 11 December 2027. These are separate stages, and discovering any bug does not automatically trigger a reporting duty.

Manufacturers have central obligations, while importers and distributors have obligations of their own according to their roles. The requirements also cover products from manufacturers outside the EU when those products are placed on the EU market. Compliance is therefore not optional. The European Commission’s summary of the CRA explains how the responsibilities are divided.

My concern is the gap between legal responsibility and the technical ability to act.

If a manufacturer stops responding, the importer does not suddenly gain access to a working build environment or the ability to create signed security updates. Stopping further sales does not automatically help customers who have already installed the products, either.

Show how a security issue is actually handled

That is why I want more than a promise to “comply with the CRA”. I want to see how the supplier has handled previous security issues: how quickly reports were answered, how affected versions were identified, how fixes were distributed and how customers were informed. I also want to know when maintenance ends and what we can do if the supplier disappears.

A published vulnerability can be a sign that someone is examining the product and that the manufacturer is handling findings openly. An empty list of security issues may just as easily mean that nobody has looked closely enough. Milesight publishes information about vulnerabilities and planned fixes. Dragino openly documents how several of its products can be updated. I consider that good IoT hygiene, provided we also check what can actually be done with the model and firmware version the customer uses.

Those of us who sell, integrate and recommend IoT products need to be able to have that conversation about our own suppliers as well. Customers need to know the limitations that come with a product and what a future fix might involve.

I want the next sensor procurement to include a demonstration of how a security issue is actually handled. Start with an identified device and affected firmware, then show the installed fix, any necessary key replacement and a verified result.

Because on the day someone can read the keys from a sensor, knowing who sold it is not enough. We need to know who can restore its security – and how.

Inlägget Who takes responsibility after installation dök först upp på From the world of wireless.

Over the past decade, I have had the opportunity to participate in several international collaborations focused on digitalisation, sustainability and connected technologies. One thing has become increasingly clear. Some of the most interesting opportunities for Swedish IoT companies are no longer found in distant markets but much closer to home. Europe is becoming a more important market for IoT than many realise.

Why Europe is becoming the default IoT market

This development is driven by several factors. The most obvious is that the challenges we are trying to solve are increasingly shared across borders. Whether we talk about smart cities, energy efficiency, connected healthcare, industrial digitalisation or sustainable mobility, the problems look remarkably similar in Sweden, Austria, Germany, the Netherlands and many other European countries.

An ageing population places pressure on healthcare systems, and digitalisation is needed as a consequence. The same goes for cities searching for ways to reduce emissions and congestion, and industries that are expected to become more resource-efficient while remaining globally competitive. Across Europe, organisations are turning to digital technologies and IoT to address these challenges. For innovative companies, this creates an opportunity. A solution developed to solve a problem in Sweden often has relevance far beyond the domestic market.

Regulation is quietly reshaping the market structure

One of the lessons I took with me from my years in international collaborations through IoT Alliance was that European countries are often far more aligned than we give them credit for. Not necessarily in terms of politics or culture, but in the challenges we are trying to solve with technology.

What has changed in recent years is that Europe is not only becoming more aligned around common challenges. It is also becoming more aligned around the frameworks used to address them. Cybersecurity requirements, radio regulations and data governance are increasingly shaped through common European initiatives. While regulation is often perceived as an obstacle to innovation, it also creates something extremely valuable for technology companies: predictability. Building a solution for one European market increasingly means building a solution that can be adapted and scaled across many others.

This is particularly important for small and medium-sized companies. Few Swedish IoT companies have the resources to establish local organisations in every market they wish to enter. Instead, growth often depends on finding the right collaborations in terms of partners, distributors, system integrators, municipalities or industrial actors. In many cases, internationalisation starts long before the first sale. It starts with relationships.

One of the most valuable aspects of international initiatives is therefore not necessarily access to customers. It is access to networks. Companies gain opportunities to meet organisations that face similar challenges, work within the same technical domains or operate in adjacent parts of the value chain. Sometimes these encounters lead to business opportunities. Sometimes they lead to collaborations, joint development projects or entirely new perspectives on existing problems.

Internationalisation is relationship-driven

I have also noticed something else. There appears to be a growing willingness to collaborate across European borders. Perhaps it is driven by geopolitical uncertainty. Perhaps by increasing awareness of Europe’s need for technological resilience. Regardless of the reason, the momentum is difficult to ignore. Organisations that previously looked globally for every partnership are increasingly exploring opportunities closer to home.

For Swedish companies working within IoT, electronics, mobility and smart cities, this development creates opportunities that should not be overlooked. Internationalisation remains important, but it may no longer mean looking as far away as we once thought. Some of the most relevant markets, partners and innovation environments may already exist within a few hours of your hometown.

Inlägget Europe is becoming the natural home market for IoT dök först upp på From the world of wireless.

A connected sensor device is no longer just a sensor connected to a network. A platform is no longer merely a dashboard presenting data. Intelligence is being embedded throughout the entire solution stack, from edge devices to cloud platforms, and AI is becoming an integral part of almost every aspect of connected systems.

At the same time, regulators have not been standing still. This summer, three important European regulations will enter the IoT market as major milestones, marking a set of changes that will reshape the future regulatory landscape for connected devices.

While they address different domains, they share a common theme: they will influence how connected products are designed, operated and maintained across their entire lifecycle.

A turning point for IoT: three EU regulations arriving this summer

The first date is August 2, when provisions of the AI Act begin to apply. For organisations integrating AI into products (think edge devices with real embedded ai) and services, this marks the transition from discussing responsible AI to demonstrating it in practice. While some high-risk applications have longer transition periods, many obligations start becoming relevant now.

IoT just entered its compliance era — and this is the second trigger dates

The second date is September 11, when key reporting obligations under the Cyber Resilience Act (CRA) take effect.

For manufacturers of connected products, cybersecurity no longer ends when the product ships. From this date, organisations must be prepared to report actively exploited vulnerabilities and severe security incidents within defined timelines.

In practice, this means that vulnerability management can no longer be handled informally. Manufacturers need processes for identifying, tracking and assessing vulnerabilities, monitoring products in the field and maintaining the capability to deliver security updates throughout a clearly defined product support lifetime. For many IoT vendors, the challenge is not the reporting itself. The challenge is establishing the internal processes required to detect and assess incidents quickly enough to meet the new obligations.

The third date follows immediately after. On September 12, the Data Act begins to apply more directly to newly introduced connected products and related services. The regulation changes the relationship between manufacturers, customers and the data generated by connected products. Users must be able to access data generated by the devices they use and, under certain circumstances, request that the data is shared with third parties. For manufacturers, this means that data ownership can no longer be treated as a purely commercial decision.

Product architecture, APIs, cloud platforms and data management strategies increasingly need to be designed with data portability and accessibility in mind. For organisations building connected products, these requirements are likely to influence both technical design choices and future business models.

Individually, these regulations address different aspects of connected products. Together, they provide a useful indication of where the European market is heading.

For manufacturers, the implications are practical rather than theoretical. AI functionality must be documented and governed, cybersecurity incidents must be managed and reported, and users will gain stronger rights to access the data generated by connected products.

Whether you are building devices, platforms or complete solutions, these are three dates worth keeping on your radar.
The convergence of IoT and AI is creating new opportunities. This summer also reminds us that it brings new responsibilities.

Inlägget Three dates that every IoT professional must know dök först upp på From the world of wireless.

That logic no longer holds.

What we are seeing now is not just an increase in requirements, but a shift in where they apply. New regulations all point in the same direction: security is moving from the end of the development cycle into the design phase of the IoT product.

This is where critical trade-offs have to be made. And in hardware-centric systems, those decisions are very difficult to change later.

EU regulation is making secure by design unavoidable

It is easy to view the NIS2 as an organisational requirement, CRA as a product regulation, and RED as something related to radio equipment. In practice, they converge at the same point: the physical product.

NIS2 pushes requirements upstream through the supply chain, meaning that component selection and design decisions are affected. RED, through EN 18031, defines a technical baseline for what is considered an acceptable level of security in connected IoT products. CRA adds lifecycle responsibility, where the manufacturer is accountable not only at delivery, but throughout the entire lifespan of the product. At the same time, the Data Act reshapes how data is exposed and shared, affecting both architecture and interfaces.

This means security can no longer be treated as a layer added on top. It has to be built into the design itself, from the component level and upwards—what we call secure by design.

Secure by design in practice

A whitepaper from Rapid7 shows how relatively simple attacks can go far when basic security principles are missing. By manipulating the circuit board and exploiting unprotected debug interfaces, weak update mechanisms, or insufficient, sometimes even non-existent, authentication between device and backend, it is possible to extract credentials directly from the system.

What stands out is not the complexity of the attack, but the lack of resistance. No advanced methods are required—only that someone takes advantage of what was left open in the design.

This is where secure by design becomes concrete. The new regulations are not just about managing risk. They address recurring design flaws that appear again and again in real implementations, and they move responsibility to the point where those flaws can actually be eliminated: in the design of the IoT product.

Firmware updates without signing. Keys handled insecurely in software. Debug interfaces left open to simplify development and production.

This is not acceptable. It is covered by RED’s cybersecurity requirements, and it must be complied with. If a product does not meet the baseline requirements, it cannot be sold in the EU. This is no longer about what is technically appropriate. It is about regulation.

This is where secure by design moves from principle to requirement.

Security as a fundamental principle

At its core, it comes down to a few fundamental decisions. Cryptographic keys must be generated, stored, and used in a secure execution environment, not exposed in general-purpose software. Firmware must be signed and verified throughout the entire chain, from bootloader to application. Communication must be secured from the first packet, with authentication and protection against replay attacks —not just encrypted transport.

At the same time, physical interfaces such as UART, JTAG, or other debug ports must be treated as part of the attack surface and handled accordingly. They cannot be left as remnants from development. They must be secured.

These are architectural decisions. Once the product is deployed, it is often too late to correct them without significant redesign of hardware or software.

EN 18031 makes it concrete

Within RED’s cybersecurity requirements, EN 18031 defines what is required in areas such as access control, authentication, secure updates, protection of data and keys, and secure communication.

What is interesting is not that these areas are new, but that they are now formalised and testable. It is no longer enough to claim that a solution is secure—it must be demonstrated.

For many existing IoT products, this means the original architecture is not sufficient. For new products, it means the bar is significantly higher from the start.

Security across the lifecycle

With the Cyber Resilience Act, the time perspective also changes. An IoT product can no longer be considered finished at delivery. It must support secure updates, handle vulnerabilities when they are discovered, and enable incident reporting within defined timeframes.

At the same time, requirements linked to digital product passports extend traceability and data availability across the entire lifecycle. Even decommissioning becomes part of the security model, where sensitive information and cryptographic material must be handled and destroyed in a controlled way.

Security is no longer a property of the product. It is a continuous process that follows it from design to end-of-life.
Where the difference is made

It is easy to see this as added complexity in IoT. But it can also be seen as structure.

For those working close to the hardware, this is an opportunity to differentiate. By taking control of identity, key management, and update mechanisms already in the design phase, the need for late adjustments and external fix

Inlägget Secure by design is no longer a bolt-on option dök först upp på From the world of wireless.

Networks may temporarily fail, services may become unavailable, but eventually communication is restored. In many organizations, connectivity is treated as something delivered — and restored — by someone else. The challenge becomes securing a sufficiently strong SLA and enough redundancy.

That assumption works remarkably well right up until it does not.

In business-critical environments such as energy, water management, transportation, and industrial automation, entire operational models are often designed around the expectation that communication layers remain continuously available. SCADA systems, telemetry, remote control functions, and distributed sensor networks are frequently architected as though communication infrastructure were inherently stable, externally managed, and ultimately recoverable.

Reality is rarely that deterministic.

This is where hybrid architecture becomes increasingly relevant as a design principle rather than simply a networking strategy. The idea is straightforward: no single communication bearer is sufficient under all operating conditions, and critical infrastructure must be capable of transitioning into locally isolated operation without losing essential functionality.

From centralized infrastructure to locally isolated islands

Most digital infrastructure today is optimized for centralized operation. Mobile networks, cloud platforms, internet-based control systems, and remotely managed environments form the operational backbone of modern infrastructure. In IoT, technologies such as 4G, 5G, and LoRaWAN have become natural carriers for telemetry, monitoring, automation, and remote access.

Under normal operating conditions, this model is extremely efficient.

The weakness appears when communication disruptions are treated as exceptional rather than inevitable. Many infrastructures are still designed around a binary assumption: communication either works or it does not. There is often limited consideration for degraded operational states between those two conditions. When centralized communication disappears, operational visibility, automation logic, and control functions may disappear with it.

Locally isolated operation changes that logic entirely.

In systems designed for local autonomy, parts of the infrastructure continue functioning independently even when external communication paths become unavailable. Local nodes retain operational intelligence, decision-making capability, and control authority. Critical processes continue operating locally while external communication is degraded or entirely absent.

This does not remove the need for internet connectivity or public mobile infrastructure. Modern systems still depend heavily on external communication for analytics, coordination, remote management, and integration with surrounding ecosystems.

What changes is the architectural assumption itself.

Connectivity is no longer treated as something that must always exist. Instead, systems are designed around the reality that external communication may intermittently disappear — without allowing critical operations to fail as a consequence.

Hybrid architecture is not about multiple networks

The interesting aspect of hybrid architecture is that it is not simply about deploying several parallel networks. It is about designing communication systems where multiple technologies cooperate under different operational conditions and priorities.

A modern infrastructure deployment may combine:

• Fiber where fixed infrastructure is available
• Public mobile networks for scalable and flexible deployment
• Private radio networks for deterministic local communication and resilient fallback operation

In a properly designed architecture, transitions between communication bearers should not require operational intervention. The infrastructure adapts to changing conditions while preserving the functions that matter most.

Different communication layers serve different purposes. Public mobile infrastructure provides reach, scalability, and rapid deployment. Fiber provides capacity and stability. Private radio networks provide local operational continuity independent of public network availability and external control planes.

The objective is not technological purity. The objective is operational continuity.

Why this matters now

The growing interest in private radio networks is not primarily driven by technological innovation. In many cases, the underlying technologies have existed for decades.

What has changed is the surrounding risk landscape.

Organizations are becoming increasingly aware that large-scale infrastructure disruptions rarely affect only a single service. A prolonged loss of internet connectivity, cloud access, or public communication infrastructure can simultaneously impact monitoring systems, operational visibility, automation platforms, remote access, and coordination capabilities.

This is where the discussion about operational sovereignty becomes practical rather than ideological.

The question is no longer whether infrastructure should be connected. The real question is how infrastructure continues operating when external communication becomes unreliable, unavailable, or contested.

Hybrid architecture addresses that challenge by decoupling critical local functionality from constant dependence on centralized communication layers.

In practice, this means local control systems cannot depend entirely on uninterrupted connectivity to central platforms. Communication paths must instead be selected based on operational requirements rather than commitment to a single technical standard.

Within that architecture, private radio networks become a complementary bearer for the parts of communication that must continue functioning even when public infrastructure does not.

The defining difference is not how systems are connected — it is what still works when they are not.

Inlägget Hybrid architecture as the new normal dök först upp på From the world of wireless.

Let us look back at the era of IoT before IoT. In that era—the late 1990s—we were building private radio networks based on proprietary RF technology. The learnings, the pitfalls from that era, were something I did not expect to revisit, and certainly not 25+ years later. Nowadays, we talk a lot about resilience and cybersecurity—and those are important, of course. But we often forget that if our systems are not operational and finely tuned, even the best hardware in the world will underperform. Most IoT systems don’t fail—they degrade.

In many IoT projects, there is a moment when everything appears to be working. Data is being delivered. Coverage maps look convincing. From a distance, the system feels like it has all the right attributes of a stable system. And yet, at some point, something starts to drift.

Packets are lost. Power consumption rises faster than the oil price. Latency increases. Some devices become unreliable, but not consistently enough to raise more than an eyebrow. The system does not fail outright. It degrades.

This is one of the more difficult aspects of IoT to deal with. Failures are not binary. They are fluctuating. But what looks like a connectivity issue is sometimes something else entirely.

The illusion of stability

Connectivity in IoT is often treated as a checkbox. Once a device is “online,” the assumption is that the problem is solved. Yieeha.

But connectivity is not static at all. It is a dynamic condition shaped by radio environments, protocols, hardware characteristics, antennas (and cables), and deployment decisions over time.

Take LoRaWAN as an example. On paper, it is robust, energy-efficient, and well-suited for large-scale deployments. And it is. But it is also highly sensitive to how the network is actually built and operated. When you purchase connectivity from your fiber operator or mobile network operator, they are responsible for the delivery of the bits and bytes. If you use a LoRaWAN operator, you should rightfully expect the same. But if you are the operator—the one who built the system—the problem is yours. A network can be fully compliant with specifications and still underperform in the field, and unfortunately, I see that happening from time to time.

When the physics starts to matter

In real deployments, radio behavior becomes unavoidable. Interference in the 868 MHz band is a shared reality. Other LoRaWAN networks, alarm systems, and various short-range devices all coexist in the same spectrum. Over time, the noise floor can rise without any change in your own system. You are simply using a shared resource, so this has to be expected.

The result can be packet loss—not uniformly, but at certain times of day or in certain locations. From a system perspective, everything still looks “mostly fine.”

Antenna design and placement introduce another layer of complexity. High-gain omnidirectional antennas can extend coverage, but they also narrow the vertical radiation pattern. Nodes located close to the gateway may fall into what is effectively a dead zone. In trying to optimize reach, you unintentionally degrade local reliability.

Even reflections and multipath effects from buildings and metal structures can shift signal behavior in ways that are difficult to predict—and even harder to monitor continuously.

Capacity is not just about bandwidth

As networks scale, another dimension emerges: capacity.

In LoRaWAN, capacity is governed by spreading factor, payload size, transmission interval, and regulatory constraints such as duty cycle. These are not abstract parameters. They directly influence how long each transmission occupies the air.

Higher spreading factors increase range, but they also dramatically increase airtime. This means fewer devices can communicate effectively within the same network. You need to find a balance.

If Adaptive Data Rate (ADR) is misconfigured—or not used at all—devices may continue transmitting with unnecessarily high spreading factors. The network still functions, but efficiency drops. Airtime increases. Collisions become more likely.

The hidden cost of minor issues

What makes these problems particularly challenging is that they rarely appear as critical failures. Instead, they accumulate.

A few lost packets lead to retransmissions. Retransmissions increase airtime. Increased airtime reduces overall network capacity. Devices stay active longer, consuming more energy. Battery life shortens. Maintenance intervals shrink.

At scale, this becomes significant. What started as a marginal radio issue evolves into a cost problem, an operational problem, and ultimately a sustainability problem. More battery replacements. More site visits. More hardware cycles.

Beyond connectivity

If there is one takeaway, it is this: connectivity in itself is not the goal. I know that many connectivity experts preach a certain technology. I don’t. Reliable system behavior over time is what we should strive for.

That requires moving beyond a religion-based fixation on a specific wireless technology—there is no one-size-fits-all. When you have selected your technology of choice, think in terms of system dynamics. Understand how design decisions in one layer affect outcomes in another. Anticipate how the environment will evolve after deployment—not just at installation.

Take ownership.

Because in the absence of end-to-end responsibility, IoT systems tend to drift. Not dramatically, but gradually. Quietly. Until the gap between expectation and reality becomes too large to ignore.

In many ways, the most interesting IoT challenges are not about getting things to work. They are about understanding why they stop working as expected—and better yet, planning so that such situations do not occur.

That is where the real engineering begins.

Inlägget When connectivity looks fine—but isn’t dök först upp på From the world of wireless.

As a newly baked sales engineer, I was asked to put together a wireless system to replace telephone modems in a SCADA system. The phone lines were connected to each and every pump station in the area, and some 30+ phone lines were costly. During an update of the old modem setup, the local water supply company wanted to look at a more modern solution. Wireless — almost unheard of in the early 1990s.

The first IoT systems before the internet was even a thing

With some help, I put together a draft system design with a plan on how to interconnect all the stations with wireless links up to 10–12 km or more (vague memories here). The antenna analysis and installation instructions were faxed to the customer — there was no public internet at that time. That part I remember clearly. I even had to go to the office on a Saturday just to forward a fax from my antenna supplier to the customer with all the antenna mounting heights and types.

Anyways, we sold the system. The customer got it installed. Everything ran smoothly after some final adjustments.

What did we achieve?

• A system to remotely control pumps for fresh water.
• A system that could read all the substations in a second or two.
• A system where you could restart anything or adjust anything without travelling.
• A system that provided the customer with more insight than before.

The only thing that disqualifies this as an Internet of Things solution was that there was no internet involved. It was like one big isolated intranet with no risk of viruses in the email.

The only anxiety we had during the installation was range anxiety. RF range anxiety, that is. Would the antennas be sufficient or not?

I get it. This is a story from the past. Why bother, right? In the context of the students, I believe in the power of sharing your mistakes so others can learn. We remember the term IoT being coined in the late 1990s, but stories like this are almost untold. The mistake? Around the same time that Kevin Ashton coined the term, we had a Houston moment. A problem.

Range solved one problem — and created another

The payoff time for these wireless links was ridiculously short. About a year. The number of frequencies was limited, but the range was excellent. So with great range, systems that reused the same band in adjacent regions, and a glitch in the radio planning from the Swedish Post and Telecom Authority — tada — we got interference between systems.

System A asked, “How are you doing?”

And system B responded back to system A.

Not exactly a great way to build wireless networks.

So what can we learn from this?

Frequencies are a natural resource. Use them carefully and don’t transmit over a larger area than you actually need to cover. Free frequencies are free for everyone, so there is no guarantee that your message will reach the intended recipient. In these systems, we eventually solved problems through more accurate radio planning, directional antennas, and lower antenna installations. We had almost a full 2 MHz band to play with. Using free frequencies, you will not have that luxury.

The potential problem with free bands is congestion. I tried to raise this question more than a decade ago. In 2012, I published an article arguing that license-free spectrum might become a bottleneck if we continue to rely on it without expanding the available bands. At the time, the discussion was mostly about Wi-Fi congestion in the 2.4 GHz band. The truth is that it can take 10–15 years to free up spectrum globally. And today there are surprisingly few discussions about expanding license-free spectrum, at least as far as I can see.

Success is what crowds a frequency band

Fast forward to 2026. Today the conversation looks slightly different. IoT networks such as LoRaWAN are also built on license-free spectrum. The openness of these bands is what made rapid innovation possible. Anyone can deploy a network, connect sensors, and start building services.

But the physics of radio has not changed. As more deployments appear, more devices transmit, and more gateways are installed, the same question returns: how much traffic can a shared band really carry before interference becomes the limiting factor? This is not a criticism of LoRaWAN. It is simply a reminder of how radio works, and something that I feel is very important to share with the soon-to-be IoT system designers. Shared spectrum, like any shared resource, always comes with shared responsibility.

And if history teaches us anything, it is that success eventually fills the spectrum it depends on. Every successful wireless technology eventually runs into the same limit: physics.

Inlägget Building IoT before IoT existed dök först upp på From the world of wireless.

The first is that SMS can no longer be sent from IoT hardware once GSM has been shut down. The second is that voice calls via VoLTE do not work in applications such as gate controllers or access systems, even though the device itself claims to support VoLTE.

Why your IoT device stopped calling

For a long time, voice calls in technical installations have been something few people needed to think about. SMS and voice services simply worked, relying on 2G or 3G, often without anyone being aware of which underlying technology was actually used.

When operators shut down the legacy networks, both SMS and voice services change fundamentally. There is no longer any possibility to continue using circuit-switched telephony, neither for voice calls nor for SMS. Instead, all voice and messaging services must run over 4G or 5G – with VoLTE acting as the common enabler.

The result is that many legacy IoT systems, based on older devices —devices that have “always worked” —suddenly can no longer make calls or send SMS, even though the hardware on paper supports VoLTE.

How voice and SMS worked in 2G and 3G

In older mobile networks, both SMS and voice calls were circuit-switched services, completely separate from data communication. When a modem or device registered to the network, it automatically gained access to SMS and voice services via a dedicated channel, independent of any data session. These networks carried a legacy from analogue telephony, meaning that no IP connection was required for voice calls, no special modem configuration was needed, and the SIM card only had to have basic telephony enabled.

What changes in 4G and 5G

In LTE and 5G networks, there is no circuit-switched telephony provided. All SMS and voice calls are delivered as IP traffic via VoLTE. VoLTE, just like modern SMS delivery, is based on IMS – the operator’s IP-based service platform. It is easy to assume that VoLTE is purely a modem capability. In reality, VoLTE is an operator service where several components must work together. The hardware must support VoLTE technically, the firmware must correctly handle IMS registration, and the subscription must be provisioned to allow VoLTE for the specific type of device.

A common misconception is that VoLTE itself is a requirement for sending SMS in modern mobile networks. What is actually required is that the device is allowed to register with IMS, the IP-based service platform of the mobile network. VoLTE is one of the services using IMS for voice calls. SMS in LTE and 5G networks is delivered via the same IMS platform, but as a separate service.

For IoT installations, this means that the SIM card and the subscription profile must allow IMS registration, even if the device is never intended to make voice calls. If IMS registration is blocked, data communication will work as expected, but SMS delivery may fail completely.

The subscription trap

When it comes to subscriptions, this is where things often break down. In the network sunsets we have seen in Sweden, the root cause is very often that the SIM card simply does not have these services enabled. The modem registers only for LTE data and never performs IMS registration. This becomes particularly visible in IoT deployments. Many subscriptions are designed purely for data communication and therefore allow LTE data traffic, while blocking VoLTE and other IMS-based services. The result is a device that appears to function normally in the network, while SMS and voice services never connect.

Hardware can still be part of the problem

Many established LTE modems used in industrial routers were developed during a time when 2G and 3G were still available. These modems may handle SMS through fallback to legacy networks, but in some cases lack a complete IMS profile for SMS over LTE in the standard firmware. Based on our experience today, however, the vast majority of routers and modems delivered to the Swedish market in recent years do support SMS over LTE. That said, individual installations and markets may of course differ.

A necessary reset for connected systems

The shutdown of 2G and 3G is not a temporary disruption. It is a structural change in how voice and messaging work in mobile networks.

For installers and system owners, the takeaway is clear: future-proofing is no longer just about radio technology or coverage. It requires a deliberate check of the entire chain – modem capabilities, firmware maturity, IMS support and, just as importantly, how the subscription is provisioned.

Inlägget The hidden impact of mobile network sunsets dök först upp på From the world of wireless.

Forensics in connected buildings

Building automation is fundamentally different from traditional IT; here, the focus is on measurement values from sensors or presence detection from PIR sensors. In his research, Johnny has used CO₂ sensors, IR sensors and magnetic contacts, among other components. But a smart building also includes actuators—devices that take action based on sensor readings. These systems often rely on low sampling frequencies, simple logic functions and components never designed for evidentiary value. This makes systematic testing and methodology essential to determine what can actually be trusted.

When intentional and unintentional events mix

In a connected building, data is generated by three types of events: deliberate stimuli, unintentional occurrences, and pure accidents. A magnetic sensor reacting to a door opening, a voice command to a smart speaker turning on a light, or a water leak triggering a shutoff valve—all these events generate digital traces that can, in theory, be used to reconstruct a timeline during an investigation. But one critical question remains: can sensor data be manipulated to produce a misleading picture of what actually happened, or are the measurements correct? Did the sensor function as intended, and how was it mounted? You will find more on this topic in my post on bias.

False motion and hidden footprints

One of the most illustrative test cases involved PIR sensors, commonly used in offices and stairwells for presence detection. PIR reacts to changes in infrared radiation—practically speaking, heat—and by flying a small drone indoors, the research team produced clear false positives: the system interpreted the drone as human motion. This demonstrates how easily misleading traces can be created, and how quickly an investigation may be pushed off course. Equally important were the attempts to achieve false negatives; using a metallised emergency blanket, the team could partially mask body heat and bypass motion detection. In practical tests with motion-controlled bathroom lighting, registration could fail entirely. CO₂ sensors showed higher robustness; human respiration is difficult to hide over time, though breathing into air mattresses provided a partial workaround. But once you overlay two sensors’ data, the challenge becomes significantly harder. The PIR sensor may not be triggered, yet the CO₂ sensor might show elevated levels—unless, of course, a leaking CO₂ cartridge is tucked away in a corner.

Forensic work demands methodology

To draw credible conclusions, investigators need a structured workflow mirroring traditional forensics—seizure and documentation, hardware analysis, data extraction, interpretation and final assessment—yet with an added engineering dimension. Timestamps may be unsynchronised, sampling frequencies too low, and log levels tuned for operations rather than evidence collection. This results in data gaps and creates small time windows that can be exploited by an attacker or someone intent on avoiding detection. The human factor also plays a critical role; cognitive bias, expectations and groupthink can all skew interpretation. NFC’s practice of having two analysts work together helps reduce the risk of premature conclusions.

Cyberattacks and hybrid threats reach our buildings

When building automation and IoT systems are connected, the attack surface—and the incentive for malicious activity—increases. Motives range from financial gain and extortion to sabotage and complex hybrid influence where critical infrastructure or production capacity becomes the target. The consequences can include locked-out operations staff, manipulated sensors, or altered indoor environments designed to cause harm or distort forensic data. Preventive measures must therefore combine classical security architecture—segmentation, network separation, patch processes—with operational routines: incident plans, clear responsibility chains and defined procedures for securing logs and artefacts when an intrusion is suspected.

Digital twins and preserving scenarios

Digital twins offer one promising path forward: continuously updated replicas of the building’s state, enabling both attack simulation and the ability to freeze a moment in time during an incident. By combining lidar, GPS, time logs and sensor data, it becomes possible to create a synchronised temporal snapshot that aids reconstruction. Digital twins can also serve as controlled test environments where teams practice attack and defence scenarios without risking production systems. Yet for digital twins to hold forensic value, design choices must prioritise evidence integrity: secure logs, clock synchronisation, higher sampling rates where relevant, and an architecture that supports preservation of snapshot data.

When the building becomes a witness

What makes this field so compelling is the tension between technical potential and practical limitations. Sensor data, when handled correctly, can help investigators understand what actually occurred; but the same data can mislead if systems are fragile or deliberately manipulated. For the IoT sector, this introduces a responsibility: to design solutions that not only optimise operations and energy efficiency but also account for forensic traceability. Our connected buildings expose more signals than ever before, but leveraging them requires knowing how to interpret and preserve them.

Here you can access Johnny’s research.

Inlägget Buildings are no longer silent witnesses dök först upp på From the world of wireless.

Just the other week, I came across a new term to express antenna gain. It’s surprising to see a new term after all these years — I still remember early antenna seminars by Ari Alonen at CompleTech, perhaps one of the most valuable hours of my career. Yet, I found the term dB Marine recently, and I had to take a closer look, because the dB specs seemed very optimistic — exaggerated, to say the least.

Understanding dB: not all numbers are equal

Decibel, or dB, is not an absolute measurement. It’s a ratio, a way to express how much stronger or weaker a signal is compared to something else. In antennas, dB is closely linked to directivity — how an antenna focuses its energy during transmission and reception.

Here’s the crucial part: dB alone tells you nothing about the reference. Without it, the number is essentially meaningless. To be relevant and comparable, antenna gain is expressed as dBi or dBd. dBi compares gain to a theoretical isotropic antenna radiating equally in all directions. dBd compares to a half-wave dipole, a common real-world reference. The relationship is always consistent: 0 dBd ≈ 2.15 dBi. This makes measurements traceable, verifiable, and comparable.

dB Marine: a number without a reference

And now we get to the heart of the headline. Some manufacturers use “dB Marine” to describe antenna performance. It sounds technical, rugged, and impressive. But in all fairness, it has no reference. It’s not dBi. It’s not dBd. It’s simply dB — which means we don’t know what it’s compared with, how it was measured, or how it relates to other antennas.

How “dB Marine” is probably measured

Since there’s no standard, we can only speculate. Typically, a manufacturer might place the antenna on a boat or mast in a semi-controlled setting and measure received signal strength at a nearby receiver. The water may be flat or choppy, and the boat may be stationary.

Even over open water, environmental factors dominate: waves, reflections, humidity, temperature, and the boat’s orientation all affect signal strength. Small tilts or pitch changes can drastically alter readings. In other words, “dB Marine” can vary wildly depending on how and where the test was performed.

The result is a number that sounds precise but is essentially a marketing placeholder. When you see “9 dB Marine,” it could correspond to 5 dBd, 7 dBi — or nothing meaningful at all. The bigger the number seems, the more reassuring it feels — go Marine! But that’s the trap. Without a defined reference, a bigger number doesn’t guarantee better performance, only higher uncertainty.

Lessons from outboards: when numbers mislead

A similar phenomenon happened with early two-stroke marine outboards. Mercury engines were rated at “tower of power” horsepower measured at the engine shaft, not the propeller. Later standards measure at the propeller for accuracy. Measuring directly gave a higher number — just like “dB Marine” inflates apparent antenna gain.

The trap of high-gain antennas at sea

Marine users want range, stable communication, and antennas that withstand roll, pitch, and salt air. In practice, too much antenna gain can backfire. As gain rises, the radiation lobe narrows, focusing energy toward the horizon. On a moving boat, rolls and pitch may misalign the lobe with the base station, causing intermittent communication — even if specs look impressive on paper.

Moderation wins: why less can be more

For vessels or vehicles, moderate gain often delivers the most stable performance. Antennas with 2–5 dBi usually outperform 7–12 dBi antennas because they maintain a wider radiation pattern tolerant of movement.

When comparing antennas, transparency matters. Always check gain in dBi or dBd. If you see only dB, ask for the reference.

In the end, “dB Marine” is not a standard — it’s marketing. The right antenna isn’t the one with the highest dB, but the one with the right dB.

If you need advice on antennas, reach out to discuss your needs.

Inlägget The more dB the better? Go Marine (ironic headline)! dök först upp på From the world of wireless.