_SNB%20Hard%20crop.png)
A leading European Matter OEM partnered with Snowball OBIS to ship more than a million devices a month from five ODM-operated factories across three countries — without a single private key ever leaving an HSM.
That combination is what took the team through three approaches that didn't fit.
The three approaches the team worked through were each a sound model in the right context. None matched this customer's combination of constraints.
Each vendor's service has its own profile format, submission flow, and lead time — and the customer's portfolio spanned 21 products across 4 silicon vendors. With non-returnable inventory and multi-week customization cycles, the cost of getting any one product wrong was high, and the cost of running 21 of them in parallel was higher. The model also ends at the chip facility: re-provisioning, credential rotation, and other post-production operations that need the OEM's cryptographic authority have nowhere to live.
The architecture assumed real-time cloud connectivity throughout mass production — but across the Thailand–Vietnam–China network, where cross-border links degrade routinely and recover unpredictably, any disruption stops every line that's mid-batch. A single cloud outage would halt all five factories at once. It also assumed someone on the factory floor owned the integration between cloud PKI and secure provisioning. Most ODMs lack cryptography specialists — they can neither build it nor maintain it.
Never left the spreadsheet. Each new key — for a new product, a new SoC, a new use case — would have meant someone from the OEM's security team traveling to each factory and performing an injection ceremony. It would also have meant handing day-to-day custody of the key material to factory teams the OEM didn't directly manage. Not a one-time deployment cost. A permanent stream of recurring travel, recurring ceremonies, and recurring loss of cryptographic control.
SNOWBALL came in, recommended independently by one of the OEM's ODMs and one of the silicon vendors.
What SNOWBALL proposed wasn't "a better PKI service" or "a better factory HSM." The OEM's problem couldn't be solved by any single tool — because the constraint wasn't tooling, it was the operating model.
The three approaches the team had worked through shared one hidden assumption: that the decision to perform a cryptographic operation, and the execution of that operation, must happen in the same place.
OBIS — SNOWBALL's OnBoard IoT Security platform — is built on a different assumption. It ships as one system: a cloud portal where the OEM governs, a Factory Service at each ODM site, programming-station software on the line, and EdgeHSM — the on-premise appliance that anchors trust in the factory. Decision-making stays with the OEM. Execution runs locally. The two are bound by a scoped authorization the OEM issues and the factory enforces.
That decoupling shows up in three architectural properties, plus one delivery property that made it adoptable.
Every operation a factory performs — issuing a DAC, provisioning an OTA encryption key, re-opening Secure Debug for rework, even programming firmware — happens under a cryptographically signed authorization object the OEM issues from the cloud portal. Each authorization is scoped to a specific product version, factory, quantity, and time window.
EdgeHSM, deployed at each factory, is built on an EAL5+ certified secure element. It verifies every authorization before performing any operation, and refuses anything outside its scope. All cryptographic material in the factory lives inside the EdgeHSM boundary at every moment of its existence. Device key pairs are generated inside the SoC and the private keys never leave it; only the CSR is sent to EdgeHSM, which returns the signed certificate. No private key is ever injected into the device from outside. No factory operator, no ODM partner, and no system in the factory ever sees a private key in cleartext.
Once an authorization package reaches EdgeHSM, the factory needs no further cloud round-trips. Authorized production runs continue for the full window the OEM granted, regardless of network conditions. Multiple authorizations can run in parallel. When connectivity returns, audit logs and production records sync within minutes.
ODMs install the factory side of OBIS — they don't develop it. The Factory Service, EdgeHSM, and programming-station software ship as a single bundle. This is what made the model adoptable by ODMs, and what lets a new factory come online in days.
Here's how this actually runs in production.
The OEM sets up the product. In OBIS, the OEM creates the product, configures the cryptographic keys it requires, and sets the rules for how it can be produced — most importantly, the total quantity that may ever be produced. The OEM then invites the ODM into the Product Workspace.
The ODM prepares the version. The ODM uploads the firmware, signed with the secure boot key the OEM specified, and configures the Matter factory data, commissioning parameters, and chip security features. When everything is in place, the ODM creates a new Product Version — a snapshot of exactly what this product will be in production.
The OEM approves the version. The OEM reviews and approves the Product Version, locking it as the authoritative reference for production.
The ODM creates a batch. Based on the approved version, the ODM creates a Production Batch and assigns it to a factory — defining the quantity for this run and the production window. Over time, the ODM creates as many batches as production requires, but the running total can never exceed the quota the OEM set at the start.
On the line. The encrypted Production Batch lands in EdgeHSM at the factory. Programming Stations execute device-by-device provisioning under EdgeHSM's control. Each device gets its keys generated on-chip, its certificates issued, and a production record written.
Records flow back. Records sync to the cloud portal within minutes. The OEM's security team in Europe sees production across all five factories from a single dashboard — every batch, every device.
Secure Debug rework, weeks later. A factory finds a unit that needs rework. Re-opening the Secure Debug port requires the OEM's Secure Debug authentication key. Under traditional models, this either means handing the key to the factory or escalating every rework to the OEM. In OBIS, the authority is already in place — defined when the original batch was authorized. The factory triggers the rework within that scope. EdgeHSM uses the key, kept inside its hardware boundary, to re-open the port.
No platform is free. Three real costs the OEM accepted going in, worth naming.
TRADE-OFFS
Outcomes
Outcomes
