TL;DR: Multi-IMSI eSIMs can switch between multiple IMSIs for resilience, regional routing, and cost control, but Workz Group argues that the real value comes from orchestration layers that expose mapping, edit priority rules, and preserve state across re-downloads. Without lifecycle governance, profile storage alone leaves operators blind to what is active and why.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Workz Group's blog post: Multi-IMSI eSIMs only deliver their intended resilience and routing benefits when orchestration exposes mapping, lets operators change priorities, and preserves applied state across profile re-downloads.
Why it matters: For IAM and NHI practitioners, the governance lesson is that identities or credentials embedded in profiles need lifecycle control, auditability, and recovery logic, not just secure storage.
Context
Multi-IMSI eSIMs store multiple IMSIs and related credentials so a device can switch network identity based on geography, availability, or policy. The security and governance gap is not whether the data exists in the profile, but whether operators can see, change, and prove which identity is active at any point in the lifecycle.
That matters because lifecycle state changes are where control breaks down. If mapping is hidden inside technical files and re-downloads can revert to old settings, operators lose auditability and consistency, which turns a managed connectivity asset into an opaque configuration problem.
Key questions
Q: What breaks when multi-IMSI orchestration cannot preserve lifecycle state?
A: Operators lose consistency between intended routing policy and what the device actually uses. A re-download can restore an older IMSI set, which means resilience, locality, and commercial steering decisions no longer survive recovery events. That creates governance drift, weakens auditability, and makes troubleshooting far harder because the active identity is no longer predictable.
Q: Why do hidden IMSI mappings create operational risk?
A: Hidden mappings create risk because operators cannot verify what is active, what fallback exists, or whether the deployed state matches policy. When the authoritative mapping sits inside technical files, troubleshooting, compliance checks, and recovery decisions all become guesswork instead of governed operations.
Q: How should organisations govern re-downloads and recovery for eSIM profiles?
A: They should treat re-downloads as a controlled lifecycle event, not a simple reinstall. The orchestration layer should retain the applied mapping for each profile instance, verify that the current priority order is restored, and prevent rollback to obsolete IMSI sets. Recovery must preserve policy, not just recreate a profile.
Q: What is the difference between storing IMSIs and governing IMSI orchestration?
A: Storing IMSIs keeps identity material available, but governing orchestration defines how that material is selected, changed, audited, and recovered. Storage is passive. Orchestration is the control layer that keeps the active IMSI set aligned with geography, redundancy, compliance, and commercial routing decisions across the profile lifecycle.
Technical breakdown
How multi-IMSI mapping works inside an eSIM profile
A multi-IMSI applet stores several IMSIs and associated network credentials inside the eSIM profile, usually with rules for geography, failover, or commercial routing. The profile can then present different mobile identities depending on operator availability, local breakout requirements, or priority order. The operational challenge is that the raw mapping often sits in technical structures that are hard to inspect. Without a clear orchestration layer, the organisation can store the identities but still not govern which one is preferred, when fallback occurs, or how changes are audited.
Practical implication: Treat IMSI mapping as governed configuration, not hidden profile data.
Why lifecycle automation matters for eSIM orchestration
Lifecycle automation is what lets operators add or remove IMSIs, change priority order, and apply those changes across profile batches without republishing every profile manually. That is important because the control surface is not static. It changes as roaming agreements shift, congestion appears, regulations differ by market, or commercial routing needs update. If orchestration cannot manage these changes centrally, teams end up with inconsistent profile states across inventory and deployed devices, which weakens both resilience and operational accountability.
Practical implication: Use lifecycle controls to keep routing policy aligned with current business and network conditions.
Why re-download and recovery state must be preserved
Re-download events are a common lifecycle edge case because a user or device may delete, reset, or regenerate an eSIM profile. If the orchestration layer does not store the applied IMSI mapping per profile instance, the new download can revert to an older IMSI set and undo prior governance decisions. That creates state drift between what operators intended and what devices actually use. In governance terms, the issue is not storage capacity but state persistence across recovery events.
Practical implication: Persist applied mapping and priority state so recovery does not overwrite operational policy.
Threat narrative
Attacker objective: The article is not about an attacker, but the operational objective at risk is maintaining accurate control over which IMSI and credentials are active across the fleet.
- Entry occurs when an eSIM profile is downloaded or re-downloaded without preserved orchestration state, causing the device to inherit outdated IMSI mapping.
- Credential and identity state are then reused because the profile still carries multiple IMSIs and credentials, but the active selection is no longer aligned to current policy.
- Impact follows when routing, fallback, or regional assignment no longer matches operator intent, creating blind spots, inconsistent connectivity, and governance drift.
Breaches seen in the wild
- SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Lifecycle governance, not storage, is the real control plane for multi-IMSI eSIMs. The article shows that the useful security and operational boundary is not whether multiple IMSIs exist in a profile, but whether teams can govern mapping, priority, and recovery state over time. That is a lifecycle control problem, which is why visibility and editability matter more than static retention. Practitioners should treat the orchestration layer as the authoritative control point.
Hidden IMSI mapping creates a verification gap that resembles broader identity governance failure. If operators cannot read the active IMSI set in human terms, they cannot easily audit what is deployed or explain why a device is using a given network identity. That weakens accountability in the same way opaque entitlement models weaken IAM and NHI governance. Practitioners should insist on auditable mapping rather than technical obscurity.
Re-download persistence is the named governance gap this topic exposes. When a reset or re-download can restore stale IMSI assignments, the environment has state drift between intended policy and actual device behaviour. That is a lifecycle integrity problem, not a storage problem. Practitioners should focus on preserving applied state across recovery events so operational decisions survive re-provisioning.
Multi-IMSI orchestration is part of machine identity governance, not just telecom configuration. The IMSIs and credentials inside these profiles function as machine-facing identity material that determines how devices authenticate and route. Once that is recognised, the control conversation shifts toward inventory, lifecycle ownership, and change assurance. Practitioners should align multi-IMSI operations with the same governance discipline used for other non-human identities.
Dynamic routing policy needs change control, because business intent and network reality move faster than static profile design. Seasonal routing, regional compliance, congestion handling, and wholesale cost steering all depend on changing the active identity set without losing oversight. That means the orchestration layer must support controlled edits, not just storage. Practitioners should view this as a governed policy engine with recovery state, not a passive repository.
What this signals
Multi-IMSI governance is becoming a lifecycle integrity problem, not a provisioning problem. Once devices can switch identities dynamically, the question is no longer whether the IMSIs exist in storage. The question is whether the orchestration layer can prove which mapping is active, who changed it, and whether a recovery event preserved policy intent.
Machine identity thinking fits this topic better than simple telecom configuration thinking. The IMSI set behaves like governed identity material because selection, fallback, and re-download outcomes all affect trust in the device’s network identity. Practitioners should bring the same control discipline to eSIM orchestration that they apply to other non-human identities, including inventory, lifecycle ownership, and controlled change.
For practitioners
- Map active IMSI sets at profile level Require human-readable visibility into IMSI mapping, priority order, fallback logic, and regional grouping for every deployed eSIM profile.
- Preserve orchestration state across re-downloads Store the applied IMSI mapping per profile instance so device resets and profile regeneration do not revert to obsolete routing choices.
- Apply bulk change control to profile batches Use controlled batch updates for additions, removals, and priority changes so inventory and on-device profiles stay aligned after commercial or network changes.
- Audit recovery behaviour after profile resets Test what happens when a user deletes and re-downloads an eSIM, then verify that the latest mapping survives the recovery path.
Key takeaways
- Multi-IMSI eSIMs only deliver resilience and routing value when orchestration governs the active mapping, not when profiles merely store several identities.
- Re-downloads and profile resets are the most important failure points because they can silently restore stale IMSI choices.
- The practical control issue is lifecycle integrity: organisations need readable state, controlled change, and recovery behaviour that preserves policy intent.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Multi-IMSI profiles can carry more active identity reach than operators can easily govern. |
| NHI-07 — Long-Lived Secrets | Stored IMSI credentials can persist across re-downloads if lifecycle state is not preserved. | |
| Recommendation — Limit active IMSI scope to the minimum required for the device’s current operational context. Rotate or retire stale IMSI credentials when profile state changes or devices are re-provisioned. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article centres on managing identity material through changes, recovery, and re-downloads. |
| Recommendation — Manage IMSI credentials as authenticators with controlled issuance, update, and revocation. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Priority rules and fallback order determine which network identity is authorised for use. |
| Recommendation — Govern IMSI selection rules as entitlement decisions and review them whenever connectivity policy changes. | ||
Key terms
- Multi-IMSI: Multi-IMSI is an eSIM design pattern that stores more than one subscriber identity in a single profile. It lets a device choose between different network identities for coverage, compliance, resilience, or commercial routing, but only works safely when the active state is visible and controlled.
- eSIM Orchestration: eSIM orchestration is the control layer that manages how profiles are created, updated, recovered, and redeployed. It turns a static embedded identity into governed state by handling mapping, priority, lifecycle persistence, and bulk change operations across many devices or profile batches.
- IMSI: The International Mobile Subscriber Identity is a unique identifier used by mobile networks to recognize and communicate with a device or subscriber. In IoT lifecycle management, disabling the IMSI is a definitive action that stops remote reconnection and should be treated as irreversible operational control.
- Profile Re-download: Profile re-download is the process of deleting, regenerating, or re-installing an eSIM profile on a device. The governance risk is state drift, where the newly downloaded profile no longer reflects the latest IMSI assignments or priority rules unless orchestration preserves that information.
Deepen your knowledge
NHI Foundation Level course covers NHI governance, identity lifecycle, and secrets management in a practical, practitioner-led format. It helps security teams and identity programmes apply consistent control thinking to machine-facing identity material.
Published by the NHIMG editorial team on July 14, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org