The legacy M2M model separates data preparation and secure routing, so enterprises must tightly integrate SM-DP and SM-SR components. That increases implementation complexity and makes vendor changes slow, because the eUICC is often tied to an SM-SR during manufacturing. In practice, this can lock organisations into a brittle operating model when they need flexibility most.
Why This Matters for Security Teams
The legacy M2M eSIM model is not just a telecom architecture choice. It creates a dependency chain that affects procurement, deployment speed, resilience, and exit options for large IoT estates. When SM-DP and SM-SR functions are tightly coupled, enterprises inherit operational constraints that can turn routine carrier or platform changes into a major programme. That is a security and continuity issue because identity, routing, and device lifecycle control are all entangled. NIST guidance on control separation and lifecycle governance is useful context here, especially NIST Cybersecurity Framework 2.0.
Security teams often underestimate how quickly this becomes a vendor-risk problem. If the initial manufacturing path embeds assumptions about one supplier’s SM-SR processes, the enterprise may later discover that migration requires device rework, re-provisioning, or exceptions that are hard to automate. That can weaken resilience, complicate compliance evidence, and reduce bargaining power when contracts change. It also makes incident response harder, because the organisation may not have clean separation between the parties that can update profiles and the parties that control secure routing. In practice, many teams encounter the switching risk only after they need to scale, refresh contracts, or recover from a supplier failure, rather than during design.
How It Works in Practice
In the legacy M2M model, the data preparation function and the secure routing function are split across distinct components. That separation is not inherently bad, but in practice it often creates a fixed integration path between the enterprise, the connectivity provider, and the eUICC provisioning chain. If the SM-SR relationship is established during manufacturing or early onboarding, later changes can be slow because the device identity and profile management path was never designed for easy transfer.
For enterprise IoT, the operational consequences usually show up in three places:
- Provisioning complexity, because onboarding requires coordination across manufacturing, platform, and connectivity teams.
- Migration friction, because changing providers may require profile rework or device touchpoints that are expensive at scale.
- Control fragmentation, because no single team may own the full lifecycle from build to retirement.
This is why NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference point. It does not describe eSIM architecture directly, but it reinforces the need for controlled configuration, access enforcement, and system lifecycle discipline. The practical lesson is to treat M2M provisioning as a governed control plane, not a one-time manufacturing step. Enterprises should define who can authorise profile changes, who can rotate credentials, how vendor exits will be executed, and what evidence proves the device fleet remains under policy after each change.
Where this guidance breaks down is in highly distributed deployments with long-lived devices, weak remote management, or carrier-specific manufacturing flows, because the cost of remediation can exceed the cost of staying with the original vendor.
Common Variations and Edge Cases
Tighter integration often improves initial delivery speed, but it also increases switching cost and operational overhead, so organisations must balance launch simplicity against long-term portability. Best practice is evolving here, and there is no universal standard for how much abstraction an enterprise should build into its IoT identity and connectivity stack.
Some deployments accept the legacy M2M model because they prioritise bulk rollout over future portability. That can be reasonable for short-lived assets or narrow pilots. The risk grows when the fleet is strategic, geographically distributed, or subject to regulatory change. In those cases, vendor lock-in is not only a commercial issue. It can become a resilience issue if a supplier changes terms, discontinues support, or cannot meet new security requirements.
There is also a governance edge case when enterprises assume that carrier management and device identity management are interchangeable. They are not. The former concerns connectivity operations. The latter concerns control over credentials, profiles, and lifecycle state. Where autonomy, fleet scale, or zero-touch provisioning matter, practitioners increasingly examine whether the architecture supports cleaner separation and more portable governance. That alignment is especially important in enterprise IoT programmes that expect to evolve over several years rather than a single deployment cycle.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC | Vendor dependency and switch risk are supply-chain governance concerns. |
| NIST AI RMF | The question is about operational governance and lifecycle risk, not AI. | |
| NIST SP 800-53 Rev 5 | CM-2 | Configuration control is central when manufacturing choices lock future changes. |
Map carrier and eSIM dependencies, then govern supplier exit and continuity as part of risk management.
