MatterODM by Shenan YangguangWhat "local-first" actually means in Matter
Matter is a local-first protocol: a door contact or PIR reports its state on the home network and can drive local automations — for example a door opening triggering a local siren — without requiring any cloud connection. This is the protocol's defining privacy property, and it is real, not marketing. A Matter sensor does not need to phone home to do its job. The data stays on the local network, which is the strongest possible default for a security device that is, by definition, watching the most sensitive space in a person's life.
The consequence is often missed. Because Matter does not impose a cloud, the privacy posture of a Matter security line is decided far more by what the brand layers on top than by the protocol itself. A brand that sells sensors and a strictly local controller has a radically smaller data footprint than a brand that adds cloud event history, remote viewing and cross-device analytics. Both are "Matter." Only one of them is quietly processing personal data at scale.
Where the data actually flows
A cloud only enters a Matter security product if the brand adds an app and cloud stack on top of the local device — and that app and cloud stack, not Matter, is where personal data such as account identifiers, event logs, location context and, for camera products, imagery actually flows. A white-label app and cloud stack is the brand's service, operated by the brand or on the brand's behalf, and it is the point at which the honest privacy conversation begins.
This matters because the legal responsibilities attach to that flow. A security brand that operates an app and cloud stack is, in GDPR terms, the controller of the personal data those services process — which means the privacy notice, the lawful basis, the data-minimisation choices and the deletion guarantees are the brand's obligations, not the factory's. A factory can build a device that minimises what it emits, but it cannot absorb the controller duties of a service it does not operate. Pretending otherwise is the most common — and most dangerous — shortcut in this category.
GDPR applies even if the factory is in China
GDPR applies to any product that processes the personal data of people in the EU, regardless of where the manufacturer is based, so a Chinese-built security device sold into Europe still pulls its brand into GDPR scope the moment the brand's app or cloud touches EU customers' data. The regulation's reach is territorial over the data, not the factory. A brand that assumes "we build in Shenzhen, so European privacy law is someone else's problem" is simply wrong, and the assumption is a recurring source of compliance gaps in cross-border security hardware.
The practical duties are concrete. Data minimisation means collecting only what the function requires; transparency means a clear privacy notice in the app and manual; and any transfer of personal data outside the EEA — to a cloud in another region, for instance — needs a valid transfer mechanism such as standard contractual clauses. For a security brand, the camera and video case is the sharpest: imagery of a home is personal data, and cross-border storage of it is a transfer that must be justified, not assumed. The brand owns that decision; the factory builds the device that can be configured to respect it.
EN 18031 is not GDPR
EN 18031 is a technical cybersecurity standard for radio equipment under the EU Radio Equipment Directive — it sets engineering requirements such as secure defaults, protection against network threats and updateability — whereas GDPR is a legal obligation about how personal data is processed, and passing EN 18031 does not satisfy the legal and administrative duties GDPR imposes. The two overlap on technical points like encryption and access control, but they are different instruments: one is a product-engineering conformance, the other is a data-protection legal regime with fines, a regulator and a right of audit.
For a security brand the takeaway is to stop treating one as a substitute for the other. A device can be fully EN 18031-conformant and still leave the brand exposed under GDPR if its app and cloud stack mishandle personal data — the standard and the law test different things. For the device-security side of the same obligation, our cybersecurity compliance note covers the UK PSTI, ETSI EN 303 645 and the EU Cyber Resilience Act; this note is specifically about the data-privacy and residency layer those do not replace.
The honest factory-brand split
The privacy duties split by where the data lives: the factory is responsible for what the hardware itself does — local-first reporting, secure identifiers, disciplined logging — while the brand that operates the app and cloud stack owns the GDPR duties for the personal data those services process. Shenan Yangguang designs, prototypes, validates and mass-produces Matter security hardware, and we build devices that can run fully local-first without a mandatory cloud, support local automations, and keep on-device identifiers and logs disciplined. We do not operate a brand's cloud, and we do not pretend to be the data controller for a service we do not run.
What we do is make the brand's compliance easier: a device that minimises what it emits shrinks the brand's GDPR surface, and a local-first architecture means the brand can offer a genuinely private mode as a selling point rather than a loophole. If you are bringing a Matter security line to the EU or UK, ask us first about the local-first and identifier-handling design, then ask your own team the harder questions about where your app's data lives and who can see it — and we will support the first set while you own the second.