Is Matter Safe Enough? Security and Privacy Guidelines

Smart homes aren’t futuristic—they’re here. Motion sensors flip lights, voice unlocks doors, and IoT runs the routine. Every new device adds convenience and another point an attacker can target. The more connected our homes become, the more exposed they are to cyberattacks, data leaks, and unauthorized access.

This is where Matter steps in. Matter aims to bring together different smart home systems using one safe and secure method. Connectivity Standards Alliance (CSA) took the initiative to launch Matter with the support of tech giants such as Apple, Google, Amazon, and Samsung. However, just having promises isn’t enough. The real issue is whether Matter is actually secure and private enough to be trustworthy.

This article explores that question in depth—breaking down Matter’s architecture, its cryptographic backbone, known vulnerabilities, and the ethical tension between security and privacy. We’ll also highlight where current coverage falls short and how developers, brands, and consumers can close the gap.

What Is Matter? A Quick Primer for Non-Engineers

Matter is an open-source, IP-based protocol that aims to remove the problem of devices not working together in a smart home. It lets devices from different brands talk to each other smoothly using Wi-Fi, Thread, Ethernet, and Bluetooth LE for pairing. The main purpose is to make sure devices can work together without any issues.

No matter if you’re using a Nest thermostat, a Philips Hue bulb, or a Yale smart lock, Matter makes sure they all understand each other.

Devices that are approved as Matter-certified have a special mark that shows they can work with different smart home systems like Apple HomeKit, Google Home, and Amazon Alexa.

But Matter does more than make things easier.

It’s built on a foundation of security and privacy, with features like device attestation, encrypted messaging, and certificate-based identity baked into its core.

The principal architectural entities within a Matter network include Devices and Nodes, Fabrics, Controllers and Administrators, and Commissioners:

• Device and Node: A device is a physical entity, such as a thermostat or light bulb, which can host one or more nodes—logical entities that each run a Matter protocol stack.
• Fabric: A fabric is a logically independent network segment—essentially, a trust domain—where a group of devices operate under shared cryptographic credentials and a common root of trust.
• Controller and Administrator: The controller manages nodes and facilitates secure operation; administrators define access policies and issue operational certificates.
• Commissioner: The commissioner is responsible for securely onboarding (commissioning) new devices, validating their credentials, and establishing them within the fabric4.

This system uses open standards and open-source tools, which allows various systems to work well together, simplifies managing everything from a single location, and enables independent experts to review and verify the security claims.

Security Principles

Matter’s security design is anchored in several foundational principles, as articulated by its creators:

• Security is enforced at multiple protocol layers (application, commissioning, operational communications), ensuring that threats at one layer do not expose devices at another.
• All sensitive operations leverage NIST-approved, industry-standard cryptographic primitives.
• Devices need to show they are genuine by using digital certificates before they can connect to the network; devices that are not properly verified or anonymous are not allowed.
• The system is built to handle new threats over time, allowing for frequent software updates, the ability to switch to stronger encryption methods, and strong ways to recover from issues.
• The protocol helps stop unnecessary exposure, ensures privacy is protected, and only allows the minimum amount of data needed for secure communication.

Matter Cryptographic Suite and Encryption Standards

Matter requires a standardized set of cryptographic tools for all communications and device setup, following current best practices. Here are the main algorithms and standards used:

These cryptographic primitives serve to protect all communications—both during initial onboarding (using temporary keys) and throughout regular operations (using established, fabric-scoped keys).

Innovative features include:

• End-to-end encryption of message payloads
• Command-level access control and integrity checks
• Encrypted device identifiers to obfuscate communicating parties’ identities, enhancing privacy.

Despite this, independent security researchers have identified several concerning deviations and weaknesses in how these standards are implemented in practice (see the vulnerabilities section below).

Passcode-Authenticated Session Establishment (PASE)

The PASE Protocol

PASE is the entry point for a device’s secure journey into the Matter ecosystem. Used during commissioning, it is based on the SPAKE2+ Password-Authenticated Key Exchange (PAKE) protocol. The commissioner obtains a setup passcode (usually via QR code) from which both parties derive session keys for an initial secure channel.

How PASE Works

