Is zwave security necessary?

Going out on a limb here, I suspect including a device in secure mode means that it converses using some kind of encrypted connection. I’ve read various reports that the decoding/encoding of this signal can lead to slow-to-respond networks due to the low processing power of various devices.

I guess - why do I need to install my light switch in secure mode? What benefit is that giving me (as a boring old home-owner that likes to control things with my voice and phone)? Can a (technically savvy enough) neighbor spy (or control) on my not-secure-enabled switch?

Just trying to understand the tradeoffs and risks of securely (nor not) included zwave devices.

If there are any articles worth reading, please point me to them. My google-fu has led me to piles of home security systems, but not much on the pros/cons of secure-mode.


I will try to find information about Zwave security and post the links but this is what I remember from my research into Zwave.

Adding a node as secure only works (and required for control of devices to function) for devices that actually have security built in (locks, sirens, smoke detectors, the random smart plug with energy monitoring like the Aeotec Smart Switch 6). If you try to add a node as secure but it does not support security, the controller and the node will fallback to normal insecure communication. This will be transparent to you the user as it will appear the node has been added secure, but in reality the device and the controller negotiated in insecure mode because the node doesn’t support secure.

You can mix secure and insecure devices and it will not affect device or network performance. Mixing Zwave and Zwave plus devices (different generations of devices) will cause everything to communicate at slightly slower speeds of normal Zwave.

There is a security vulnerability of Zwave. This is the part I am fuzzy about because it came out a couple years ago and was so specific that I said to myself it’ll never happen and just briefly glanced over the security paper. The attack vector has to do with the security header when adding a device in secure mode or trying to. Someone could either spoof the security header and reveal information about the Zwave network. What I don’t remember is if that then allows the attacker to control nodes or do anything on the network. I just remember the paper mentioning the attacker can gain access through the security header.

Edit: looks like I was sort of correct. There’s a vulnerability in the pairing process and normal device secure communication that allows the cryptography keys to be exchanged repeatedly and read then reused to gain access to a lock or other secure device.

Edit 2: trying to find a Krebs on Security article but not finding it right now. Here’s another article that explains the attack vector in the pairing process is actually a backwards compatibility design decision and quite literally has to be performed at the exact moment to even remotely have a chance to maybe gain access to a lock.

I seem to remember that some locks will not function correctly unless paired securely, but for lights that won’t be an issue.