Evaluating Thread, Zigbee and Z-Wave Against Common Criteria Cryptographic Requirements ^†

Abstract

The explosive growth of the Internet of Things (IoT) has brought an array of resource-constrained devices to domains such as smart homes, industrial automation, and healthcare, raising substantial cybersecurity challenges. Lightweight wireless protocols, such as Thread, Zigbee, and Z-Wave, are integral to IoT connectivity, but the degree to which their embedded cryptographic mechanisms satisfy formal cybersecurity certification schemes remains underexplored. This work draws primarily on recent peer-reviewed publications and major conference proceedings to rigorously evaluate Thread, Zigbee, and Z-Wave against the Common Criteria (CC) Functional Requirements for Cryptography (FCS) as specified in CC:2022 and the EU cybersecurity certification scheme on Common Criteria (EUCC). The assessment focuses on essential CC cryptographic components, including key generation (FCS_CKM.1), secure key distribution (FCS_CKM.2), agreement protocols (FCS_CKM_EXT.7), cryptographic operations (FCS_COP.1), and random bit generators (FCS_RBG.1). The analysis reveals that Thread demonstrates the strongest alignment with CC requirements by leveraging Advanced Encryption Standard—Counter with CBC-MAC mode (AES-CCM) authenticated encryption and Elliptic Curve Diffie-Hellman (ECDH)-based key exchange within a decentralized trust framework. Zigbee matches this cryptographic strength at the primitive level, but its dependency on a centralized Trust Center for key management complicates full compliance with key lifecycle and distribution controls. Z-Wave, especially through its S2 Security framework, improves by incorporating authenticated ECDH exchanges, though proprietary constraints and limited protocol transparency remain obstacles to independent assurance. This comparative study concludes that while all three protocols provide a baseline of robust cryptographic security, only Thread currently aligns with CC and EUCC certification schemes. Zigbee and Z-Wave will require additional protocol hardening and enhancement of cryptographic key lifecycle management to achieve comparable assurance levels. Ensuring conformance with formal cybersecurity standards is imperative for building trust and resilience across critical IoT infrastructures.

1. Introduction

The rapid expansion of the IoT has introduced a diverse range of resource-constrained devices into various sectors, including smart homes, industrial automation, and healthcare [1,2]. These deployments, while offering enhanced connectivity and automation, concurrently present substantial cybersecurity challenges [3,4]. Protecting IoT systems requires robust confidentiality, integrity, and authentication mechanisms [1]. Resource limitations observed in many IoT devices, such as limited processing capability, memory, and power supply, require the implementation of Lightweight Cryptographic (LWC) methods for information security [5,6].

Lightweight wireless protocols, including Thread, Zigbee, and Z-Wave, are fundamental to IoT connectivity [7]. However, the extent to which their embedded cryptographic mechanisms align with formal cybersecurity certification schemes remains an underexplored area [8,9]. Formal certifications, such as those derived from Common Criteria (CC) and the EU cybersecurity certification scheme on Common Criteria (EUCC), provide a standardized benchmark for evaluating security assurances [8,10]. Such evaluations are critical for establishing trust and ensuring the resilience of IoT infrastructures against evolving cyber threats [11].

This study assesses Thread, Zigbee, and Z-Wave against the CC Functional Requirements for Cryptography (FCS) [12] as specified in CC:2022 and the EUCC scheme [10], focusing on key cryptographic components such as Key generation (FCS_CKM.1), secure key distribution (FCS_CKM.2), agreement protocols (FCS_CKM_EXT.7), cryptographic operations (FCS_COP.1), and random bit generators (FCS_RBG.1) [12]. Following this introduction, the Section 2 details the evaluation framework based on standardized CC processes while the Literature Review contextualizes these protocols within current security standards and practices [13].

2. Methodology

