Full Blog Text
A secure UAE smart-building project should define device ownership, credential control, network boundaries, update responsibility, remote-access rules, event logging and incident ownership before commissioning. Security cannot be left as a final IT approval because meters, gateways, controllers and sensors are already part of the building's operating environment.
The UAE National Policy for Internet of Things Security gives buyers a useful structure. Its five principles cover security and privacy by design, impact-based priorities, strong defence, recognised best practice, and collaboration and transparency. Dubai's IoT Security Standard and smart-building infrastructure guidance add local context for connected systems.
Source context: reviewed the UAE National Policy for Internet of Things Security, the Dubai Electronic Security Center IoT Security Standard, and TDRA telecommunications and smart-building infrastructure guidance.
Why metering and building IoT need their own review
A smart meter may appear low risk because it only reports consumption. In practice, the full system can include field buses, IP gateways, cloud APIs, billing records, maintenance accounts, remote VPN access and links to a BMS. Some devices also support relays or valves. The risk depends on what the device can reach and what a compromised account can change.
Start with impact. A failed temperature sensor may affect a BTU calculation. A compromised gateway may expose hundreds of endpoints. An unmanaged remote account may provide a path into operational technology. Different consequences require different controls.
1. Define ownership before installation
- Name the owner for each meter, sensor, gateway, controller, cloud tenant and integration account.
- Record who approves changes and who can grant vendor access.
- Put firmware support periods, vulnerability notification and end-of-life duties into the purchase order or contract.
- Confirm who owns configuration backups and recovery documentation.
2. Remove shared and default access
Default passwords and shared engineering accounts are easy during commissioning and expensive later. Require named accounts where the platform supports them, strong unique credentials, role-based access and a process for disabling access when staff or contractors leave.
Where a field device cannot support modern identity controls, protect it at the gateway and network layers. Document the limitation instead of pretending it does not exist.
3. Separate operational networks
Metering, BMS, office IT, guest Wi-Fi and public internet services should not share unrestricted paths. Use network segmentation, firewall rules and allow-listed communication flows. A gateway should reach only the systems, ports and destinations required for its job.
Segmentation also improves troubleshooting. When data stops, the team can test a known path rather than search an undocumented flat network.
4. Treat each protocol according to its limits
- M-Bus: protect the master, gateway and upstream IP connection. Maintain an accurate slave register and physical access control.
- Modbus: restrict write access, isolate controller networks and avoid exposing Modbus TCP directly to untrusted networks.
- BACnet: control who can discover, read and write objects. Review broadcast and routing boundaries.
- LoRaWAN: manage device and application keys, join procedures, gateway ownership and network-server access.
- MQTT and APIs: require authenticated encrypted connections, scoped permissions, certificate or token rotation and clear data-retention rules.
5. Put remote maintenance behind a controlled door
Remote support is often necessary for gateways, billing platforms and control systems. It should use a managed VPN or equivalent secure access service with named users, approval, time limits and logs. Avoid permanent inbound port forwarding and undocumented consumer remote-desktop tools.
Ask one blunt question during handover: can the owner see every remote path into the system and disable it without calling the former contractor?
6. Require useful logs and a response owner
Logs should show login attempts, configuration changes, device outages, firmware events, communication failures and control actions where the system supports them. Decide how long logs are retained and who reviews them. Collection without review does not reduce risk.
Evidence to request at handover
- Final device and gateway inventory with serial numbers, addresses and locations.
- Network diagram showing zones, firewalls, remote access and cloud connections.
- Account and role register without exposing passwords.
- Firmware and software versions with support and update contacts.
- Configuration backups and a tested restoration procedure.
- Data-flow list covering billing, BMS, cloud, API and third-party destinations.
- Incident contacts and the process for revoking vendor access.
When a buyer should pause the award
Pause when the supplier cannot name the cloud host, explain the update path, remove default credentials, provide a network diagram or confirm who owns the data and accounts. These are not paperwork details. They determine whether the owner can operate and recover the system after handover.
Where ConnectME fits
ConnectME integrates smart meters, sensors, M-Bus and Modbus gateways, LoRaWAN devices, protocol converters, BMS links, utility billing platforms and secure remote-connectivity components. A project review can document the required data paths, network boundaries, access ownership and support model before devices are commissioned.
Next step: include this checklist in the technical submittal and commissioning plan. Ask ConnectME to map the field devices, gateways, cloud services and remote-support paths for the proposed smart metering or building IoT system.
The safest time to define device ownership, remote access and update responsibility is before the first gateway is commissioned.
ConnectME Integration Team