Who should own eSIM profile offboarding in an enterprise?

Why This Matters for Security Teams

eSIM profile offboarding is not just a telecom housekeeping task. It is the moment when device access, subscription entitlements, and embedded credentials must be retired with the same discipline used for NHI or service account deprovisioning. If ownership is unclear, profiles can outlive the device, the vendor, or the business need that created them. NHI Management Group’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is a warning sign for any identity-like asset that persists beyond the original transaction. NIST SP 800-53 Rev. 5 also treats lifecycle control as a core security function, not an optional cleanup step.

The practical risk is simple: if no single owner is accountable, offboarding becomes a ticket-routing exercise instead of a control. That creates lingering reachability in mobile fleets, IoT estates, and managed endpoints where a retained profile can still support connectivity, policy drift, or recovery abuse. Security teams often assume network operations will handle it because the asset touches carrier infrastructure, but the real failure is usually governance, not transport. In practice, many security teams discover residual eSIM exposure only after a subscription has already been repurposed or a device has left control, rather than through intentional lifecycle review.

For deeper lifecycle context, see the NHI Lifecycle Management Guide and the Top 10 NHI Issues, both of which show why ownership and revocation are inseparable.

How It Works in Practice

Best practice is for the identity or device lifecycle governance function to own eSIM profile offboarding, with network operations, endpoint management, and procurement acting as executors. That owner should define when a profile must be disabled, who approves removal, how confirmation is recorded, and what evidence proves the profile is no longer usable. In mature environments, this is handled through a joiner-mover-leaver style workflow that treats the eSIM profile as a controlled identity artifact, not as a carrier-only record.

A workable operating model usually includes:

• Trigger events such as device retirement, user transfer, vendor exit, or contract termination.
• Policy checks that confirm the device is still managed and that the profile is not tied to a recovery or break-glass function.
• Revocation steps that disable the profile, invalidate dependent access, and close any linked inventory records.
• Verification that the profile is unavailable on the endpoint, in the carrier portal, and in any MDM or CMDB system.
• Evidence retention so auditors can confirm who approved offboarding and when the action completed.

This is where NHI governance patterns translate directly. If a profile can be provisioned dynamically, it should also be removable on the same authority trail. The same principle is reflected in NIST SP 800-53 Rev. 5 access and configuration controls, which emphasise accountable lifecycle management and verification. For a broader risk lens, NHI Management Group’s Ultimate Guide to NHIs highlights how poor lifecycle visibility drives exposure across non-human identities, especially when ownership is diffuse.

These controls tend to break down when carrier-managed records, device ownership, and security approval paths sit in different systems because no single team can prove completion end to end.

Common Variations and Edge Cases

Tighter offboarding control often increases coordination overhead, requiring organisations to balance faster operational change against stronger assurance that profiles are actually removed. Current guidance suggests the owner should remain the identity or device governance team even when another group performs the technical disablement, but there is no universal standard for this yet. Some enterprises place execution in network operations while keeping approval and verification in security or endpoint governance. That split can work if the RACI is explicit and every offboarding event is traceable.

Edge cases matter. Shared devices, roaming assets, emergency spares, and M2M or IoT deployments can require exceptions because a profile may support service continuity rather than a single user. In those cases, offboarding should not mean immediate deletion without replacement planning. Instead, the owner should require a documented handoff, replacement profile, or service migration plan before deactivation. This is especially important when carrier billing, inventory reconciliation, and security revocation happen on different cadences.

Organisation size also changes the answer. In smaller environments, one team may own both device lifecycle and network administration. In larger estates, the right model is usually a governance owner with delegated execution. The key is that someone outside day-to-day carrier operations is accountable for closure, because carrier tickets alone rarely prove that access was fully removed. For examples of how unmanaged lifecycle gaps create real exposure, see Top 10 NHI Issues and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.

Related resources from NHI Mgmt Group

• Why is single-provider AI agent governance not enough for enterprise security?
• Who should own policy when application email crosses cloud and security teams?
• Who should own enforcement when policies cover both human and non-human identities?
• Who should own the control model for non-human secrets?