This work draws primarily on recent peer-reviewed publications and major conference proceedings to undertake a rigorous evaluation. The analysis concentrates on the FCS of CC, particularly those relevant to key management and data protection. The Common Criteria for Information Technology Security Evaluation (ISO/IEC 15408-2) [14] provides an internationally recognized framework for information security evaluation [10]. This framework enables third-party assessment and defines Evaluation Assurance Levels (EALs). The EUCC scheme directly utilizes aspects of CC, specifically its vulnerability assessment families, to ensure a well-informed choice of assurance levels [8,10]. The study focuses on specific FCS from CC:2022, which dictate precise security functions for cryptographic modules [15]. Thread, Zigbee, and Z-Wave were selected due to their widespread deployment in IoT ecosystems, particularly in constrained environments such as smart homes and industrial control systems [2,7]. The comparison approach involves dissecting each protocol’s cryptographic implementation against the five selected CC FCS components, highlighting compliance strengths and deficiencies in relation to formal certification requirements. It is important to establish that this study constitutes a formal theoretical analysis and structural mapping, rather than an empirical penetration testing or hardware exploitation exercise. Given that formal cybersecurity certification schemes operate on rigorous documentation and architectural alignment before physical evaluation, this paper’s primary academic contribution lies in the systematic, critical synthesis of the foundational specifications of Thread (1.4.0), Zigbee (R23.1), and Z-Wave (S2) [16,17,18]. By abstracting the highly technical, protocol-specific cryptographic mechanisms into the standardized regulatory language of the CC Functional Requirements for Cryptography (FCS), this research establishes a foundational theoretical baseline. This theoretical mapping is a necessary prerequisite for understanding compliance gaps prior to any empirical, laboratory-based certification efforts.

3. Literature Review

Lightweight wireless protocols are integral to the functionality of the IoT, enabling communication among resource-constrained devices [6]. These protocols must balance stringent resource limitations with the need for robust security [19,20]. However, traditional cryptographic approaches often require significant resource allocation, necessitating the development of lightweight cryptographic methods tailored for IoT devices with limited memory and processing power [5,21].

Previous research has extensively explored the security postures of IoT wireless protocols from various technical perspectives. For instance, Kambourakis et al. [7] provided a comprehensive review of mainstream IoT PAN protocols, highlighting broad architectural vulnerabilities, while Marksteiner et al. [2] focused on general wireless security within the smart home domain. Furthermore, numerous studies have evaluated the efficiency of lightweight cryptographic algorithms tailored for resource-constrained environments [3,5,20]. While these foundational works provide valuable empirical insights and general vulnerability assessments, they typically evaluate protocols in isolation or focus on broad cryptographic efficiency rather than regulatory compliance. A notable gap remains in the current literature regarding the systematic mapping of these specific protocols against standardized, internationally recognized certification frameworks. This study addresses this gap by moving beyond general vulnerability analysis, focusing specifically on how the cryptographic characteristics of Thread, Zigbee, and Z-Wave map to the strict, formalized parameters of the Common Criteria and the EUCC.

CC provides a framework for specifying and evaluating security functions and assurance requirements. The EUCC builds upon the CC, incorporating its vulnerability assessment components to provide a harmonized approach to cybersecurity certification across the EU [8,10]. Both schemes emphasize independent third-party evaluation, promoting transparency and trustworthiness in certified products, which is crucial for critical IoT infrastructures [22].

Thread employs robust cryptographic mechanisms, notably Advanced Encryption Standard in Counter with Cipher Block Chaining Message Authentication Code mode (AES-CCM) authenticated encryption and ECDH-based key exchange within a decentralized trust framework [2]. Zigbee utilizes AES-128 encryption, but often relies on a centralized Trust Center for key management [23,24]. Z-Wave, with its S2 Security framework, has incorporated authenticated ECDH exchanges to enhance key establishment [2].

4. Comparative Evaluation of Cryptographic Components

In this section, a detailed theoretical mapping is conducted. Instead of outlining protocol features, the analysis critically evaluates how the underlying architectural choices of each protocol—such as Thread’s decentralized mesh and Zigbee’s centralized Trust Center—either align with or challenge the systematic structural requirements of the Common Criteria cryptographic components.

4.1. Key Generation (FCS_CKM.1)

The Common Criteria requirement FCS_CKM.1 mandates that cryptographic keys must be generated with high entropy and unpredictability to ensure their strength and randomness, effectively preventing any form of predictability or compromise [15]. This process typically employs approved Deterministic Random Bit Generators (DRBGs) seeded by robust entropy sources for maintaining cryptographic security [15,25], while secure Key Derivation Functions (KDFs) are essential to produce cryptographic keys that meet stringent security requirements [15].

