Security Versus Interoperability: Real Tension or False Dichotomy?

Technology companies are right that the potential for harm exists. But does this mean regulators should drop their antitrust efforts because of the grave security harm that Google and Apple argue will result? Not necessarily.

A small class of technology companies has consolidated power in Western markets, prompting a sustained wave of regulatory pushback in the European Union and the United States. Often, this regulatory pushback is in the form of interoperation mandates, which require companies to facilitate greater integration with third-party products. In the example of Apple, the mandates require Apple to make specific functionalities of their phones accessible to third-party developers, such as the hardware that enables tap-and-go payments. Some tech companies have responded to this regulation by pointing to concerns that the interoperation will pose a security risk to users.

It is true that interoperation, if not executed carefully, can create security and privacy risks. Companies have strong incentives to spotlight or even exaggerate these risks—especially when speaking to policymakers and a general public that often cannot directly evaluate the technical implications. At the same time, regulators see healthy competition as a paramount goal and are unlikely to curtail their efforts. Rather than break up companies altogether, some regulators prefer interoperation as a means to preserve the current form of companies while still giving third parties greater access to markets. However, the potential security concerns of this lighter touch approach should not be wholly discounted.

In a multidisciplinary collaboration between experts on antitrust and computer security, we have written a paper to clarify the security considerations and trade-offs involved in interoperation, aiming to help regulators identify and respond to genuine security challenges while preventing the misuse of the “security bogeyman.” Highlighting this distinction is critical to enable the security community and policymakers to make informed decisions about the risks (and benefits) of interoperation.

In our paper, we examine these security versus interoperability arguments via a systematic review of EU documents. We analyze in which contexts the security considerations are weightier and in which contexts they serve more as a pretext to preserve an economically advantageous status quo. We propose an analytical framework to clarify the patterns we observed in our analysis.

Horizontal and Vertical Interoperation

Dominance in technology markets comes in two flavors.

First, there is power derived simply from scale. This is the traditional version of a monopoly: a service so massive that it becomes the default. WhatsApp is a prime example in Europe; it holds a commanding market share because it is ubiquitous, making it difficult for users to avoid.

The second type is platform power. This is unique to platforms that both have scale and own the underlying infrastructure—such as operating systems (iOS, Android) and app stores. In these cases, the company doesn’t just run the biggest train line, it owns the tracks. If an app developer wants to reach a customer, they must run on the company’s rails, adhering to their rules and paying their fees. This structural control is far more potent than simple market scale because it allows the track owner the ability to block any train from using its infrastructure.

These different monopoly structures correspond to the type of interoperation that would be required to bring two products together. By interoperation, we mean allowing other developers access to aspects of the incumbent companies’ infrastructure that were not previously open to them. This is a broad concept: For contactless payments, it could mean device manufacturers allowing third-party access to tap-and-go hardware; in the messaging context, it could mean facilitating messaging between users across different platforms.

“Size monopolies”—those that simply run the biggest, busiest line—would require horizontal interoperation. This is about connecting two separate networks that sit side by side. Imagine building a junction that allows any train to cross over from the “blue line” to the “purple line” seamlessly. This is necessary when two similar products, such as WhatsApp and Signal, need to talk to each other. Interoperation should allow a message from either service to reach its destination.

In contrast, “platform monopolies”—those that own the tracks—would require vertical interoperation. Just as a train must be built to fit the specific gauge of the rails, a third-party app relies on compatibility with the operating system (OS) to function. Vertical interoperation ensures that the third-party train can run on the incumbent’s tracks without being derailed by any type of barrier. These barriers can include rules, such as those for app stores, and technical compatibility, such as allowing apps to access the near field communication functionality of a phone.

Framework

Our analysis of relevant EU antitrust cases reveals three patterns of security arguments that map closely to these horizontal and vertical monopoly structures.

Horizontal cases generally present a technical engineering challenge that needs to be addressed in order to facilitate secure interoperation. Because the goal is to bridge two independent systems, the security debate centers on technical harmonization: how to allow two systems to function together without breaking existing security guarantees, such as end-to-end encryption. The argument here is usually about the feasibility of a secure connection.

In contrast, vertical cases primarily involve a vetting challenge. Here, the incumbent company often holds the power to block third parties from potential users entirely. The security argument focuses on policy rather than technical feasibility: The platform claims it must retain the right to inspect and approve external actors to prevent malware or abuse.

We also observe hybrid cases that are vertical but involve both technical integration hurdles and policy adjustments. We outline these categories below; for a more in-depth discussion of the specific case studies, please see the full paper. These categories are not perfectly distinct in practice, but we find them a useful conceptual framework.

Engineering Concerns

Template of a security engineering concern (from a platform’s perspective):

1. Interoperating would require building a new technical mechanism or architecture for our system to interface with other systems.
2. Our system has existing technical security guarantees. Designing a new architecture to preserve these guarantees is an engineering task that is costly in time, effort, and coordination with others—and may require innovation, so success is not certain.
3. Therefore, interoperating secure systems is more costly than interoperating systems in general, and if we don’t get the engineering right, the security of billions of users could be undermined.

