IoT work splits into four layers: the network and power the devices sit on, the devices themselves, the software that turns readings into something a person acts on, and the firmware where nothing off the shelf fits. Listonics covers all four. In the UAE there is a fifth layer, which is registering the service with TDRA.
Part of our guide to Office Network & Wi-Fi.
The registration almost nobody mentions
Start here, because it is the part that catches businesses out after the devices are already on the wall. In the UAE, delivering an IoT service is not something you can simply decide to do. TDRA operates a registration service for Internet of Things services, and the outcome of it is an approval certificate to practise IoT service delivery.
It is aimed at the business and government sectors, it costs nothing, and TDRA publishes an expected turnaround of two working days. The company must be licensed locally or have a legal representative in the country. Where a service is classified as critical, the National Internet of Things Advisory Board makes a recommendation before TDRA approves it.
Now look at what TDRA asks you to submit. A network connection diagram of the service. A disclaimer letter for the device. Information security certificates where they exist, and a penetration testing or vulnerability report where one is available. The regulatory procedures set out the process in full.
Read that list again. The required document is a network diagram, and the supporting documents are security assessments. The regulator is asking for infrastructure documentation, which is the one thing a device supplier does not produce and an office IT company does every week.
The network under the devices
Most IoT disappointments are network problems wearing a different costume. A camera that drops its feed, a sensor that stops reporting at the far end of a warehouse, a door controller that works until the Wi-Fi is busy. The device is usually fine.
So the first question on any project is what the devices will actually talk over, and the honest answer is rarely one thing. Wired and powered over Ethernet where the device will sit still and matter, which is most cameras and most door hardware. Wi-Fi where cabling is impossible, planned for device density rather than for laptops. Low-power mesh such as Thread for building sensors, which the Thread Group maintains and which underpins the Matter ecosystem most new building devices now ship with. Long-range radio such as LoRaWAN, governed by the LoRa Alliance, for a yard, a site or a building where running cable is not realistic. Cellular where the thing moves.
The part that is not optional is separation. Devices go on their own network, with their own rules about what they may reach, which is ordinary network and firewall work done deliberately. An unsegmented camera network is the most common serious finding we see, and we have written about the same principle in a harder setting in our note on SCADA and OT security.
Devices: supplied, installed and documented
We source and install the hardware as part of the project rather than leaving you to coordinate three suppliers. That means IP cameras and recorders, access control readers and door controllers, environmental and temperature sensors, occupancy and leak detection, and the gateways that tie a radio network back into your systems.
Where you already have devices, or where a vendor is contractually your supplier, we work to them instead.
Every installation leaves documentation behind: what is installed, where, on which network, with which credentials, and who holds them. Cabling and containment is part of the same job, because a sensor on a desk is a trial and a sensor in a ceiling void is an installation.
Dashboards and software, built in house
A reading nobody sees is not monitoring. The software layer is where IoT projects earn their keep or quietly stop being used, and it is usually the layer the device supplier hands back to you as a vendor portal with a login nobody remembers.
Our developers build the part that fits your business: a dashboard that shows the handful of things your managers actually decide on, reporting that produces the record an auditor or a client asks for, and integrations into the systems you already run. That often means pushing readings into Microsoft 365, or into a custom CRM or internal tool we have built, so the data lands where work already happens rather than in another tab.
The design principle we hold to is that a dashboard should be boring. If somebody has to interpret it, it is not finished.
Firmware and hardware, where nothing off the shelf fits
Occasionally a project needs something that does not exist as a product. A gateway that has to speak to an old control system nobody supports. A board that has to sit somewhere hot, wet or inconvenient. A device that has to behave in a specific way when it loses its connection.
We have developers who work at that level, and we will take that work on. We will also tell you when it is the wrong answer, which is most of the time. Custom hardware is a commitment to maintaining it, and an off-the-shelf device with a good integration is usually cheaper to own. If we propose building something, the proposal says who maintains it.
The alert path, which is where these projects actually fail
The alert path is worth its own section because it is the single most common reason an IoT deployment stops being trusted. The sensor works, the reading is correct, and the alert goes to a shared mailbox nobody reads, or to a person who left, or it never leaves the building because the connection was down.
An alert has to reach a named human, escalate when that human does not respond, and survive the outage it is most likely to be reporting on. We wrote this up in full for refrigeration in making sure the alert reaches a human, and the same logic decides whether a door system behaves sensibly when nobody is on site, which is the subject of our piece on access control during unstaffed hours.
Thresholds matter as much as the plumbing. A system that cries wolf gets muted within a fortnight, and a muted system is worse than none, because everyone believes they are covered.
Security, because these are computers on your network
A camera is a small computer with a network cable, often running software its manufacturer stopped updating years ago, frequently still on the password it shipped with. Treated as furniture, it becomes an easy way into an office.
The baseline we apply is unexciting and effective: devices on their own segment, default credentials changed and recorded properly, remote access through a controlled path rather than a port opened to the internet, firmware updates tracked, and the whole arrangement written down. That is cybersecurity work applied to hardware people do not think of as computers.
It also feeds back into the first section: if TDRA asks for a vulnerability report, the answer exists already.
How a project runs, and what it costs
Every project starts with a site visit and a written scope, because quoting IoT from a floor plan produces numbers that change. Projects run from AED 2,500 to AED 30,000 depending on requirement, and anything larger is split into phases you approve one at a time.
What you get at the end is the installation, the documentation, the credentials in your name, and a system somebody else could take over if you ever replace us. We do not hold your devices behind an account you cannot access.
Our IoT and connected devices service is the shorter overview of the same work. If you are at the stage of wondering whether a supplier's quote covers the network, the registration and the alert path, send us the quote. That conversation is free and often short.
Frequently asked questions
Quite possibly, and it is worth establishing early rather than late. TDRA runs a registration service for Internet of Things services that produces an approval certificate, aimed at companies and government entities, with the condition that the company is licensed locally or has a legal representative in the country. Check your own position with TDRA directly, since the detail depends on what the service does.
No. We are an office IT company that covers the network, installation, software and integration layers, supplies and installs devices, and takes on firmware or custom hardware when a project genuinely needs it. We do not manufacture a product line of our own, and we are happy to work with whichever device vendor you have chosen.
Usually yes, and that is often the better outcome. Existing cameras, readers and sensors can normally be brought onto a properly segmented network, documented, secured and integrated into something useful. Replacing working hardware is a last resort rather than an opening suggestion.
It depends on distance, power and how often readings are needed, so the answer comes from the site visit rather than a brochure. Broadly, cable anything that will not move, use low-power mesh inside a building, long-range radio across a yard or compound, and cellular for anything mobile. Most real sites end up using more than one.
That is a design decision, not an accident, and it should be made before installation. Devices can buffer readings locally and forward them when the line returns, alerts can fail over to a cellular path, and door hardware needs an explicit answer about whether it fails secure or fails open. We put that decision in the scope document so it is yours rather than the installer's.
Either. Some clients want the system handed over documented and run it themselves. Others fold it into a support agreement so the devices are monitored, firmware is tracked and somebody notices when a sensor stops reporting. The second is the honest recommendation, because an unmonitored monitoring system tends to fail silently.
Written by Srinivasan Ramachandran, Founder, Listonics · Last reviewed October 8, 2026