Thread leverages a decentralized trust framework, where devices can generate their own keys using strong cryptographic primitives [2]. The protocol specification implies the use of robust random number generation for key material, often relying on hardware-based True Random Number Generators (TRNGs) or Cryptographically Secure Pseudorandom Number Generators (CSPRNGs) [26]. This decentralized approach, coupled with explicit use of ECDH for key exchange, suggests a strong adherence to FCS_CKM.1 by promoting the generation of high-entropy ephemeral and long-term keys.

Zigbee networks use both network keys and link keys, which are 128-bit keys [24]. The specification explicitly states that devices generating random keys for distribution require a strong method of random number generation [16], which finally meet the FIPS 140-2 [27] standards for randomness and entropy, suggesting methods like basing numbers on random clocks, external events, or pre-seeded values [16].

Z-Wave, particularly with its S2 Security framework, incorporates authenticated ECDH exchanges, which inherently involve the generation of ephemeral key pairs [2]. While the S2 specification enhances security, the reliance on proprietary elements can pose challenges for independent verification against strict FCS_CKM.1 requirements.

Table 1 provides a comprehensive comparative overview of the key generation mechanisms alignment for all three protocols.

Table 1. Comparative analysis of key generation (FCS_CKM.1).

Criterion	Thread	Zigbee	Z-Wave
Key Generation Mechanism	Decentralized trust framework; devices generate keys locally using strong cryptographic primitives.	Uses both network and link keys (128-bit); key generation relies on strong RNG methods per specification.	Utilizes authenticated ECDH exchanges generating ephemeral key pairs within the S2 Security framework.
Random Number Generation	Relies on hardware-based TRNGs or cryptographically secure pseudorandom number generators (CSPRNGs).	Mandates RNG compliance with FIPS 140-2 standards; sources include random clocks, external events, or pre-seeded values.	Depends on RNG capabilities of controllers and devices; PRNG specifics often proprietary, limiting independent verification.
Use of Cryptographic Primitives	Explicit use of ECDH for key exchange to promote high-entropy ephemeral and long-term keys.	Implements 128-bit keys with recommended RNG methods; actual implementation varies by IC manufacturer.	Incorporates authenticated ECDH exchanges; security enhanced but transparency on RNG methods is limited.
Adherence to FCS_CKM.1	Strong adherence through decentralized key generation and robust RNG sources.	Primitive requirements met in specification, but real-world adherence varies due to vendor-dependent RNG.	Enhanced security with the S2 framework; challenges exist in independent verification due to proprietary RNG elements.

4.2. Secure Key Distribution (FCS_CKM.2)

FCS_CKM.2 specifies the secure distribution of cryptographic keys, ensuring their confidentiality and integrity during transit and prior to use [15]. This involves employing robust key exchange protocols, key wrapping, or encrypted channels for key protection. Additionally, secure channels like TLS or IKE are commonly utilized to safeguard key transport, while mechanisms including AES-128 CCM and AES-128 CMAC provide authenticated encryption and integrity verification during key distribution [15,17].

Thread employs Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS) protocols for key distribution, leveraging well-established cryptographic methods [18]. The use of ECDH key exchange establishes a secure channel for session key distribution, maintaining confidentiality and integrity throughout the process [28]. Thread’s decentralized mesh network design enhances robust key distribution in dynamic topologies, aligning strongly with the requirements as defined in FCS_CKM.2.

Zigbee secures communications using 128-bit network keys and link keys [24]. Key distribution typically relies on a pre-configured link key, shared between the Trust Center and joining devices for encrypted communications [16,24]. Although this aims to imporve security, its centralized operation introduces a single point of failure, complicating secure key management throughout the key lifecycle, especially if the Trust Center is compromised or insufficiently hardened [16,24].

Z-Wave’s S2 Security framework significantly enhances key distribution by using authenticated ECDH exchanges during device inclusion, for delivering secure session and network key transfer [7,17,29]. This process segments the network into three security classes: (i) S2 Access Control, (ii) S2 Authenticated, and (iii) S2 Unauthenticated, each with distinct AES-128 keys [7]. Although vulnerable “legacy” configurations may still exist, modern S2 implementations align closely with FCS_CKM.2 requirements for secure key management [2,7,17].

