Splitting those functions often creates blind spots between connectivity state and device state. Teams may provision access without a clear view of which devices are active, retired, or misconfigured, which increases operational error and slows response. The practical failure mode is inconsistent control, where security, inventory, and provisioning records drift apart during fast-growing deployments.
Why Splitting Provisioning From Lifecycle Control Creates Exposure
When eSIM provisioning and device lifecycle control live in separate systems, the core risk is not just administrative inconvenience. It is a loss of authoritative state: one system may believe a device is active while another has already retired it, quarantined it, or never recorded it correctly. That mismatch can turn ordinary operational drift into unauthorised connectivity, delayed deprovisioning, or failed incident containment. NIST’s NIST Cybersecurity Framework 2.0 is useful here because the problem sits squarely in governance, asset visibility, and control consistency rather than in connectivity alone.
In practice, many security teams encounter the failure only after an offboarded device still has a live path to service, rather than through intentional reconciliation between inventory and provisioning systems.
How the Failure Mode Develops in Practice
The practical weakness is a broken handoff between identity-like provisioning state and the device lifecycle record. eSIM activation, suspension, replacement, and revocation are time-sensitive actions. If those actions are not tied to the same source of truth that tracks device ownership, status, and retirement, each system can become internally correct but globally wrong. That is why split control often causes stale entitlements, duplicate records, and delayed revocation after loss, theft, decommissioning, or reassignment.
Operationally, the issue tends to surface in one of three ways. First, a device is replaced but the old profile is still active because the provisioning platform never received a lifecycle event. Second, a device is marked retired in inventory, but connectivity remains live because the telecom or management side was not synchronised. Third, a device is transferred between users or purposes, and the new assignment is recorded in one system while the old access remains in another. The result is not simply bad bookkeeping. It is uncontrolled persistence of connectivity across a device population.
- Reconciliation gaps create periods where no one can say which profile is authoritative.
- Manual synchronisation increases the chance of missed revocation and duplicate activation.
- Delayed lifecycle updates slow incident response because containment depends on two records staying aligned.
For teams that operate at scale, this becomes a governance problem as much as a technical one. A process that works for a small fleet often breaks when devices are reissued quickly, swapped frequently, or managed across suppliers. OWASP’s OWASP Non-Human Identity Top 10 is relevant only at the boundary where eSIM profiles, automation accounts, or machine-managed credentials become the mechanism that actually enforces the provisioning state. Where that applies, the failure is usually one of ownership, rotation, or revocation discipline, not the eSIM technology itself.
The guidance breaks down when organisations assume integration is the same as control. A connected workflow can still leave gaps if neither system is treated as the authoritative source for revocation.
Where Split Control Becomes Harder to Govern
Tighter separation can improve modularity and vendor flexibility, but it also raises the cost of keeping state aligned. That tradeoff becomes especially visible in edge cases such as temporary loan devices, bulk renewals, roaming changes, or emergency suspensions, where the lifecycle event and the connectivity change do not happen at the same moment.
One common variation is a partial integration model, where provisioning and lifecycle tools exchange only some events. That can work if the excluded cases are rare and heavily monitored, but it becomes fragile when device turnover is high. Another variation is delegated operational ownership, where telecom operations, endpoint management, and security each control a slice of the process. In those environments, the main risk is ambiguity over who can revoke access quickly and who is responsible for confirming that the revocation actually propagated. Guidance on this point is still evolving in the industry, but the consensus is clear that ownership must be explicit and auditable if split control is retained.
For device-heavy environments, the larger issue is cumulative drift. Even small reconciliation delays can become material when hundreds or thousands of devices are being added, reassigned, or retired. The control objective is not perfect synchronisation at every instant; it is fast enough reconciliation that no stale profile remains trusted longer than the organisation can justify.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.1 — Organisational Context | Split control is a governance and ownership problem affecting authoritative state. |
| ID.AM — Asset Management | The risk stems from drift between device inventory and active connectivity state. | |
| PR.AC — Identity Management, Authentication and Access Control | eSIM provisioning directly governs which devices retain access paths. | |
| Recommendation — Define accountable ownership for provisioning and lifecycle state before allowing separate systems. Maintain an accurate device inventory that matches active eSIM status. Revoke access promptly when device status changes or ownership ends. | ||
| CIS Controls v8 | 5 — Account Management | Lifecycle drift creates stale access that must be removed and reviewed. |
| 6 — Access Control Management | Split systems can leave access active after the device should be out of service. | |
| Recommendation — Enforce timely removal of access when devices are retired or reassigned. Synchronise access changes with lifecycle events to prevent stale entitlement. | ||
Practitioner Guidance
What to prioritise: Treat revocation and retirement as the highest-value workflow to harden first. If a device can be offboarded in one system without forcing a corresponding change in the other, you have an exposure that will be hard to detect during routine operations.
What to verify: Confirm which system is authoritative for device status, who can change it, and how quickly the other system receives and applies that change. The test is not whether the interface exists, but whether a stale record can survive long enough to matter.
What practitioners underestimate: Audit logs alone do not solve split control. Teams need evidence that provisioning, suspension, reassignment, and retirement all converge on the same lifecycle outcome, especially during bulk events or incident response.
Practitioner takeaway: If provisioning and lifecycle control cannot be reconciled quickly and reliably, the organisation should assume stale connectivity will exist somewhere in the fleet and design containment around that assumption.
Related resources from NHI Mgmt Group
- How should organisations govern identity when digital access and physical access are split across different systems?
- Who is accountable when remote access approvals, MFA, and logging are split across different systems?
- Why do application risks often get missed when teams split ASPM and CNAPP across different consoles?
- Why do security risk scorecards matter when human behaviour and access risks are spread across different systems?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
