eSIM Takes Off in the Airline Industry

16.05.2025
guide-image

In Conversation with Artur Michalczyk, Chief Technology Officer at emnify

Apple’s move to eSIM-only iPads* and iPhones isn’t just a hardware update. It’s a turning point in how companies manage connected devices. Many airlines deploy iPads for Electronic Flight Bag (EFB) and for administrators and airline IT teams, the eSIM marks a new chapter. With physical SIMs gone, so is the need for complex provisioning logistics and manual configurations. At emnify, CTO Artur Michalczyk has been working with airline customers to turn this shift into a strategic advantage.

We sat down with him to unpack what this change means in practice and why the move to eSIM-only iPads offers a rare opportunity to simplify, secure and scale device connectivity across global fleets.

A new era of zero-touch EFB deployment

“For years, managing EFB connectivity meant inefficient procurement processes to source SIMs which offered the required coverage and pricing, physically inserting SIMs and troubleshooting devices by hand,” says Michalczyk. With the latest generation of Apple iPads coming without a physical SIM slot, airlines are rethinking their connectivity workflows. For Michalczyk, this is not a disruption—but a catalyst for progress.

efb“This is a great opportunity. Without the need for a physical SIM, airlines can manage devices far more efficiently. They can roll out updates faster, control costs better and significantly improve security.” 

One airline already putting this into practice is Discover Airlines, Lufthansa Group’s quality leisure carrier. Discover turned to emnify to automate provisioning entirely through Mobile Device Management (MDM). By integrating emnify’s platform with their existing MDM, they now provision connectivity for iPads running EFB instantly over the air—no plastic SIMs, no QR codes and no messy manual work.

Managing connectivity at scale—instantly and securely

“Airlines shouldn’t be managing devices. They should be managing policies,” says Michalczyk. With emnify, you define connectivity rules—what apps and domains are allowed, how much data a device can use, which networks it can access—and apply them across thousands of devices. Updates take effect in seconds, fleet-wide, globally. 

This mirrors how MDM already works for app and system settings. And now, connectivity follows the same scalable model.

Why traditional operators fall short

Most mobile network operators (MNOs) and mobile virtual network operators (MVNOs) aren’t designed for airline use cases. Networks are typically optimized for terrestrial coverage, not the unique needs of a globally distributed and constantly moving fleet. While many operators offer multi-network roaming, devices are often steered to the preferred roaming partner in each country—meaning if coverage is poor in a specific location, the automatic fallback to a better network may take longer or not work altogether.

“That doesn’t suit aviation needs,” says Michalczyk. “If a network is weak or unavailable, the device should instantly connect to the next-best option—no delay, no downtime.” 
 
Roaming costs are another concern. Outside the EU, rates can spike quickly—and with hundreds of available networks, they’re hard to predict and can change frequently. “People forget how expensive roaming can be in places like the Middle East, Asia, or the Americas,” Michalczyk explains.

emnify addresses this with true multi-network connectivity in 190+ countries and consistent, predictable data plans tailored to airline-specific needs. Airlines can configure coverage preferences and adjust settings directly in the portal—keeping pilots connected and costs under control wherever operations take them.

Built-in protections against cost spikes and misuse

While iPads are consumer devices by design, in aviation they’re critical professional tools—and when deployed without restrictions, they can pose risks. A crew member could, for example, stream media or trigger a major iOS update while abroad, leading to unexpected costs and potential security concerns. 

“These devices can do a lot more than just access the systems they’re meant to,” says Michalczyk. “That’s why we built in DNS filtering and the ability to apply strict network rules.” This allows airlines to define exactly what the devices can connect to—flight planning tools, weather apps, backend systems—while blocking everything else. It eliminates unnecessary traffic, boosts security, and gives the airline full control over data usage. 

In Discover Airlines’ case, the ability to select which services can be accessed from the iPad running EFB was key. With predictable costs and granular controls, they finally gained visibility and peace of mind.

Finally: Full Control of EFB Connectivity

emnify gives airline IT teams what they’ve been missing—an automated, scalable and secure way to manage EFBs without manual provisioning or network blind spots.

Consumer eSIMs meet enterprise-grade control 

What makes this shift powerful isn’t just the form factor—it’s the integration potential. “With Consumer eSIMs, you can tie connectivity to a user profile, secure it with authentication, and push it to the device via MDM,” says Michalczyk.

emnify supports this with real-time usage monitoring, device-level policies and global compliance - all in one platform. This work was recently recognized at the MVNOs World Awards 2025, where emnify was named eSIM Provider of the Year for its role in advancing enterprise eSIM adoption.

The bottom line: simplify, secure, scale

Fo
r Michalczyk, this is about more than streamlining SIM logistics. “It’s a chance to modernize how airline IT teams manage connected devices—at scale, securely, and without compromise.” The shift to eSIM-only iPads may have forced a change, but with the right platform, that change unlocks speed, efficiency, and control.

“What used to take weeks now takes seconds,” he says. “And when you’re operating globally, that speed makes all the difference.”

