IoT SIM fleets: who authorized a profile change on 200,000 devices?

A connectivity management console has a bulk operations tab. It exists because operators need it. It also means a single authenticated session can take two hundred thousand meters, ambulances or telematics units off the network in one call.

Part of Telecom and subscriber identity

Prerequisites

• An inventory of platform credentials with write access to provisioning APIs, including automation and CI tokens.
• Device counts reachable by each credential, by customer and by profile group.
• Your contractual service level commitments and the penalty structure attached to them.

Step 1 — Compute devices per credential

The organising number. For each credential, count the devices it can address with a state-changing operation — suspend, activate, change profile, change APN, push a subscription.

Expect at least one credential to reach everything. Platform support accounts and automation tokens usually do, because scoping them was never a requirement.

Step 2 — Price an hour of lost connectivity

This turns a security discussion into a commercial one, which is the only way it gets funded.

For safety-relevant fleets — medical devices, alarm panels, utility telemetry — add the consequence that has no price and note it separately rather than pretending it can be modelled.

Step 3 — Set the ceiling

Pick the device count at which an erroneous or malicious bulk operation produces a loss your operations leadership would want to have been asked about. For most platforms that is a few thousand devices, which is far below what any credential can currently reach.

Then check the ceiling against your legitimate operational history. Pull twelve months of bulk operations and look at the distribution of device counts. If ninety-five percent of legitimate operations are under five hundred devices, a ceiling of two thousand is generous and will almost never fire.

Step 4 — Express it in the credential

delegation:
  issuer:   [platform operations lead, hardware credential]
  delegate: [provisioning service key]
  scope:    operations = [suspend, activate, profile_change]
            customer = [id] | any
  limits:   max_devices_per_operation = 2000
            max_devices_per_hour = 5000
  notAfter: [24 hours]
  depth:    0

An operation exceeding the ceiling produces no valid authorisation and fails visibly. It does not partially execute — partial execution across a fleet is worse than refusal, because it leaves an inconsistent state nobody planned for.

Step 5 — Design the above-ceiling path

Large legitimate operations happen: a customer migration, a profile update across a product line, an emergency response to a network event.

Above the ceiling, require a human signature over a statement that renders the device count explicitly. The person authorising a fleet-wide operation should see the number, in the statement they sign, not in a dialog they dismissed.

Step 6 — Test the failure modes

1. Ceiling exceeded during a scheduled automation window — does the automation fail safe and alert, or silently skip?
2. Delegation expiry during a long-running migration — does the operation resume after renewal or restart?
3. Issuer key rotation mid-window — both keys valid, no interruption. Test deliberately.
4. Emergency override at 3am — is there a path, and is it recorded?

What this does not address

There is no public incident record of malicious fleet-wide re-provisioning, and this article does not imply one. The exposure is structural: authority without a magnitude bound, on estates whose size has grown by orders of magnitude since the authority model was designed.

It also does not address device-side security, radio access, or the physical SIM supply chain.

Gating by magnitude rather than by operation

This inverts the usual instinct, which is to gate by operation type. Suspending one device and suspending the fleet are the same operation; only the selector differs, and the selector is what should set the bar.

Objections and honest limits

“Our platform has role-based limits.” Which bound who may perform an operation, not how many devices one performance touches. Those are different axes and most platforms only model the first.

“Bulk operations are routine for us.” Then the thresholds should reflect your routine. The point is that a threshold exists and is derived from your own distribution, not that it is low.

Adding magnitude gating

1. Measure your own distribution. How many devices does a typical operation touch?
2. Set thresholds from that, not from intuition. The 99th percentile of normal is a defensible starting line.
3. Render the count and the selector. ‘200,000 devices matching tenant=X’, not ‘bulk suspend’.
4. Require two signatures above the top threshold. With a short delay, which is the only thing that makes recovery possible.

Terms used here

Remote SIM provisioning

Downloading and managing subscriber profiles over the air, which makes connectivity a software-controlled property.

Blast radius

The number of entities affected by a single operation — the axis most authorisation models do not represent.

Selector

The query determining which devices an operation applies to. The dangerous part of a bulk request.

Frequently asked questions

Will ceilings break large customer migrations? They will require a signature, which is the intent. Set the ceiling from your own operational distribution so that routine work is unaffected.

Does this add latency to provisioning? Verification is local and sub-millisecond. Routine operations run under a pre-signed delegation with no human in the path.

What about automation and CI tokens? Those are the credentials most likely to reach everything and least likely to have been scoped. Treat them first.

Is any of this required by GSMA specifications? No. Remote SIM provisioning specifications address the provisioning mechanism, not the authorisation model above it.

Why gate by magnitude rather than operation? Because suspending one device and suspending the fleet are the same operation. Only the selector differs, and that is what sets the consequence.

What should the approval render? The resolved count and the selector — ‘200,000 devices matching this query’ — not the operation name.

How should thresholds be set? From your own distribution of operation sizes, not from intuition. The 99th percentile of normal is a defensible start.

Sources and further reading

• GSMA — eSIM remote SIM provisioning specifications
• FTC — business guidance on marketplaces and consumer protection
• CISA — known exploited vulnerabilities and incident reporting
• GSMA — fraud and security resources