Securing Your Connected Home: Practices for Smart Device Networks in Germany

A typical smart home in 2026 connects dozens of devices to the home network — sensors, actuators, cameras, voice assistants, and energy monitors — each representing a potential entry point if not managed carefully. The security posture of a connected home depends less on any single device and more on how the network is structured and maintained.

This article examines network architecture decisions, firmware practices, and the data-protection considerations specific to German households under the Datenschutz-Grundverordnung (DSGVO).

The IoT Threat Landscape

Consumer IoT devices have historically presented several categories of security issues: default credentials that are rarely changed, infrequent or absent firmware updates, unencrypted local communication, and dependence on external cloud infrastructure that may be discontinued.

The Mirai botnet (2016) demonstrated the consequence of internet-facing IoT devices with unchanged factory credentials — over 600,000 devices were recruited into a botnet used in distributed denial-of-service attacks. German residential devices were among those affected.

More relevant to typical residential installations is the lateral movement risk: a compromised device on a flat home network can potentially communicate with other devices, including computers and network-attached storage. Network segmentation addresses this directly.

Network Segmentation with VLANs

A VLAN (Virtual Local Area Network) creates logical separation between device groups on the same physical network infrastructure. IoT devices placed in a dedicated VLAN can reach the internet (for firmware updates, cloud APIs) but cannot initiate connections to devices on the primary home network segment.

Fritz!Box Configuration

AVM's Fritz!Box is the most widely deployed home router in Germany, with a large installed base across DSL and cable connections. Fritz!OS supports guest network separation and, since Fritz!OS 7.x, guest network VLAN tagging for managed switches and Wi-Fi access points.

A practical IoT VLAN configuration on Fritz!Box involves:

1. Creating a dedicated Wi-Fi SSID for IoT devices (e.g., "Home-IoT") with WPA2/WPA3 and a unique password
2. Enabling "Network isolation" on the guest/IoT network to prevent device-to-device communication within the VLAN
3. For managed switches (Fritz!DECT or third-party 802.1Q): tagging IoT-connected ports with a separate VLAN ID
4. Using Fritz!Box firewall rules to allow only specific outbound ports from the IoT VLAN (e.g., 80, 443, 8883 for MQTT)

Separate SSID for IoT — Minimum Viable Segmentation

Without managed switch infrastructure, creating a dedicated Wi-Fi SSID in a guest network profile with the "Internetzugang freigeben, aber keinen Zugang zu Heimnetz erlauben" option in Fritz!Box settings provides basic isolation. IoT devices on the guest network cannot reach the main home network but retain internet access.

Default Credentials and Device Hardening

Many IoT devices ship with factory-set credentials — frequently documented online or identical across entire product lines. Changing these before connecting a device to the network is the single most impactful step in device hardening.

Categories of settings to review on new IoT devices:

• Admin interface credentials (username and password)
• UPnP (Universal Plug and Play) — disable if not required; UPnP can automatically open ports in the router
• Remote access / cloud dashboard access — enable only if needed
• Local API access — configure with authentication where the device supports it
• MQTT broker credentials — use per-device usernames and passwords rather than a shared credential

Firmware Update Practices

Firmware vulnerabilities in IoT devices are regularly disclosed. Manufacturers vary widely in their update cadence and duration of support. Some indicators of a well-supported device include publicly documented release notes, a clear end-of-life policy, and participation in vulnerability disclosure programmes.

The EU Cyber Resilience Act (CRA), which began phased application in 2024, introduces mandatory security update obligations for connected product manufacturers selling in the EU market. Under the CRA, manufacturers must provide security updates for the expected product lifetime and notify ENISA of actively exploited vulnerabilities.

Local Processing vs. Cloud Dependency

A meaningful proportion of smart home security concerns stem from cloud dependency: data routed through manufacturer servers may be subject to the manufacturer's privacy policy, jurisdiction, and business continuity. Device functionality tied to cloud services may become unavailable if the service is discontinued.

Home Assistant as a Local Controller

Home Assistant, running on a Raspberry Pi 4, Raspberry Pi 5, or a dedicated Home Assistant Yellow device, provides a local automation controller that does not require internet access for core functionality. Integrations for Zigbee (ZHA, Zigbee2MQTT), Z-Wave (Z-Wave JS), and Matter run entirely on the local network.

Home Assistant's companion app communicates with the local instance over the home network. Remote access, when needed, is typically configured via Nabu Casa (the cloud service operated by the Home Assistant project) or a Wireguard/Tailscale VPN — both of which avoid exposing the Home Assistant port directly to the internet.

Node-RED for Automation Logic

Node-RED is a flow-based automation environment that can run alongside Home Assistant or independently on the same local server. It processes automation logic without cloud involvement, using MQTT, HTTP, and WebSocket connections to interact with devices on the local network.

Camera Placement and Privacy

IP cameras present distinct privacy considerations. In Germany, the DSGVO applies to personal data including images of people. Cameras pointed at areas accessible to others (streets, shared building entrances, neighbours' properties) are subject to stricter requirements than cameras limited to the interior of a private dwelling.

The Landesdatenschutzbehörden (state data protection authorities) have published guidance on residential camera use. Internal cameras should be avoided in areas where household members have a reasonable expectation of privacy (bathrooms, bedrooms). The data storage period and access controls for camera footage are relevant DSGVO compliance questions for self-hosted NVR systems.

DSGVO and Smart Home Data

Smart home devices collect behavioural data — presence patterns, appliance usage, energy consumption — that qualifies as personal data under DSGVO when it can be linked to identifiable individuals. In a private household, DSGVO's "household exemption" (Art. 2(2)(c)) applies to data processed exclusively for personal or household activities without extending to third parties.

The household exemption does not apply when data is shared with cloud services operated by manufacturers in third countries without adequate data protection (a concern for some US-based IoT platforms under post-Schrems II frameworks). Local-processing deployments that avoid cloud connectivity largely sidestep these questions.

Approach	Network Exposure	Cloud Dependency	DSGVO Considerations
Flat network, cloud devices	High	Full	Third-country transfers possible
IoT VLAN, cloud devices	Medium	Full	Third-country transfers possible
IoT VLAN, local HA + MQTT	Low	None / optional	Household exemption applies
Offline Zigbee/Z-Wave	None (no internet)	None	Household exemption applies

Further reading: BSI's guidelines for home users on network security are available at BSI Smart Home guidance. The EU Cyber Resilience Act text is published in the Official Journal of the EU.