1. Onboarding passcode: Each device ships with a unique, device-specific, randomly generated numeric passcode (typically 8 digits).
2. Key derivation: SPAKE2+ combines the passcode with a static device salt and other cryptographic parameters using PBKDF2, yielding shared secret values.
3. Session key agreement: Both parties exchange commitments and validation codes, confirming proof-of-possession of the passcode without transmitting it directly.
4. Lifecycle: Keys derived during PASE protect all subsequent messages until the more robust CASE protocol is established for long-term operational communications.

Security Properties and Weaknesses

Although the SPAKE2+ protocol is strong in theory, its adaptation for Matter brings in significant changes and possible weaknesses:

• Low passcode entropy: An 8-digit number passcode offers just 100 million different combinations (~26.6 bits of entropy). This makes it possible for someone to try all options by force, especially if the system’s security limits are avoided.
• Inadequate PBKDF2 iterations: The official guidelines recommend 1,000–100,000 iterations, falling short of best practices (600,000+ is widely recommended for PBKDF2-HMAC-SHA256). Lower iteration counts make offline attacks easier.
• Static salts: Many devices use static salts, enabling attackers to precompute attack tables (rainbow tables) and accelerate brute-force/passcode discovery.
• Implementation flaws: Security researchers discovered that the official open-source SDK failed to enforce the lockout after 20 failed attempts and allowed concurrent PASE sessions during commissioning, further increasing the attack surface.

Attackers who obtain a valid passcode—by brute-force, shoulder-surfing, or device resale—could impersonate or re-commission a device. The implications are more severe if other defense mechanisms are not implemented robustly.

Certificate-Authenticated Session Establishment (CASE) and Device Attestation

CASE Overview

Once a device is commissioned via PASE and provisioned with the necessary operational credentials, it uses the CASE protocol for secure operational communication. CASE is based on the well-studied SIGMA-I key exchange protocol, which uses Diffie-Hellman key exchange with digital signatures and Message Authentication Codes (MACs) for authentication and session key derivation.

Key Processes

• Operational credentials: The device is provisioned with a Node Operational Certificate (NOC), signed by a trusted Certificate Authority (CA), either directly (Root CA) or via an Intermediate CA.
• Mutual authentication: Each device presents its NOC, and parties prove possession of private keys by signing ephemeral public keys exchanged during Diffie-Hellman key exchange.
• Session resumption: CASE supports a session resumption mechanism to improve efficiency. However, academic analysis has questioned the security downgrade this feature introduces—attackers with partial knowledge may undermine session security dramatically.

Device Attestation and the PKI Hierarchy

Device attestation is Matter’s unique solution to the IoT “counterfeit device” problem. Through a specialized Public Key Infrastructure (PKI), every physically manufactured device is stamped with a unique, non-modifiable Device Attestation Certificate (DAC).

DAC Issuance and Trust Hierarchy:

• Product Attestation Authority (PAA): The ultimate trust root, approved and listed in the Distributed Compliance Ledger (DCL), publicly available for all ecosystem members.
• Product Attestation Intermediate (PAI): Used by manufacturers for specific product lines or device families.
• Device Attestation Certificate (DAC): Unique per device, derived and cryptographically signed for attestation during commissioning or verification events.

The attestation process makes sure that only real and approved devices can connect to a network by using proof that any commissioner or network manager can check.

Distributed Compliance Ledger and Attestation Hierarchy

The Role of the DCL

The Distributed Compliance Ledger (DCL) is a crucial backbone of Matter’s compliance and trust ecosystem. This decentralized, immutable blockchain-style ledger holds cryptographically signed records of:

• Device certification status
• Manufacturer and vendor IDs
• Product attestation certificates
• Firmware versions and compliance records
• URLs for certificate revocation lists (CRLs) and user documentation11.

Before a device joins any Matter fabric, its DAC is traced through its PAI up to a trusted PAA listed in the DCL. This global registry—publicly readable but strictly managed—makes it straightforward to validate device authenticity, trace vendor provenance, and verify certificate revocation status.

Device Attestation Public Key Infrastructure (PKI)

Every step in commissioning and verifying a Matter device rests upon cryptographically signed certificate chains, with revocation and renewal mechanisms built in for lifecycle control. All cryptographic material and certification data must be protected by both software and, ideally, hardware means, particularly at the DAC private key level.

