Jan Lattunen at Simplex Wireless recently published a sharp technical breakdown of a problem every IoT developer knows intimately: you power-cycle a Quectel module with a roaming SIM and wait. Five minutes. Ten. Finally, registered, roaming, on 2G. Meanwhile, a native carrier test SIM connected in under ten seconds. His diagnosis is precise. Four root causes account for the majority of slow registration cases: stale PLMN caches from a previous session or location, automatic RAT selection that falls back to 2G because that network answered first, roaming steering latency where the carrier platform silently redirects traffic to preferred partners, and outdated modem firmware with documented registration handling issues on non-native SIMs. His fixes are equally practical: lock to LTE during development, clear the FPLMN list after any SIM swap, upgrade to current firmware releases. All real. All fixable at the AT command level. But here is what struck me. ## The common precondition All four failure modes share a common precondition: the device is discovering its network for the first time in the field. It shipped with a bootstrap profile. It powered on. And now it is scanning every frequency band, across every RAT, working through a preferred PLMN list, getting rejected by non-partner networks, caching those rejections, and retrying in decreasing signal order. That is not a bug. That is the architecture working exactly as designed. The modem is doing precisely what it was told to do: find a network, any network, that will accept the credentials it was given at manufacturing time. The 15-minute window is the cost of that search. In a lab, it is a productivity issue. In a production deployment, for an alarm system, an asset tracker, or a medical monitor, it is a field failure mode. ## The question underneath the question The real question is not how to make that 15-minute window shorter. It is why that window exists at all. In-Factory Profile Provisioning (IFPP) loads operational carrier profiles onto the eUICC at the personalization facility, before the chip ever reaches the OEM's production line. The device ships with working connectivity. First power-on is network attachment, not network discovery. No PLMN scan lottery. No 2G fallback. No roaming steering delay. No 15 minutes of silence while your field-deployed device figures out where it is. ## The trade-off worth naming This is not a free lunch. Bootstrap provisioning gives you a destination-agnostic production line, which is genuinely valuable. Every device is identical regardless of where it ships. The factory does not need to know whether a unit is going to Dallas or Düsseldorf. That simplicity has real manufacturing value. IFPP inverts the equation. You gain deterministic field behaviour because the operational profile matches the destination network. But you accept a new upstream requirement: the device's destination must be known at the point of eUICC personalization. That supply chain coordination is real work. It means the OEM's order management system, the eUICC vendor's personalization workflow, and the carrier's profile preparation pipeline must all be synchronised around a destination-aware provisioning process. The decision is not obvious. It is a genuine architectural trade-off between manufacturing-line simplicity and field-deployment predictability. But it is a trade-off that most enterprises are not even aware they are making, because the bootstrap approach has been the default for so long that it does not feel like a choice. It feels like the way things are done. ## Where this gets interesting: certification When the operational profile matches the target market, FCC, IC, and PTCRB type approval testing evaluates the device's actual production behaviour, not a bootstrap negotiation sequence that will never occur in the field. The test results are more representative and more likely to clear cleanly. That is not a free benefit of IFPP; it is a downstream consequence of choosing field predictability over manufacturing-line simplicity. ## Two articles, one connectivity stack Jan's article solves the problem you have today. IFPP solves the problem so your next deployment never has it. Read Jan's full breakdown at Simplex Wireless. For the deeper analysis of why bootstrap provisioning is not IFPP, and why the distinction costs enterprises at scale, read The Bootstrap Delusion on IoT Business News. --- *ENODA Ventures helps IoT companies navigate the architecture decisions that sit below the firmware line: SIM strategy, eUICC posture, carrier selection, and manufacturing provisioning workflows.* Read about Managed Connectivity Evolution →