IoT Security: A Practical Guide for Industrial and Commercial Deployments
Connected devices, industrial routers, MQTT brokers and remote monitoring systems all share the same fundamental vulnerability: they are reachable from the outside world. This guide covers what that means in practice, where the real risks sit, and what good security looks like layer by layer.
of a new public IP address
with default credentials
on a single exposed router port
Why IoT security is different
Traditional IT security focuses on protecting servers, workstations and corporate networks. IoT security has a different problem. The devices are physical. They are often in remote or unattended locations. Many run embedded operating systems with limited update mechanisms. And they are frequently connected to things that matter – power infrastructure, water systems, building controls, CCTV networks, industrial machinery.
The combination of remote deployment, physical consequence and persistent connectivity creates a risk profile that standard IT practices do not fully address. A laptop that is compromised can be wiped and reissued. A PLC that is accessed through a compromised gateway router, or a building management system that an attacker has pivoted into through a poorly secured IoT device, is a different kind of problem.
There is also a cultural gap. IoT devices are typically specified and installed by engineers whose primary focus is making them work reliably, not making them secure. Security is often treated as something to be added later, if it is thought about at all. The result is a large installed base of connected devices that are accessible, lightly authenticated and rarely updated.
The core principle: IoT security is not about a single fix. It is about building layers of protection so that the failure of any one layer does not result in a full compromise. This is sometimes called defence in depth, and it applies whether you are deploying three devices or three thousand.
The threat landscape for industrial IoT
Understanding what you are actually defending against is the starting point. The threats facing industrial and commercial IoT deployments are not theoretical. They are happening continuously at scale, and most of them are automated rather than targeted.
Automated scanning
Bots continuously sweep public IP ranges looking for open ports and known services. A new public IP is typically probed within minutes. No human attacker is needed.
Credential stuffing
Default usernames and passwords for routers, cameras and industrial devices are well documented online. Automated tools cycle through them systematically against any open management interface.
Firmware exploitation
Known vulnerabilities in router firmware, camera software and industrial device operating systems are public knowledge. Unpatched devices remain vulnerable indefinitely.
Supply chain and firmware tampering
Compromised firmware or malicious updates targeting specific device families have been documented. Verifying firmware integrity matters, particularly on devices with automatic update features.
Lateral movement
A compromised router or gateway is often not the end goal. It is a stepping stone into the wider network – to SCADA systems, PLCs, building controls or data stores that sit behind it.
Denial of service
Industrial IoT devices on public IP SIMs can be subjected to traffic floods that exhaust data allowances, cause device reboots or disrupt legitimate monitoring and control functions.
It is worth noting what the vast majority of attacks are not: targeted, sophisticated or carried out by nation-state actors. Most compromises of IoT infrastructure result from opportunistic automated scanning hitting devices with weak or absent authentication. The fix is usually straightforward – it just has to actually be done.
Where the risk actually comes from: the access model problem
If there is one root cause behind most IoT security incidents, it is this: someone needed remote access to a device, chose the most convenient option available, and that option was port forwarding.
Port forwarding means the device’s management interface, camera stream, SCADA endpoint or automation platform is directly reachable on a public IP address. The engineer can get to it. So can everyone else.
A device on a closed local network with no remote access path is not meaningfully at risk from internet-based attacks. Risk is introduced by remote access. The method of remote access determines the risk level. Port forwarding is the highest-risk method. A VPN tunnel is the lowest.
This matters because the connectivity type – whether a site uses wired broadband, a fixed public IP SIM, FTTP, or leased line – is largely irrelevant to the security risk. What matters is whether there is a path from the public internet to the device, and what stands between the attacker and the device at the end of that path.
Public IP SIM cards and the cellular exposure problem
Fixed public IP SIM cards are widely used in IoT deployments because they give engineers a direct, predictable address to reach remote hardware. The problem is that “reachable by the engineer” and “reachable by automated internet scanners” are the same thing when port forwarding is involved.
A cellular router on a public IP SIM with port 22 (SSH), port 80 (web interface) or port 443 (HTTPS management) forwarded to the internet will receive probing traffic within minutes of going live. Our Teltonika security guide includes real data on what this looks like in practice, along with an interactive audit tool to check your configuration.
The alternative is a private APN. A private APN SIM places the device on an isolated mobile network segment with no public IP address. Traffic flows to a dedicated infrastructure endpoint – typically a VPN concentrator, a private cloud environment or a direct connection to a corporate network. The device is not visible from the public internet at all. This is the most secure connectivity model for fixed industrial deployments.
For more on the difference between public IP, private APN and the various SIM options available for IoT, our IoT SIM explained guide covers the connectivity choices in detail.
VPN as the right remote access model
Where remote access is needed – and it usually is – a VPN tunnel is the right model regardless of the underlying connectivity. The device sits on a private network. The engineer connects to a VPN server and then accesses the device on its local address. No management ports are exposed publicly. Automated scanners never reach the device.
Modern industrial cellular routers support VPN natively. WireGuard, OpenVPN and IPsec are all commonly available on devices from Teltonika, Robustel, Milesight and other manufacturers. WireGuard in particular has become the preferred choice for new deployments because of its low overhead, strong cryptography and straightforward configuration – important on devices with constrained processing resources.
Engineer laptop / mobile
↓ WireGuard / OpenVPN client
VPN server (cloud or on-premises)
↓ Encrypted tunnel
Industrial router at remote site
↓ Private LAN
Device / sensor / PLC / camera
# No management ports exposed publicly
# Automated scanners never reach the device
# All traffic encrypted end to end
Teltonika RMS (Remote Management System) provides a managed alternative for Teltonika devices that prefer not to run their own VPN infrastructure. It creates encrypted tunnels to individual devices through the RMS platform without requiring a public IP or open ports. This is a practical option for smaller deployments where a dedicated VPN server adds unwanted complexity.
Layer by layer: what IoT security actually looks like
Good IoT security is not a single product or a single configuration change. It is a set of overlapping controls at different layers. If one layer fails or is bypassed, the others limit the damage. Here is how to think about the layers for a typical industrial or commercial IoT deployment.
Connectivity and network architecture
The first layer is how the device reaches the internet and how traffic flows to and from it. Private APN is the most secure. VPN over public IP is the next best. Port-forwarded public IP is the weakest. Network segmentation – keeping IoT devices on their own VLAN or subnet – limits the blast radius if something is compromised.
Router and gateway hardening
The router or gateway is typically the first device that faces the network. It needs to be properly configured before deployment: default credentials changed, unused services disabled, firmware updated, management access restricted to specific IPs or available only over VPN. Firewall rules should follow a default-deny approach – blocking everything that is not explicitly needed.
Device and endpoint authentication
Every device on the network should require authentication before it responds to commands or shares data. This applies to cameras, MQTT clients, industrial sensors and automation platforms equally. Default credentials must be changed. Strong unique passwords – or certificate-based authentication where supported – should be enforced. Devices that cannot be authenticated properly should not be connected to critical networks.
MQTT and protocol security
MQTT is the dominant messaging protocol in IoT and it requires careful configuration. An open, unauthenticated MQTT broker on a public IP is a significant vulnerability – it can expose sensor data, accept malicious commands and provide a pivot point into connected systems. TLS encryption, username/password authentication and access control lists (ACLs) restricting which clients can publish to or subscribe from which topics are all standard practice on production deployments.
Firmware and software updates
Known vulnerabilities in device firmware are public information. An unpatched device running firmware from two years ago is carrying known exploits that automated scanners are actively looking for. A firmware update policy – with a defined schedule, a testing process for critical infrastructure and a record of what versions are running where – is an operational requirement, not a nice-to-have.
Monitoring, alerting and visibility
You cannot defend what you cannot see. Knowing which devices are online, what their traffic patterns look like and when something changes is the foundation of operational security. Teltonika RMS provides this for Teltonika hardware. Broader fleet management, SNMP monitoring and SIEM integration become important at scale. The goal is to detect anomalies before they become incidents.
Physical security
A device that can be physically accessed can be factory reset, have its SIM card removed or be replaced with a compromised unit. Enclosures with tamper detection, cable management that makes unauthorised connections visible and site access controls are part of the security picture for unattended remote deployments.
Securing specific application types
CCTV and video surveillance
IP cameras are among the most commonly compromised IoT devices. They run embedded Linux, many share the same firmware base across manufacturers and their default credentials are extensively documented. A camera on a public IP with default credentials is indexed by Shodan within days and accessible to anyone who looks.
The correct model for remote CCTV access is a VPN to the site, then access to cameras on their local addresses. If a VMS (video management system) needs to be accessible externally, it should sit behind a properly authenticated HTTPS endpoint, not a raw port forward. Direct RTSP streams should never be forwarded to the public internet.
Building management systems
BMS controllers and building automation equipment – HVAC, access control, energy metering, lighting – are particularly sensitive because compromise can have immediate physical consequences. The BMS vendor network is also a common attack vector: many BMS installations include remote access for the vendor’s own maintenance team, and if that access is a simple port forward with shared credentials, it is a vulnerability in your network regardless of what you have done on your own side.
Network segmentation is especially important for BMS. The BMS network should not share routing with corporate IT systems, and certainly not with guest or visitor networks. Access from outside should go through a VPN with strong authentication, with access logs reviewed periodically.
Industrial automation and SCADA
Industrial control systems were historically air-gapped – physically separated from any network with external connectivity. That model has been eroded by the practical need for remote monitoring, predictive maintenance and integration with enterprise systems. The result is SCADA systems and PLCs that are now reachable over networks, often without the security architecture that would be applied to IT systems.
SCADA security deserves its own treatment, but the basics apply: network segmentation using a dedicated OT (operational technology) network, a properly configured industrial DMZ between OT and IT, no direct internet connectivity to control systems, and remote access only via authenticated VPN with multi-factor authentication where the system supports it. Protocols like Modbus, DNP3 and IEC 61850 were not designed with authentication in mind – the network architecture has to compensate for that.
Node-RED is increasingly used to bridge industrial protocols and cloud platforms in these environments. Our Node-RED security guide covers the specific risks and the right access model for Node-RED deployments in industrial contexts.
Edge computing and on-router automation
Some cellular routers now run Docker containers and support running full automation platforms – including Node-RED – directly on the router hardware. This is genuinely useful for edge processing but it adds an additional attack surface. If the router is compromised, so is everything running on it. And if Node-RED on the router is accessible externally without authentication, it provides a powerful automation engine to any attacker who finds it.
The rule is the same as for any other service: access via VPN, authentication enabled, unused services disabled. Our guide to running Node-RED on Teltonika RUTC routers covers the Docker-based deployment model and the considerations that go with it.
IoT security and UK regulatory compliance
Security is increasingly not just good practice – it is a regulatory requirement. UK and European regulations are moving in a consistent direction: connected devices must be secure by design, vendors must support updates, and operators of critical infrastructure have specific obligations.
| Framework | Who it affects | Key requirements |
|---|---|---|
| PSTI Act 2024 | UK manufacturers and importers of consumer connectable products | No universal default passwords; vulnerability disclosure policy; minimum security update period disclosed |
| Radio Equipment Directive (RED) | Radio equipment sold in the EU; likely UK alignment | Cybersecurity requirements for internet-connected radio equipment; network protection; personal data safeguards |
| NIS2 Directive | EU essential and important entities; UK equivalent via NIS Regulations | Risk management measures; incident reporting; supply chain security; minimum security baselines |
| UK Cyber Essentials | UK organisations, particularly those handling government contracts | Boundary firewalls, secure configuration, access control, malware protection, patch management |
| IEC 62443 | Industrial automation and control systems | Layered security zones and conduits; security levels; lifecycle security requirements for OT systems |
For most operators of industrial IoT infrastructure, the practical starting point is not full regulatory compliance mapping but basic hygiene: changed default credentials, VPN-only remote access, firmware update policy, and network segmentation. These steps address the vast majority of real-world risk and move the needle significantly on most compliance frameworks at the same time.
A practical IoT security checklist
This covers the baseline. It is not exhaustive for high-security or regulated environments, but it addresses the most common failure modes.
- Change all default usernames and passwords before deployment – on every device, not just the router
- Disable all management services that are not actively needed (SSH, Telnet, HTTP, SNMP v1/v2)
- Use VPN for all remote access – do not port-forward management interfaces to the public internet
- If using cellular, consider private APN for fixed industrial deployments rather than public IP SIM
- Apply firewall rules using a default-deny approach – block everything not explicitly permitted
- Enable HTTPS everywhere a web interface or API is accessible over a network
- Enable authentication and TLS on all MQTT brokers accessible outside a trusted local network
- Keep firmware and software updated on a defined schedule – record versions and patch dates
- Segment IoT devices onto their own network – do not place them on the same segment as IT systems
- Monitor devices for connectivity changes, traffic anomalies and failed login attempts
- Have a documented process for responding to a suspected compromise
- Review third-party remote access arrangements – vendor access is your responsibility too
- Back up configurations so devices can be restored to a known-good state after an incident
- Check public exposure using tools like Shodan – search your own IP ranges periodically
Going deeper: guides and tools on IoT Portal
The sections below link to the detailed guides on this site covering specific aspects of IoT security. Each one goes into more depth on a particular topic or device type.
Not sure how exposed your infrastructure is?
The Teltonika security audit tool walks through your router configuration, tests for common exposure patterns and gives you a prioritised list of things to fix.
Run the security audit