TL;DR: eSIM profiles act as digital SIM credentials that are created, delivered, installed, and eventually retired through a managed lifecycle, according to Workz Group. For identity teams, the key issue is that mobile device access now depends on a governed non-human credential chain, not a one-time provisioning event.
NHIMG editorial — based on content published by Workz Group: eSIM management 101, understanding eSIM profiles
By the numbers:
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should organisations govern eSIM profiles as identity credentials?
A: They should treat eSIM profiles as managed non-human identities tied to device access, not as a one-time telecom setting.
Q: Why do eSIM profiles create lifecycle risk for connected devices?
A: Because the profile can remain active or reusable after the device relationship changes if no one is tracking its state.
Q: What breaks when organisations cannot see eSIM profile status accurately?
A: They lose the ability to tell whether a profile is active, pending, installed, or effectively retired.
Practitioner guidance
- Classify eSIM profiles as identity assets Place eSIM profiles under identity governance ownership so that creation, allocation, reuse, and retirement are tracked as lifecycle events, not just telecom events.
- Reconcile profile state to device inventory Build a control that maps available, allocated, linked, downloaded, installed, and unavailable profiles to the live device estate so dormant or orphaned profiles are visible.
- Define revocation criteria for lost or reassigned devices Document the conditions under which a profile must be released, reissued, or made unavailable, and ensure those triggers are linked to offboarding and device replacement workflows.
What's in the full article
Workz Group's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanation of each eSIM profile state from available to unavailable.
- Technical description of how SM-DP+ prepares and packages the profile for delivery.
- Practical view of how QR code, activation code, and direct network download fit into provisioning.
- Lifecycle context for how profile statuses signal warnings, errors, and retirement conditions.
👉 Read Workz Group's eSIM profile guide for the full lifecycle breakdown →
eSIM profiles and device identity lifecycle: what IAM teams miss?
Explore further
eSIM profile governance is NHI governance for connected devices. The profile contains the credentials a device uses to authenticate, so its lifecycle must be managed as a non-human identity lifecycle rather than treated as a network support function. This aligns naturally with the NHI lifecycle model and with identity governance programmes that already manage service accounts, tokens, and certificates. Practitioners should recognise eSIM profiles as a governed identity object, not a telecom abstraction.
A few things that frame the scale:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why lifecycle status tracking matters before access sprawl becomes unmanageable.
A question worth separating out:
Q: Who should own eSIM profile offboarding in an enterprise?
A: Ownership should sit with the team responsible for identity or device lifecycle governance, not solely with network operations. When subscriptions, devices, or vendors change, someone must be accountable for making profiles unavailable and confirming that access has been removed. That accountability is what prevents lingering credential exposure in connected fleets.
👉 Read our full editorial: eSIM profiles expose the governance gap in connected device identity