How to test SGP.32 devices: a practical field-test guide

Testing an SGP.32 device takes two layers: lab conformance against the GSMA SGP.33 test specifications, and field validation that drives the real device through its eIM on live networks. Conformance proves each component follows the standard. Field validation proves the whole chain works: eIM association, profile download through the eIM, enable, disable and delete, the switch from bootstrap to operational profile with rollback and fallback, network attach on NB-IoT, LTE-M or LTE, an application data round trip such as MQTT, every target country, deliberate failure cases and regression after every change.

This guide turns that into a test plan you can run, with pass criteria and a checklist at the end. If you are new to the architecture, start with What is SGP.32?.

Lab conformance vs field validation

The GSMA publishes three SGP.33 test specifications, all at version 1.2 since January 2025: SGP.33-1 for the IoT eUICC, SGP.33-2 for the IPA and SGP.33-3 for the eIM. They test each component’s interfaces against test tools that play the other roles.

	Lab conformance (SGP.33)	Field validation
Question answered	Does each component follow the specification?	Does my product work, end to end, where I sell it?
Scope	One component per test suite	Device + module + eUICC + IPA + eIM + SM-DP+ + network
Environment	Test tools, simulated servers, test certificates	Live networks, real operator profiles
Covers network attach and data	No	Yes
Covers roaming and local operator policy	No	Yes
Who runs it	Accredited labs, vendors	Device makers, connectivity providers, operators
When	Before certification	Before launch, after every change, continuously

You need both. Conformance catches specification errors early. Field validation catches what conformance cannot see: a module whose firmware mishandles a logical channel, a private APN that blocks the route to the eIM, or a visited network that rejects the new profile.

Before you start: build the test inventory

Write down exactly what is under test, because SGP.32 results only hold for a specific combination.

• Device: module model and firmware version, eUICC product and batch, IPA variant (IPAd or IPAe) and version.
• Identities: the EID of each test eUICC and the eIM it is associated with.
• Profiles: a bootstrap profile or initial profile, plus activation codes for each target operator, including spare and deliberately invalid ones for negative tests.
• Markets: for each country, the expected PLMN codes, the radio technology (NB-IoT, LTE-M or LTE) and the APN.
• Servers: eIM tenant and API access, the operator’s SM-DP+ contact for error lookups, and the MQTT or application endpoint.
• Evidence: where you will capture modem logs, decoded signaling, packet captures, the eIM’s package history and SM-DP+ notifications.

The SGP.32 field test plan

1. eIM association

Confirm the eUICC trusts the right eIM before anything else.

• The eIM can read the device’s EID, eUICCInfo2, IPA Capabilities and installed profile list through a data request.
• The IPA reaches the eIM over the configured transport (HTTPS, CoAP/DTLS, LwM2M or MQTT) using the bootstrap profile.
• If you will ever change eIM, test adding a second eIM and deleting the first on a test device now, not after deployment.

Pass: the eIM receives a signed, current view of the device within your expected polling interval.

2. Profile download via the eIM

Test every trigger and mode you will use in production: activation code, SM-DS event or default SM-DP+, and direct or indirect download.

• Measure each stage: package queued, package collected by the IPA, download complete, notification received.
• Confirm the eIM records the download result and that the operator’s SM-DP+ shows the profile as installed.
• Repeat with a device that is asleep when the package is queued, using your real PSM or eDRX settings.

Pass: the profile installs, both servers agree on its state, and timings are within your threshold. When downloads fail, map the error to its stage; our guide to eSIM profile download errors explains the common codes.

3. Enable, disable and delete

• Enable the new profile and confirm with a profile list that it is enabled and the old one disabled.
• Disable and re-enable, if your operations will use it.
• Delete a disabled profile and confirm the SM-DP+ receives the deletion notification.
• Check the guard rails: deleting a profile that is still enabled must fail with a clear error, and a replayed or out-of-date command must be rejected by the eUICC.

Pass: every operation returns a signed result that matches the device’s actual state.

4. Bootstrap to operational switch and rollback

This is the step most likely to strand a device. Send the enable command with rollback granted, then confirm that:

• the device re-attaches on the new profile;
• the IPA can still reach the eIM on the new profile, since private APNs and firewalls often block it;
• the signed result reaches the eIM.

Then repeat with a profile that cannot work in the test location and confirm the IPA rolls back to the previous profile and reports it.

Pass: the device is reachable after the switch, or recovers through rollback without manual intervention.

5. Fallback

The Profile Fallback Mechanism, added in SGP.32 v1.1, is optional on the eUICC. If your eUICC and IPA support it, set the fallback attribute on the profile you trust most, remove connectivity on the operational profile, and confirm the IPA switches to the fallback profile and later returns. Confirm the eIM’s view of which profile is enabled stays correct throughout.

Pass: the device recovers connectivity through the fallback profile, and the eIM can see what happened.

6. Network attach on NB-IoT, LTE-M and LTE