Operational Certificates and ACLs

Once commissioned, devices receive Operational Certificates (OpCerts) and are assigned Access Control Lists (ACLs). These define what each device can do—whether it can control others, read sensor data, or initiate sessions.

Proper ACL design limits the blast radius if one node is compromised. But misconfigured ACLs can lead to privilege escalation, especially in multi-admin environments. The SCHUTZWERK report outlines common ACL pitfalls and how to avoid them.

Hardware-Level Protections: Beyond Software Encryption

Security isn’t just about software—it’s about where and how keys are stored. Matter encourages manufacturers to implement:

• True Random Number Generators (TRNG)
• Physically Unclonable Functions (PUF)
• Trusted Execution Environments (TEE)

These technologies make sure that cryptographic keys are created safely and kept in memory that can’t be tampered with. Firmware updates are checked for authenticity using a Root of Trust (RoT), which stops bad software from being added during over-the-air updates.

Unfortunately, Matter doesn’t require these standards to be followed. It delegates them to vendors, creating inconsistency across devices. A device from Brand A may have robust hardware protections, while Brand B’s device may rely solely on software encryption.

This gap opens the door to hardware-level exploits, especially in budget devices that cut corners.

Privacy Principles and Data Minimization in Matter

Core Privacy Principles

The Matter protocol includes several privacy-focused rules in its design, which are in line with international data protection regulations like the GDPR.

• Data minimization: It follows the principle of data minimization by ensuring that only the information needed for a specific task is collected, sent, and kept. All data flows are justified in the protocol standard, reducing “over-collection” risk.
• Confidentiality and integrity: All personal and device-related data exchanged over the network is encrypted; tamper protection is standard.
• Defined purpose: Data shared between nodes is strictly for device operation as specified by the protocol, prohibiting unintended or excessive secondary uses.
• Non-trackable identifiers and private session headers: Node IDs are obfuscated or dynamically encrypted, making it difficult to track device owners or infer behavioral patterns from network traffic.
• Transparency and open standard: The open specification enables robust, independent privacy auditing and cross-vendor discipline.

Nevertheless, proper privacy protection also relies upon the supporting ecosystem and manufacturer infrastructure, such as cloud services and user apps. The Matter specification permits—but does not enforce—additional regulatory or privacy program overlays by vendors.

Known Vulnerabilities: What Developers and Users Should Know

No protocol is immune to mistakes. The SCHUTZWERK team found 20 important security issues in how Matter is implemented. These are not just ideas—they are real dangers that developers need to be aware of and take steps to prevent. Some of the biggest problems include:

• Passcodes: Using the same static passcodes on multiple devices makes it easier for hackers to guess them through brute-force attacks.
• Random Number Generators: Poorly designed random number generators weaken the security of keys.
• Fake commissioners pretend to be trusted devices during onboarding.
• Evil twin attacks exploit session establishment flaws.
• Misconfigured ACLs that allow unauthorized access
• Bridge devices bypassing full certification and security checks

Other vulnerabilities include HTTP downgrade attacks, unsanitized input, status injection, and timed interaction exploits. These flaws can be mitigated—but only if developers follow secure-by-design principles and audit their implementations thoroughly.

For consumers, the takeaway is simple: not all Matter devices are created equal. Certification serves as a starting point, but how well a product is implemented is just as important.

Image courtesy: https://www.schutzwerk.com/

Bridge Devices: The Loophole in Matter’s Promise

Matter was created to remove the need for proprietary bridges.

However, many manufacturers continue to use bridge devices to support older systems like Zigbee and Z-Wave. Although these devices are handy, they can also create security issues.

A bridged device may not support device attestation, secure commissioning, or encrypted messaging. Instead, it relies on the bridge to enforce Matter’s standards. If the bridge is poorly implemented or uncertified, the entire network’s security can be compromised.

This is especially problematic when users assume that all devices in a Matter ecosystem are equally secure. As ResTechToday mentions, bridges can give people a false feeling of security.

To address this, users should:

• Choose native Matter devices for important functions such as locks and cameras
• Check that bridges are certified by Matter and are kept up to date
• Check access controls and permissions after connecting bridged devices

Developers should avoid shortcuts and ensure that bridges meet the same security standards as native devices.

