What Is In-Factory Profile Provisioning, and Why Should IoT Manufacturers Care?

If your device connects the moment it powers on, no matter which country it lands in, someone made a decision about its carrier profile long before it left the factory. For years that decision meant one hardware SKU per market. A new pair of GSMA specifications, SGP.41 and SGP.42, changes where that decision gets made and gives manufacturers a way out of the SKU trap entirely.

What it is and how it works

In-Factory Profile Provisioning (IFPP) is the practice of loading a device’s operational carrier profile onto its eUICC (the embedded chip that stores SIM credentials) at the final stage of manufacturing, instead of earlier at the chip supplier or later once the device is in the field. It’s defined across two specifications. SGP.41, published in February 2025, sets the architecture: who’s involved, what gets exchanged, and in what order. SGP.42 is the full technical specification that implements it, and as of this writing it’s still being finalized, with the industry broadly expecting it to land sometime in 2026.

The mechanism at the center of this is the Bound Profile Package, or BPP. A carrier’s profile server (called an SM-DP+ in this context) prepares a profile and binds it to one specific eUICC identity ahead of time. That BPP gets delivered to your production environment before a manufacturing run, and a component called the Factory Profile Assembler writes it onto the correct chip as the device comes off the line, at the last possible moment before it ships.

One point worth being precise about: SGP.41/42 is a sibling standard to SGP.32, not a part of it. SGP.32 defines how an eIM manages and swaps profiles on a device that’s already deployed. SGP.41/42 defines how a profile gets onto that device in the first place, at the factory. Same family of GSMA specs, two different moments in a device’s life.

Why it matters for IoT specifically

Consumer eSIM users activate their own profile with a QR code or an app. That doesn’t work for a smart meter or an asset tracker with no screen and no one standing next to it. IoT manufacturers have historically solved this by ordering pre-loaded eUICC stock: one SKU per destination market, forecast months ahead, held as inventory that can’t be reallocated if a shipment gets rerouted. Ship into five regions and you’re managing five SKUs and five forecasts for what is otherwise the same board.

IFPP removes that fork. One hardware build, personalized by market at the very end of your own production run, when you actually know where the unit is headed. That’s also different from what happens once a device is already in the field: Remote SIM Provisioning under SGP.32 is what lets a deployed device switch carriers later without a truck roll. IFPP just gets it connected correctly on day one.

What can go wrong

The most common mistake is treating SGP.41/42 as a newer version of SGP.32 that will eventually replace it. It won’t. A device provisioned in-factory still needs an SGP.32 eIM relationship for anything that happens after day one: a carrier changes coverage, a contract ends, a device gets redeployed to another region years into its life. Skip that planning and you’ve solved the shipping-day problem while leaving a gap for everything after.

The second mistake is building a production timeline around IFPP as though it’s shipping today. SGP.42 is still finalizing, and commercial tooling around it is still maturing. Teams chasing a single global SKU right now are generally getting there through flexible retrofit paths on the SGP.32 side, not by waiting on SGP.42.

The third is treating BPP delivery to the factory as a minor logistics detail. It requires a secure channel between the carrier’s profile server and your production environment, set up ahead of the run. That’s a real integration project.

What to do about it

Three steps worth taking now, regardless of where SGP.42 stands. First, ask your eUICC supplier where they stand on SGP.41 support and what their SGP.42 roadmap looks like, so you’re not caught flat-footed when it finalizes. Second, keep your IFPP planning and your SGP.32 eIM planning as two separate workstreams with a clear handoff, not one combined project. Third, if reducing SKUs is the near-term goal, look at what’s achievable today through SGP.32 retrofit approaches rather than waiting on a spec that isn’t finished.

IFPP and SGP.32 solve two different moments in a device’s connectivity story: getting it working on day one, and keeping it working for the years after. Worth understanding them as two connected standards rather than one evolving one. Learn more about how eIM fits into your fleet’s lifecycle once devices are in the field.

This article was curated by Jan Lattunen, CCO Simplex Wireless

About the Author: Jan Lattunen manages Sales and Marketing for Simplex Wireless. Jan has 20 years’ experience in working with SIM card technology and was involved in launching the eSIM in North America with major carriers and OEMs. His expertise in telecommunications is around SIM cards. On a personal note, Jan is a family man and avid cyclist with advocacy for safety in the roads. You can connect with Jan on https://linkedin.com/in/JanLattunen