IoT Strategy
29.07.2026

Escaping minimum commitments and lock-in in IoT connectivity

Annual minimums, activation-based billing, and single-operator lock-in punish fast-scaling IoT fleets. Here’s what flexible, pilot-friendly connectivity terms look like instead.

IoT connectivity contracts often feel designed for large, predictable deployments — and punish everyone else. Minimum commitments, activation-based billing, and lock-in punish flexible scaling, and the companies that scale faster than expected feel it most, even though rapid growth is, in every other respect, great news.

That’s the irony worth sitting with: the fleets these terms hurt most are the successful ones. It’s one of the nine reasons IoT fleets switch connectivity providers.

Here’s how the punitive terms work, where they come from, and what flexible commercial terms look like instead.

How do punitive contract terms show up?

Fleet managers describe being locked into annual contracts with minimum volume commitments well above what they actually use, so they pay every month for idle capacity. Others are billed from the moment a SIM is activated rather than when a device first goes live — meaning any device sitting in a warehouse quietly generates cost before a single byte of data has moved.

The rigidity goes beyond billing cycles. Several prospects describe losing deals outright because a provider demanded large upfront payments or imposed terms that simply didn’t fit the project’s commercial reality. Others are locked in with one operator because their SIM contract makes switching practically impossible, leaving them exposed when that operator underperforms.

And without per-SIM visibility into usage, a problem like a device going rogue only surfaces when the overage invoice lands — by which point the cost is already billed.

“Our provider’s pooled-data billing gives no per-SIM visibility. When a device goes rogue we only find out after an overage invoice lands.”

Why are IoT contracts built this way?

This is a telecom legacy problem. Traditional telecom contracts were built around predictable, large-scale consumption: a fixed number of SIMs, a known data envelope, a stable network footprint. The commercial model followed suit — commit upfront, pay for minimums, accept the terms or walk away.

For an IoT fleet whose deployments ramp gradually, vary by season, or hinge on winning the next customer contract before ordering the next batch of SIMs, that model is a poor fit. Minimum volume clauses, activation-based billing, and single-operator lock-in are all artifacts of a contract structure that was never designed with flexible scaling or hypergrowth in mind.

Nobody built these terms to punish IoT fleets. But nobody rebuilt them for IoT either — and that’s the difference between a provider with telecom terms and a provider with IoT terms.

What flexible IoT connectivity terms look like

What fleet managers increasingly ask for — offered up by fleet managers themselves — is the idea of a testing period. They aren’t afraid to commit; they’ve done it before, albeit to mixed results. But they want real clarity on what they’re committing to.

Beyond that, they’re looking for providers that won’t lock them in on pure commercial terms or enforce commitment for its own sake. Above all, managers want flexible ramp-up and ramp-down pricing, staircase discounts, or pilot-friendly sandbox options.

Put together, the checklist for a contract that fits a scaling fleet looks like this: a testing period before commitment, billing tied to devices actually going live rather than SIM activation, ramp-up and ramp-down flexibility, per-SIM visibility so a rogue device surfaces before the invoice does, and no lock-in on pure commercial terms.

How Onomondo approaches commercial terms

Onomondo’s terms are built for how fleets actually scale: flexible terms, pilot and sandbox options to test before committing, and per-SIM visibility so you see what every device is doing — not just what the pool consumed after the fact.

Underneath it is the tenet this whole series keeps returning to: fleet managers should be free to choose, free to control, and free to leave. A provider confident in its product doesn’t need lock-in to keep customers — which is exactly why lock-in should make you suspicious of the providers that do.

Contract terms are one half of the commercial picture; what the invoice actually says is the other. For the fees and fragmented billing side, see why your IoT connectivity bill never matches the quote, or go straight to Onomondo’s pricing.

Frequently asked questions

Do IoT SIMs require a minimum commitment?

Many providers require annual contracts with minimum volume commitments — often well above what a fleet actually uses, so you pay every month for idle capacity. But that’s a legacy telecom contract structure, not a technical necessity, and providers built for IoT offer flexible ramp-up and ramp-down instead.

What is activation-based billing?

Billing that starts the moment a SIM is activated rather than when the device first goes live. A device sitting in a warehouse quietly generates cost before a single byte of data has moved.

Can you get an IoT SIM with no contract?

Yes — fleet managers increasingly look for testing periods, pilot-friendly sandbox options, and providers that won’t lock them in on pure commercial terms. The point isn’t avoiding commitment altogether; it’s having real clarity on what you’re committing to first.

Why is single-operator lock-in risky?

When your SIM contract makes switching practically impossible, you’re exposed if that operator underperforms — you carry the downtime and have no leverage to fix it.

Build your
own network

Secure, reliable device connectivity anywhere with our efficient IoT SIMs. Gain complete control and leave behind unreliable networks.

Start testing Onomondo for free

Ready to experience next-generation IoT connectivity? Create an account, explore the platform, and start testing Onomondo’s IoT SIM cards for free.

Articles
How to deploy eSIM IoT
IoT Technology
This one’s for you looking at a brand new fleet with eSIM IoT. The article explains: 3 ways to deploy the eSIM IoT ecosystems, the pros, cons, and how to decide.
The mini buyer's guide to esim iot
Articles
eSIM IoT: A short buyer’s guide
IoT SIM IoT Strategy
Ready to enter the eSIM IoT market? Take a few minutes to read this guide. Our short eSIM IoT buyer’s guide ensures that you get the best possible solution for your needs, navigates you through the market, and lists questions to ask the prospective vendors.
Questions the align with your team on eSIM IoT
Articles
Before eSIM IoT: 5 questions for your team
IoT Strategy
Here are a few questions to discuss eSIM IoT internally. Weigh the tradeoffs and conclude on how it’s best to deploy eSIM IoT for your objectives.
eSIM IoT: What are you buying
Articles
eSIM IoT: What are you buying?
IoT checklist
The eSIM IoT ecosystem comprises three components: the SGP.32-ready eUICC SIMs in the form factor of your choice, the eSIM IoT Remote Manager, and the eSIM profiles. In principle, all three of these components should be interchangeable.
Do you need eSIM IoT?
Articles
Reality check: Do you even need eSIM IoT?
IoT SIM Future-proofing IoT IoT Strategy
Is eSIM IoT the only solution to connectivity pains? This post lists the 7 most common pain points and compares eSIM IoT with alternatives solutions.
AT commands for eDRX and PSM
Articles
Implementing eDRX and PSM: AT Commands
Connectivity Basics
eDRX and PSM cut power consumption on LTE-M and NB-IoT devices in very different ways. Compare the two schemes, the AT commands to configure them, and the real-world caveats.
What is an eIM for eSIM IoT?
Articles
What is an eIM?
IoT SIM
An eIM decides which mobile operator profile runs on a deployed device, and changes it over the air without anyone touching the hardware. Here’s what it does, how it works with the IPA and the SM-DP+, and the one question worth asking any vendor before you commit.
API, webhooks and automation for scaling IoT fleets
Articles
IoT SIM management APIs, webhooks, and automation
IoT Strategy
At scale, managing IoT SIMs by hand or by support ticket blocks growth. Here’s how APIs, webhooks, and bulk actions automate connectivity management.
Troubleshooting connectivity: Device or network?
Articles
IoT device vs network: ending the troubleshooting blame game
IoT Strategy
Without packet-level visibility, nobody can prove whether a fault sits in the device or the network — so nobody owns it. Here’s how the blame game works and what breaks the loop.