Best Practices and Security Guidelines for Matter Deployment

In light of identified vulnerabilities, expert consensus, and the CSA recommend several best practices are recommended for robust and consistent Matter security:

Enhancing Passcode and Key Security

Instead of using short numbers, choose longer, random mix of letters and numbers as passwords—they are much more difficult to guess and provide better security. When converting those passwords into encryption keys, avoid PBKDF2 and go with a stronger option like Argon2id. This method makes it harder for attackers by requiring more memory and processing power. And don’t reuse salts—generate a fresh one every time to keep each session unpredictable and secure.

Physical Key Protection

To keep sensitive keys safe, it’s best to store them inside secure hardware—like a secure element or enclave—so even advanced physical attacks can’t extract them. Once a device leaves the factory, its debug ports should be permanently disabled to prevent backdoor access. And if hardware protection isn’t an option, encrypting certificates and keys while they’re stored on the device adds an extra layer of defense against tampering.

Protocol and Firmware Operations

To keep pairing secure, devices should strictly enforce lockout after too many failed attempts—twenty is the recommended ceiling—and block multiple sessions from running at once. Access control lists also need careful attention; wildcard entries or overly broad permissions can open the door to misuse, so it’s important to keep them tight and regularly reviewed. And wherever users can input names or values, those fields must be properly sanitized to prevent injection attacks or accidental data exposure.

Group and Multicast Security

Multicast security in Matter depends heavily on how bridges are configured. Bridges should never have blanket privileges; instead, their access should be limited and clearly grouped with the non-Matter devices they support—both in the user interface and backend policies. This keeps control boundaries visible and manageable.

In the long term, my aim is to leverage the knowledge and skills gained through this program to drive financial innovation and efficiency in corporate organizations, particularly within Africa’s growing business landscape. I believe this program will be a critical step toward achieving that vision.

Network and Platform Requirements

Devices should only connect using secure protocols—WPA2 or better for Wi-Fi, and BLE 5.2+ in Secure Connections Only Mode. No fallback to weaker standards unless users explicitly allow it. Firmware must stay current through signed OTA updates verified by trusted sources.

Certificate and Device Lifecycle Management

During commissioning—and at regular intervals—devices should check the status of their certificates using pointers in the Distributed Compliance Ledger (DCL). This ensures that revoked devices, intermediates, or product authorities are flagged before they’re trusted. If a key is compromised or cloned, manufacturers must act fast: publish an updated revocation list, notify admins, and block the rogue device before it can cause harm. Staying current with CRLs isn’t optional—it’s essential for keeping the network clean and secure.

Security–Privacy Trade-offs in Matter Implementations

Matter tries to balance privacy, usability, and security—but these goals often pull in different directions. Numeric passcodes are easier to use but offer weaker protection. Lightweight key derivation suits low-power chips, yet compromises cryptographic strength. Giving vendors flexibility leads to inconsistent safeguards across devices.

These trade-offs should be made deliberately. As threats evolve and hardware improves, implementers should lean toward stronger security and tighter privacy wherever possible.

Comparison with Other IoT Security Frameworks

How does Matter measure up to previous and alternative smart home standards?

Matter is based on open standards, certificate-based explicit device attestation, data minimization, and regular security. Its universal adoption among major platform vendors (Apple, Google, Amazon, Samsung, etc.) provides a compelling path forward for improved IoT safety, though “last-mile” implementation gaps persist.

Certificate Revocation and Future Security Updates

Starting with Matter 1.2, certificate revocation is no longer optional—it’s now a formal part of the protocol. When a key is compromised, vendors are required to revoke all related certificates, including the Device Attestation Certificate (DAC) and Product Attestation Intermediate (PAI), and publish updated Certificate Revocation Lists (CRLs). These CRLs are referenced in the Distributed Compliance Ledger (DCL), allowing commissioners to verify device status during onboarding.

If a device’s certificate is revoked, it’s blocked from joining the network, and users are either warned or prevented from continuing setup. This mechanism helps keep compromised or cloned devices out of trusted environments. Future updates to the Matter standard are meant to strengthen dynamic salt enforcement, enhance key derivation choices, and improve cryptographic agility to keep up with evolving threats.

Guidelines for Secure Matter Deployment

