Z-Wave protocol security, explained

Z-Wave began in 1999 at the Danish company Zensys as a proprietary system-on-chip protocol for home automation, operating in sub-1 GHz unlicensed bands chosen specifically to avoid 2.4 GHz Wi-Fi/Bluetooth congestion. Its physical and MAC layers were submitted to the International Telecommunication Union and approved as ITU-T Recommendation G.9959 in January 2015 — giving Z-Wave's radio layer the same kind of international standards-body footing that protocols like Zigbee and Thread have through IEEE 802.15.4. The Z-Wave Alliance, which now stewards the specification, describes the technology as "an open-source, interoperable, wireless, RF-based communications technology designed specifically for control, monitoring, and status reading applications in residential and commercial environments," with member companies including Silicon Labs, ASSA ABLOY and Johnson Controls.

Z-Wave's original security framework, retroactively named S0 once S2 shipped, encrypted traffic with AES but paired devices using a key-exchange step with a documented flaw: the shared network key was itself transmitted during pairing wrapped in a fixed, publicly known all-zeros temporary key — an issue the security consultancy SensePost reported in 2013, meaning anyone capturing that one pairing exchange could recover every subsequent message on the network. The Z-Wave Alliance announced its replacement, S2, on 17 November 2016, and its Board of Directors voted to make S2 mandatory for all newly certified devices starting 2 April 2017. S2 replaces the broken key exchange with Elliptic Curve Diffie-Hellman (ECDH), adds a QR-code or PIN-based out-of-band authentication step so pairing can be cryptographically bound to a code printed on the physical device rather than trusted blindly over RF, and tunnels Z-Wave-over-IP gateway traffic through TLS.

S2 fixed the key-exchange weakness, but Pen Test Partners researcher Andrew Tierney found in 2018 that the choice of which framework to use during pairing was itself unprotected: Z-Wave's Node Info exchange, which tells a controller what security class a device supports, is sent unencrypted and unauthenticated — by design, for backward compatibility with older S0-only devices. Tierney showed an active attacker present during pairing could intercept that exchange, strip out the bit flagging S2 (COMMAND_CLASS_SECURITY_2) support, and make the controller believe the device only speaks S0 (or, in some scenarios, no security at all) — then recover the network key through S0's already-known weak key exchange. Published 23 May 2018 and later tracked as CVE-2018-25029, the finding carried an unusual sting: Tierney's write-up notes the researchers "were fascinated to see reference to a 'S0 downgrade attack' in Z-Wave documentation, suggesting that it may be a known issue but has not been acknowledged or resolved" — the downgrade path wasn't a surprise to the spec's authors. At the time, an estimated 100 million-plus Z-Wave chips across roughly 2,400 vendors were in the field; the practical mitigation is that the attack requires an attacker physically in RF range during the specific pairing window, not an anytime remote compromise, and modern controllers are expected to warn a user when a pairing falls back to S0.

Yes — research has also targeted Z-Wave's normal operation, not just pairing. A January 2020 academic paper, "Crushing the Wave," reported two denial-of-service techniques that abuse unencrypted commands used during both pairing and normal operation — manipulating the Nonce Get / S2 Nonce Get command and the Find Nodes In Range command — to block a Z-Wave gateway's packet processing and knock an entire connected mesh offline, without needing to break S2's underlying cryptography at all. That's a useful reminder that a protocol's cryptographic framework (S0 vs. S2) and its lower-layer command handling are two separate attack surfaces, each needing its own scrutiny.

Z-Wave sits in the same smart-building category as BACnet and KNX in that it is frequently deployed by integrators and facilities teams rather than an organization's core OT/ICS security function, which means an asset owner's first real question is usually simply "what is actually running S2, and what is still on S0 or unpatched firmware from before the 2017 mandate." Since the downgrade and DoS research above target protocol-level behavior rather than a single vendor's implementation bug, neither is something a firmware patch alone reliably fixes — physical pairing-time proximity controls and network segmentation matter as much as keeping device firmware current.

SoftWSP's OT network assessments passively identify which protocols — Z-Wave included — are actually running across a facility's network, which security framework (S0 or S2) paired devices are using, and where unmanaged or forgotten gateways create risk, without requiring any agent installed on existing building-automation equipment. See OT Snapshot for how that passive read works.

This guide is based on the ITU-T G.9959 recommendation text, the Z-Wave Alliance's own technology overview page, Pen Test Partners' original 2018 Z-Shave disclosure, contemporaneous reporting on that disclosure, and the January 2020 "Crushing the Wave" academic paper, all fetched or read directly for this guide. It does not constitute a penetration-test report against any specific Z-Wave deployment.