CSA's Matter 1.6 and Product Security 1.1 Force System-Level Certification for IoT

CSA expands certification scope to complete IoT systems

The Connectivity Standards Alliance launched Matter 1.6 and Product Security 1.1 at its June Unify event in Austin, fundamentally changing what enterprises must certify when deploying IoT infrastructure. Product Security 1.1 now requires certification of complete systems—devices, mobile apps, gateways, and remote processes—rather than individual hardware components. The change adds independent testing pathways and directly responds to fragmented global cybersecurity mandates, particularly the EU Cyber Resilience Act and US FCC Cyber Trust Mark.

For procurement teams, this means security testing budgets must now cover application security assessments, gateway firmware reviews, and cloud backend security evidence. Projects that previously certified only hardware endpoints will face expanded compliance costs. The shift matters most for deployments touching consumer-facing or prosumer devices in multifamily buildings, retail environments, and small business installations where regulatory pressure is highest.

Matter 1.6 targets richer device status and cross-ecosystem interoperability

Matter 1.6 focuses on how devices expose status information to users and interact across ecosystems. The IP-based standard continues its push to displace Zigbee, Z-Wave, and proprietary smart-home protocols by offering multi-vendor compatibility backed by Apple, Google, Amazon, and Samsung. Legacy protocols still hold large installed bases, but struggle to meet newer regulatory expectations around device attestation and mandatory firmware-over-the-air updates that IP stacks handle more naturally.

For smart building and campus projects, Matter 1.6 provides a more mature multi-vendor baseline than previous releases. Expect RFP language to shift toward "Matter 1.6-compatible devices" as the default requirement rather than vendor-specific protocol specifications. This reduces long-term vendor lock-in risk for corporate real estate and industrial facilities planning 5-10 year infrastructure lifecycles.

Aliro standardizes mobile credentials for commercial access control

CSA's Aliro protocol aims to turn smartphones and wearables into universal keys for commercial and industrial doors, competing directly with proprietary mobile credential schemes from HID, dormakaba, Allegion, and Bluetooth-based or NFC-based vendor stacks. The protocol addresses what has been a fragmented market where each access control vendor maintains its own mobile app and credential format.

For physical security and facilities teams evaluating door access upgrades, Aliro creates a de facto multi-vendor mobile credential standard. This changes the risk calculation versus accepting a single vendor's closed mobile access ecosystem. Projects involving corporate campuses, hospitality properties, or multi-tenant facilities should now include Aliro compatibility as an evaluation criterion to preserve optionality across access control vendors.

Regulatory drivers force protocol choices at the design stage

The EU Cyber Resilience Act and FCC Cyber Trust Mark have moved from future policy to active design constraints in 2026. Both regulations mandate secure-by-design principles, vulnerability handling processes, and firmware-over-the-air update capability for connected products. Protocols must support FOTA to enable timely vulnerability remediation, which favors modern IP stacks over legacy alternatives.

Matter 1.4 and later versions with Device Attestation Certificates meet these requirements for consumer and prosumer deployments in EU and US markets. For enterprises, this means protocol selection now directly impacts regulatory compliance posture. Projects that would have defaulted to Zigbee or proprietary protocols two years ago must now evaluate whether those choices create compliance gaps or increase the cost of meeting mandatory security requirements.

What to watch: System-level certification becomes table stakes

CSA's shift to system-level certification under Product Security 1.1 sets a new baseline that competing frameworks—UL 2900, IEC 62443, and hyperscaler cloud security programs—will need to match or exceed. Enterprises should expect vendor risk assessments to reference Product Security 1.1 certification as an auditable standard, particularly for projects involving building automation, energy management, or physical access where devices, apps, and cloud services form an integrated system.

The independent testing pathways in Product Security 1.1 create higher assurance levels similar to UL or Common Criteria approaches, but scoped specifically to IoT ecosystems. For security and procurement teams, this provides clearer language for RFPs: require Product Security 1.1 certification for any vendor proposing a multi-component IoT deployment. The cost of certification will flow into vendor pricing, but the alternative—managing fragmented security evidence across devices, apps, and cloud components without a unified standard—creates higher operational risk and audit burden.