EU Digital Markets Act: security implications of interoperability and sideloading

The Digital Markets Act (Regulation (EU) 2022/1925) opens designated operating systems, app stores, browsers and messaging services to third parties, and every one of those openings changes what security teams must manage on EU devices. The DMA is a competition law, not a security law, but Articles 6(4), 6(7) and 7 each contain a security carve-out that lets a gatekeeper take integrity and security measures only where they are strictly necessary, proportionate and duly justified. That means more of the protection that used to come from platform defaults now has to come from the organisation's own device, app and identity controls. This guide is for mobile, endpoint and identity teams and for app developers who serve EU users. It explains the obligations with security consequences and the controls that respond to them. For the DMA's sister law on online content and platform risk, see the Digital Services Act Security Obligations Guide.

Key takeaways

• Obligations apply per designated service. Gatekeepers must comply with Articles 5, 6 and 7 within six months of a core platform service being listed in a designation decision (Article 3(10)); the general application date was 2 May 2023.
• Sideloading is a legal right for EU users of designated operating systems. Article 6(4) requires gatekeepers to allow installation of third-party apps and app stores, with integrity measures permitted only if strictly necessary, proportionate and duly justified.
• Interoperability brings new trust boundaries. Article 6(7) gives third parties free, effective access to the same hardware and software features the gatekeeper's own services use, and Article 7 requires messaging interoperability that preserves the level of security, including end-to-end encryption where applicable.
• Organisations own the residual risk. On corporate and BYOD devices, the controls that matter are managed app distribution, install restrictions and identity-bound access, not platform defaults alone.
• Login choice is protected. Article 5(7) stops gatekeepers requiring the use of their own identification service, so federation and sign-in options for EU apps can be broader.

Who is covered

Article 2 lists ten core platform services, including operating systems, web browsers, number-independent interpersonal communications services, online intermediation services (which include app stores), virtual assistants and cloud computing. Article 3(2) presumes gatekeeper status where an undertaking has annual Union turnover of at least EUR 7.5 billion in each of the last three financial years or an average market capitalisation of at least EUR 75 billion, offers the service in at least three Member States, and the service has at least 45 million monthly active end users and 10,000 yearly active business users in the Union.

The Commission's gatekeeper page lists the security-relevant designated services below. Platforms are listed alphabetically by gatekeeper; order is not a ranking.

Most designations date from 6 September 2023; iPadOS was designated on 29 April 2024. Check the Commission's list for changes before relying on it.

The security carve-outs in the text

Article 8(1) puts the burden on the gatekeeper to demonstrate compliance, and Article 8(2) lets the Commission adopt implementing acts specifying the measures a gatekeeper must take under Articles 6 and 7. The Commission used that power on 19 March 2025 with two decisions on iOS interoperability: one specifying measures for nine connectivity features used by connected devices such as smartwatches, headphones and TVs (examples include notifications on smartwatches, peer-to-peer Wi-Fi, NFC and pairing), and one on the process developers use to request interoperability. The Commission stated the measures respect users' privacy and security and the integrity of the operating system.

Messaging interoperability timeline

The gatekeeper publishes a reference offer with technical details and terms (Article 7(4)) and must meet reasonable requests within three months (Article 7(5)). Article 7(6) allows the Commission to extend these time limits in some cases. See the End-to-End Encryption and Messaging Protocols Guide for the protocol side.

Threats the openings create

• Malicious apps from other sources: distribution outside the main store maps to MITRE ATT&CK for Mobile T1476 Deliver Malicious Application via Other Means. Social engineering ("install our app from this store") is the usual route. See the APK sideloading guide.
• Rogue or compromised alternative stores: a third-party store becomes a supply chain dependency with its own signing, review and update process.
• Over-privileged interoperable accessories: an accessory app that receives notifications or pairs automatically may see message previews, one-time codes and calendar data.
• Cross-client messaging data: once a message reaches a third-party client, retention, backups and logging follow that client's design, not the originating service's.
• Default drift: choice screens and easier uninstall change which browser and assistant handle corporate links and data unless managed.

Controls for organisations

Corporate-owned devices

