Zigbee/Security, hubs and the bench/Security depends on setup
Lesson 10 of 13 · in 3D and VR

Security depends on setup

Zigbee has the cryptographic mechanisms, and what you get depends on how a device was added. This lesson compares a legacy onboarding with an install-code onboarding and turns a replayed frame away.

Lonely BinaryUpdated 2026-10-145 min readNo board required

View it in VR

Lesson 10 of the Zigbee course opens in a VR headset, on a table in front of you, and a voice starts three seconds after you arrive. Type this short address into the browser on a headset such as Meta Quest or Apple Vision Pro, and press Enter VR. No headset? Press Start the lesson: the same lesson, full screen.

learn.lonelybinary.com/vr/zigbee/10

Mechanisms, not a verdict

"Is Zigbee secure?" has no yes or no answer. The standard defines protection for frames, and whether a particular network benefits depends on how it was set up. The bench for this lesson is a timeline for that reason: security is about who knew what, and when, and a floor plan shows none of it.

What protects what

Frame protection uses AES-128 in a mode that gives both secrecy and a check that the frame was not changed. Those are two properties, and a frame can have one without the other. The radio's own layer has security facilities of its own, separate from the Zigbee network and application layers, and not every frame is protected at every layer.

Three key roles matter here. A network key protects network-layer frames for the whole network. A link key protects an exchange between a device and the trust centre, which is the role that decides who may join. An install code is a code printed on or with a device, and a unique link key is derived from it. The bench shows the roles and never a value.

Two ways to join

Older arrangements relied on a well-known default link key. Anyone who knew it could take part in the exchange that delivers the network key. That is a real part of Zigbee's history and of its compatibility, and it is not how joining always works today.

With an install code the device has a key of its own, so a joiner without the code cannot take part. The cost moves to procedure: someone has to read or scan the code, and keep it from people who should not have it.

Counters and replays

Every protected frame carries a counter that only goes up. A receiver that keeps the highest value it has accepted turns away anything not above it, so recording a command and sending it again fails. The protection holds only while the counter is kept and checked correctly. A device that loses its counter has nothing to compare against.

What to take from it

The answer to "is it secure" is a list: how the device was commissioned, which keys are in use, what the implementation does with its counters and what the configuration permits. The same cipher sits inside a careful network and inside a careless one.

Common mistakes

  • Saying "it is encrypted, so it is secure." Encryption and authentication are separate properties, and neither covers a key that was handed to everyone.
  • Treating the default key as how joining works. It is a legacy arrangement. Check how the device you are adding actually onboards.
  • Trusting a counter that is not kept. A replay check protects only while the receiver stores and tests the value.

Edit this page — content/fundamentals/zigbee/security-depends-on-setup.mdx

Discuss this article

Ask about this page. The answer stays here, on the page it belongs to, for whoever hits the same wall next.

Browse Fundamentals on the forum →