Table 2 provides a comprehensive comparative overview of the secure key distribution mechanisms alignment for all three protocols.

Table 2. Comparative analysis of key distribution (FCS_CKM.2).

Criterion	Thread	Zigbee	Z-Wave
Key Distribution Protocols	Uses DTLS and TLS with ECDH key exchange for secure session key distribution.	Employs pre-configured link keys managed centrally by a Trust Center for encrypting network keys.	Implements authenticated ECDH exchanges in the S2 Security framework; legacy fallback to pre-shared keys.
Security Model	Decentralized mesh network enabling robust and dynamic key distribution.	Centralized Trust Center introduces a single point of dependency and potential vulnerability.	S2 subdivides security classes, isolating devices by security level; stronger cryptographic assurance in modern setups.
Cryptographic Strength	Full security services with standardized cryptographic mechanisms (ECDH, TLS/DTLS).	128-bit keys; relies on pre-shared keys which may affect security if the Trust Center is compromised.	256-bit Curve25519 ECDH for key exchange; AES-128 CCM for encryption and authentication.
Alignment with FCS_CKM.2	Strong alignment via decentralized, cryptographically sound key exchange protocols.	Partial alignment; centralization may complicate assurance of secure key distribution across lifecycle.	Largely aligns for modern S2 implementations; legacy modes are less secure.

4.3. Key Agreement Protocols (FCS_CKM.7)

FCS_CKM_EXT.7 delineates stringent requirements for cryptographic key agreement protocols, mandating that multiple entities securely establish a shared secret key without relying on pre-shared secrets [15,25]. These protocols must adhere to approved algorithms and parameters, which include Diffie-Hellman and RSA-based schemes with validated domain parameters [15,25]. Proper implementation involves key confirmation, key derivation, and validation of static and ephemeral keys [25].

Thread extensively employs ECDH as its primary key agreement protocol [2]. This choice of ECDH, enables devices to agree upon shared secret keys over an insecure channel, providing forward secrecy and resisting known attacks. The use of ECDH within its decentralized architecture strongly aligns Thread with the requirements of FCS_CKM_EXT.7.

Zigbee, while relying on AES-128 for symmetric encryption, traditionally manages keys through a centralized Trust Center [23,24]. Its primary model for key establishment is often based on pre-shared keys or keys distributed by the Trust Center [24]. Consequently, Zigbee’s original design does not inherently fulfill the FCS_CKM_EXT.7 requirement for dynamic key agreement between peers. While Zigbee 3.0 introduces advanced key establishment, the centralized Trust Center remains a potential weak point in its architecture.

Z-Wave’s S2 Security framework integrates authenticated ECDH exchanges for key agreement, which represents a significant enhancement over earlier Z-Wave security versions [2], for establishing a shared secret key through public-key cryptography and providing robust protection. The S2 framework’s explicit inclusion of ECDH directly addresses the requirements of FCS_CKM_EXT.7.

Table 3 provides a comprehensive comparative overview of the secure key agreement protocols alignment for all three protocols.

Table 3. Comparative analysis of key agreement protocols (FCS_CKM_EXT.7).

Criterion	Thread	Zigbee	Z-Wave
Key Agreement Method	ECDH	Pre-shared keys or Trust Center distributed keys (AES−128 symmetric encryption)	Authenticated ECDH within S2 Security framework
Key Management Model	Decentralized, dynamic key agreement between devices	Centralized Trust Center manages key distribution	Enhanced over earlier versions with public-key cryptography for key establishment
Compliance with FCS_CKM_EXT.7	Strongly aligns; provides forward secrecy and robust cryptographic strength	Does not inherently fulfill dynamic key agreement requirement; newer versions improve but retain Trust Center reliance	Directly addresses FCS_CKM_EXT.7, improving cryptographic assurance

4.4. Cryptographic Operations (FCS_COP.1)

