Skip to main content
Many organisations rely on connected devices for daily operations, yet few have complete visibility into the security gaps these devices may conceal. These devices tend to stay in place for years, move between environments or rely on networks that behave differently from one moment to the next, which makes blind spots easy to miss.
Blind spots often lurk in seemingly harmless areas, yet they can significantly impact the extent to which a deployment is exposed and the ease with which something small can be misused. Verizon's Data Breach Investigations Report notes that attack paths frequently begin with overlooked system behaviours that seem routine. These gaps are common because teams focus on outcomes, and devices are expected to run quietly in the background.
Internationally recognised frameworks address these risks directly. The GSMA IoT Security Guidelines outline practical measures for securing connected device deployments across mobile networks. ETSI EN 303 645 sets the European cybersecurity baseline for consumer and enterprise IoT devices. Many of the most serious risks arise from predictable patterns in how devices connect, communicate and stay online.
10 Areas That Put Connected Devices at Risk
Every connected environment develops familiar patterns in how devices behave on the network. These patterns can reveal subtle weaknesses that are easy to miss in day-to-day operations, yet they have a meaningful impact on overall security.
1. Weak and Default Credentials
Weak and default credentials are a blind spot because they feel harmless during setup. Many connected devices arrive with preset usernames and passwords that work immediately, which makes provisioning faster, but if these credentials aren't changed, they create significant security vulnerabilities. This affects large and small deployments and has been exploited on a massive scale. The Mirai botnet is a prime example, exploiting publicly available default credentials to compromise hundreds of thousands of devices worldwide.
Many teams already understand the importance of passwords, yet weak and default credentials remain one of the most common ways attackers gain access to connected devices.
Guidance for Weak and Default Credentials
| Framework | GSMA IoT Security Guidelines | ETSI EN 303 645 (Provision 5.1) |
|---|---|---|
| What It Requires | Calls for unique, device specific credentials and discourages universal default passwords in IoT service deployments. | Requires no universal default passwords and mandates that each device has a unique password or forces the user to set one at first use. One of the few mandatory provisions in the standard. |
The fix is simple. Make credential rotation part of the provisioning process so that each device receives a strong, unique password before it goes live, not after. Relying on someone to update credentials later leads to prolonged risk exposure. At the connectivity layer, your IoT MVNO can also restrict device communication to authenticated, private channels, which limits the impact even if a default credential ever slips through.
2. Insecure Network Services
Many connected devices still run background services that were never intended for production use. These might include legacy protocols such as Telnet, unencrypted HTTP management pages, or diagnostic ports left active during development. Each open service increases exposure, especially when a device is deployed outside controlled environments.
If these services are reachable from the public internet, they can be found quickly by automated scanners. Shodan, the search engine that indexes internet exposed devices, routinely lists millions of open ports and insecure IoT interfaces. IT teams recognise how easily these entry points can be discovered, while non technical leaders are often surprised at how visible these devices really are.
Many organisations are surprised by how often unnecessary or outdated network services are left running on connected devices. These services are usually enabled during development or manufacturing and never removed before the device enters real operational environments. They may not cause immediate issues, but they quietly widen the attack surface and make devices easier to probe or misuse.
Guidance for Insecure Network Services
| Framework | GSMA IoT Security Guidelines | ETSI EN 303 645 (Provision 5.6) |
|---|---|---|
| What It Requires | Advises minimising the attack surface by disabling any services that are not essential for the device's function. | Requires minimising exposed attack surfaces and ensuring unnecessary ports, services and functions are disabled while software runs with least privilege. |
Begin by auditing which services are active on each device model in your estate. Manufacturers can supply this information, and independent security assessments can verify it. Any service that is not essential should be disabled.
Where disabling is not possible, your connectivity provider can help contain the exposure. A private APN, paired with network-level firewall rules, can completely block inbound traffic to unnecessary services, reducing risk even when the device itself cannot be modified.
3. Insecure Management Interfaces
A device can be physically secure and configured correctly, but if the cloud portal or app used to manage it lacks strong authentication or encryption, attackers have a much easier route in. Gaining access to a management interface can expose the entire device fleet, even without physical access to the hardware. This is the layer most attackers will target first because it centralises control, often offers broad permissions and can reveal sensitive device information that would otherwise be difficult to access.
Even well-protected devices become vulnerable if their management interfaces are not secured to the same high standards. This often includes cloud portals, mobile apps or APIs that sit above the device layer. These interfaces are convenient for scaling and automation, but they can also become a single point of exposure if authentication is weak or communications are not encrypted.
Guidance for Insecure Management Interfaces
| Framework | GSMA IoT Security Guidelines | ETSI EN 303 645 (Provision 5.5) |
|---|---|---|
| What It Requires | Requires strong authentication, authorisation and encrypted communications across all APIs and service interfaces in an IoT ecosystem. | Requires secure communication for devices and associated services, ensuring interfaces protect confidentiality and integrity of all transmitted data. |
Begin by auditing which services are active on each device model in your estate. Manufacturers can supply this information and independent security assessments can verify it. Any service that is not essential should be disabled.
Where disabling is not possible, your connectivity provider can help contain the exposure. A private APN combined with network-level firewall rules can block all inbound traffic to unnecessary services, which significantly lowers the risk even when the device itself can't be modified.
4. No Secure Update Mechanism
Every software flaw has a window between discovery and patch. For devices without a secure remote update mechanism, that window never closes. A device deployed several years ago may still be running vulnerable firmware today simply because there is no safe, scalable way to update it. Manual updates are rarely feasible across large or geographically distributed fleets, which leaves a long tail of devices exposed long after a fix exists.
Many connected devices are designed to run for years with minimal intervention, which makes their update process one of the most important parts of their security posture. When a device cannot receive authenticated, secure firmware updates, any vulnerability discovered after deployment remains open for the lifetime of that device. This is common in environments where devices are widely distributed, placed in hard‑to‑reach locations or simply never designed to be updated remotely.
Guidance for Secure Update Mechanisms
| Framework | GSMA IoT Security Guidelines | ETSI EN 303 645 (Provision 5.3) |
|---|---|---|
| What It Requires | Requires support for secure over‑the‑air updates, using cryptographically signed firmware delivered over encrypted communication channels. Reliable network connectivity is identified as a dependency for secure update delivery. | Requires that IoT devices are securely updateable and that updates are verified for authenticity and integrity before installation. This is one of the standard's mandatory requirements. |
Make secure over‑the‑air updates a mandatory requirement during procurement. Vendors should demonstrate that firmware is cryptographically signed and delivered over an encrypted channel before any device is approved for deployment. It's essential to request a clear end-of-support timeline, as devices without a defined patch schedule become long-term security liabilities.
Your IoT MVNO plays a vital role by providing stable connectivity, which helps ensure remote updates are reliable, even in low-signal or remote locations.
5. Outdated Firmware and Unpatched Components
Many IoT devices still run on software stacks that were assembled years ago. This can include outdated Linux kernels, legacy communication libraries or embedded components that no longer receive patches. When a vulnerability is discovered in any of these layers, the device becomes exposed, regardless of how secure the top layer of the manufacturer's code might be. Most businesses lack clear visibility into the components within their connected devices, making it difficult to assess risk or determine the scope of a vulnerability when a new CVE is announced.
Many connected devices rely on layers of third-party libraries, embedded operating systems and older software components that remain unchanged long after deployment. These underlying components often become outdated without notice, remaining invisible to the teams who use the devices day-to-day. When a vulnerability is discovered in any part of that software stack, the device becomes exposed even if the manufacturer's own application code is sound.
Guidance for Firmware and Component Updating
| Framework | GSMA IoT Security idelines | ETSI EN 303 645 (Provision 5.3 and 5.7) |
|---|---|---|
| What It Requires | Requires IoT service providers to maintain a software inventory and track vulnerabilities in third party components throughout the device lifecycle. | Requires devices to verify software integrity and manufacturers to maintain a vulnerability disclosure policy and remediation plan for all components, including third party libraries. |
Ensure that a Software Bill of Materials (SBOM) is a standard requirement in your procurement process. An SBOM provides a clear list of every component running on a device, including version numbers and known vulnerabilities, and it is becoming a formal expectation under emerging regulations such as the EU Cyber Resilience Act.
If a supplier cannot provide an SBOM or is unwilling to share it, treat that as a signal that long-term security maintenance may be inconsistent or difficult to verify.
6. Unencrypted Data Transmission
Many connected devices still transmit information using unencrypted protocols such as HTTP or other legacy services with no transport security. This often happens because the same communication path used for simple telemetry is also used for personal information, payment data or operationally sensitive readings.
Using the public internet as the transport path makes this worse. Traffic can move through networks, routers and service providers that the organisation has no visibility into and no security agreement with, which exposes the data at every stage of its journey.
Many connected devices send data across networks that the organisation does not own or control. When traffic is unencrypted, anyone with access to its path can potentially view sensitive information that should remain private. This includes routine telemetry as well as sensitive operational data. The risk often arises because devices still rely on older or default protocols that transmit information in clear text.
Guidance for Encrypted Data Transmission
| Framework | GSMA IoT Security Guidelines | ETSI EN 303 645 (Provision 5.5) |
|---|---|---|
| What It Requires | Requires all data in transit between IoT endpoints and cloud services to be encrypted using recognised best practice protocols, recommending TLS or DTLS for device communications. | Requires IoT devices and associated services to use best practice cryptography to communicate securely and identifies unencrypted transmission of sensitive data as non-compliant. |
Encryption needs to be a mandatory requirement for all device communications. TLS 1.2 should be the minimum, with TLS 1.3 preferred for modern deployments. Configuration standards should prohibit HTTP or any protocol that sends data without protection.
In high-risk environments, route device traffic away from the public internet. Using a private APN creates a dedicated pathway that delivers data directly to your infrastructure, bypassing public networks. This network-level solution operates like a VPN, substantially lowering the risk of data exposure while information is in transit.
7. Insecure Default Settings
Devices are often designed to be as easy as possible to install. This can mean open debug interfaces, permissive firewall rules, disabled authentication features or broad network access left active from the factory. These defaults reduce setup time but create a significantly larger attack surface. If devices are not reviewed and secured before deployment, they may be vulnerable from the moment they first connect to the network.
Many connected devices arrive configured for quick installation rather than long-term security. Default settings that simplify setup can also increase the attack surface as soon as a device is activated. In fast-paced deployments, these defaults often remain unchanged, leaving devices more exposed than teams may realise.
Guidance for Secure Default Settings
| Framework | GSMA IoT Security Guidelines | ETSI EN 303 645 (Provisions 5.6 and 5.8) |
|---|---|---|
| What It Requires | Requires devices to ship in a secure by default state with minimal attack surface, unnecessary features disabled and security controls active from first use. | Requires device attack surfaces to be minimised with unused capabilities disabled by default and mandates that installation and maintenance remain simple without compromising security. |
Implement a device hardening checklist as a standard part of every deployment. This should include closing unnecessary ports, disabling debug interfaces, enabling authentication controls, and reviewing any factory-default remote access settings. Apply this same baseline to every device type to avoid inconsistencies.
Your IoT MVNO can reinforce this by applying network-level policies that block unnecessary traffic paths and prevent insecure defaults from becoming active exposures, even on devices that cannot be fully reconfigured.
8. Weak Device Identity
Many IoT deployments authenticate devices only through their network connection, without any binding between the SIM, the device hardware and the cloud services they access. This makes it easy for a SIM to be removed and used elsewhere or for a cloned device to appear legitimate. IMEI locking, which binds each SIM to the hardware it was provisioned for, is a basic control that is widely available but rarely enabled. Without a hardware-rooted identity, it is impossible to reliably distinguish a trusted device from one that has been cloned or stolen.
Many connected deployments still rely on network connectivity alone to recognise devices. Without strong identity controls rooted in hardware, it becomes difficult to distinguish a legitimate device from one that has been cloned, stolen or tampered with. This weakens trust across the entire fleet and exposes systems to avoidable risks.
Guidance for Device Identity Controls
| Framework | GSMA IoT Security Guidelines | ETSI EN 303 645 (Provisions 5.4) |
|---|---|---|
| What It Requires | Recommends using the SIM as a hardware root of trust to store cryptographic credentials securely and authenticate devices to cloud services. Also recommends IMEI locking to bind SIMs to specific devices. | Requires sensitive security parameters to be stored securely and explicitly references the UICC (the technical term for a SIM) and GSMA eSIM specifications as appropriate secure storage mechanisms. |
Implement IMEI locking across your entire device estate to ensure each SIM can only operate in its designated device. Your IoT MVNO can configure this efficiently at scale.
In high-sensitivity environments, adopt the GSMA IoT SAFE approach, leveraging the SIM's secure element as a hardware root of trust. This enables devices to authenticate directly to cloud services using cryptographic certificates instead of passwords or software tokens, providing significantly stronger identity assurance.
9. Insufficient Data Privacy Controls
Many IoT devices collect more data than is required for their intended function. This information is often transmitted to cloud platforms controlled by the manufacturer and may be shared with third parties according to terms that are rarely reviewed in detail. Data that seems harmless on its own can become sensitive when aggregated or cross-referenced with other information. Under GDPR and related laws, the liability for personal data sits with the organisation using the device, not the vendor. This means unseen data flows can create compliance obligations without the organisation realising it.
Connected devices often capture and transmit more information than their intended function requires. This can include location data, usage patterns or environmental readings that, when combined, can be linked back to individuals. Once collected, this data is often transmitted to cloud platforms or stored by the manufacturer, frequently with limited transparency about how it is processed or shared. For organisations subject to data protection law, the responsibility for this data does not sit with the vendor. It sits with the organisation operating the device.
Guidance for Data Privacy Controls
| Framework | GSMA IoT Security Guidelines | ETSI EN 303 645 (Clause 6) |
|---|---|---|
| What It Requires | Requires personal and sensitive data processed by IoT devices to be handled in line with data protection law, applying data minimisation and purpose limitation by design. | Requires protection of personal data, application of data minimisation and clear communication to users regarding what data is collected and how it is used. |
Complete a data mapping exercise for every device model in your fleet. Determine what data each device collects, where it is sent, who can access it, and how long it is retained. Require formal data processing agreements from device vendors and platform providers to clarify roles and responsibilities.
A private APN with application-layer traffic filtering adds further control by limiting where device data can be sent. This provides a level of oversight and containment that consumer mobile infrastructure cannot offer.
10. Poor Asset Visibility and Lifecycle Management
This visibility gap makes every other security challenge more difficult to address. If you don't know what's connected, you can't patch, monitor, or safely retire those devices. Legacy equipment, forgotten test units, or hardware reassigned without proper documentation all become unmanaged, active connections. A forgotten device remains on your network. If you can't see it, you can't secure it, and if you don't know it exists, you can't disable it.
One of the greatest risks in any connected environment is a lack of visibility into what is active on the network. Devices may remain online long after a project ends, be reassigned between teams without adequate documentation, or stay connected even when they are no longer in use. These visibility gaps undermine all other security measures, as you cannot protect a device you're unaware of or decommission a connection you cannot see.
Guidance for Asset Visibility and Lifecycle Management
| Framework | GSMA IoT Security Guidelines | ETSI EN 303 645 (Clause 6) |
|---|---|---|
| What It Requires | Requires personal and sensitive data processed by IoT devices to be handled in line with data protection law, applying data minimisation and purpose limitation by design. | Requires protection of personal data, application of data minimisation and clear communication to users regarding what data is collected and how it is used. |
A real-time asset inventory is the foundation of every other security control in this guide. Your IoT MVNO should be able to provide a live view of every active SIM, including its status, data usage and last known location.
Any device that appears in your asset register but not in your SIM inventory, or vice versa, should be flagged for immediate investigation. This is the ideal time to request comprehensive visibility from your provider.
Strengthening Your Connected Environment
The ten blind spots in this guide each point to practical actions that significantly improve the security and reliability of connected devices. These factors include credentials, updateability, network behaviour, identity, data handling, and lifecycle management, and they are highlighted across internationally recognised security frameworks, including the GSMA IoT Security Guidelines and ETSI EN 303 645. These are not rare edge cases. They are standard exposures that appear in organisations of every size running connected devices.
Cellhire enables these controls at the connectivity layer through private networking, identity binding, secure SIM management, and real-time fleet visibility. This foundation empowers you to implement security measures with confidence.
If you're looking for a straightforward, commitment-free way to explore available improvements, speak with Cellhire's IoT experts.
Frequently Asked Questions About Securing Connected Devices
Why do IoT security blind spots appear even in mature organisations?
Because most blind spots come from normal device behaviour, not obvious failures. Devices stay in service longer than planned, move between environments or rely on default settings designed for convenience rather than security. These patterns are common across every sector, which is why frameworks like GSMA FS.60 and ETSI EN 303 645 highlight them as standard risks.
How can I tell if my IoT devices are sending data securely?
Check two things: the protocol and the route. If devices still use HTTP or any protocol without encryption, the data is exposed. And if traffic travels over the public internet, it moves through infrastructure you do not control. TLS encryption and private routing (such as a private APN) close both gaps.
Do I really need a Software Bill of Materials (SBOM) for IoT devices?
If your devices run long lived firmware or third party components, an SBOM is the only way to know what is inside them. When new vulnerabilities appear, it becomes far easier to assess exposure. SBOMs are fast becoming expected under cybersecurity regulations and procurement standards.
How do I know if my devices can be updated securely?
Look for cryptographically signed firmware updates delivered over encrypted channels. If updates rely on manual intervention or unsecured downloads, vulnerabilities remain open indefinitely. Secure remote updates are now a baseline requirement in GSMA FS.60 and ETSI EN 303 645.
What is the simplest first step to improving IoT security?
Start with visibility. If you cannot see every device and SIM that is active, you cannot protect them. A real time inventory helps you find forgotten hardware, inactive SIMs and devices that have moved without documentation.
Cellhire's IoT SIM Management offers real-time visibility into every SIM, making it easier to quickly identify blind spots and prioritize security efforts.
How does the SIM influence IoT security?
The SIM can act as a hardware root of trust. It can store cryptographic credentials, bind to a specific device using IMEI locking and authenticate directly to cloud services. This reduces reliance on weak software credentials and prevents SIMs being moved or cloned without detection.
Why do insecure default settings remain such a problem?
Manufacturers optimise for easy installation, not hardened security. Debug ports, permissive network rules and disabled authentication often ship as defaults. Unless these are changed before deployment, devices remain exposed from the moment they connect.
Can an IoT connectivity provider reduce these risks?
Yes. Strong providers give you private routing, device level identity controls, secure SIM lifecycle management and real time fleet visibility. These capabilities directly influence eight out of the ten blind spots surfaced in the blog.
