Why Hardware Questions Are Different

The questions you ask a SIM or connectivity provider are about network coverage, data rates, and management platforms. The questions you ask a hardware provider are about what is actually happening inside the device. You are trying to establish whether the hardware is genuinely SGP.32 capable at the architecture level, or whether it is marketing an eSIM badge over what is functionally a traditional SIM slot with a QR code workflow bolted on.

These questions apply to router manufacturers, module vendors, and any OEM who is specifying cellular connectivity in their hardware.

Question 1: Is the IPA Device-Based (IPA-d) or eUICC-Based (IPA-e)?

The IPA (IoT Profile Assistant) is the component that receives eIM management instructions and executes them on the eUICC. Whether it lives in the device firmware or in the eUICC chip itself has significant implications for your power budget and deep sleep capability.

If the vendor cannot answer this, they have not engaged with the SGP.32 specification at an architectural level. They are selling a device with an eSIM chip, not a device with a genuine SGP.32 implementation.

Question 2: Does the Hardware Support CoAP Over UDP for Profile Downloads?

CoAP (Constrained Application Protocol) is the lightweight protocol SGP.32 uses for profile management on NB-IoT and LTE-M networks. If a device only supports HTTPS for profile operations, it requires a stable, reasonably high-bandwidth connection to complete a profile download. That rules out NB-IoT and makes LTE-M deployments significantly more expensive in data terms.

For any device that will operate on NB-IoT, CoAP support is not optional – it is the foundation of the entire SGP.32 value proposition for constrained devices.

Question 3: Can the Module Handle Asynchronous Profile Management?

Asynchronous management means the device can receive an eIM command while it is in deep sleep and execute it the next time it wakes up. This is critical for battery-powered devices with low duty cycles.

Ask specifically: “If the eIM pushes a profile change command and my device is in a 24-hour sleep cycle, will it execute that command when it next wakes, or does it need to be awake and connected at the moment the command is sent?”

Question 4: What Is the Bootstrap Profile Provider and What Is the Validity Period?

The bootstrap profile is pre-loaded onto the eUICC at the manufacturing stage. Understanding who provides it and how long it is valid tells you about the supply chain dependencies and deployment timeline flexibility.

A bootstrap validity of one year from manufacturing date is common. If you are purchasing hardware that will sit in a warehouse for six months before deployment, you need to know whether the bootstrap will still be valid when the device powers on in the field.

Question 5: Is the eUICC Certified for SGP.32, and Under Which Version?

eUICC chips must be certified to operate under a specific GSMA specification version. SGP.32 v1.2 is the current standard. A chip certified only for SGP.02 or SGP.22 cannot operate as a native SGP.32 device, regardless of what the marketing material says.

Ask for the GSMA eUICC type approval certificate number. If the vendor cannot provide it, the chip is either not certified or they do not know enough about their own product to answer basic compliance questions.

Question 6: What Happens if the Profile Download Fails Mid-Transfer?

Profile downloads can be interrupted by signal loss, power interruption, or server errors. A device that was in the middle of a profile switch when the connection dropped may end up in an indeterminate state – the old profile disabled, the new one not yet installed.

Ask specifically about rollback mechanisms. The correct answer is that the device automatically rolls back to the last known good profile state if the download fails, and the eIM is notified of the failure so the operation can be retried.

Question 7: How Many Simultaneous Profiles Can the eUICC Store?

eUICC chips have limited storage. The number of profiles they can hold simultaneously varies by chip specification. More stored profiles means more resilience – you can hold a primary, a secondary, and a fallback profile on the device simultaneously.

For mission-critical applications, a minimum of three stored profiles is sensible: a primary operational profile, a backup operator profile, and the original bootstrap as an emergency fallback.

Question 8: Does the Management Platform Support Your Existing Monitoring Infrastructure?

Most hardware vendors offer their own management platform – Teltonika has RMS, Milesight has DeviceHub, Cradlepoint has NetCloud. Before committing to a platform, establish whether it integrates with your existing monitoring, alerting, and ticketing systems via API or webhook.

A management platform that exists as an island, requiring staff to log in separately and manually reconcile device status, creates operational overhead that reduces the benefit of eSIM management.

The single most important question: Ask the vendor to walk you through exactly what happens when a device powers on for the first time – from bootstrap activation through to operational profile installation. If they cannot describe this process in detail, they have not completed a full end-to-end deployment themselves.

The Hardware Specification Minimum for SGP.32

For guidance on the equivalent questions to ask your connectivity provider, see What to Ask Your eSIM Provider. For a technical explanation of the architecture behind these questions, see the SGP.32 Architecture Guide.