FCS_COP.1 requires that cryptographic operations performed by the target of evaluation utilize approved algorithms and modes of operation to ensure critical security objectives such as confidentiality, integrity, and authenticity [15]. This includes symmetric-key encryption modes like CBC, CTR, and XTS, Authenticated Encryption with Associated Data (AEAD) modes such as CCM and GCM, as well as hashing and digital signature algorithms [15]. Additionally, the generation of one-time values like nonces and IVs must adhere to strict randomness requirements as specified in FCS_OTV_EXT.1 to maintain cryptographic strength [15].

Thread utilizes AES-CCM for authenticated encryption [2]. AES-CCM is an approved cryptographic algorithm and mode that simultaneously provides confidentiality, data integrity, and data origin authentication, meeting the high standards required by FCS_COP.1.

Zigbee also employs AES-128 encryption [23]; however, the specific mode of operation used (e.g., CCM, CBC) might not always be consistently applied across all layers or device implementations [23]. While AES-128 itself satisfies the algorithm requirement, the comprehensive application of authenticated encryption modes, is crucial for full FCS_COP.1 compliance.

Z-Wave, particularly with S2 Security, also uses AES-128, often in an authenticated mode to provide both confidentiality and integrity [2]. The S2 framework is designed to protect against replay attacks and ensure message authenticity, indicating the use of a robust mode of operation such as AES-CCM or similar [7]. This application of AES-128 in a secure mode generally aligns Z-Wave with FCS_COP.1 requirements for cryptographic operations, particularly in newer S2-enabled devices.

Table 4 provides a comprehensive comparative overview of the secure cryptographic operations alignment for all three protocols.

Table 4. Comparative analysis of cryptographic operations (FCS_COP.1).

Criterion	Thread	Zigbee	Z-Wave
Cryptographic Algorithm	AES-CCM (AES in Counter with CBC-MAC)	AES-128	AES-128
Mode of Operation	Authenticated Encryption (CCM)	Varies (CCM, CBC, or others); inconsistent across layers/devices	Authenticated modes like AES-CCM; AES-CMAC for integrity
Security Features	Confidentiality, Integrity, Data Origin Authentication	Strong symmetric encryption; integrity features may not always be addressed	Confidentiality, Integrity, Replay Attack Protection, Message Authenticity
FCS_COP.1 Compliance	Fully compliant; provides robust protection for data transmission	Partially compliant; full compliance requires consistent use of authenticated modes	Generally compliant; strong compliance in newer S2-enabled implementations

4.5. Random Bit Generation (FCS_RBG.1)

FCS_RBG.1 specifies requirements for the generation of random bits, crucial for cryptographic key generation and other security-critical functions, emphasizing unpredictability and sufficient entropy [26].

Thread relies on the underlying hardware and software to provide cryptographically secure random bit generation. Given its use of ECDH and AES-CCM, the implicit requirement for high-quality random numbers for nonces, ephemeral keys, and other cryptographic inputs is paramount [2]. While the specification does not detail the exact RBG implementation, its adherence to established security protocols like DTLS suggests the necessity of FIPS 140-2 compliant random number generators [18] that aligns Thread with FCS_RBG.1 requirements.

Zigbee specification explicitly mandates strong random number generation for creating random keys, requiring that these numbers are unpredictable and possess sufficient entropy to resist exhaustive search attacks. Methods proposed include using random clocks, external events, or pre-seeded values. The actual implementation’s quality depends on the IC manufacturers, which can lead to inconsistencies in meeting stringent FCS_RBG.1 standards across different devices [16].

Z-Wave’s S2 security framework necessitates high-quality random number generation for ephemeral ECDH key pairs and nonces used in authenticated encryption. Similar to other protocols, the underlying hardware implementation of the random bit generator is critical for meeting FCS_RBG.1 requirements [30]. While the S2 framework itself implies the need for strong randomness, the proprietary nature of some Z-Wave components might limit the transparency needed for a full, independent audit of its random bit generation capabilities against formal standards like FIPS 140-2.

Table 5 provides a comprehensive comparative overview of random bit generation alignment for all three protocols.

Table 5. Comparative analysis of random bit generation (FCS_RBG.1).

