Do you have to register an IoT service with TDRA, and what does it involve?

What TDRA actually operates

The UAE regulates Internet of Things services rather than leaving them as an unclassified part of ordinary IT. TDRA operates a registration service for Internet of Things services which produces an approval certificate for the applicant.

The service description sets out who it is for and what conditions apply: it is aimed at companies and government entities, on the condition that the applicant is licensed in the country or has a legal representative here. The document it asks you to submit is a network connection diagram, along with any security assessments that exist.

There is also a published set of regulatory procedures for IoT which is the fuller reference for anyone whose project is large enough that the detail matters. Our IoT solutions page covers the process from the project side.

It is worth separating two things that often get merged in conversation. There is the question of whether a given deployment needs registering, which is a legal question about your business and its activities. And there is the question of what the regulator wants to see if it does, which is a documentation question with a concrete answer. The second is the part an installer can simply hand you, and having it makes the first conversation much shorter.

Why this catches ordinary offices out

The word registration suggests something heavyweight and the phrase Internet of Things suggests somebody else's problem, so most offices installing a handful of cameras never ask the question at all. They find out, if they find out, when a landlord, an auditor or a client's security questionnaire asks whether the deployment is registered.

The honest position is that the answer depends on what you are doing and it is a question for your own advisers rather than for an installer. What an installer can tell you is what you have actually built, in the form the regulator asks for. What we will not do is tell you whether you are obliged to register, because that is a legal determination about your business and not a technical one about your network.

That distinction matters more than it sounds. The common failure is not a company deciding wrongly: it is a company never raising the question, because everyone involved assumed it belonged to somebody else.

There is a second reason this slips. Device projects rarely arrive as one project. A camera system goes in with the fit-out, access control is added when the lease changes, a leak sensor appears after a flood, and a temperature logger arrives because a client asked for one. Nobody ever sat down and designed an estate, so nobody ever produced a description of it, and the question of whether the whole adds up to something that needs registering is never asked because nobody is looking at the whole.

Settle the question before you buy devices

Timing is the practical advice in this piece. Establish your position at the design stage rather than after the installation, for a reason that is purely pragmatic: the thing you are being asked to describe is the architecture, and the architecture is cheap to change on paper and expensive to change on a wall.

A network connection diagram produced during design is a by-product of designing properly. The same diagram produced two years later is an archaeology exercise, where somebody walks the building working out what was installed, what it connects to and who owns the account it reports into. We have done both, and the second costs considerably more than the first.

There is a cost argument too, and it is the one that usually persuades. Changing a network design before installation is a conversation. Changing it afterwards means re-terminating cable, re-addressing devices, reconfiguring a firewall and revisiting every integration that referenced the old arrangement, on a site that is now occupied and working. The regulatory question is a good reason to think about the architecture early, but it is not the only reason, and an office that designs properly ends up with the document almost by accident.

• Whether your organisation is the entity delivering a service, or simply a user of equipment on your own premises.
• Who the legally responsible party is, since the condition refers to local licensing or a legal representative.
• Where the data goes, including whether a vendor platform outside the country is involved.
• What the network will actually look like, because that is the document being requested.
• Whether any security assessment exists or is planned, since it is requested where available.

The network connection diagram, and what makes a good one

This is the deliverable, so it is worth knowing what a useful one contains. It is not an artistic floor plan and it is not a vendor brochure diagram with clouds and arrows.

A good diagram shows every class of device and where it physically sits, which network segment each one is on, how those segments are separated and what rule governs traffic between them, where the gateway or controller lives, and the route out of the building including which internet connection it uses. It should also show where data comes to rest, including any vendor platform, and which accounts have access.

Produced properly it is useful well beyond the regulator. It is the document an insurer asks for, the one a client's security questionnaire is really trying to extract, and the one that lets a different engineer understand the site in two years. We treat it as part of the work rather than as a compliance extra, which is the same argument we make about documentation on the connected devices page.

The test of a good diagram is whether someone who has never visited the building could use it to find a device, work out what it talks to, and say what would break if a segment were isolated. If it cannot answer those three questions it is decoration. Most vendor-supplied diagrams fail the test, because they describe the product rather than your installation.

Security assessments, where they exist

The registration asks for security assessments where they exist, which is a reasonable thing to ask and an awkward thing for a small office to produce. Most have never had one.

The pragmatic answer is not to commission a formal audit for the sake of a form. It is to be able to show the baseline: that devices are on a separated network with explicit rules, that default credentials were changed and recorded, that device web interfaces were considered against the OWASP Top Ten, that firmware updates have an owner, and that somebody is told when a device stops reporting.

That is a short document and it is genuinely useful. If a formal assessment is later required, having it means the assessment starts from a known position rather than from a survey.

One practical note on credentials, since it is the item most often missing. Recording that default passwords were changed is not the same as recording what they were changed to and who holds them. Both matter, and the second is the one that makes a handover possible. Where devices support individual accounts rather than one shared login, use them, for the same reason individual accounts matter everywhere else: a shared credential makes the logs useless.

Who submits it, and who does the technical work

The split is clean and it is worth stating because it decides who owns the deadline. The application is made by the entity delivering the service, which is your company, because the condition attaches to local licensing or legal representation. It cannot be submitted by an installer on your behalf as though it were our certificate.

What we do is the part that is technical: the diagram, the description of the architecture, the security baseline and the evidence that it is configured as described. That is produced as part of the installation rather than charged as a compliance service, because it is documentation we would write anyway.

If your project is large, or if the answer to whether registration applies is genuinely unclear, that is a conversation for your legal adviser with the diagram in hand. The diagram makes the conversation short, which is most of its value.

One thing to avoid is treating the certificate, if you obtain one, as the end of the matter. The description you submitted is a description of a system that will change: devices get added, a vendor platform gets swapped, a segment gets opened up to make something work. Whoever owns the estate should know that material changes mean the description is no longer accurate, and should keep the diagram current as part of ordinary change control rather than as an annual panic.

How this sits with everything else you have to satisfy

IoT registration is rarely the only obligation in play, and it helps to see where it fits. Devices that watch people raise privacy questions separate from telecoms regulation. Devices in an industrial setting bring a different standards world, which we covered in SCADA and OT security. Devices that control a door during unstaffed hours bring a safety question about what happens on power loss, covered in gym access control.

The cabling decision sits underneath all of it and is made earliest. Cameras, readers and most sensors want power over Ethernet, which means the points have to be designed in with the rest of the data cabling rather than added later, a point we make on the structured cabling page. An estate that was cabled properly is also far easier to describe accurately, because the physical layer matches the drawing.

None of those is answered by the registration, and the registration is not answered by any of them. The useful habit is to keep one document describing what is installed and how it is separated, and to let each obligation draw on it rather than maintaining a separate story for each.

If you want the infrastructure side of that handled alongside the devices, the connected devices page sets out what the work covers, and you can get in touch to talk through a specific site.

The network side of the same job, which is what the diagram ends up describing, is covered in segmenting a network for connected devices.

Frequently asked questions

Written by Srinivasan Ramachandran, Founder, Listonics · Published Oct 11, 2026 · Last reviewed October 11, 2026 · 2,124 words