The eSIM testing checklist: what to test, from download to roaming, with pass criteria

A complete eSIM testing checklist follows the subscriber’s whole journey: download and install the profile, activate it, attach to the network, then prove data, SMS and voice work, on the home network and on every roaming partner that matters. Each check needs a pass criterion written down before the test runs, measured on a real device with a real profile on a live network. The checklist below groups more than 70 checks into ten areas, with pass criteria and notes on how to automate them.

How to use this checklist

Decide three things before you start:

• Scope. Which profiles (one per product or per APN configuration), which device types (phones, modules, routers) and which markets and partner networks.
• Pass criteria. The thresholds in the tables are starting points. Tune them to your service level commitments and keep them stable so results stay comparable over time.
• Evidence. Each run should record identifiers (EID, ICCID, IMSI), the network (PLMN, RAT, band, cell), timestamps and raw logs. A verdict without evidence can’t be debugged.

AT commands in the tables are the standard ones from 3GPP TS 27.007. Vendor-specific equivalents also work.

1. Provisioning: download and install

Check	How	Pass criterion
Download by QR / activation code	Install a fresh, released profile	Profile installed; no SM-DP+ error
Download via carrier app or discovery	Use the app flow or SM-DS	Same as above, with no manual code entry
Single-use code reuse	Repeat a consumed activation code	Refused with a clear, documented error
Confirmation code	Correct code, then a wrong code	Correct code succeeds; wrong code is refused and counted
EID-bound order	Download on the intended and a different eUICC	Only the bound EID succeeds
Download over restricted networks	Captive portal, filtered DNS, IoT bootstrap APN	Succeeds where expected; fails cleanly elsewhere
eUICC memory limit	Fill the chip with profiles	Clear insufficient-memory error, no corruption
Notifications	Inspect SM-DP+ or operator logs	Install, enable and delete notifications received
Download time	Measure from start to installed	Within your target (for example, under 60 s on a good connection)

Failure signatures for each of these are explained in eSIM profile download errors.

2. Activation and profile management

Check	How	Pass criterion
Enable after install	Enable the new profile	Profile active; ICCID and IMSI read correctly (AT+CIMI)
Switch between profiles	Enable profile B while A is active	B active, A disabled, device re-registers
Disable and re-enable	Disable, then enable	Service restored without re-download
Delete	Delete a disabled profile	Removed; memory freed; delete notification sent
Profile policy rules	Try to disable or delete a protected profile	Blocked as the PPRs specify
MSISDN mapping	Read the number or call a known handset	MSISDN matches the inventory record
Fallback (IoT)	Make the operational profile fail to attach	Device falls back to the bootstrap profile as designed

3. Network attach and registration

Check	How	Pass criterion
Home attach	Automatic network selection	+CEREG / +C5GREG status 1 (home) within your time limit
Roaming attach	Attach abroad or on a partner PLMN	Status 5 (roaming) on an allowed partner
Correct operator	Read AT+COPS?	PLMN matches expected MCC-MNC
Correct RAT	Read the registered access technology	Expected technology (5G SA/NSA, LTE, LTE-M, NB-IoT)
Forced RAT	Lock to each supported technology	Registers on each technology the plan includes
Forbidden or barred networks	Force a non-partner PLMN	Rejected with the expected cause; device recovers
Reject causes	Decode NAS signaling	No unexpected attach reject cause
Re-attach after outage	Airplane mode or detach, then re-attach	Registers again within the time limit

4. Data

Check	How	Pass criterion
PDN / PDU session	Activate the default bearer	Session up on the correct APN or DNN
IP addressing	Read assigned addresses	Expected IP type (IPv4, IPv6 or both)
DNS	Resolve a known hostname	Resolves within your limit
Reachability	Ping a known host	Packet loss below your threshold (for example, 0 of 10)
HTTP(S)	Fetch a known page	Completes; time to first byte recorded
Breakout location	Check the public IP’s location	Matches the design (home-routed or local breakout)
Private APN / VPN	Reach an internal host	Reachable only through the intended APN
Data barring	Exceed or disable the plan	Blocked or redirected as the product specifies

5. SMS

Check	How	Pass criterion
Mobile-originated SMS	Send to a monitored number	Delivered; status report received
Mobile-terminated SMS	Send to the device	Received with the correct sender and content
Long and Unicode SMS	Concatenated and UCS-2 messages	Reassembled correctly
SMS while roaming	Repeat MO and MT on partners	Delivered in both directions
SMS transport	Inspect signaling	Expected path (SGs, IMS or NAS), no fallback surprises
Application-to-person SMS	Short codes, OTP senders	Delivered within your time target

6. Voice and VoLTE

Check	How	Pass criterion
IMS registration	Check IMS state after attach	Registered to IMS where VoLTE is offered
Outgoing call	Call a monitored number	Connected; setup time within target (for example, under 5 s)
Incoming call	Call the device	Rings and connects
Bearer	Inspect call signaling	VoLTE or VoNR where expected; circuit-switched only where intended
Audio	Recorded call	Two-way audio, no one-way or silent call
Call duration	Hold the call for a set time	No drop before the planned end
Roaming voice	Repeat on partners	Works on each partner where voice is sold
Emergency	Use operator-defined test procedures only	Never place test calls to real emergency numbers without arrangement

