Most hardware OEMs lock in their carrier choice at the design stage – and spend the next decade paying for that decision. Over-the-air (OTA) profile switching changes that equation entirely, giving fleet operators the ability to change, update, and manage connectivity configurations across thousands of vehicles without touching a single device.

In this article

• What OTA profile switching actually means
• The architecture behind OTA profile management
• Why single-carrier SIMs are a liability in always-connected fleets
• Security considerations for remote configuration management
• What fleet operators should look for in an OTA platform
• Frequently asked questions
• Key takeaways

What OTA profile switching actually means

A telecom profile is the bundle of credentials, network settings, and operator parameters that tells a device which carrier to connect to and how. In a traditional deployment, that profile is physically baked into the SIM at the factory. Changing it means shipping new SIMs, coordinating logistics, and scheduling field service – all of which costs time and money at scale.

OTA profile switching replaces that physical process with a software-driven one. Using eSIM (eUICC) technology, a device can receive, store, and activate a completely new carrier profile over an existing cellular connection. No hardware change. No truck roll. No downtime window negotiated with a logistics team.

For always-connected vehicle fleets – whether commercial trucks, connected cars, light electric vehicles, or telematics hardware – this creates an operational capability that simply didn't exist with physical SIM infrastructure. A fleet operating across multiple countries can be migrated to a regional carrier profile overnight. A vehicle cohort experiencing coverage degradation in a specific corridor can be switched to a better-performing network without anyone leaving the office.

This is the difference between connectivity that's fixed at production and connectivity that's managed as a living configuration.

The architecture behind OTA profile management

Understanding how OTA profile switching works requires a look at the standards that make it possible. The GSMA defines two primary frameworks for eSIM in non-consumer contexts: SGP.02 (the M2M standard) and the newer SGP.32(the IoT eSIM standard, published in 2024).

The M2M model (SGP.02)

Under the M2M architecture, profile management is split between two server-side components. The SM-DP (Subscription Manager Data Preparation) prepares and stores encrypted carrier profiles, while the SM-SR (Subscription Manager Secure Routing) manages the secure channel between the SM-DP and the eUICC on the device. Profile operations – download, enable, disable, delete – are executed from the back end, following a server-initiated push model. This suits fleet deployments well, because the operator, not the end user, controls connectivity state. You can read a detailed breakdown of how eSIM technically works and the differences between M2M and consumer eSIM for deeper context.

The IoT eSIM model (SGP.32)

SGP.32 modernises the M2M approach by eliminating the SM-SR lock-in that made switching between infrastructure providers difficult in practice. It introduces two new components. The eIM (eSIM IoT Remote Manager) manages profile state operations and can initiate profile downloads from multiple SM-DP+ platforms – not just one pre-configured provider. The IPA (IoT Profile Assistant) acts as a proxy between the eIM and the eUICC, either resident on the device or embedded in the eUICC OS.

SGP.32 also removes the requirement for SMS as a transport mechanism – critical for constrained hardware – and supports multiple protocol options including HTTP/TCP/TLS for broadband connections and CoAP/UDP/DTLS for network-constrained devices. The practical result is that any SGP.32-compliant device can communicate with any compliant infrastructure without pre-negotiated integrations, which eliminates the vendor lock-in that has historically made profile switching more theoretical than operational. For a deeper technical walkthrough, the introduction to IoT eSIM standard SGP.31/32 covers the architecture in full, and 1oT's GSMA-compliant RSP implementation on AWSshows how this infrastructure operates at scale.

Why single-carrier SIMs are a liability in always-connected fleets

The connectivity requirements of a vehicle fleet are fundamentally different from a static IoT deployment. Devices move, cross borders, and operate in environments where network quality varies continuously. A SIM locked to a single carrier creates a single point of failure – and common connectivity failures in fleet telematics deployments follow predictable patterns that we see repeated across the industry.

Regional outages are the most immediate risk. When a carrier experiences a maintenance window or infrastructure failure, every device on that network goes dark simultaneously with no fallback and no graceful degradation. Coverage gaps in transit compound this: each network has geographic blind spots, and vehicles operating in fringe areas – rural corridors, cross-border routes – are exposed to silent data loss if the device cannot reselect a better network. When a telematics device goes dark, the downstream effects compound quickly: hours-of-service records become incomplete, fuel tax reporting gaps open regulatory exposure, and risk management teams lose the data they need at precisely the moment it matters most.

Network sunsets have already disrupted large telematics deployments globally. 2G and 3G shutdowns turned operational hardware into stranded assets, requiring expensive replacement cycles that OTA-capable fleets avoided entirely. Then there are roaming restrictions: many countries impose rules on how long a foreign SIM can operate in-country before being classified as permanently roaming and blocked. Switching to a local carrier profile via OTA resolves this – but only if the eSIM infrastructure supports it. The complexity of roaming restrictions across markets makes this a genuine operational concern, not a theoretical one.

Multi-network eSIM deployments address these risks by design. Devices can hold multiple carrier profiles and switch between them based on network conditions, pricing, or compliance requirements – all managed remotely through a connectivity platform. This is not just a coverage story; it's a redundancy and business continuity story.

One technical detail worth flagging for vehicle deployments: LTE-M is the correct radio technology for mobile assets. It supports cell handover, meaning devices can transition between base stations without dropping the data session. NB-IoT does not support handover and is unsuitable for anything moving at highway speeds – a point that sounds obvious but gets overlooked more often than it should during hardware selection.

Security considerations for remote configuration management

Remote profile management introduces an attack surface that needs careful design. The good news is that GSMA standards include security requirements that are non-negotiable for certified infrastructure.

Standards-based security foundations

