What a security gateway actually does
A Matter gateway (or hub) is a device that connects local Matter accessories to the IP network and, when it includes a Thread radio, acts as the Thread border router that lets Thread accessories reach that network. For a security brand it is the anchor: door sensors, PIR detectors and cameras attach to it locally, and it keeps the system working when the cloud does not. Local-first control is not a nice-to-have for alarms; it is the point.
The gateway is also where a brand's automation logic lives — scenes, schedules, and the rules that turn "door opened after midnight" into "notify the phone and flash the light". Done on the gateway, those rules run even offline; done only in the cloud, they stop the moment the connection does.
One box, several device types
A composed device in Matter is a single physical product that exposes multiple logical endpoints, each with its own device type and clusters, so one enclosure behaves to controllers as several Matter devices. A security gateway is the textbook composed device. The same hardware can present a border-router role, a bridge role for any legacy sensors you still support, and a controller role that runs automations. Each endpoint is a real, certifiable device type — not a marketing label.
Endpoints a security gateway typically exposes
A Thread border router endpoint (so the home's Thread mesh forms), a bridge endpoint (so non-Matter sensors appear as Matter), and a controller endpoint that owns scenes and schedules. Some designs add a contact-sensor or occupancy endpoint if the gateway itself carries a tamper switch or a local ambient sensor. The cluster choice at each endpoint is what controllers actually bind to, and it is what the certification plan must enumerate.
Certification as one programme, not three
A border router is the device that lets Thread-based Matter accessories join an IP network and reach controllers and the cloud. Because the gateway is one composed device, its certification is one programme that walks every endpoint's clusters against the spec — border-router behaviour, bridge behaviour, controller behaviour — in a single test plan. That is cheaper and faster than certifying three separate boxes, and it keeps the behaviour consistent across endpoints. We explain the broader device-type and cluster selection in our article on Matter device types for a security line.
The radio architecture underneath
A gateway usually pairs a Thread radio (for the sensor mesh) with a Wi-Fi or Ethernet backhaul (to the router). The Thread side is low-power and self-healing; the backhaul is the gateway's own link to the internet. The two radios, the border-router firmware and the enclosure RF design are where most integration risk lives — and where a factory that owns all of it, rather than bolting a module onto someone else's board, controls the outcome. Connectivity is integrated as a standard CSA-certified Matter connectivity module, a purchased component like any other, while the gateway logic, RF tuning and enclosure are our own.
Factory stance: we build the whole chain
Shenan Yangguang designs the schematic, builds the prototypes, writes the gateway firmware, cooperates on certification and runs mass production — so the composed-device behaviour is designed and tested as one product, not assembled from three suppliers' partial responsibilities. That matters for security: a tamper event, a bridge drop and a scene firing should behave as one coherent system, and that only holds if one engineering team owns the data path end to end.
When a gateway is the right first product
For a brand entering Matter security, a gateway-first strategy is often sensible: it establishes the local control plane your sensors will depend on, and it lets you launch sensors later as endpoints without re-architecting. The trade-off is certification complexity up front — a composed device is a harder first cert than a single sensor — so the decision should follow your roadmap, not just your launch date. A brand that only wants to ship a door sensor this quarter may be better served certifying the sensor first and treating the gateway as phase two.
Placement, power and the enclosure duty
A gateway is a mains-powered anchor, not a coin-cell sensor, and that changes the enclosure duty. It usually sits near the router, which is rarely the centre of the home, so the Thread mesh it forms has to reach bedrooms and doors from a corner. RF tuning of the enclosure and antenna placement are where real-world range is won or lost, and they are factory work — schematic, prototype and over-the-air measurement — not something a module vendor guarantees for your box. We integrate connectivity as a standard CSA-certified Matter connectivity module and tune the rest of the radio path ourselves.
Thermal and the always-on radio
An always-on gateway runs its radios and processor continuously, so enclosure thermal design is a real reliability driver: a case that traps heat shortens the life of the power supply and the radios. This is the kind of detail a brand only notices after returns climb, which is why we treat thermal and EMC as design constraints from the first prototype rather than as a pre-ship test to pass. The same discipline applies to the bridge endpoint: a legacy sensor that drops off the bridge is a security gap, so bridge stability is part of the gateway's own test plan, not an afterthought.
What the factory prepares for the certifier
For a composed gateway, the certifier walks every endpoint against the spec. The factory's job is to hand over a coherent package: the PICS stating which clusters each endpoint implements, the build that matches the certified configuration, and the attestation chain provisioned per unit. Because Shenan Yangguang owns schematic, firmware, prototype and production, that package describes one product built by one team — which is what makes a single composed-device certification programme credible to the test provider rather than a patchwork of three suppliers' partial evidence.