Can smart devices be a security risk?

Smart devices are now common in homes, offices, schools, clinics, shops and shared workspaces. They can include routers, cameras, printers, smart TVs, thermostats, door entry systems, voice assistants, NAS devices, lighting systems and other equipment connected to a network.

This guide explains why these devices can become part of the security picture, how attackers may misuse poorly protected devices, and what practical steps reduce the risk without treating every device as a crisis.

Supporting visual reference. This image summarises the topic at a high level. The written guide below provides the full explanation and practical guidance.

Use the links below to jump to the section most relevant to your question.

• What counts as a smart device?
• Why smart devices can create security risk
• What the aquarium thermostat example shows
• How compromised devices can be used in wider attacks
• Why network segmentation matters
• Practical steps to reduce risk
• What this does not mean
• Further reading
• Need help with something covered in this guide?
• Further Guidance and Support

A smart device is any device that connects to a network to send or receive data, even if its main purpose is not computing. In a home or office environment, this can include equipment that is visible to users as well as equipment managed by suppliers, facilities teams or installers.

Examples include routers, wireless access points, printers, CCTV cameras, smart TVs, thermostats, door entry systems, voice assistants, NAS devices, video recorders, lighting systems, environmental sensors and other internet connected equipment.

The security issue is not that every connected device is unsafe. The issue is that these devices are sometimes added to networks without the same review, update planning or access control applied to laptops, servers and cloud accounts.

Many smart devices are designed to perform a narrow task. A printer prints, a camera records, a thermostat controls temperature and a smart TV displays content. Because that visible function may continue working normally, it can be easy to overlook whether the device is still supported, updated, monitored or correctly separated from more sensitive systems.

A connected device may create risk when it:

• uses default or weak credentials

• exposes unnecessary remote access

• runs outdated or unsupported firmware

• no longer receives security updates

• depends on an old supplier account or cloud service

• has more network access than it genuinely needs

• sits on the same network as sensitive business systems without a clear reason.

However, supported and fully updated does not mean invulnerable. Firmware and device software can contain weaknesses that have not yet been discovered, vulnerabilities for which an effective fix is not yet available, or configuration problems that an ordinary update does not correct.

A useful way to think about the risk is:

Device is connected
↓
Device has software, accounts and network access
↓
A weakness, compromised account or vulnerable service is encountered
↓
The device may be misused
↓
What happens next depends partly on what that device is allowed to reach

This is why patching is important but not sufficient on its own. Connected devices should also be known, appropriately configured, monitored where practical and given only the access they actually need.

NCSC guidance has documented compromised routers, IoT devices, firewalls, NAS devices and other edge equipment being used as part of larger covert networks. End-of-life devices are particularly concerning because security updates may no longer be available, but supported devices should still be treated as part of the wider security model.

One widely reported example involved an unnamed casino where attackers reportedly used an internet connected thermometer in a lobby aquarium as a way into the network. The important lesson is not the fish tank itself. The lesson is that a low profile connected device can become relevant if it is connected to the same environment as more sensitive systems.

This example is useful because it shows how risk can sit outside the obvious places. A business may focus on computers, payment systems, email accounts and firewalls, while overlooking equipment installed for facilities, monitoring, display or convenience.

The issue is often ownership and visibility. IT may manage computers and servers, facilities teams may manage cameras, thermostats and access systems, while suppliers may install equipment with their own remote access or cloud management. If no one has a complete view of what is connected, who manages it and what access it has, smaller devices can fall between responsibilities.

This external video provides a useful narrative explanation of the aquarium thermostat example.

A compromised smart device may be used in different ways depending on the environment and the attacker’s objective. It may provide a foothold, help scan other systems, relay traffic, communicate with malware, or take part in wider attacks against other organisations.

The NCSC advisory explains that covert networks can be used across several stages of malicious activity, including reconnaissance, malware delivery, command and control, and data exfiltration. This matters because traffic may appear to come from ordinary internet connected devices rather than from a clearly suspicious source.

This is one reason static blocking alone is not enough. Blocking known bad IP addresses can help, but the list of bad sources can change quickly. Better protection also depends on knowing what is connected, limiting unnecessary access, reviewing remote access, and monitoring unusual behaviour where practical.

Network segmentation means separating devices or systems so that they do not all have the same level of access. The objective is not separation for its own sake. The objective is to make access intentional.

For example:

Smart TV
needs internet access
↓
may need screen sharing
↓
does not normally need access to business file shares or administration systems

A CCTV camera may need to communicate with a recorder or supplier cloud service, but it does not normally need broad access to staff computers. A printer may need to receive print jobs, but that does not mean it should be able to reach every management interface or server on the network. Guest WiFi should not normally provide access to internal business systems.