Companies rightly point out that building secure systems is a difficult engineering task. Retroactively adding interoperability requires that complex systems be retrofitted carefully to allow secure communication with third parties. For example, the evolution of rich communication service, a sophisticated protocol slowly replacing the insecure short message service (SMS) paradigm, demonstrates that while such a change is possible, it is undeniably difficult.

Security engineering can be particularly hard in federated settings, where multiple groups must collectively agree on a protocol. In a centralized system such as WhatsApp, an update to security features is decided by Meta alone; in a decentralized system, changes must be negotiated and enforced across the network.

Crucially, the current mandates for interoperation still allow incumbent companies to dictate security standards. This mitigates the coordination problem: because the incumbent company retains the authority to set the rules, avoiding the gridlock of pure committee-based governance. Thus, while the engineering tasks remain difficult, the incumbent’s ability to enforce its own high standards remains intact.

The clearest example of this engineering tension is regarding end-to-end-encrypted messaging, which we discuss in technical detail in the paper.

Vetting Concerns

Template of a security vetting concern (from a platform’s perspective): 

1. Interoperating would mean our users and systems interact with third parties and third-party software.
2. Third parties and third-party software may make different decisions about security than we do. We cannot guarantee that third-party software will adhere to the same standards as software that we have developed or examined carefully ourselves.
3. Therefore, allowing third-party software on our platform could undermine billions of users’ security.

Providing third-party software is a central part of many platforms’ business models (e.g., offering third-party apps to smartphone users). However, these products are not necessarily secure, and their flaws can undermine an entire platform’s safety.

Combating this is generally not a question of engineering, but of vetting. App stores exemplify this dynamic, where OS providers stipulate strict requirements—covering security, privacy, and safety—before allowing apps onto their app stores. In the cases where interoperation is mandated, technical interoperability generally already exists; there is no engineering barrier to third-party apps running on the OS. Instead, it is a question of platform policy. Because third-party products run on top of the platform, these are also classic examples of vertical interoperability.

We observe this vetting dynamic play out as a spectrum of policy choices, illustrated by the sharp contrast between personal computers and video game consoles. Personal computers have historically prioritized flexibility; while they may offer app stores, it is easy for users to download software from the internet, where vetting is minimal. This openness accepts a higher security risk because a general-purpose computer’s utility would be reduced for many users if its engineers restricted it to a narrow list of preapproved software.

Conversely, video game consoles are strictly controlled, a limitation users accept because the device has a specific, narrow purpose. Mobile app stores sit uneasily in the middle of these two extremes. Modern smartphones are powerful general-purpose computers, yet they are often policed with greater strictness. This comparison illustrates that the level of security vetting is not a technical inevitability, but a platform policy choice about how to balance security against functionality. 

Ultimately, security arguments in these vertical contexts can help reinforce a lucrative status quo. Because the platform acts as a strict gatekeeper, third-party developers face an existential choice whether to obey the incumbent company’s rules or lose access to the market entirely. This leverage allows the platform to enforce rules in the name of security—including fees and restrictions on external links—that many developers view as burdensome. Epic Games pulled its popular game Fortnite from both Apple’s and Google’s app stores because they found the fee requirements too onerous. Unlike technical engineering constraints, these security policies are more malleable and subject to the incumbent company’s discretion. Thus, the combination of structural market power and the unilateral authority to set security rules cements the company’s strong economic position over third-party developers.

Hybrid Concerns

Template of a hybrid concern (from a platform’s perspective):

1. Interoperating would mean allowing third parties to access functionality reserved for our company’s internal use.
2. Opening up those functionalities entails third parties interacting with security-sensitive parts of our OS. Designing a new system to secure such access is a costly engineering task that may require innovation.
3. Therefore, third-party access to these functionalities carries inherent security risk and could undermine the security of billions of users.

There are cases where there are both engineering challenges to interoperation as well as a need for careful vetting of services. We see this pattern when third-party developers want access to specific functionality, such as host card emulation, which enables a phone to mimic a credit or transit card, or peer-to-peer Wi-Fi, which is used in many applications, including Apple’s AirDrop. Before the antitrust mandates, these functionalities were limited to use by the incumbent company’s own services.

However, this greater access to functionality needs to be done carefully to preserve security. The mandates stipulate that the incumbent companies should allow access only in ways that preserve existing security and that the companies reserve the right to vet third parties that want to use these now-accessible functionalities.

The market structure here creates a unique friction. In standard vertical cases, third-party apps are economic complements; they add value to the phone, so while Apple or Google may want to squeeze them for fees, they are ultimately incentivized to support third-party apps. In hybrid cases, however, the third-party product is a direct substitute for the platform’s own service (e.g., a bank app competing with Apple Wallet, or a third-party smartwatch competing with the Apple Watch).

Because the platform is competing against its own tenant, the incentive shifts from extraction to self-preferencing. For example, Apple Pay had proprietary access to the functionalities needed for tap-and-go payments, meaning no third-party developer could make a competing app. The economic incentive is no longer just to tax the competitor, but to cut off the necessary avenues of interoperability entirely. In these scenarios, security arguments become a powerful tool to justify denying access to the hardware features that competitors need to create their products. The fact that these security arguments can be of either the policy or engineering form makes potential competitors particularly vulnerable.