Modern mobile operating systems are designed with integrated security architectures that limit malicious access, carefully managing connections between hardware, software, and apps. The DMA’s hardware and software interoperability mandate, Article 6(7), requires designated “gatekeepers” to provide developers and businesses with free and effective interoperability with mobile hardware and software features, including those features controlled by the operating system.  

The second article in my short series identifies six key risks to the mobile ecosystem posed by the DMA Article 6(7) interoperability mandate. 

Key Risk: Expanded Attack Surface  

Interoperability mandates introduce new entry points that malicious actors can target, expanding the attack surface and increasing security risks. Importantly, these entry points were likely not considered when the operating system (OS) was developed, meaning that the security architecture does not take these new targets into account. 

The newly exposed interfaces increase the risk of direct memory access attacks, in which an attacker gains access to and directly manipulates the computer’s memory. Modern operating systems limit access to memory because these attacks can bypass almost any other security protections — direct memory access gives an attacker the keys to the kingdom. They can plant spyware, bypass permission limitations, change stored data, remove password requirements, extract encryption keys, escalate privileges, or install a system backdoor without interference. 

The Pegasus spyware is one example of the consequences of expanded attack surface; it uses OS-level access to reach cameras, microphones, and messages through hidden system interfaces that were not designed to be used by non-system apps. When the security layers protecting a device are exposed, even a small vulnerability can expose the entire phone. 

Key Risk: Data Integrity and Confidentiality 

There are also risks to data integrity and confidentiality without direct memory access. In submitting interoperability requests, developers can request access to broad types of data. Although not necessarily malicious, overly broad access to user data can risk user privacy and security. Additionally, access requests may be intentionally vague or broad to sidestep permissions for certain kinds of data, like notification content, Wi-Fi history, or message history. It is not yet clear whether the DMA will be interpreted as eliminating permissions for some of this sensitive content, or if there is an “equally effective” way to grant access to legitimate developers, but it is a growing concern surrounding initial requests for interoperability. Legitimate actors may ask for overbroad access, and malicious actors might abuse DMA mandates to harvest or misuse certain personal data by asking for interoperability and bypassing the permission architecture in place.  

Interoperability requests that replicate the overbroad permissions of past data-sharing systems risk repeating failures like Cambridge Analytica, where a seemingly harmless quiz app collected millions of users’ personal details through an open Application Programming Interface (API) and shared them without consent. 

Similar issues have occurred on Android, where malicious apps misused the accessibility service — intended to help people with disabilities — to read messages and capture passwords. Giving third parties wider access to data, even for good reasons, can quickly spiral into privacy abuse when oversight or limits are weak. 

Key Risk: System Instability and Degraded Performance 

In July 2024, CrowdStrike implemented an anti-virus update that crashed computers around the world. The CrowdStrike product had access to the kernel, deep in the operating system, and the misconfigured file impacted the operating system and memory access. Mobile phones emerged unscathed thanks to their secure architecture relative to PCs. 

Mobile operating systems rely on centralized control and vertical integration. They are not engineered for arbitrary third-party integrations. Disruptions to this architecture put the stability of the system at risk and could cause system crashes, degraded user experience, and delays in innovation.  

Consider, for example, Apple’s AirDrop or Google’s Nearby Share, both designed as seamless and secure file-sharing tools within trusted boundaries and with security controls. If Article 6(7) compels these services to interoperate with third-party file-sharing apps or hardware, without equivalent safeguards like malware scanning, robust encryption, and strict performance controls, the result could be a dramatic increase in system instability and security risks. 

Key Risk: New Supply Chain Vulnerability  

In 2019, foreign threat actors targeted the US federal government and private sector entities in a widespread campaign that became known as SolarWinds. To accomplish this unprecedented breach, the attackers executed a supply chain attack, infiltrating a third-party software vendor’s network and embedding malicious code to be shipped to the vendor’s customers without their knowledge.  