1. Use managed app distribution: deliver work apps through your mobile device management (MDM) or unified endpoint management platform and block installs from unapproved sources where the platform's management settings allow. Confirm the current setting names in each platform's enterprise documentation, because they change as DMA features evolve. See the Mobile Device Management Security Guide.
2. Allow-list alternative stores deliberately: if a business need requires one, treat the store as a supplier: review its security documentation and add it to third-party risk records.
3. Manage defaults: push the approved browser and set link-handling policy so corporate links open in a managed browser. See the Browser Security Hardening Guide.
4. Govern accessories: restrict pairing and notification sharing for third-party wearables on high-risk roles, and hide notification previews for apps that carry codes or sensitive data.

BYOD and personal devices

• Protect the app, not the device: use app protection policies, managed work profiles or containers so corporate data stays inside managed apps regardless of where other apps came from. See the Android Enterprise Security Guide and the iOS and iPadOS Enterprise Security Guide.
• Gate access on device posture: conditional access that checks device state and app integrity before issuing tokens.
• Write it into policy: update the BYOD Policy Template with rules on alternative stores and messaging apps used for work.

Messaging

• Decide which channels are approved for work: interoperability does not change your records retention duties; approved channels should be ones you can retain and discover.
• Train staff on cross-client chats: a conversation with an external client app can carry different retention and backup behaviour.

Guidance for app developers

• Distribute through channels you control: publish an official list of where your app is available so users can spot impersonations.
• Use app attestation: verify that requests come from your genuine, unmodified app, whatever store it came from. See the Mobile App Attestation guide.
• Keep secrets off the device: sideloaded repackaged copies make embedded API keys easier to extract. See Secrets in mobile apps.
• Request only needed interoperability features: if you build an accessory app, ask for the narrowest feature set and document how you handle notification content.

Where identity fits

Three identity effects follow from the DMA. Article 5(7) protects the choice of identification service, so apps serving EU users can offer independent sign-in options; teams should apply the same assurance level to every option they accept. Sideloaded and repackaged apps raise the value of binding sessions to a genuine app instance through attestation and short-lived tokens rather than static API keys. And passkeys, which are bound to the relying party's domain, resist phishing from lookalike apps better than passwords and SMS codes. See the Passkey Rollout Guide.

Enforcement and compliance mechanics

These duties fall on gatekeepers only. Organisations that use the platforms have no DMA obligations, but they inherit the changed environment. Gatekeepers' public compliance report summaries under Article 11 are a useful source for the current security measures each one applies to third-party apps and interoperability.

Measuring progress

• Managed install coverage: share of corporate devices where installs from unapproved sources are blocked by policy.
• Unapproved app sources: count of devices reporting apps from unapproved stores, trending down.
• App protection coverage: share of BYOD users whose work data sits inside protected apps.
• Accessory exposure: high-risk users with third-party wearables receiving full notification previews.
• Token binding: share of mobile API traffic verified by app attestation.

Common failure patterns

• Assuming platform review still covers every app: apps from alternative stores follow that store's review process.
• Leaving install sources unmanaged on corporate devices: the right to install exists for users; the organisation sets policy for managed devices.
• Static API keys in mobile apps: repackaged copies distributed through other channels extract them easily.
• Ignoring notification content: one-time codes in previews reach any paired accessory app.
• Treating messaging interoperability as a retention change: retention and discovery duties stay with the organisation.

Framework mapping

Practitioner checklist

• List which of your EU device platforms and apps are designated core platform services.
• Block installs from unapproved sources on corporate devices where management settings allow.
• Assess any alternative app store as a supplier before allowing it.
• Apply app protection policies or work profiles on BYOD.
• Manage default browser and link handling for corporate data.
• Restrict notification previews and accessory pairing for high-risk roles.
• Approve messaging channels for work based on retention and discovery needs.
• For your own apps, publish official download sources and adopt app attestation.
• Remove static secrets from mobile app builds.
• Review gatekeepers' Article 11 compliance summaries each year for security measure changes.

Standards and references

• EUR-Lex: Regulation (EU) 2022/1925 (Digital Markets Act)
• European Commission: DMA gatekeepers
• European Commission: Guidance under the DMA on interoperability (19 March 2025)
• MITRE ATT&CK: T1476 Deliver Malicious Application via Other Means
• NIST: SP 800-53 Rev 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

This guide summarises Regulation (EU) 2022/1925 and is not legal advice. Related NHI Mgmt Group resources: Digital Services Act Security Obligations Guide · Mobile Device Security Guide · Mobile App Security Guide · APK sideloading