For each target radio technology, record registration status, selected operator and PLMN, band, signal quality (RSRP, RSRQ and SINR), attach time and the power-saving timers the network grants. When an attach fails, capture the attach reject cause from the decoded NAS signaling. Causes defined in 3GPP TS 24.301 such as #11 (PLMN not allowed), #13 (roaming not allowed in this tracking area) or #15 (no suitable cells in tracking area) point at subscription or roaming configuration rather than at the device. Differences between the two LPWA technologies are covered in NB-IoT vs LTE-M testing.

Pass: the device registers on an expected network with the expected technology and acceptable signal.

7. Data and MQTT round trip

Registration is not service. Open the data session with the profile’s APN, resolve DNS, and complete an application-level round trip. For most IoT products that means connecting to the MQTT broker over TLS, publishing a message and receiving it back on a subscribed topic. Record latency and failures separately for connect, publish and subscribe.

Pass: the round trip completes on every profile and technology you ship.

8. Multi-country and roaming

Repeat steps 2 to 7 in every target market. For roaming profiles, force each allowed visited network by PLMN and check that the device attaches and passes data on each, and that steering of roaming does not leave it stuck on a network that rejects it. Also check first power-on: the bootstrap profile must work everywhere a device might be switched on for the first time. The roaming testing guide covers the network-side checks in more depth.

Pass: a complete, passing result for each country, operator and technology combination.

9. Failure injection

Deliberately break things and check the device and servers behave predictably.

Fault	How to induce it	Expected behaviour
Used or invalid activation code	Reuse a single-use code	Download fails with an SM-DP+ error; the eIM gets the result; the device stays on its current profile
eUICC memory full	Fill the eUICC with test profiles	The SM-DP+ eligibility check fails cleanly
Device offline when work is queued	Power down, queue a package, power up	The package is delivered on the next connection, or expires as configured
Power loss mid-download	Cut power during the download	The session is cancelled and a retry succeeds
New profile rejected by the network	Enable a profile not allowed at the location	Attach reject recorded; rollback or fallback restores the device
Wrong APN on the new profile	Use a profile with a misconfigured APN	Attach succeeds but data fails; the IPA cannot reach the eIM; rollback triggers
Replayed command	Resend an old eUICC Package	The eUICC rejects it with a replay error
Weak or congested coverage	Test at cell edge or force a weak band	Timeouts and retries stay within limits; no corrupted state

10. Regression

Re-run the core suite after any change to device or module firmware, the IPA, the eIM, the eUICC batch or OS, or an operator’s profile. Keep a reduced suite (attach, data round trip and IPA-to-eIM reachability) running on a schedule in each key market, because operator and roaming configuration changes without notice.

SGP.32 test checklist

#	Test	Pass criterion	Evidence to keep
1	eIM association	eIM reads EID, eUICCInfo2, profile list	eIM data response
2	Download via eIM (each trigger and mode)	Profile installed; eIM and SM-DP+ agree	Timings, notifications
3	Download to a sleeping device	Delivered at next wake-up	eIM queue history
4	Enable / disable / delete	Signed results match device state	eUICC Package Results
5	Guard rails	Invalid and replayed commands rejected	Error codes
6	Bootstrap to operational switch	Device reachable on the new profile	Attach log, eIM result
7	Rollback	Device restored to the previous profile	Rollback result
8	Fallback (if supported)	Device recovers and eIM view is correct	Profile list before and after
9	Attach per technology	Registered on expected PLMN and RAT	Signaling, signal metrics
10	Data and MQTT round trip	Publish/subscribe completes	Latency, packet capture
11	Each country and visited network	All combinations pass	Per-market results matrix
12	Failure injection	Predictable, recoverable behaviour	Logs per fault
13	Regression	No change from baseline	Scheduled run history

For general eSIM checks that apply beyond SGP.32, see the eSIM testing checklist.

How SimCheck.ai helps

SimCheck.ai runs this kind of plan on real cellular modems with real eSIM profiles on live networks, either on the shared SimCheck network or on your own edge devices with a supported Quectel modem, including the LTE-M and NB-IoT capable BG95-M3.

• Install profiles via SGP.32. Add activation codes to the eSIM inventory and install them through a cloud eIM, or through an SGP.22-style LPA, chosen per modem.
• Run the checks as Quick Tests. The Network Connection Test reports registration, operator, technology, band and RSRP, RSRQ and SINR. The Data Connection Test checks the data session, DNS and ping. The IoT (MQTT) test attaches on LTE-M or NB-IoT and completes an MQTT publish/subscribe round trip.
• Control the conditions. Force the radio technology and the operator by PLMN, and override the APN, to work through markets and roaming partners one by one.
• Keep the evidence. Each run includes logs, decoded signaling with any network reject cause, and packet captures.
• Automate regression. Save configurations and run them on a schedule, chain steps with assertions in flows, and feed results into reports such as the roaming matrix.

Get started

Field validation is what turns an SGP.32 design into a product you can ship to every market with confidence. To see how teams validate eIM, eUICC, device and operator combinations on live networks, visit SGP.32 IoT eSIM testing, or read about broader IoT connectivity testing.