GSMA’s VoLTE roaming test specification IR.25 is a useful reference for which voice and SMS scenarios matter when roaming.

7. Roaming, per partner

Run this block for every partner network in every market you sell. Results belong in a roaming matrix: home profile across, visited network down.

Check	How	Pass criterion
Attach on partner	Force the partner PLMN	Registered (roaming)
Data on partner	Session, DNS, ping	Same criteria as section 4
SMS and voice on partner	MO and MT	Same criteria as sections 5 and 6
Steering of roaming	Automatic selection in a market with several partners	Device lands on the preferred partner
Non-partner rejection	Force a network without an agreement	Rejected; device moves on to an allowed network
RAT availability	Force each RAT on the partner	Matches the commercial agreement (for example, LTE-M or 5G SA roaming)
Charging	Compare test usage with partner records	Usage appears correctly in billing (see IREG vs TADIG)

The roaming testing guide covers this area in depth.

8. IoT specifics

Check	How	Pass criterion
LTE-M and NB-IoT attach	Force each technology	Registers on the technologies the module and plan support
PSM granted	Request timers with AT+CPSMS; read the network’s grant	Network grants usable T3324/T3412 values
eDRX granted	Request with AT+CEDRXS; read the grant	Network grants an eDRX cycle; device stays reachable as designed
Wake-up and reattach	Let the device sleep, then send uplink	Data flows without a full reattach
MQTT / CoAP round trip	Publish and receive, or request and response	Round trip completes within your latency budget
Coverage	Test at the edge of coverage	Attach and transfer succeed in coverage enhancement
Remote profile management	eIM-driven download, enable, delete (SGP.32)	Operations complete and results reach the eIM

For technology-specific detail, see NB-IoT vs LTE-M testing and how to test SGP.32 devices.

9. Performance and QoS

Check	How	Pass criterion
Signal	Read RSRP, RSRQ, SINR (what they mean)	Recorded with every verdict; flagged below your floor
Latency	Ping series	Median and 95th percentile within targets
Throughput	TCP and UDP tests (for example, iperf3)	Downlink and uplink above plan-appropriate floors
Jitter and loss	UDP stream	Below thresholds for your use case (voice, video, telemetry)
Bufferbloat	Latency under load	Loaded latency within target
Web experience	Real browser page loads	Load times within target on key sites
Consistency	Repeat across times of day	No systematic degradation at peak hours

10. Regression and monitoring

Check	When	Pass criterion
Smoke set (attach, data, SMS)	On a schedule, per market	All pass; failures alert someone
Full checklist	Before launch and after major changes	All pass or have a documented exception
Change-triggered re-test	HSS/HLR, APN, SM-DP+, firmware or partner changes	Affected sections re-run and pass
Periodic roaming re-test	Regularly per partner	Roaming matrix stays green
Trend review	Weekly or monthly	No drift in attach time, latency or throughput

GSMA’s roaming test organization document IR.23 recommends periodic re-testing after commercial launch and re-testing after network changes. The same logic applies to any eSIM product.

Gaps most eSIM test plans miss

Teams that already test eSIMs tend to miss the same few areas:

• Failure paths. Plans check that a fresh profile installs, but not what happens when a code is reused, an order expires or the eUICC is full. Those are the cases support teams hear about.
• One device, one market. A profile that works on one phone model in the home country tells you little about a module abroad. Device and partner diversity is where regressions hide.
• Data without DNS or breakout checks. A bearer can come up with broken DNS or the wrong breakout. Users then report “connected, no internet”, and the attach test still shows green.
• Voice on roaming partners. VoLTE that works at home can fall back or fail on a partner without the right IMS roaming setup.
• Testing once. Partners change configurations, steering rules move traffic, and firmware updates change modem behavior. Without scheduled re-tests, a launch-day pass slowly goes stale.

Capture this on every run

Whatever tool runs the checklist, store the same evidence with each verdict:

• Identity. EID, ICCID, IMSI, MSISDN, device model and firmware.
• Network. PLMN, RAT, band, cell ID, RSRP, RSRQ, SINR.
• Timing. Start and end times, time to register, time to first data, call setup time.
• Signaling. Registration states and any reject cause, decoded.
• Artifacts. Logs and packet captures for failed runs, at minimum.

How to automate the checklist

Most checks reduce to a few repeatable primitives: install or select a profile, force a network or technology, register, open a data session, send an SMS, place a call, measure. Automating them takes four pieces:

1. Real devices in the right places. Modems or phones with eUICCs where your customers are, or the ability to force the target partner PLMN.
2. An orchestration layer that turns each check into a script with a pass criterion, and runs scripts in sequence or in parallel.
3. A scheduler and alerts, so the smoke set runs without anyone remembering to start it.
4. A results store that keeps verdicts and evidence comparable across runs, devices and markets.

SimCheck.ai provides those pieces on real modems. Quick Tests cover attach, SMS, data, performance, iperf3, speed, MQTT and voice checks. Each test can force a RAT or a partner PLMN, and saved tests run on a recurring schedule. The Flow Builder chains cellular, data, SMS and voice steps into one run with conditions and assertions, and the Roaming matrix report rolls per-partner results into a single view.

Run the checklist on live networks

The checklist is only as good as the network it runs on. Start with the eSIM testing use case to see how SimCheck.ai runs these checks with your own profiles on real modems, on the SimCheck network or on your own edge devices anywhere.