A simple network model might therefore look like:

Business devices → business systems and approved services

Smart / IoT devices → only the services they genuinely require

Guest devices → internet access without access to internal systems

Segmentation does not prevent every device from being compromised. Its purpose is containment. If a printer, camera, smart TV or other device becomes vulnerable or compromised, the network design can help limit what that device is able to reach next.

This is why segmentation remains useful even when devices are fully updated. It reduces the amount of trust placed in any one device and can limit the impact if one layer later fails.

Reducing smart device risk starts with visibility. A device cannot be managed properly if no one knows it exists, who installed it, who administers it, whether it is still supported or what other systems it can reach.

Useful steps include:

• keep an inventory of routers, access points, printers, cameras, smart TVs, NAS devices, thermostats and other connected equipment

• record who owns or manages each device, including suppliers, installers or facilities contractors

• record the device model and support status where practical

• replace unsupported or end-of-life equipment where reasonable

• keep firmware and device software updated where supported updates are available

• change default credentials and avoid unnecessary shared administrator accounts

• disable remote access and services that are not required

• use separate networks or VLANs where appropriate

• avoid placing guest, IoT and business devices on one unrestricted flat network

• review which systems each device genuinely needs to communicate with

• review supplier and installer access periodically

• remove old supplier, installer or staff accounts

• record relevant cloud portals, mobile applications and remote management services

• protect management portals with strong authentication where available

• review useful logs or alerts where the router, firewall or management system provides them

• use DNS filtering and other network controls as part of a wider layered approach.

Smart device security also includes the accounts and services around the physical device. A camera, NAS device, door entry system, printer or thermostat may depend on a supplier portal, mobile app, cloud dashboard, installer account or remote support platform.

The review should therefore ask:

Who can manage this device?
↓
What does it need to communicate with?
↓
Is the device still supported?
↓
How would we know if its behaviour changed?
↓
How could it be isolated if necessary?
↓
What would we do if the device or its cloud service stopped working?

That final question is particularly important for devices that support an essential business function. A door entry system, network router, CCTV recorder, payment-related device or environmental control may need a known recovery or replacement path rather than simply a security configuration.

Depending on the device, useful continuity information may include configuration backups, administrator credentials held securely by the organisation, supplier contact details, replacement options and a record of how the device is connected to the network.

These measures are not a one-time checklist. Devices, suppliers, firmware and business requirements change. The enduring principle is to understand what is connected, what it can reach, who controls it and how the organisation would contain or recover from a problem.

This does not mean that every smart device is unsafe or that organisations should avoid connected equipment. It also does not mean that one firewall rule, one VLAN or one firmware update can remove every risk.

Supported and fully updated devices are generally preferable to unsupported equipment because known security fixes can still be applied. However, updates cannot guarantee that a device contains no undiscovered weakness or that its supplier, cloud service, account or wider network path cannot be compromised.

Network segmentation also has a specific purpose. It does not make an insecure device secure. It helps limit what that device can reach if something goes wrong.

The objective is proportionate risk reduction:

Know the device
↓
Keep it supported and maintained
↓
Limit unnecessary access
↓
Monitor where practical
↓
Contain problems
↓
Recover or replace when necessary

Good security is layered. Devices, accounts, networks, suppliers, monitoring and recovery planning need to work together rather than relying on one setting or product.

The following sources may be useful if you would like to explore the standards, terminology, and real world examples in more detail.

• NCSC: Defending against China nexus covert networks of compromised devices
• NCSC: Preventing lateral movement
• NCSC: 10 Steps to Cyber Security: Network security
• NCSC: Managing the risks from obsolete products
• Business Insider: Hackers once stole a casino’s high roller database through a thermometer in a lobby fish tank
• Cloudflare: What is the Mirai botnet?
• Palo Alto Networks Unit 42: 2020 IoT Threat Report
• Wired: Hackers remotely kill a Jeep on the highway

A guide can explain the issue and outline useful checks, but some situations need the actual device, account, service, website, network or supplier arrangement to be reviewed. Evening Computing can help review what is happening and advise on suitable next steps before changes are made.

This guide forms part of a broader layered security approach. For structured guidance on security and resilience planning, see our Security and Resilience page.

For information about practical implementation and ongoing support, you can review our IT services and local IT support coverage across London, Hertfordshire, and Essex.

Return to all guides

Author
Elías Sánchez
IT Support Consultant
Evening Computing

This guide was prepared by Elías Sánchez with research and drafting assistance from AI tools. All technical content has been reviewed and adapted for clarity and accuracy.

Last reviewed
17 August 2026