Supply chain attacks can have widespread impact across all types of downstream organizations and are difficult to detect. Mobile 

operating systems benefit from a multi-layered defense-in-depth strategy, which fortifies them against supply chain attacks. Unvetted components from third parties can compromise their integrity. When a third-party component is compromised, it becomes an attack vector.  

One-size-fits-all regulation undermines differentiated security models. In part one of this series, I outlined the high-level architecture that mobile OSs generally share, but further differences exist in their security models. Interoperability mandates that do not take differentiated security models into account can have even greater unintended consequences, making simplistic assumptions about how security controls are implemented and forcing new architectures into established computing systems. This is like a mandate that all doors have security guards in front of them, instead of allowing a guard, a security monitoring system, or a deadbolt to accomplish the same goal.   

Key Risk: Authentication and Authorization Weaknesses 

Mobile operating systems mitigate security risks through identity verification and access control, but third-party access at the operating-system level complicates this. While identity verification for apps is generally used to manage an account, authentication at the OS-level is the basis of a device’s trust model. Instead of logging into an app or service, hardware and operating system authentication establishes who can control the device itself. If this is bypassed or compromised, every app and all of the device’s data are vulnerable.  

Modern mobile operating systems increasingly rely on hardware-backed authentication mechanisms, such as Apple’s Secure Enclave or Android’s Trusted Execution Environment, because software-based security has not proven adequate. These modules provide tamper-resistant storage of cryptographic keys and enable device-level identity verification. Interoperability mandates that compel third-party access to operating systems or hardware features may bypass or dilute these protections by requiring tokens or credentials to be shared. This weakens the principle of least privilege — the idea that any user or program should have the least permissive access necessary to accomplish a task — and creates new opportunities for impersonation to apps or services.  

Key Risk: Technical Challenges  

Certain technical challenges arise from the tension between open access and secure design. Once systems become heterogeneous, the engineering complexity increases exponentially.  

Engineering secure interoperability across complex, vertically integrated operating systems introduces exponential complexity. Each additional integration layer — whether for translation, backward compatibility, or hardware abstraction — creates new code paths that must be tested, patched, and maintained. This complicates vulnerability management and increases the likelihood of regressions in performance or stability. Moreover, because third-party components may evolve independently, the task of maintaining a coherent security baseline becomes significantly harder for OS providers. Rigid compliance deadlines imposed without regard to this complexity risk forcing unstable implementations into the market. The DMA imposes interoperability in ways that outpace security governance capacity.  

DMA interoperability obligations also interact with the broader EU regulatory landscape. The Network and Information Security Directive (NIS2) imposes cybersecurity risk management and reporting obligations on operators of essential and important entities. The General Data Protection Regulation (GDPR) requires data minimization and strict safeguards for personal data processing. The Cyber Resilience Act (CRA) sets baseline security requirements for connected devices and software. Some requests for interoperability under the DMA already implicate multiple frameworks — for example, access to Wi-Fi history implicates data protection and cybersecurity equities. 

Under these parallel frameworks, gatekeepers may face conflicting obligations — for example, being required to allow access to sensitive data or APIs under the DMA while simultaneously being liable for breaches under NIS2 or GDPR. Coordinating the DMA with these regimes and providing clarity to gatekeepers about their obligations is essential to avoid undermining Europe’s broader cybersecurity and privacy protections. 

Considering these risks, how can gatekeepers and other tech companies move forward under the DMA? In part three of the Europe’s DMA series, I share a series of recommendations on how to make interoperability work without compromising security. 

Bandwidth is CEPA’s online journal dedicated to advancing transatlantic cooperation on tech policy. All opinions expressed on Bandwidth are those of the author alone and may not represent those of the institutions they represent or the Center for European Policy Analysis. CEPA maintains a strict intellectual independence policy across all its projects and publications.

The post Part 2: Opening Up — Europe’s DMA and the Risks of Interoperability appeared first on CEPA.