To maintain Matter systems secure and private, manufacturers and sophisticated users must be proactive rather than reactive. Devices should always run the most recent approved SDKs and firmware, with fixes installed as soon as patches are released. Hardware is also important: platforms with a built-in root of trust, such as secure components or enclaves, provides far better protection for sensitive keys, especially when combined with secure key injection during production.

Onboarding should be hardened with longer, high-entropy passcodes—ideally alphanumeric—as the ecosystem evolves to support them. Key derivation must also improve; where hardware allows, Argon2id is a smarter choice than PBKDF2, offering stronger resistance to brute-force attacks. Commissioning should be tightly controlled, with strict attempt limits and disabled pairing mode when idle.

Cryptographic material must be stored securely, and debug interfaces should be permanently disabled after manufacturing. Access control lists need careful attention—no wildcards, no leftover permissions, and no blank entries. And users should be educated on the basics: don’t share QR codes or passcodes, and always reset devices before buying or selling them.

In enterprise or critical environments, it’s essential to verify that every device certificate and hardware root traces back to a trusted authority. DCL entries must be accurate and up to date—because trust in Matter isn’t just about the protocol, it’s about every decision made around it.

Security vs Privacy: The Ethical Dilemma

Security and privacy often pull in opposite directions. Strong encryption can not only secure data but it can also hide it from misuse. Matter’s architecture stresses device authentication and data integrity, however it fails to solve broader challenges, such as:

• Surveillance by manufacturers
• Data monetization
• Lack of user control over data retention

The Diplo Foundation argues that true privacy requires governance, transparency, and user agency. Matter’s technical safeguards are a start—but they’re not enough.

Ethical design must go beyond encryption. It must include user consent, data portability, and clear disclosures. Without these, Matter risks becoming another protocol that protects devices but not people.

Is Matter Safe Enough? A Balanced Verdict

Matter is undeniably a leap forward in smart home connectivity. Its architecture—built on PKI encryption, secure commissioning, and device attestation—lays a strong foundation for interoperability and trust. The protocol’s alignment with GDPR and its emphasis on data minimization show a clear intent to protect user privacy.

However, intent alone isn’t enough.

The protocol’s reliance on vendor implementation introduces variability. Some manufacturers may follow best practices, while others may cut corners—especially in budget devices. The lack of enforcement around hardware-level protections, such as PUF and TEE, leaves room for inconsistencies and exploits.

Moreover, the cryptographic flaws identified in KU Leuven’s analysis—including low-entropy passcodes and static salts—are not minor oversights. They represent real vulnerabilities that could be exploited in the wild.

The SCHUTZWERK report further highlights the risks of rogue commissioners, evil twin attacks, and bridge device loopholes. These are not theoretical—they’re practical concerns that developers and consumers must address.

So, is Matter safe enough?

It depends on who’s implementing it, how it’s configured, and whether users are informed. Matter provides the tools—but it’s up to manufacturers and integrators to use them responsibly.

FAQs: What People Are Asking About Matter Security

Conclusion

Matter is a big step forward for smart home and IoT connectivity that is safe and works with other devices. Its thoughtful architecture combines layered cryptography, certificate-based device authentication, global transparency via DCL, regular software updates, and a strong privacy model. Yet, it is not without weaknesses: cryptographic decisions constrained by usability and cost, vendor implementation flexibility, and evolving attack techniques mean “complete security” cannot be assumed out of the box.

For most home users, Matter is safer than any previous mass-market IoT protocol—provided devices are kept current and manufacturers follow best practices. For environments with significant risks such as critical infrastructure, privacy-sensitive situations, only Matter devices with hardened key storage, strong encryption, and strict ACL management should be considered. Active monitoring of certificate revocations and participation in the broader security community remain critical.

The protocol’s strengths lie in its transparency, updatability, community oversight, and vendor accountability. Its weaknesses—primarily, downstream implementation errors and physical attack exposure—can and should be mitigated by following the published and evolving security guidelines, and by collaborating across the industry to retire unsafe practices rapidly.

Matter is as secure as the sum of its execution integrity, ongoing improvement, and collaborative attention. Stakeholders who rigidly follow developing best practices and respond proactively to new vulnerabilities as they emerge will get the full benefits of safe, reliable, and private smart home automation.