*Apple first removed the physical SIM tray from iPads with the release of the iPad Pro 11-inch (4th generation) and 12.9-inch (6th generation) in late 2022—making these the first iPads to support eSIM-only connectivity. This change laid the groundwork for many airlines to rethink how they deploy and manage EFB devices at scale. 

Related Posts

Image for post What Is GSMA SGP.32? The Definitive Guide to the Next-Gen eSIM IoT Standard

What Is GSMA SGP.32? The Definitive Guide to the Next-Gen eSIM IoT Standard

Table of contents Introduction How does SGP.32 compare to SGP.02 and SGP.22? How SGP.32 Works: Key Components Explained IoT eSIM Architecture – SGP.32 Compliance & Standards: What You Need to Know Challenges & Implementation Considerations How emnify Supports SGP.32-Ready IoT Deployments Conclusion: Why SGP.32 Matters Introduction GSMA’s SGP.32 is the newest global SIM technology standard for IoT which finally makes remote profile management and profile switching a reality. It enables connected devices to securely download, manage, and switch SIM profiles over the air without requiring a user interface, QR codes, or physical SIM replacements. Unlike earlier GSMA standards designed for traditional machine-to-machine deployments, SGP.32 was defined specifically for modern IoT deployments, where physical SIM logistics and vendor lock-in have caused operational headaches for far too long. At its core, SGP.32 introduces a streamlined architecture that allows enterprises and connectivity providers to manage SIM profiles from any number of connectivity providers from one unified platform. At scale, this means, businesses are not locked into a single provider for their device’s full lifecycle and therefore are not burdened with costly SIM swaps when switching or adding new operators. Typical use cases for which this becomes extremely helpful to businesses deploying connected devices include: For manufacturers of connected devices (OEMs) that need devices to connect directly from the factory but don’t want the device to be locked to that specific network for their customers. Here SGP.32 enables that enables devices to be deployed with a bootstrap profile that gets the device online and SGP.32 enables any number of additional operator profiles to be added based on the device's deployment area. Providers of connected devices now have a built-in resiliency plan. In the past, if a business wanted to leave their connectivity provider it added complexity as it meant leaving their already deployed devices connected with their original operator (SIM swaps are too costly) and adding another provider for future deployments. This management of multiple operators added complexity and operational overheads. With GSP.32. For providers of connected devices, SGP.32 also integrates a level of resiliancy that wasn’t available before. The fact that it is now possible to have multiple profiles on a single SIM means that a true ‘fallback’ option is available. What this means in reality? If the primary profile fails, the device can simply be switched to the backup operator. Not only does this protect uptime, but it also protects operations from unexpected events such as, outages, the operator switching off coverage in your deployment zone or even if the operator goes out of business. How does SGP.32 compare to SGP.02 and SGP.22? SGP.02 SGP.02 was designed for traditional M2M deployments. In theory, it enabled remote profile to download and switching. In practice, however, the architecture was complex, costly to integrate, and not well suited to low-power or bandwidth-constrained IoT devices. For most deployments, large-scale remote profile swapping simply wasn’t commercially feasible. SGP.22 SGP.22 was built for consumer devices like smartphones and tablets. It assumes a user interface, QR code scanning, and user-driven profile downloads. That works perfectly for phones, but not for 'screenless’ devices. SGP.32 SGP.32 is the first standard designed specifically for IoT fleets. It removes the need for user interaction, supports constrained environments like NB-IoT and LTE-M, and enables fully server-orchestrated profile lifecycle management at scale. How SGP.32 Works: Key Components Explained eUICC (Embedded Universal Integrated Circuit Card) Although not new or specific to SGP.32, the eUICC is crucial to enable remote profile management. The eUICC is the secure chip inside the SIM that can store multiple operator profiles. SM-DP+ (Subscription Manager Data Preparation+) The SM-DP+ is the secure server where eSIM profiles are stored, prepared, and encrypted for download to devices. Each profile has a unique identifier called an activation code, which is what devices use to retrieve the profile. The QR code used in consumer eSIM downloads is simply a graphical representation of that activation code. SM-DS (Subscription Manager Discovery Server) The SM-DS is a discovery service that devices can query to check if new eSIM profiles are available. If a profile is ready, it tells the device which SM-DP+ server hosts it so the profile can be downloaded. While commonly used in consumer eSIM deployments, it is often optional in IoT architectures where the platform already orchestrates the profile download. EID (eUICC Identifier) The unique ID assigned to every eUICC. It’s how the SIM is securely identified during remote provisioning. eIM (eSIM IoT Manager) The control layer introduced with SGP.32. It lets you remotely download, enable, disable, delete, and switch profiles across devices and fleets. The eIM can be a standalone platform or part of a traditional CMP like it is for emnify. Connectivity Management Portal Not new but as the name implies this is where you manage connectivity such as, adding removing coverage zones and changing plans. It is in the CMP that the eIM can be integrated so that SGP.32 functionality such as, adding or removing profiles can be managed from the same interface. IPA (IoT Profile Assistant) The IoT-native replacement for the consumer LPA. It runs on the device and handles profile discovery and downloads without needing a screen or user input. Activation Code Are required to activate the SIM by inputting them into the CMP/eIM. Bootstrap Profile A minimal connectivity profile that gets the device online for the first time so it can download its operational profile. Operational Profile The main operator profile used during normal device operation. Multiple operational profiles can live on the same SIM. Fallback Profile A secondary operator profile stored on the same SIM that can be activated if the primary one fails, protecting uptime and continuity. Polling Interval Is the frequency a device tries to connect to the eIM to understand if there is a new profile. IoT eSIM Architecture – SGP.32 SGP.32 Remote Profile Management Flow Explained The device connects using its existing profile The device is already online, typically via a bootstrap or operational profile. A profile download is scheduled on the eIM An operator profile is registered on the eIM using its activation code, preparing it for download to the device. The device checks the eIM for pending operations At its polling interval, the device contacts the eIM and discovers that a new profile is available, including which SM-DP+ server hosts it and which activation code to use. The IPA prepares the device The IPA establishes the secure session required to download the profile. The profile is retrieved from the SM-DP+ The encrypted operator profile is securely delivered from the SM-DP+ to the device. The eUICC securely stores the new profile The profile is installed on the eUICC but not necessarily activated yet. Profile activation is scheduled on the eIM A user or automated process configures the new profile to be activated. The device activates the profile During the next polling cycle, the device learns about the activation instruction from the eIM and the IPA activates the profile on the eUICC. The device switches connectivity The device begins operating on the new operator profile without any physical SIM change. Compliance & Standards: What You Need to Know SGP.32 is not just a new orchestration model. It is a GSMA-defined standard built on strict security, interoperability, and transport requirements. These compliance elements are embedded directly into the specification and are critical for secure, large-scale IoT deployments. Security All profile lifecycle operations between the eIM and the eUICC are cryptographically authenticated and integrity-protected. This ensures profiles cannot be downloaded, modified, or switched without proper authorization. Transport Protocols SGP.32 supports standard TCP/IP communication as well as lightweight protocols such as CoAP over UDP with DTLS encryption. This allows it to operate efficiently across a wide range of IoT environments, including low-power and bandwidth-constrained networks like NB-IoT and LTE-M. Challenges & Implementation Considerations Evolving Ecosystem SGP.32 adoption is still in progress across vendors, platforms, and standards bodies. Interpretations and support may vary as the ecosystem matures. Platform Maturity Not all IoT platforms will initially provide full eIM functionality, IPA support, or large-scale orchestration tooling. The depth of implementation will differ between vendors. Open Ecosystem vs. Closed Implementations While SGP.32 technically enables multi-operator profile management, not every provider will support open third-party profile orchestration. Some implementations may limit profile management to their own network ecosystem. Enterprises evaluating SGP.32 solutions should carefully assess whether cross-operator flexibility is genuinely supported in practice, not just in theory. Backward Compatibility Migration from older standards such as SGP.02 or SGP.22 is not possible. How emnify Supports SGP.32-Ready IoT Deployments As SGP.32 moves from specification to real-world deployment, the key question is not just compliance. It is implementation. The standard enables multi-profile, multi-operator orchestration. But whether that flexibility is truly available in practice depends on the platform operating the eIM layer. emnify’s cloud-native architecture was built around centralized, API-driven profile lifecycle management. Through its integrated eIM capabilities, enterprises can download, enable, disable, and switch both emnify and third-party operator profiles across fleets from a single control plane. This approach aligns directly with the architectural intent of SGP.32: operator independence at the profile level, not just at the hardware level. Rather than binding deployments to a single network ecosystem, emnify enables organizations to design IoT architectures where connectivity can evolve over time, whether adding new operators, localizing in new regions, or introducing fallback profiles for resilience. In practice, this means SGP.32 is not just supported, it is operationalized in a way that preserves long-term flexibility. Check our unique SGP.32 offer, the emnify Advanced eSIM. Conclusion: Why SGP.32 Matters GSMA SGP.32 marks a structural shift in how IoT connectivity is designed and operated. It moves the industry beyond hardware-bound SIM logistics and toward software-driven profile orchestration built specifically for headless, large-scale device fleets. By enabling secure, server-orchestrated lifecycle management, SGP.32 allows enterprises to add, change, and manage operator profiles remotely without physical intervention. Devices can ship connected from the factory with a bootstrap profile, reducing the need for multiple regional SKUs and eliminating much of the traditional SIM logistics associated with global deployments. At the same time, SGP.32 introduces the possibility of true provider independence. Enterprises can localize connectivity as deployments expand into new regions, add new operators over time, and avoid being locked into a single connectivity provider for the lifetime of a device. It also strengthens operational resilience. With the ability to store and manage multiple profiles on a single eSIM, organizations can introduce fallback connectivity options that protect uptime and reduce the operational risk of network outages or coverage changes. For organizations building global IoT deployments, understanding SGP.32 is no longer optional. It is foundational to designing connectivity architectures that remain flexible, scalable, and commercially adaptable over the full device lifecycle.