Criterion	Thread	Zigbee	Z-Wave
Random Bit Generation Approach	Relies on hardware or software; implicit use of secure RBG for ECDH keys and AES-CCM nonces.	Explicit mandate for strong, unpredictable random number generation meeting FIPS 140-2	High-quality RBG required for ephemeral ECDH keys and nonces within S2 security framework
Compliance with FCS_RBG.1	Aligned via use of FIPS 140-2 compliant RNGs as implied by DTLS adherence	Directly satisfies FCS_RBG.1 requirements	Implied requirement for strong randomness; full audit limited by proprietary components
Implementation Notes	Specification lacks explicit RBG details; depends on underlying platform security protocols	Randomness sources include clocks/external events; quality varies by IC manufacturer	Hardware-based RBG critical; transparency and independent verification constrained

5. Discussion

Alignment with CC and EUCC Requirements: Thread aligns most closely with CC and EUCC standards by using decentralized, standardized primitives like AES-CCM and ECDH [2,10]. Zigbee’s reliance on a centralized Trust Center complicates compliance with distributed key lifecycle requirements [24]. Z-Wave S2 improves alignment via authenticated ECDH, though its proprietary history may limit the transparency needed for full certification [2].

Protocol-Specific Strengths and Limitations: Thread leverages open standards and a decentralized mesh to avoid single points of failure, though managing this complexity is a challenge [2]. Zigbee offers mature AES-128 encryption but remains vulnerable to Trust Center compromises [23,24]. Z-Wave S2 provides robust key agreement, yet its legacy of proprietary constraints still hinders independent assurance [2].

Obstacles to Independent Assurance and Transparency: Independent assurance is hindered by Zigbee’s manufacturer-dependent implementations and Z-Wave’s restricted specification access [2,24]. Even Thread’s open-standard approach faces scrutiny regarding specific hardware-level variations during certification.

Implications for IoT Trust and Infrastructure Resilience: Comprehensive alignment with CC/EUCC, currently led by Thread, is essential for critical infrastructure resilience [22]. Failing to meet these cryptographic standards creates systemic vulnerabilities in key management and bit generation, undermining trust in IoT ecosystems [26,31].

6. Conclusions

This comparative evaluation of Thread, Zigbee, and Z-Wave against Common Criteria cryptographic functional requirements reveals distinct security postures as illustrated in Table 6. Thread demonstrates the strongest alignment with CC and EUCC due to its use of AES-CCM authenticated encryption and ECDH-based key exchange within a decentralized trust framework, providing robust key generation, distribution, and agreement [2]. Zigbee offers strong cryptographic primitives (AES-128) but faces challenges in meeting comprehensive key lifecycle and distribution controls due to its reliance on a centralized Trust Center [24]. Z-Wave’s S2 Security, with its authenticated ECDH exchanges, significantly enhances its cryptographic capabilities, though proprietary elements and transparency issues persist [2].

Table 6. Synthesis of key protocol characteristics.

Criterion	Thread	Zigbee	Z-Wave
Alignment with CC	Strongest alignment with CC and EUCC	Good cryptographic primitives but weaker CC alignment	Enhanced cryptographic capabilities; moderate CC alignment
Cryptographic Features	AES-128-CCM encryption	AES-128-CCM encryption	S2 Security (AES-128 with authenticated ECDH exchanges)
Key Management Approach	ECDH-based key exchange within a decentralized trust framework	Centralized Trust Center managing key lifecycle and distribution	Proprietary elements in key management; uses public-key crypto for establishment
Notable Limitations	None specified; robust key generation, distribution, and agreement	Challenges in comprehensive key lifecycle management and distribution controls	Transparency issues due to reliance on proprietary standards

The ongoing evolution of IoT connectivity standards demands a stronger emphasis on achieving formal cybersecurity certifications to ensure robust security and user trust [32]. Future efforts should prioritize the development of open, auditable cryptographic implementations that are lightweight yet resilient, fostering transparency in protocol specifications and encouraging independent security evaluations across all IoT layers. Additionally, advancing research into quantum-resistant cryptography is vital to safeguard IoT networks against emerging threats. Establishing unified certification and standardization frameworks is imperative to build enduring trust and resilience in the expanding IoT ecosystem [32,33].