Testing SGP.32 Before You Scale: A Stage-by-Stage Pilot From Factory to Field

What to verify at each stage of an SGP.32 device’s journey, so your first batch tells you what a full rollout will do.

An SGP.32 deployment rarely fails at the concept level. It fails at a specific stage: a bootstrap profile that lapsed on a shelf, a device that switches on abroad with roaming disabled, a profile switch nobody tested until it was needed. A pilot is the cheapest place to find those problems, but only if it is designed to look for them.

The journey a pilot has to cover

An SGP.32 device leaves the factory with a bootstrap profile, a minimal connectivity profile whose job is to reach the eSIM IoT Manager (eIM), the server that tells the device what to do next. Between the two sits the IoT Profile Assistant (IPA), which carries instructions between the eUICC (the embedded SIM chip that holds operator profiles) and the eIM. The IPA runs either on the SIM itself (IPAe) or in the device (IPAd). Simplex’s guide to how bootstrap works and its explainer on what the eIM actually does cover the mechanics. This piece assumes them and asks a different question: what should you check, and when?

A device passes through five stages, and each one is a place where something can quietly break. Figure 1 shows them, with the first power-on highlighted because it is the moment the whole chain is exercised for the first time, in the place a customer will switch the device on.

How this differs from testing a traditional SIM

With a conventional SIM, the profile is fixed at manufacture. A pilot mostly asks one question: does the device attach and pass data? If it does on the bench and in a few field sites, the odds are good it will keep doing so.

SGP.32 turns connectivity into a sequence. The device connects on bootstrap, reaches the eIM, receives an instruction, downloads a profile, and enables it. Each handoff depends on a different party, and a gap in any one of them looks the same from the outside: a device that is powered on and silent. That is why remote SIM provisioning is easy to demonstrate and harder to validate.

Four layers have to agree. The first is the SIM and eUICC: is it certified for SGP.32, and does the IPA run on the SIM (IPAe) or rely on the device (IPAd)? The second is the module and firmware: does the modem firmware support the chosen approach, and is roaming enabled so bootstrap can attach abroad? The third is the eIM and service: is the APN reachable, and can the eIM talk to the profile source you plan to use? The fourth is connectivity and commercial: are bootstrap and operational agreements active in every target country, with terms that allow a later switch?

It also changes what “working” means. Attaching once proves very little. The capability you are buying is the ability to change connectivity later, so the pilot has to test that change, not only the first connection.

What this means in practice

Run the pilot on a small batch and make it deliberately uncomfortable. Three habits separate a useful pilot from a demo.

Test in the countries you will ship to, not the one your lab is in. Bootstrap attaches on a visited network, so a device that connects perfectly on your bench can stall abroad if roaming is off or the APN, the access point name that routes its data, is wrong. Send a few units through your real logistics route so the first power-on happens where a customer will do it.

Age some devices on purpose. Hold a subset in storage for the longest period your supply chain realistically allows, then power them on. Whether a bootstrap profile survives long shelf time depends on your SIM and network agreements, so ask for the answer in writing and then test it. In-factory profile provisioning changes what is loaded before shipment, which makes this test more relevant, not less.

Test the second switch, not just the first. Getting a device onto its operational profile proves activation. Moving it to a different profile later proves the thing you adopted SGP.32 for. Do it on live pilot devices, at least once with a change of network.

Where pilots go wrong

The common failures are mundane. A device powers on, attaches to a tower and produces no data, and the team blames coverage when the cause is roaming or an APN. A pilot passes on the bench and fails in the field because nobody tested the destination country. A team validates activation, skips the second switch, and finds the problem only after devices are deployed.

The failure that costs the most is untested recovery. SGP.32 deployments depend on three safeguards: rollback, so a device that switches profiles and loses connectivity can return to the previous one; fallback, so an interrupted download does not corrupt a profile; and a bootstrap profile that keeps a minimal link alive. Simplex’s lessons from its own SGP.32 work describes all three. Do not assume yours works. Cause a failure on purpose and watch the path in Figure 2.

A pilot that only proves the happy path tells you the architecture works when nothing goes wrong. The value is in the stages you break on purpose: shelf time, the destination country, the second switch, and the failed one. If a small batch passes all four, scaling becomes a logistics problem rather than a technical one.

If you want a second set of eyes on your plan, Simplex can run an SGP.32 readiness review of your device, SIM, and firmware setup before you commit to a pilot batch.

This article was curated by Jan Lattunen, CCO Simplex Wireless

About the Author: Jan Lattunen manages Sales and Marketing for Simplex Wireless. Jan has 20 years’ experience in working with SIM card technology and was involved in launching the eSIM in North America with major carriers and OEMs. His expertise in telecommunications is around SIM cards. On a personal note, Jan is a family man and avid cyclist with advocacy for safety in the roads. You can connect with Jan on https://linkedin.com/in/JanLattunen