The baseline is stronger than most OEMs assume. Mutual authentication means all profile operations between the eIM or SM-DP+ and the eUICC require cryptographic verification – neither side accepts instructions from an unverified counterpart. Profile packages are encrypted before transmission and can only be decrypted by the target eUICC, so interception in transit yields nothing usable. The entire trust chain is anchored by GSMA Certificate Issuer (CI) root certificates, and infrastructure providers must achieve GSMA SAS-SM site security certification to operate legitimately – this is a meaningful bar, not a checkbox.

Network-layer security for fleet configurations

Beyond profile management, the network configuration itself carries security implications. Private APNs are the standard approach for fleet telematics: they route device traffic directly into a private network without traversing the public internet, eliminating a significant attack surface. Adding a VPN layer provides an additional encryption tunnel for sensitive telemetry or diagnostic data. Understanding how private APNs, VPNs, and fixed IPs work together is particularly relevant for connected car deployments that carry both operational data and payment-adjacent transactions – and real-world APN and VPN deployment examples illustrate how these configurations are applied across different vehicle use cases.

IMEI locking – tying a SIM to the specific hardware it was provisioned for – prevents SIM extraction and reuse in unauthorized devices. When combined with anomaly detection in the connectivity management platform, this creates a layered security posture that catches misuse before it becomes a billing or compliance problem. A practical guide to keeping IoT devices and SIM cards secure covers these controls in detail.

The honest caveat: security in IoT is largely decided at hardware design time. A GSMA-certified eSIM architecture is a strong foundation, but it does not compensate for hardware that lacks secure boot or firmware update processes that use unencrypted channels. OTA capability improves the security posture of deployed fleets, but only within the constraints of the underlying hardware design.

What fleet operators should look for in an OTA platform

Not all connectivity platforms that claim OTA profile switching deliver it operationally. The capability exists on a spectrum – from basic profile download support to full lifecycle orchestration with real-time telemetry. Here is what actually matters for fleet deployments:

• Session-level visibility: You need to see what's happening at the individual device level in real time – not aggregated reports that arrive hours later. When a vehicle goes dark, you should know which network it last registered on, when the session dropped, and what the device reported before going offline. Orchestration without session-level telemetry is a dashboard costume, not operational control.
• Multi-profile storage and management: The platform should support storing multiple carrier profiles on each eUICC and switching between them programmatically – not requiring manual intervention per device.
• Automated profile switching triggers: Profile changes should be triggerable by rules – geographic region, network performance thresholds, data costs – not only manual commands from an operator dashboard.
• Granular user access control: Fleet operators run distributed teams. Finance, operations, and field technicians each need different levels of platform access. A platform that doesn't support role-based access control will create both security and operational risks as the organization scales.
• Production-to-deployment lifecycle support: OTA capability is most valuable when it spans the full device lifecycle – from testing and manufacturing through deployment and end-of-life. Platforms that treat connectivity as a binary on/off switch miss most of the operational value.
• GSMA compliance: Infrastructure providers operating SM-DP+ or eIM components should hold current GSMA SAS-SM certification. This is the baseline for trusting that profile operations are cryptographically secure, not a differentiating feature.

For fleet management specifically, 1oT's fleet connectivity platform and connected car solution are built around these requirements – including multi-network access across 190+ countries, eSIM profile orchestration, and real-time session monitoring through the 1oT Terminal. The IoT eSIM and M2M eSIM infrastructure options support SGP.32 and SGP.02 respectively, with provisioning capable of completing profile operations in under a second.

Frequently asked questions

What is the difference between a profile switch and a roaming switch?

A roaming switch changes which local network a device camps on within the same carrier subscription – governed by the SIM's preferred network list and the home operator's roaming agreements. A profile switch is more fundamental: it replaces the entire carrier subscription on the eUICC, changing the IMSI, authentication credentials, and network access rules. Profile switching is what enables you to move from one carrier to a completely different one, including switching to a local carrier profile to avoid permanent roaming restrictions.

Can OTA profile switching cause service interruption?

There is a brief interruption during profile activation – the device deregisters from the current network, activates the new profile, and re-registers. In well-implemented deployments, this takes seconds. The M2M fallback mechanism defined in SGP.02 automatically reverts to the previous profile if the new one fails to establish connectivity, which prevents devices from being stranded on a non-functional profile in their current location.

Does OTA profile switching require specific hardware?

Yes. The device must contain a GSMA-compliant eUICC and the cellular module must support BIP (Bearer Independent Protocol) for communication between the SIM and the network-side infrastructure. Not all IoT modules support BIP, which is why hardware validation before deployment matters. For SGP.32 deployments, the IPA component also needs to be supported – either in the device OS or the eUICC itself. This is one of the areas where getting a compatibility assessment early prevents expensive surprises later.

Key takeaways

• OTA profile switching is a software-defined alternative to physical SIM replacement, enabling carrier changes, regional optimization, and compliance management across entire fleets without physical access to devices.
• SGP.32 removes SM-SR lock-in, making it possible to work with multiple SM-DP+ providers without pre-negotiated integrations – a meaningful shift in how vendor flexibility works in practice.
• Single-carrier SIM dependencies are an operational risk, not just a commercial inconvenience. Regional outages, coverage gaps, roaming restrictions, and network sunsets all become hard failures without multi-network fallback capability.
• Security is built into the standards – mutual authentication, encrypted profile packages, and PKI-rooted certificates are baseline requirements for certified eSIM infrastructure – but hardware design and firmware update practices remain the OEM's responsibility.
• The value of OTA isn't just in the switch itself: it's in the operational visibility, automation, and lifecycle management that a capable connectivity platform wraps around it. Profile switching without session-level telemetry is a partial solution at best.

Ready to evaluate OTA profile management for your fleet deployment? Talk to the 1oT team about fleet connectivity to see how multi-network eSIM and platform-level orchestration work in practice.

‍