---
schema: "eutechreg/dossier-markdown@1"
slug: "integrity-under-dma"
version: "1.0"
first_published: "2026-09-09T15:41:51.160Z"
last_updated: "2026-09-09T15:41:51.160Z"
---

# Integrity under the DMA: sources, interpretation and safeguards

How the DMA’s integrity safeguards interact with other legal duties, user protection and sensitive AI interfaces, centred on Apple and Google Android.

## Dossier metadata

- **First published:** 9 September 2026
- **Current version:** 1.0
- **Editor:** Mikołaj Barczentewicz
- **Jurisdiction:** European Union
- **Legal framework:** [Regulation (EU) 2022/1925, Articles 6(4), 6(7), 7 and 8](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng)
- **Key documents:** [Apple features decision](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf); [Apple process decision](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100204_2073.pdf); [Android final-measures extract](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf)
- **Index:** Apple (company); Google (company); DMA (law); Interoperability (issue)

<a id="scope"></a>

## The question and source coverage

Article 6(7) DMA requires access and effective interoperability and expressly permits strictly necessary, proportionate and duly justified measures to protect integrity. [1, Article 6(7)](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng) What protection does that framework allow or require when access exposes users to privacy and security risks, including through sensitive AI interfaces?

The Commission’s Apple decisions interpret integrity as unimpaired functioning of the operating system and relevant features, including their security controls, and use that interpretation to limit privacy and security restrictions on access. [3, paras 100–107](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) I examine whether that boundary follows from the DMA read in its statutory context and consistently with the Charter. My argument concerns both the interpretation of the interoperability obligation itself and the other legal duties preserved by Article 8(1). [21, PDF pp. 1–2 and 15–17](https://www.medialaws.eu/wp-content/uploads/2023/08/Interpreting-the-EU-Digital-Markets-Act-consistently-with-the-EU-Charters-rights-to-privacy-and-protection-of-personal-data11.pdf) [DMA–GDPR comments, section V and fn 31](https://laweconcenter.org/resources/icle-comments-on-the-interplay-between-dma-and-gdpr/)

The [statutory analysis](#statutory-reading) addresses interpretation and the limits of specification powers. The section on [integrity and other legal duties](#integrity-other-duties) examines how binding duties constrain implementation, including where they leave a choice of protective measures. The [access-arrangements comparison](#access-arrangements) and [practical applications](#practical-cases) assess the resulting protection under realistic conditions of use.

The July 2026 Android measures add substantial protections, including hotword isolation, access to protected execution environments, feature-specific confidentiality conditions and eligibility for five Restricted features. [5, paras 13(c), 15(e), 33(b)(3), 35(i), 44(e) and 120–138](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf) Their coverage and the certification opt-out matter to assessing adequacy. The published extract supplies operative measures but omits the full decision’s reasons. For the wider draft/final comparison, see [Google Android interoperability under Article 6(7) DMA](/dossiers/google-android-interoperability-dma/).

<a id="statutory-safeguards"></a>

## Statutory safeguards compared

Selected clauses in the adopted DMA. The comparison records the interests expressly named and the conditions governing safeguards; the statutory analysis examines their interpretation.

### 1. Which interests are expressly named in the safeguards?

**Article 6(4): applications and stores:** Integrity of the hardware or operating system; a separate subparagraph allows measures and non-default settings enabling end users to protect security.

**Article 6(7): feature interoperability:** Integrity of the operating system, virtual assistant, hardware or software features provided by the gatekeeper.

**Article 7: communications interoperability:** Paragraph 9 expressly names integrity, security and privacy of the gatekeeper’s services.

**Sources:** [1, Articles 6(4), 6(7) and 7(9)](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng)

### 2. What must the gatekeeper justify?

**Article 6(4): applications and stores:** Both safeguards require strict necessity, proportionality and due justification by the gatekeeper.

**Article 6(7): feature interoperability:** Strict necessity, proportionality and due justification by the gatekeeper.

**Article 7: communications interoperability:** Paragraph 9 also requires strict necessity, proportionality and due justification.

**Sources:** [1, Article 6(4), second and third subparagraphs; Article 6(7), second subparagraph; Article 7(9)](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng)

### 3. What form does protection take?

**Article 6(4): applications and stores:** Integrity measures; separately, measures and settings other than default settings enabling effective user protection.

**Article 6(7): feature interoperability:** Measures ensuring interoperability does not compromise the listed objects’ integrity. The safeguard itself does not expressly add user-security settings.

**Article 7: communications interoperability:** Measures ensuring that third-party interoperability does not endanger service integrity, security and privacy.

**Sources:** [1, Articles 6(4), 6(7) and 7(9)](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng)

### 4. How is choice addressed nearby?

**Article 6(4): applications and stores:** Installation, effective use, access outside the gatekeeper’s service, and assistance with changing defaults.

**Article 6(7): feature interoperability:** Access to the same features is the operative starting point; Recital 57 explains competitive services, innovation and user choice.

**Article 7: communications interoperability:** Paragraph 7 preserves the end user’s freedom to decide whether to use interoperable functionalities.

**Sources:** [1, Articles 6(4), 6(7), 7(7); Recital 57](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng)

### 5. What accompanies the justification?

**Article 6(4): applications and stores:** Recital 50 mentions necessary design options, while locating the discussion in application distribution.

**Article 6(7): feature interoperability:** Article 8(1) independently requires compliance with applicable law, including data protection and cybersecurity. The integrity exception’s scope does not itself determine the content of those duties.

**Article 7: communications interoperability:** Paragraph 3 preserves the gatekeeper’s level of security, including end-to-end encryption where applicable; paragraph 8 limits data collection/exchange and requires data-protection compliance.

**Sources:** [1, Recital 50; Articles 7(3), 7(8), 8(1)](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng)

### 6. What constrains the Commission’s specified measures?

**Article 6(4): applications and stores:** Article 8(2) authorises measures implementing Article 6(4), while Article 8(7) requires effective compliance and proportionality. The scope of that authority and the proportionality of its exercise are separate questions.

**Article 6(7): feature interoperability:** The same limits apply under Article 6(7). A requirement must implement the enacted obligation; rejecting a gatekeeper’s integrity justification establishes neither authority for the requirement nor its proportionality.

**Article 7: communications interoperability:** Article 8(2) also authorises specification under Article 7, subject to Article 8(7). These limits differ from the gatekeeper’s justification for its own safeguard under Article 7(9).

**Sources:** [1, Articles 6(4), 6(7), 7(9), 8(2) and 8(7)](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng)

<a id="statutory-reading"></a>

## Reading the statutory differences

### The operative safeguard clauses

Article 6(4), second subparagraph:

> The gatekeeper shall not be prevented from taking, to the extent that they are strictly necessary and proportionate, measures to ensure that third-party software applications or software application stores do not endanger the integrity of the hardware or operating system provided by the gatekeeper, provided that such measures are duly justified by the gatekeeper. [1, Article 6(4), second subparagraph](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng)

Its third subparagraph adds:

> Furthermore, the gatekeeper shall not be prevented from applying, to the extent that they are strictly necessary and proportionate, measures and settings other than default settings, enabling end users to effectively protect security in relation to third-party software applications or software application stores, provided that such measures and settings other than default settings are duly justified by the gatekeeper. [1, Article 6(4), third subparagraph](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng)

Article 6(7), second subparagraph:

> The gatekeeper shall not be prevented from taking strictly necessary and proportionate measures to ensure that interoperability does not compromise the integrity of the operating system, virtual assistant, hardware or software features provided by the gatekeeper, provided that such measures are duly justified by the gatekeeper. [1, Article 6(7), second subparagraph](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng)

Article 7(9):

> The gatekeeper shall not be prevented from taking measures to ensure that third-party providers of number-independent interpersonal communications services requesting interoperability do not endanger the integrity, security and privacy of its services, provided that such measures are strictly necessary and proportionate and are duly justified by the gatekeeper. [1, Article 7(9)](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng)

### Textual differences and the scope of integrity

The requirement of due justification appears in Article 6(7) and in both protective subparagraphs of Article 6(4). The textual asymmetry concerns the additional end-user-security ground and the form of the permitted measures, rather than the presence of a burden of justification. Article 7(9), in turn, expressly includes service security and privacy alongside integrity. [1, Articles 6(4), 6(7) and 7(9)](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng)

Article 6(7) names integrity without separately naming privacy or end-user security. The interpretive question is what follows from that drafting choice. The scope of integrity, the access obligation and their relationship with other provisions must be worked out together. Article 8(1) requires implementation consistent with applicable law, including data protection, cybersecurity, consumer protection and product safety. [1, Articles 6(7) and 8(1)](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng) In my [*Pandora* analysis](https://truthonthemarket.com/2026/04/14/opening-pandoras-interface-ai-assistants-and-the-dma/), I questioned a division that could give sensitive feature access a weaker protective framework than app distribution, particularly where integrity and security are functionally inseparable. [Pandora’s Interface, The Structural Gap Between Articles 6(4) and 6(7); Reading Article 6(7) in Light of Alphabet](https://truthonthemarket.com/2026/04/14/opening-pandoras-interface-ai-assistants-and-the-dma/)

### Recital 50 supplies the design-options formulation

Recital 50 says:

> The integrity of the hardware or the operating system should include any design options that need to be implemented and maintained in order for the hardware or the operating system to be protected against unauthorised access, by ensuring that security controls specified for the hardware or the operating system concerned cannot be compromised. [1, Recital 50](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng)

The recital addresses third-party applications and stores. The Commission applies its account of integrity to Article 6(7) in both Apple decisions. [3, para 101](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) [4, para 81](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100204_2073.pdf) I read its reference to included design options as supporting protection of functioning security controls. Treating those examples as an exhaustive definition requires a further argument: neither the word “include” nor the recital’s application-distribution setting establishes that every other privacy or security protection falls outside integrity.

### Charter-compatible interpretation

In my 2023 Charter paper, I argued that missing or inadequate safeguards may require interpreting the DMA beyond its literal wording and even contrary to the drafters’ intentions. The detailed example concerns Article 6(6), but the paper also identifies the inadequacy of reading Article 6(7) literally and in isolation. [21, PDF pp. 1–2, 9 and 15–17](https://www.medialaws.eu/wp-content/uploads/2023/08/Interpreting-the-EU-Digital-Markets-Act-consistently-with-the-EU-Charters-rights-to-privacy-and-protection-of-personal-data11.pdf) The underlying principle is stated in *Ligue des droits humains*: secondary EU legislation must, as far as possible, be interpreted consistently with primary law, with preference for a compatible reading where the wording permits more than one. [Ligue des droits humains, para 86](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62019CJ0817) In that case, the Court limited retention beyond an initial six-month period to personal data whose continued retention could be justified, rather than accepting indiscriminate retention for the five years stated in the PNR Directive. [Ligue des droits humains, paras 248–262](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62019CJ0817)

Applied to Article 6(7), that approach requires examining the privacy and data-protection interferences created by the mandated access and the safeguards needed to justify them. In my view, it leaves open both an interpretation of integrity that accommodates relevant privacy and security protections and a reading of the interoperability obligation that excludes access arrangements incompatible with the Charter. The objective of effective interoperability cannot determine those boundaries independently of the rights at stake. This argument needs to identify the interference, its justification and the protection required; it does not confer a general right on a gatekeeper to refuse competitors access. Where the limits of interpretation prevent a Charter-compatible reading, the issue becomes the provision’s validity. [21, PDF pp. 15–17](https://www.medialaws.eu/wp-content/uploads/2023/08/Interpreting-the-EU-Digital-Markets-Act-consistently-with-the-EU-Charters-rights-to-privacy-and-protection-of-personal-data11.pdf)

Article 8(1) addresses a related but distinct problem. As I argued in the paper, other legislation may leave some DMA-created risks to privacy and personal data unaddressed, and merely permitting a gatekeeper to adopt safeguards does not ensure that users’ rights will be protected. [21, PDF p. 17](https://www.medialaws.eu/wp-content/uploads/2023/08/Interpreting-the-EU-Digital-Markets-Act-consistently-with-the-EU-Charters-rights-to-privacy-and-protection-of-personal-data11.pdf) Compliance with the GDPR and other applicable duties therefore cannot substitute for assessing the interoperability obligation itself against the Charter. The [legal-duties analysis](#integrity-other-duties) examines what Article 8(1) additionally requires where those duties apply.

### Specification powers and proportionality

Article 8(2) empowers the Commission to specify measures implementing the obligations laid down in Articles 6 and 7. Article 8(7) requires those measures to achieve effective compliance and be proportionate in the circumstances of the gatekeeper and service. [1, Articles 8(2) and 8(7)](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng) The statutory authority for a particular requirement must be established before its proportionality can justify imposing it.

During the administrative procedure, Apple argued that an implementing act could not alter Article 6(7)’s normative content or introduce substantive obligations. The Commission replied that Article 8(2) permits measures within Article 6(7)’s scope to secure effective compliance and does not distinguish substantive from non-substantive measures. [3, paras 116–118](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) That reply leaves the central question to be answered for each disputed requirement: does it give effect to an obligation already contained in Article 6(7), properly interpreted, or supplement the legislation with an additional obligation? I would assess that question before weighing alternative designs, burdens and benefits. Calling a requirement a specification does not establish the necessary statutory authority.

For a measure within that authority, the Article 8(7) inquiry remains distinct from the gatekeeper’s justification for an integrity restriction under Article 6(7). The Commission must account for the proportionality of the access arrangement it specifies; rejecting the gatekeeper’s proposed safeguard does not itself establish that the arrangement provides adequate protection. [1, Articles 6(7) and 8(7)](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng)

Apple’s actions for annulment of the features decision (T-354/25) and process decision (T-359/25), brought on 30 May 2025, put these questions before the General Court. The first three pleas in each action allege incompatibility of Article 6(7) with the Charter and proportionality, an excess of the Commission’s implementing powers under Article 291 TFEU and Article 8(2) DMA, and misinterpretation and misapplication of Article 6(7). Apple also seeks to have Article 6(7) declared inapplicable under Article 277 TFEU. [Apple features action, form of order sought; pleas 1–3](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62025TN0354) [Apple process action, form of order sought; pleas 1–3](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62025TN0359) Both main proceedings were listed as pending in the Court’s case records on 11 September 2026. [T-354/25 status, case overview](https://curia.europa.eu/juris/liste.jsf?num=T-354/25&language=en) [T-359/25 status, case overview](https://curia.europa.eu/juris/liste.jsf?num=T-359/25&language=en)

### Exemption and anti-circumvention

Article 10 provides a distinct route for a Commission exemption from a specific obligation, on public-health or public-security grounds. It calls for a Commission decision and has its own procedural and balancing requirements. It should therefore be distinguished from a gatekeeper’s application of the integrity safeguard when implementing access. Article 13, in turn, prohibits undermining effective compliance and making the exercise of DMA choices unduly difficult, including through interface design. [1, Article 10(1)–(5); Article 13(3)–(6)](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng)

<a id="legislative-development"></a>

## Legislative development

Selected predecessor clauses, tracked despite renumbering. The comparison establishes what the texts say. It does not reconstruct confidential trilogue bargaining or establish why every drafting choice was made. The sequence places the Council’s November text before Parliament’s December amendments.

### 1. Commission proposal, 15 December 2020; Article 6(1)(c), (f); Recital 47

**Relevant wording or change:** Application distribution had a proportionate integrity safeguard. The then narrower ancillary-services interoperability clause contained no corresponding express safeguard. Recital 47 addressed necessary, justified measures and less restrictive alternatives.

**Significance for interpretation:** An integrity safeguard for feature interoperability must be tracked alongside the expansion of the underlying access obligation.

**Sources:** [2, Article 6(1)(c) and (f); Recital 47](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52020PC0842)

### 2. Council document 13801/21, 16 November 2021; Article 6(1)(c), (f)

**Relevant wording or change:** The ancillary-services clause added strictly necessary, proportionate and duly justified integrity measures. The application-distribution clause separately added measures enabling end users to protect security.

**Significance for interpretation:** A formulation distinguishing system integrity from end-user security was present before Parliament’s December position.

**Sources:** [8, Article 6(1)(c) and (f), printed pp. 71–72](https://data.consilium.europa.eu/doc/document/ST-13801-2021-INIT/en/pdf)

### 3. Parliament, 15 December 2021; Amendments 122 and 126

**Relevant wording or change:** Amendment 126 expanded feature access and permitted “indispensable measures” protecting integrity or preventing harm to “end-user data protection or cyber security”, with due justification. Amendment 122 also expanded the application-distribution safeguard to end-user data protection and cybersecurity.

**Significance for interpretation:** The broader grounds are express in Parliament’s proposed feature clause. They were a negotiating proposal, not an adopted entitlement.

**Sources:** [7, Amendments 122 and 126](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52021AP0499)

### 4. Council document 8722/22, 11 May 2022; Article 6(4), (7)

**Relevant wording or change:** The feature safeguard names integrity, including the virtual assistant, with strict necessity, proportionality and due justification. The separate application-distribution security safeguard is retained. Recital 50 contains the design-options passage.

**Significance for interpretation:** The broader Parliament formulation is absent from the feature safeguard in the compromise.

**Sources:** [9, Article 6(4) and (7), printed pp. 107–108; Recital 50](https://www.consilium.europa.eu/media/56086/st08722-xx22.pdf)

### 5. Regulation (EU) 2022/1925, 14 September 2022; Articles 6(4), 6(7), 7

**Relevant wording or change:** Article 6(7) retains an integrity justification. Article 6(4) separately addresses end-user security, and Article 7(9) expressly lists integrity, security and privacy.

**Significance for interpretation:** The enacted wording leaves the scope of integrity to interpretation in the context of Article 8(1) and the Charter. The drafting sequence does not settle that question.

**Sources:** [1, Articles 6(4), 6(7), 7(3), 7(8)–(9) and 8(1)](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng) [Ligue des droits humains, para 86](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62019CJ0817) [21, PDF pp. 15–17](https://www.medialaws.eu/wp-content/uploads/2023/08/Interpreting-the-EU-Digital-Markets-Act-consistently-with-the-EU-Charters-rights-to-privacy-and-protection-of-personal-data11.pdf)

<a id="commission-reading"></a>

## The Commission’s interpretation: selected quotations

### The legislative-history inference

The Apple features decision states:

> The records of the legislative process that led to the adoption of the Regulation (EU) 2022/1925 indicate that the legislator has considered but ultimately rejected the position that cyber security and end user data protection may serve as a justification. [3, para 103 and fn 95](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf)

Footnote 95 points to Parliament’s December 2021 position. [3, para 103 and fn 95](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) Amendment 126 expressly added end-user data protection and cybersecurity; that wording is absent from final Article 6(7). [7, Amendment 126](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52021AP0499) [1, Article 6(7)](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng) The Commission infers a deliberate exclusion of those justifications. I consider the drafting sequence insufficient to settle that inference: it does not establish whether the omission reflected a considered exclusion, an assumption that integrity or other provisions supplied protection, or incomplete and imperfect drafting. These are competing explanations to investigate, not findings about the negotiations. Even proof of a restrictive intention would leave the [Charter-compatible interpretation](#statutory-reading) to be addressed.

### Unimpaired functioning

The Commission gives this definition:

> A pertinent definition of integrity is the state of being unimpaired of such service or feature – that is, still functional and not damaged nor corrupted. [3, para 103](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf)

It then includes risks to correct functioning and to security controls preventing unauthorised access. Its reasoning combines the DMA’s wording and recitals, legislative development, the CRA, the platform-interoperability judgment in *Alphabet*, and *Microsoft*’s treatment of operating-system functionality. The CRA is one supporting source in that chain. [3, paras 101–104 and fns 92–98](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf)

### Authorisation and privacy controls

The decision says:

> User authorisation may in certain cases be sufficient to address an integrity concern. [3, para 104](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf)

“May in certain cases” matters: the sentence does not establish that consent eliminates every integrity risk. The GPS example separates a privacy permission from protection against manipulation of that permission. Footnote 99 calls the permission prompt a privacy measure; a measure preventing its manipulation protects integrity. [3, paras 104–106 and fns 97 and 99](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf)

This distinguishes a control’s purpose from maintaining its correct operation. An intact permission mechanism can nevertheless accompany misleading authorisation or harm to another person. The NFC example shows that the Commission can place such harm outside integrity even while assuming its existence for that part of the reasoning. [3, paras 578–581](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) The [user-choice analysis](#integrity-other-duties) and [practical applications](#practical-cases) assess the further question: whether the available safeguards preserve effective protection under realistic conditions of use.

### Competing security and privacy models

The Commission states:

> the concept of integrity in Regulation (EU) 2022/1925 does not allow gatekeepers to impose their own model of security and privacy on third-party services. [3, para 107](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf)

The surrounding text conditions competition between models on compliance with applicable legislation. The preceding discussion also recognises sectoral obligations, proportionality and Charter rights. [3, paras 105–107](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) A controller-selected safeguard may implement a binding duty even when the law leaves room for another effective design. The [legal-duties section](#integrity-other-duties) distinguishes that question from an entitlement to impose a preferred model. Rejecting the particular implementation requires assessing how the resulting arrangement meets the applicable duty.

### Evidence and the least restrictive suitable measure

The decision requires the gatekeeper to:

> demonstrate, in a verifiable way using data or other objective means, the existence and magnitude of the integrity risk. [3, para 109](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf)

Paragraph 109 also asks how the proposed measure addresses that risk and why it is necessary and proportionate, including its effect on interoperability. Paragraph 110 requires the least restrictive choice where several available measures are suitable. The wording permits objective means other than incident data. [3, paras 108–110](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) Threat modelling, testing and comparable-system evidence therefore merit assessment on their merits in a novel-risk case. Likewise, a permission prompt is a candidate alternative whose suitability must be demonstrated, including the burden it places on ordinary users; reducing friction does not alone establish adequate protection.

### Parity, verification and trust

The Commission’s parity rule states:

> an integrity measure cannot be considered strictly necessary and proportionate if it seeks to achieve a higher level of integrity than the one that Apple requires or accepts in relation to its own services or hardware. [3, para 111](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf)

The Commission also requires transparent, objective, precise, non-discriminatory conditions and independent verification. Paragraph 113 rejects reliance solely on whether Apple controls or trusts a third party. [3, paras 111–113](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) In my March 2025 analysis, I challenged the assumption that users’ trust in a particular provider could be dismissed when assessing equivalent protection. [Apple user-burden analysis, Apple section](https://truthonthemarket.com/2025/03/26/google-and-apple-determinations-show-how-little-users-matter-under-the-dma/) I would examine what that trust rests on: who can access the data, which code runs, what oversight is possible and what users must do to preserve protection. The [access-arrangements comparison](#access-arrangements) develops those differences. Equal treatment of comparable risks is compatible with different controls where the exposure differs; ownership alone establishes neither equivalence nor a justification for exclusion.

### Consistency over time

The decision requires that a condition or measure:

> genuinely reflects a concern to attain integrity in a consistent and systematic manner. [3, para 115](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf)

Paragraph 115 includes the gatekeeper’s treatment of comparable risks, enforcement and monitoring, and the effectiveness of the measure after adoption. This is a continuing suitability inquiry, not merely a requirement to produce an initial justification. [3, para 115](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf)

### Relationship between the two Apple decisions

The corresponding interpretive sequence appears at paragraphs 80–95 of the process decision and 100–115 of the features decision: statutory context (80–82 / 100–102), definition and controls (83–87 / 103–107), then evidence and constraints on protective measures (88–95 / 108–115). Paragraph references and footnote numbers should remain document-specific. The process decision applies this reasoning to handling interoperability requests; the features decision also applies it to specified technical capabilities. [4, paras 80–95](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100204_2073.pdf) [3, paras 100–115](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf)

<a id="integrity-other-duties"></a>

## Integrity and other legal duties

Even on a narrow interpretation of “integrity” under Article 6(7), interoperability must comply with the gatekeeper’s other legal duties. Article 8(1), third sentence, requires the implementation of DMA compliance measures to comply with applicable law, expressly including data protection, cybersecurity, consumer protection and product safety. [1, Article 8(1)](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng) This provides an additional route for assessing safeguards alongside the [Charter argument concerning Article 6(7) itself](#statutory-reading). The scope of the integrity exception cannot, by itself, determine the full scope of permissible or required safeguards.

### The Apple decisions and Article 8(1)

The Commission recognises this distinction in the Apple Process Decision. Paragraph 39 expressly applies Article 8(1) to measures implementing Article 6(7). Paragraph 40 nevertheless states that measures introduced in relation to interoperability solutions are limited to integrity measures. It then identifies protections available under Article 6(4) for third-party applications and safeguards available to app-store providers. [4, paras 39–40](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100204_2073.pdf) This presents a layered account: different legal provisions protect different interests and govern different activities. On that account, narrowing the integrity exception need not eliminate protection for privacy, security or safety.

The difficulty is establishing that the relevant layers cover the access arrangement in question. Article 6(4)’s application-level safeguards do not necessarily answer a risk arising through a service’s or device’s access to system features under Article 6(7). I developed this objection in my comments on the DMA–GDPR guidelines: the remainder of paragraph 40 discusses other DMA duties without explaining how Article 8(1) operates when discharging Article 6(7) itself. [DMA–GDPR comments, section V and fn 31](https://laweconcenter.org/resources/icle-comments-on-the-interplay-between-dma-and-gdpr/) Referring to other protections is an adequate answer only insofar as those protections are legally available and address the relevant risk.

One possible reconciliation is that paragraph 40 limits restrictions justified by the integrity exception while paragraph 39 independently preserves measures required by other legislation. That reading would allow the two paragraphs to operate together. It would, however, require an explanation of how a safeguard grounded in another legal duty may affect the interoperability solution.

### Binding duties and the choice of measures

Crucially, a legal duty need not prescribe a single technical measure to be binding. GDPR Articles 24 and 25 require controllers to implement appropriate technical and organisational measures, including protection by design and by default; Article 32 imposes a risk-sensitive security obligation on both controllers and processors. [GDPR, Articles 24–25 and 32](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng) These provisions leave room for decisions about implementation while making adequate protection mandatory. The fact that a controller selected a measure does not establish that it is merely an optional preference or part of a proprietary privacy model. The Commission cannot resolve the Article 8(1) question simply by observing that the GDPR does not name the particular safeguard.

This does not give a gatekeeper an unrestricted entitlement to preserve its chosen implementation. A measure may be unnecessary, discriminatory or replaceable by another suitable measure. But rejecting it requires assessing the duty it implements and whether the remaining arrangement still satisfies that duty. Where a less restrictive alternative is proposed, its adequacy must be assessed against the applicable data-protection or security standard, including the actual risks of the processing. Discretion over the means of compliance is not discretion over whether to comply.

The October 2025 draft joint DMA–GDPR guidelines provide some support for this reconciliation. Paragraphs 5–6 call for compatible application of the two instruments. [Draft joint guidelines, paras 5–6](https://www.edpb.europa.eu/system/files/2025-10/joint_com-edpb_gls_interplay_dma_gdpr_for_public_consultation_en.pdf) In their treatment of Article 6(4), paragraphs 88–89 preserve compliance with other applicable laws while requiring gatekeepers to select appropriate measures that interfere less with the DMA’s objectives. Crucially, that preference applies only where the alternatives remain effective in securing compliance with the other laws. [Draft joint guidelines, paras 88–89](https://www.edpb.europa.eu/system/files/2025-10/joint_com-edpb_gls_interplay_dma_gdpr_for_public_consultation_en.pdf) Paragraph 96 also recognises that network-encryption measures outside the integrity and end-user-security safeguards may nevertheless be required by the GDPR. [Draft joint guidelines, para 96](https://www.edpb.europa.eu/system/files/2025-10/joint_com-edpb_gls_interplay_dma_gdpr_for_public_consultation_en.pdf) The draft thus acknowledges an independent route for protection.

These passages do not expressly establish a hierarchy in which DMA objectives prevail over GDPR compliance. The more substantial question is whether the draft’s particular restrictions honour its stated commitment to effective application of both instruments. Requiring a gatekeeper to choose among effective means of meeting a legal duty differs from narrowing that duty because a protective measure would impede access. Likewise, Article 6(7)’s strict-necessity condition for integrity measures does not, without further justification, establish the test governing every obligation preserved by Article 8(1). The legal source and standard applicable to each proposed safeguard need to be identified.

### Responsibility for disclosure and recipient screening

The allocation of responsibility creates a related difficulty. A narrow reading of Article 8(1) concentrates on the gatekeeper’s own compliance, leaving independent recipients responsible for their subsequent processing. A broader reading, which I advanced in the comments, would require gatekeepers to use feasible technical and organisational safeguards against unlawful processing enabled by their implementation measures. [DMA–GDPR comments, section III.A](https://laweconcenter.org/resources/icle-comments-on-the-interplay-between-dma-and-gdpr/) The broader reading requires justification: a gatekeeper’s ability to reduce harm does not by itself establish a general supervisory responsibility. But the narrower reading also leaves work to do. Responsibility for the gatekeeper’s own disclosure may require consideration of the circumstances in which it releases data, even where another controller bears responsibility for subsequent use.

Paragraph 131 of the draft guidelines is particularly apposite. In the Article 6(9) portability context, it rejects gathering information about recipients’ GDPR compliance measures, relevant proceedings and past security breaches. Its explanation is that such information does not necessarily predict future compliance or security and is therefore not strictly necessary for the gatekeeper’s own responsibility. [Draft joint guidelines, para 131](https://www.edpb.europa.eu/system/files/2025-10/joint_com-edpb_gls_interplay_dma_gdpr_for_public_consultation_en.pdf) The first proposition does not establish that the information can never be materially relevant. A past breach may reveal little about present safeguards (although that would depend on the details of that past issue). However, documented, unresolved misconduct may present a different case. The question is whether the draft leaves sufficient room for a proportionate response to the latter while preventing screening from becoming a means of excluding competitors.

### User choice and the level of protection

Authentication establishes who is making a request and whether the required authorisation has been given. It does not establish that the user understands the consequences or can realistically manage the resulting risks. The draft requires authentication and verification of authorisation, provides granular controls, and permits or requires warnings in specified circumstances. [Draft joint guidelines, paras 113–124, 132–134 and 138](https://www.edpb.europa.eu/system/files/2025-10/joint_com-edpb_gls_interplay_dma_gdpr_for_public_consultation_en.pdf) The existence of those mechanisms does not demonstrate that shifting protective decisions onto users preserves their level of protection.

I have repeatedly challenged that assumption. In my 2023 Charter paper, I explained that users may authorise access with consequences they later find unacceptable even where information is accessible and intelligible. [21, PDF p. 8](https://www.medialaws.eu/wp-content/uploads/2023/08/Interpreting-the-EU-Digital-Markets-Act-consistently-with-the-EU-Charters-rights-to-privacy-and-protection-of-personal-data11.pdf) In [my December 2024 analysis of Apple and the DMA](https://eutechreg.com/p/apple-and-eu-dma-a-road-to-leave), I argued that even robust safeguards controlled by users could leave them worse off if maintaining their previous protection required unreasonable investments of time and knowledge. I returned to that argument after the March 2025 Apple decision. [Apple user-burden analysis, Apple section](https://truthonthemarket.com/2025/03/26/google-and-apple-determinations-show-how-little-users-matter-under-the-dma/) The relevant assessment concerns ordinary users, their habits and the effort reasonably expected of them. It cannot assume the vigilance or expertise of an unusually motivated user.

This matters when identifying less restrictive alternatives to preventive safeguards. A permission prompt, dashboard or revocation facility is not an adequate substitute merely because a sufficiently (and likely unusually) informed and motivated user could use it to avoid harm. Its effectiveness needs to be assessed under realistic conditions of use. Nor can subsequent revocation reliably undo disclosure to a recipient that has already copied the data. I developed that problem through the consent-phishing example in my DMA–GDPR comments. [DMA–GDPR comments, section II](https://laweconcenter.org/resources/icle-comments-on-the-interplay-between-dma-and-gdpr/) A properly authenticated request accompanied by credible evidence of harmful intended processing therefore remains a difficult case. Pointing to user authorisation does not resolve it.

### What the search-data comparison establishes

The Article 6(11) framework supplies a narrower comparison. The Commission accepts that independent recipient responsibility can coexist with preventive obligations imposed through the gatekeeper: the July 2026 search-data measures combine independent controllership with contractual restrictions, security controls and independent assurance. [Search final measures, paras 45–70](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100209_2712.pdf) This establishes the acceptance of that regulatory technique, not the adequacy of the particular safeguards. Their specific anonymisation duty and Article 8(2) basis also prevent automatic transplantation to Article 6(7).

The adequacy questions remain substantial. The final eligibility criteria purport to address direct and indirect third-country control, but their effectiveness depends on the scope and application of the criteria and the evidence available about control. [Search final measures, paras 3–8](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100209_2712.pdf) Separately, the technical pipeline can place a detected name entity on an allowlist if it appears in queries from more than 50 signed-in users. [Search final measures, paras 29–31](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100209_2712.pdf) A common name or name-and-surname combination is not thereby rendered anonymous: other terms in a query may identify the person concerned or reveal sensitive information about them. The final measures themselves envisage personal data about people other than the searching end user remaining in the dataset. [Search final measures, para 46(c)](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100209_2712.pdf) These are reasons to investigate the protections’ adequacy, rather than treating the specification as a successful model. My earlier critique of the proposed search-data measures raised related problems; its assessment of the April proposal must be distinguished from the later final requirements. [Search-data critique, The Technical Pipeline’s Four Big Problems; The Regime Is Built for Compliant Recipients](https://truthonthemarket.com/2026/05/27/the-european-commissions-search-data-trust-fall/)

### Android safeguards and the remaining inquiry

The later Android measures also qualify the practical concern. They permit isolation for hotword processing, provide access to protected execution environments for sensitive data, and permit specified confidentiality and user-control requirements for particular features. [5, paras 15(e), 33(b)(3), 35(i) and 44(e)](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf) These provisions demonstrate that the final framework accommodates protections beyond a bare demand for access. Their feature-dependent coverage, however, leaves the relationship between those protections, the integrity exception and Article 8(1) to be explained. Practical accommodation does not alone settle the underlying interpretation.

A defensible application should identify the threatened interest, the legal duty governing it, the actor responsible and the measures capable of satisfying that duty while providing effective interoperability. Gatekeepers should substantiate claimed requirements and assess less restrictive alternatives. The Commission’s specifications should likewise explain how their treatment of safeguards preserves compliance with other applicable law and the relevant Charter rights. Where a protective measure is rejected, the analysis should establish how the remaining arrangement meets those obligations, taking account of how users and recipients can realistically be expected to behave. The decisive issue is whether the resulting access arrangement can satisfy the DMA and the other duties that the DMA expressly preserves.

<a id="authorities"></a>

## Authorities behind the interpretation

### CRA: risk-based requirements and the limits of the analogy

The CRA’s essential cybersecurity requirements include, on the basis of the specified risk assessment and where applicable, the requirement to:

> protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user, and report on corruptions. [10, Annex I, Part I, point 2(f)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng)

This is Annex I, Part I, point 2(f). Its objects include data as well as commands, programs and configuration. The adjacent provisions separately address unauthorised access and confidentiality. It is a product cybersecurity requirement; it does not purport to define integrity for Article 6(7) DMA. [10, Annex I, Part I, points 1 and 2(d)–(f); Article 13(2)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng)

The Commission uses point 2(f) to support the link between integrity and unauthorised manipulation, and the possible relevance of user authorisation. [3, paras 103–104 and fns 93–97](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) That analogy supports treating the correct operation of security controls as an integrity interest. The CRA’s separate treatment of confidentiality and its risk framework do not establish that authorised but harmful disclosure falls outside every protective duty.

Article 13(2)–(3) requires a documented assessment informing design and implementation, with regard to intended purpose, reasonably foreseeable use, conditions of use and protected assets. [10, Article 13(2)–(3)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng) This illustrates why a framework can leave technical choices to the responsible undertaking while making adequate protection mandatory. It also supplies a useful comparator for assessing emerging risks through design analysis rather than waiting exclusively for incident statistics. Its product scope and application dates must be respected: the Article 13 and Annex I framework generally applies from 11 December 2027, subject to the Regulation’s transitional rules. Reporting and conformity-assessment provisions have earlier application dates. [10, Articles 69 and 71](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng) The Commission’s use of the CRA in the March 2025 decisions is an interpretive analogy, not proof that those later-applying product duties already governed the access arrangements.

### Alphabet: platform integrity or security under Article 102

In *Alphabet v AGCM*, paragraph 73 allows an objective justification where developing the relevant interoperability template would, in itself and in light of the app’s properties, compromise the integrity or security of the platform, or be technically impossible for other reasons. [11, para 73](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62023CJ0233) The Apple features decision invokes the platform as the protected object. [3, para 103, fn 92](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) The judgment itself names both integrity and security and concerns Article 102 TFEU. In my *Pandora* analysis, I drew on it to question an interpretation of Article 6(7) that separates integrity from security where the two are functionally inseparable. The relevance of that reasoning to the DMA needs to be argued from the particular access arrangement and statutory context. [Pandora’s Interface, Reading Article 6(7) in Light of Alphabet](https://truthonthemarket.com/2026/04/14/opening-pandoras-interface-ai-assistants-and-the-dma/)

Under the Article 102 test addressed by the judgment, the dominant undertaking must put forward its justification and supporting arguments and evidence. Once it does, the competition authority proposing to find abuse must demonstrate why those arguments and evidence cannot prevail. [11, paras 78–79](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62023CJ0233) I draw from that sequence the importance of examining the authority’s response to a substantiated risk. Article 6(7) expressly requires the gatekeeper to justify an integrity measure, but that burden does not answer whether the Commission has adequately assessed the evidence or its proposed alternatives. [1, Article 6(7)](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng)

### Microsoft: functionality in the tying remedy

The Commission cites *Microsoft*, paragraphs 1165 and 1220, by analogy. [3, para 104, fn 96](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) Those passages address removal of Windows Media Player and whether the resulting operating system remained functional. The Court relied on Windows XP Embedded, earlier separate distribution and the version supplied under the remedy; it also distinguished player files from the basic multimedia infrastructure. [12, paras 1165 and 1220](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62004TJ0201)

These passages support a factual inquiry into impairment of other system functions. Although the judgment also contains a major interoperability dispute, the cited passages concern tying. They do not announce a general rule that every privacy or security harm outside malfunction is irrelevant to interoperability regulation.

### Sports governance: constraining a market-access decision-maker

*Superleague* requires transparent, clear and precise substantive criteria, non-discrimination and effective review where an undertaking controls potential competitors’ access. It also requires transparent and non-discriminatory procedural rules, including time limits. [13, paras 135–136](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62021CJ0333) *ISU* similarly examines whether the authorisation discretion was linked to specific verifiable objectives and reviewable criteria. [14, paras 137–138](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62021CJ0124)

The Apple decisions use such authorities to support objective conditions and independent verification. [3, paras 111–113 and fns 103–109](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) The analogy concerns an access-controlling body with conflicting incentives. It supports transparent criteria and review of a refusal or restriction. It does not establish that identical technical controls are suitable for every architecture. A condition tied to a demonstrated difference in exposure can be assessed for necessity and proportionality, provided that the same criterion applies to the gatekeeper. The Android requirements of equal application and consistency in similar or comparable cases give that assessment a concrete starting point. [5, paras 115 and 117(a)–(c)](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf)

### Necessity: Scotch Whisky and Cassis

*Scotch Whisky*, paragraph 28, combines suitability, necessity and weighing against the relevant EU regulatory objectives. Paragraphs 53–54 require supporting evidence for the justification, while paragraph 55 rejects a demand to prove positively that no conceivable alternative could attain the objective under the same conditions. [15, paras 28 and 53–55](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62014CJ0333) Applied by analogy to a novel interface, that qualification favours assessment of concrete, sufficiently supported alternatives rather than an impossible demonstration that no hypothetical design could work. It does not dispense with evidence of the risk or the proposed measure’s suitability.

*Cassis*, paragraph 13, treats consumer information through labelling as a less restrictive alternative to a minimum alcohol-content rule. [16, para 13](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:61978CJ0120) The Commission uses it by analogy when discussing a permission prompt instead of a general computing-resource limit. [3, para 110, fn 102](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) The analogy requires more than the availability of information. A user must be able to understand the relevant consequence and act on it with reasonable effort. A complex permission governing continuing disclosure, or a risk to another person, may differ materially from the choice addressed by a product label. The [user-burden analysis](#integrity-other-duties) identifies why information and formal authorisation cannot by themselves establish the adequacy of the digital alternative.

### Primary law and rights-consistent interpretation

*Ligue des droits humains* states the general principle of interpreting secondary EU legislation consistently with primary law and illustrates its application to data-retention safeguards. [Ligue des droits humains, paras 86 and 248–262](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62019CJ0817) *Promusicae* addresses the balance between privacy and property/effective judicial protection in interpreting and implementing EU directives. Paragraph 68 requires an interpretation permitting a fair balance between the protected rights and avoiding conflict with fundamental rights or general principles such as proportionality. [22, paras 61–70, especially 68](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62006CJ0275) These authorities supply the method developed in the [statutory analysis](#statutory-reading): identify the interference with protected rights and examine how the interoperability obligation can be interpreted consistently with them. Neither an appeal to competition nor an assertion of a privacy risk supplies the necessary assessment on its own.

<a id="apple-android"></a>

## Apple and Android: protective measures

Selected Apple reasoning and operative requirements alongside Android’s final measures. The proceedings concern different features: the AI-specific Android entries therefore identify the relevant Apple legal framework, rather than imply equivalent technical requirements. Android’s published extract supplies measures but not the full decision’s reasons.

### 1. Integrity’s scope

**Apple decisions, March 2025:** The Commission interprets integrity as unimpaired functioning and protection of security controls, and excludes a general entitlement to impose Apple’s preferred privacy or security model. The process decision adopts parallel reasoning.

**Android final measures, July 2026:** Paragraph 114 permits strictly necessary, proportionate integrity measures. The extract does not reproduce the Apple decisions’ full definitional discussion.

**Sources:** [3, paras 103–107](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) [4, paras 83–87](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100204_2073.pdf) [5, para 114](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf)

### 2. Risk and efficacy

**Apple decisions, March 2025:** The Commission asks Apple to substantiate the specific concern through objective evidence and to demonstrate necessity and proportionality in Features paragraphs 108–110.

**Android final measures, July 2026:** Paragraph 117(c) requires objective and verifiable evidence of the risk’s existence and magnitude and effectiveness in reducing it; Alphabet must retain that evidence.

**Sources:** [3, paras 108–110](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) [5, para 117(c)](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf)

### 3. Standards, conditions and trust

**Apple decisions, March 2025:** The Commission rejects a higher integrity standard than Apple requires or accepts for itself and reliance solely on control or trust. It requires objective, precise, non-discriminatory and independently verifiable conditions; see also Features Annex paragraph 97.

**Android final measures, July 2026:** Paragraphs 115 and 117(a)–(b) require parity, independent verification and consistency with similar or comparable cases.

**Sources:** [3, paras 111–115; Annex para 97](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) [5, paras 115 and 117(a)–(b)](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf)

### 4. Purpose, technology and duration

**Apple decisions, March 2025:** The Commission’s reasoning calls for the least restrictive suitable option and consistent application. Features Annex paragraph 101(b) bars restrictions on application/device type or use case; paragraph 101(f) requires free access.

**Android final measures, July 2026:** Paragraph 117(d)–(h) restricts purpose/use-case limits, commercial requirements and unnecessary functional or technology requirements; express annex exceptions remain. Measures must last only as necessary and track technological evolution and established industry practice.

**Sources:** [3, paras 110–115; Annex para 101(b) and (f)](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) [5, para 117(d)–(h)](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf)

### 5. Notification of integrity measures

**Apple decisions, March 2025:** Features Annex paragraph 99 requires written notice and justification at least four weeks before implementation, or without undue delay in urgency. The same four cumulative exemption conditions shown for Android apply, including a documented impact determination.

**Android final measures, July 2026:** Paragraph 118 requires written notice and justification at least four weeks before implementation, or without undue delay in urgency. Exemption requires all four conditions: no user-facing effect; exclusively technical; precisely identical implementation for Alphabet and others; documented determination of no or only insignificant third-party impact.

**Sources:** [3, Annex para 99; decision paras 601–602](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) [5, para 118(a)–(d)](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf)

### 6. User authorisation

**Apple decisions, March 2025:** The Commission distinguishes permission from protection against manipulation, and applies consent reasoning to Wi-Fi data sharing.

**Android final measures, July 2026:** Paragraphs 112–113 permit consent prompts, access indicators or dashboards, and service-specific revocation, subject to equal treatment and effectiveness. Paragraph 135 separately provides informed per-service opt-out from certification, with permissible information screens and short delays.

**Sources:** [3, paras 104–107 and 428–430](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) [5, paras 112–113, 135 and 144–145](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf)

### 7. Hotword isolation

**Apple decisions, March 2025:** The selected Apple connectivity measures do not specify an AI hotword interface. Their general framework distinguishes protection of security controls from permission to use a feature; implementation must also respect applicable law.

**Android final measures, July 2026:** Paragraph 13(c) permits isolated second-stage validation. Paragraph 15(e) permits process isolation for detection and validation, with continuous audio access granted only afterwards. Paragraph 15(c) provides user control over participating apps. This is not unconditional access to pre-invocation audio.

**Sources:** [3, paras 104–107; Annex para 100](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) [5, paras 13(c)–(e) and 15(c)–(e)](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf)

### 8. Protected context and ambient processing

**Apple decisions, March 2025:** The Apple Process Decision recognises Article 8(1) and points to safeguards for other activities. Whether those routes cover a particular feature-access risk requires assessment; the cited passages do not prescribe the Android mechanisms described here.

**Android final measures, July 2026:** Paragraph 33(b)(3) requires access to protected execution environments for particularly sensitive data, as used by or available to Alphabet’s services. Paragraphs 35(i) and 44(e) permit isolation, encryption, anonymous and aggregated telemetry, and user control and awareness, on objective, precise, transparent and non-discriminatory terms also applying to Alphabet. Paragraph 35(f) permits equally applied app opt-outs.

**Sources:** [4, paras 39–40](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100204_2073.pdf) [5, paras 33(b)(3), 35(f), (h)–(i) and 44(e)](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf)

### 9. Other applicable law and eligibility

**Apple decisions, March 2025:** Article 8(1) applies to Article 6(7) implementation; Features Annex paragraph 100 requires compliance with applicable law. The decision considers a privacy prompt for Wi-Fi access outside integrity. The availability of app-level safeguards does not itself establish their adequacy for each feature-access risk.

**Android final measures, July 2026:** For five named Restricted features, paragraphs 120–138 establish eligibility and certification, including user intent, agent risks, privacy, safety, transparency, app security and developer conditions. The scheme includes an informed opt-out and a route for services that are not AI assistants.

**Sources:** [3, paras 105 and 428–431; Annex para 100](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) [5, paras 120–138](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf) [4, paras 39–40](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100204_2073.pdf)

<a id="access-arrangements"></a>

## Access arrangements and protective measures

The same protective measure may be adequate for one form of access and inadequate for another. This comparison separates four exposures and assesses candidate controls against the final Android measures. Technical examples are provider design claims.

### 1. Processing data an app already holds

**Exposure and candidate protection:** Disclosure to an inference provider and retention during processing raise confidentiality and lawful-use questions. An API can limit inputs and outputs while using isolated processing, verification of server software and constrained retention. My [analysis of trusted execution environments (TEEs)](https://eutechreg.com/p/trustworthy-privacy-for-ai-apples) develops this case. Possessing data technically does not establish a legal right to send it elsewhere.

**Legal route and final Android measures:** GDPR Articles 24–25 and 32 govern appropriate protection where applicable, alongside Article 8(1) DMA. Android paragraphs 80–86 concern access to system-level on-device models, with an exception for functionalities available only to internal OS components. They do not establish general access to every cloud inference service.

**Assessment and evidence still needed:** Compare the additional recipient, retained state and permitted outputs with the actual alternative. Apple’s Multi-Turn Agent describes encrypted cache reuse with client-supplied keys; Meta’s white paper disables persistent inference cache. Either design must be assessed within its stated boundary, rather than treating the word ‘stateless’ as a uniform guarantee.

**Sources:** [GDPR, Articles 24–25 and 32](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng) [1, Articles 6(7) and 8(1)](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng) [5, paras 80–86](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf) [Apple PCC architecture, Stateless computation and enforceable guarantees; Verifiable transparency](https://security.apple.com/blog/private-cloud-compute/) [Apple Multi-Turn Agent, KV cache reuse](https://security.apple.com/documentation/private-cloud-compute/multiturnagent) [Meta Private Processing white paper, pp. 12–15](https://ai.meta.com/static-resource/private-processing-technical-whitepaper)

### 2. Obtaining new cross-app context

**Exposure and candidate protection:** New data from other apps, notifications or device context becomes available to another service, including information about people other than the device user. Limit access to the task, control the recipient and permitted outputs, and use protected processing where suitable. Permissions and app-level choices can restrict exposure; their effectiveness depends on realistic use and the scope of the data disclosed.

**Legal route and final Android measures:** Article 8(1) preserves applicable data-protection duties. Android paragraphs 19–25 concern data apps choose to share on an opt-in role-based basis. Paragraphs 33(b)(3) and 35(i) address protected execution and confidentiality conditions for context-aware intelligence; 35(f) permits non-discriminatory app opt-outs. Both features are among the five Restricted features.

**Assessment and evidence still needed:** Processing existing app data and acquiring new context are different comparisons. Assess minimisation, permissions, recipient behaviour and data about others. Certification provides an additional route for the listed features, subject to the per-service opt-out; neither its existence nor a permission prompt establishes adequate protection.

**Sources:** [1, Articles 6(7) and 8(1)](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng) [GDPR, Articles 5, 24–25 and 32](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng) [5, paras 19–25, 33, 35(f) and (i), 120 and 135](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf)

### 3. Ambient or hotword access

**Exposure and candidate protection:** Continuous sensing can expose speech, surroundings or screen content beyond a deliberate request. Hotword detection and wider ambient access have different operative rules. Isolate pre-invocation hotword processing and limit audio extraction until detection and validation. For ambient access, assess isolation, encryption, constrained telemetry and user awareness together with the permitted outputs.

**Legal route and final Android measures:** Android paragraphs 13(c) and 15(e) accommodate hotword isolation. Paragraph 44(e) permits specified confidentiality and user-control conditions for ambient access, on terms also applying to Alphabet. Neither feature is independently named in paragraph 120’s restricted list; context-aware intelligence is. General consent and integrity provisions also apply.

**Assessment and evidence still needed:** The final text does not require unrestricted extraction of pre-invocation audio. The difficult questions concern false activation, onward disclosure, combined features and bystanders. Test the permitted controls against those exposures; do not assume universal certification coverage or infer effective protection from formal user authorisation.

**Sources:** [5, paras 13–17, 39–46, 112–120](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf) [1, Articles 6(7) and 8(1)](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng)

### 4. Third-party code and tool calls

**Exposure and candidate protection:** Code execution and external tools can change what runs in a protected environment, export information or take actions. Access to a model API differs from unrestricted execution within its host. Verify executable code and declared capabilities, constrain output channels and minimise tool disclosures. Apple’s Multi-Turn Agent validates tools against a registry. Meta describes a separate external web-search route with query limits, unlinking and user controls.

**Legal route and final Android measures:** Android paragraphs 33(b)(3) and 35(i) pair protected processing with safeguards. Paragraph 147 addresses runtime assets, including executable modules, under equal-effectiveness requirements; it does not specify arbitrary code execution inside every protected environment. Paragraph 125 permits agent-risk and user-intent conditions within the Restricted-feature scheme. Article 8(1) preserves other applicable duties.

**Assessment and evidence still needed:** Identify the requested execution privilege and every data exit before assessing equivalence. A TEE alone does not establish that code inside it will use data lawfully. Nor do registry checks or short external queries prove that harmful actions or disclosure are prevented. Compare concrete controls and feasible alternatives, including the effect on interoperability.

**Sources:** [Apple Multi-Turn Agent, Sub-turn handling](https://security.apple.com/documentation/private-cloud-compute/multiturnagent) [Meta Private Processing white paper, p. 38](https://ai.meta.com/static-resource/private-processing-technical-whitepaper) [5, paras 33(b)(3), 35(i), 117(d) and (f), 120, 125 and 147; fn 5](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf) [1, Articles 6(7), 8(1) and 8(7)](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng)

<a id="practical-cases"></a>

## Applying the safeguards

### Protected processing and the scope of access

In [my June 2025 analysis of Apple’s and Meta’s trusted execution environments](https://eutechreg.com/p/trustworthy-privacy-for-ai-apples), I distinguished processing information an app already holds from giving it new access to data across the device. Protected inference can reduce the additional exposure involved in the first arrangement. The second also requires an account of which data becomes available, to whom and for what purpose. Technical possession alone establishes neither a lawful basis for further processing nor the adequacy of its safeguards.

My April 2026 *Pandora* article applied that distinction to sensitive AI interfaces and argued for access through protective architecture. [Pandora’s Interface, AI Interoperability and the Privacy Blind Spot](https://truthonthemarket.com/2026/04/14/opening-pandoras-interface-ai-assistants-and-the-dma/) The final Android measures provide concrete support for that approach: paragraph 33(b)(3) requires access to protected execution environments for particularly sensitive data, as used by or available to Alphabet’s services, while paragraph 35(i) permits specified confidentiality conditions. [5, paras 33(b)(3) and 35(i)](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf) Those provisions qualify the earlier concern that interoperability would require bypassing protection. They leave the suitability and coverage of the particular arrangements to be assessed.

The technical comparison must also account for subsequent documentation. Apple’s introductory account of Private Cloud Compute (PCC) describes attested software, constraints on executable code and the exclusion of privileged runtime access. [Apple PCC architecture, Stateless computation and enforceable guarantees; No privileged runtime access; Verifiable transparency](https://security.apple.com/blog/private-cloud-compute/) Its Multi-Turn Agent documentation describes reuse of encrypted cache state, with the client supplying the keys for each turn and PCC retaining no cache-decryption keys between turns. [Apple Multi-Turn Agent, KV cache reuse](https://security.apple.com/documentation/private-cloud-compute/multiturnagent) Meta’s March 2026 white paper instead describes client-supplied conversation history and disabled persistent inference cache. [Meta Private Processing white paper, p. 15](https://ai.meta.com/static-resource/private-processing-technical-whitepaper) The relevant assessment concerns retained information and who can access it, rather than a uniform meaning of “stateless”.

Tool use exposes a further boundary. Apple’s Multi-Turn Agent validates client-declared tools against a registry and rejects unknown capabilities. [Apple Multi-Turn Agent, Sub-turn handling](https://security.apple.com/documentation/private-cloud-compute/multiturnagent) Meta’s white paper describes optional web search: short queries derived from the prompt and context leave the protected environment for Meta infrastructure and search providers. It specifies unlinking, a 100-character query limit, up to five queries per user prompt, transparency and an off switch. [Meta Private Processing white paper, p. 38](https://ai.meta.com/static-resource/private-processing-technical-whitepaper) These controls identify a bounded disclosure route; their existence does not establish that a sensitive query cannot identify someone or disclose information about them. The [access-arrangements comparison](#access-arrangements) therefore separates use of a model API, new data access, executable code and external outputs.

### Confidentiality and provider monitoring

In [my Incognito Chat analysis](https://eutechreg.com/p/meta-ais-incognito-chat-a-new-bar), I defended designs that constrain the provider’s ability to inspect conversations, including when that complicates monitoring. Meta’s announcement connects Incognito Chat to Private Processing. [Meta Incognito announcement, product description](https://about.fb.com/news/2026/05/incognito-chat-whatsapp-meta-ai/) A hypothetical requirement to send flagged conversations to a human-review queue would create an additional disclosure route. That would need to be assessed against confidentiality obligations; describing the route as a safety measure would not establish its necessity or the adequacy of its safeguards. Conversely, confidentiality alone would not establish that an assistant’s actions or outputs are safe.

Verification matters to comparing such models. Apple has released a virtual research environment and selected source components. [Apple PCC research release, Virtual Research Environment; Private Cloud Compute source code](https://security.apple.com/blog/pcc-security-research/) Meta’s white paper describes access to auditable artifacts for eligible researchers while keeping models and system prompts private. [Meta Private Processing white paper, p. 16](https://ai.meta.com/static-resource/private-processing-technical-whitepaper) These are useful mechanisms with different coverage. They do not make either platform’s deployed guarantees independently established here. A parity assessment should compare the relevant exposure and verifiable controls, including permitted outputs, rather than assume that more provider visibility always means more protection.

### Wi-Fi information: authorisation and effective protection

In the automatic Wi-Fi connection discussion, the Commission says Apple had not shown impairment of iOS or the feature. It characterises access to potentially sensitive data as a privacy concern, recognises GDPR and fundamental-rights requirements, and considers consent a less restrictive response irrespective of whether the concern is an integrity risk. [3, paras 425–429](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf)

Its comparison is a one-time prompt rather than a prompt for every network, with equivalent standards for Apple’s own connected devices. It also compares access already given to photos and contacts and rejects reliance on Apple Account access as a trust condition controlled by Apple. [3, paras 429–431](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) These propositions identify possible alternatives. They do not establish that the scope of information, recipients, retention and onward use creates equivalent risks.

The assessment should ask what an ordinary user can understand and control when agreeing once to future sharing. A prompt that identifies the recipient but leaves the extent of future disclosure difficult to foresee may remove friction while transferring a substantial protective burden to the user. My consent-phishing analysis explains why authentic authorisation can coexist with deceptive solicitation and why revocation cannot reliably recover data already copied. [DMA–GDPR comments, section II](https://laweconcenter.org/resources/icle-comments-on-the-interplay-between-dma-and-gdpr/) Information about other people raises an additional problem: their interests are not exhausted by the device user’s choice. The question is whether the resulting processing remains adequately protected under the applicable duties, including protection by design and by default. [GDPR, Articles 24–25 and 32](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng)

In [my December 2024 Apple analysis](https://eutechreg.com/p/apple-and-eu-dma-a-road-to-leave), I proposed granular permissions and constraints applying to Apple’s own services too, while questioning the burden of maintaining protection through user choices. Those proposals require provision-specific treatment. Article 6(4)'s end-user-security safeguard expressly excludes default settings, whereas GDPR Article 25(2) requires data protection by default. [1, Article 6(4), third subparagraph](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng) [GDPR, Article 25(2)](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng) Their interaction cannot be settled by treating every protective default as either automatically permitted or automatically excluded. The legal basis, processing and practical effect of the particular setting matter.

### NFC card skimming: evidence, definition and the remaining risk

The Commission answers Apple’s card-skimming concern in three ways. First, it finds the risk insufficiently substantiated, including the lack of explanation of Apple’s treatment of the risk in its own services. Second, even assuming the risk exists, it places use of an iOS device to harm nearby card holders outside integrity because the use need not impair iOS or the feature. Third, it regards the risk as remote and points to possible security benefits from third-party payment tools. [3, paras 576–581](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) Its second response is categorical:

> it concerns a risk that an iOS device could be used as a tool to harm others (e.g. bank card holders in very close proximity). [3, para 580](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf)

An inadequately substantiated risk can justify rejecting the proposed restriction without establishing that the threatened interest is legally irrelevant. Conversely, placing the harm outside integrity does not establish that the remaining access arrangement satisfies the duties preserved by Article 8(1). If a material risk were substantiated, the assessment would need to identify the applicable duty, responsible actor and available mitigation, and address the proportionality of the Commission’s measures under Article 8(7). [1, Articles 8(1) and 8(7)](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng) This inquiry must include the Commission’s assessment of remoteness and countervailing benefits, rather than treat every conceivable misuse as sufficient to prevent access.

The published record contains redactions and accounts of third-party submissions. It does not support an independent estimate here of skimming incidence or the net effect of access on fraud. [3, paras 579–581 and fns 617–620](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) The conclusion is correspondingly limited: the evidential objection, the boundary of integrity and the adequacy of the resulting safeguards require distinct answers.

### Android assistants: coverage of the protective routes

The final Android text combines protections at different levels. Hotword provisions permit isolated detection and validation before continuous audio access. [5, paras 13(c)–(e) and 15(c)–(e)](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf) Context-aware intelligence and ambient access permit specified isolation, encryption, telemetry and user-control conditions, also applying to Alphabet. [5, paras 35(i) and 44(e)](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf) General provisions permit consent, indicators, dashboards and revocation, subject to equal treatment and effectiveness. [5, paras 112–113](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf) This materially qualifies the prospective criticism in my *Pandora* article.

Eligibility is an additional, narrower mechanism. Five Restricted features are listed: centralised access to apps' on-device data, context-aware intelligence, structured on-device integration, screen automation and system integration. The Commission may expand the list following a reasoned request showing good cause. [5, paras 120–122](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf) Hotword detection and ambient access are not separately listed under those names. Their feature-specific safeguards therefore matter independently of certification; combinations using context-aware intelligence may engage the restricted scheme.

Within that scheme, conditions can address user intent, reconfirmation before sensitive irreversible actions, agent and model risks, privacy, safety, transparency, app security and developer processes. Feature-specific conditions must be strictly necessary and proportionate. [5, paras 125–126](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf) Certification and appeal procedures constrain the exercise of access control; temporary suspension requires a consistent body of evidence of practices capable of causing severe and immediate user harm, with communication and reinstatement duties. [5, paras 127–134](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf)

**Certification is not an invariable prerequisite.** Paragraph 135 requires informed, per-service opt-out for the device; information screens and short delays are permitted, but developer mode cannot be required. Paragraph 137 provides the route for qualified services that are not AI assistants, with proportionate conditions and the same procedures. [5, paras 135 and 137](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf) The certification opt-out does not, by its wording, waive all feature-specific safeguards or other applicable law. Its practical effect nevertheless depends on what the remaining controls achieve and how users encounter the choice.

The final text thus accommodates substantial protection while leaving questions about combinations of features, protective coverage and effective use. Programme terms and certification applications have future milestones in 2027; the extract supplies no evidence of their performance. [5, paras 136 and 138](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf) The appropriate next evidence is the concrete implementation and its testing against the relevant exposures, rather than an inference that either the Commission’s narrow reading of integrity or the existence of certification settles the outcome.

<a id="research-questions"></a>

## Assessment and remaining questions

### The scope of protection requires a Charter-compatible reading

My assessment is that the Commission’s exclusion of broader privacy and security justifications remains insufficiently established by its reading of integrity. The drafting sequence is relevant, but neither an omission nor an inferred restrictive intention resolves the meaning of Article 6(7) in the light of primary law. The [statutory analysis](#statutory-reading) develops the alternative: interpret the access obligation and its safeguard together, in the light of the interference with users’ rights and the protection required to justify it. [Ligue des droits humains, para 86](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62019CJ0817) [21, PDF pp. 15–17](https://www.medialaws.eu/wp-content/uploads/2023/08/Interpreting-the-EU-Digital-Markets-Act-consistently-with-the-EU-Charters-rights-to-privacy-and-protection-of-personal-data11.pdf)

The Commission’s reliance on protections elsewhere in the legal framework must be tested against the access arrangement: which duty applies, who bears it and whether it covers the threatened interest. [4, paras 39–40](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100204_2073.pdf) My [legal-duties analysis](#integrity-other-duties) explains why a choice of implementation does not make a duty optional. The separate Charter inquiry remains necessary where those duties leave a gap.

### Authorisation is one component of protection

The Commission recognises that user authorisation may address an integrity concern in some cases. [3, para 104](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) Its contribution depends on the risk. Genuine informed choice, deceptive solicitation, compromised controls and harm to another person are different cases. A control can function as designed while enabling harmful disclosure. Information and revocation mechanisms must therefore be assessed against what ordinary users can reasonably understand and manage, including the consequences of data already copied by a recipient. [DMA–GDPR comments, section II](https://laweconcenter.org/resources/icle-comments-on-the-interplay-between-dma-and-gdpr/)

The Android measures' consent controls and informed certification opt-out provide choices but do not establish that those choices preserve the previous level of protection. [5, paras 112–113 and 135](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf) The evidence needed concerns the actual consent flow, comprehension, frequency of decisions, scope of disclosure and protections remaining after opt-out. This is an assessment of effectiveness, not a premise that users should be prevented from choosing competing services.

### Evidence of novel risks must address the proposed design

Dirk Auer argues that the evidence and parity requirements can make precautionary restrictions on novel risks practically unavailable. His May 2026 commentary concerns the Android draft and predates the final eligibility provisions. [19, “From Pairing Animations to Ambient Surveillance” and concluding proposals](https://truthonthemarket.com/2026/05/13/the-european-commissions-six-seven-theory-of-interoperability/) The operative texts permit objective evidence and do not restrict proof to past incidents. [3, paras 108–110](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) [5, para 117(c)](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf) The final Android text also requires integrity measures to be grounded in established industry standards and practices, creating a further question where an interface or threat is novel. [5, para 117(h)](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf)

I would assess threat models, testing, comparable exposures and the efficacy of proposed mitigation, including whether the Commission’s evidential requirements can accommodate risks for which no established practice yet exists. Open Web Advocacy’s concern that protective measures can obstruct contestability supplies a necessary counterargument: calling a restriction protective does not establish its suitability or necessity. [20, opening discussion of DMA safeguards and less restrictive measures](https://open-web-advocacy.org/blog/balancing-security-and-fair-competition/) The question is both how the Commission applies its test and whether that test permits the protection required by the DMA read consistently with the Charter.

### Equivalent protection depends on the access arrangement

A service processing data an app already holds, one receiving new cross-app context, one sensing its surroundings and one executing external tools do not necessarily create the same exposure. The comparison must identify the data, recipient, execution privileges and permitted outputs. The final Android measures' protected-execution and confidentiality provisions support assessing interoperability through protective architecture. [5, paras 33(b)(3), 35(i) and 44(e)](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf) They qualify the prospective concern that access must bypass that architecture.

The Apple and Android measures impose parity and consistency requirements on protective conditions. [3, paras 111–115](https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf) [5, paras 115 and 117(a)–(c)](https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf) My concern is that an insistence on identical treatment can obscure differences in exposure, control and users’ reasons for trusting a provider. [Apple user-burden analysis, Apple section](https://truthonthemarket.com/2025/03/26/google-and-apple-determinations-show-how-little-users-matter-under-the-dma/) I would assess whether a distinction responds to a demonstrable risk or merely protects the gatekeeper from competition. The principal evidence gap is whether the implemented interfaces preserve effective access while controlling the identified disclosures and actions.

### Specification must account for the resulting protection

The power to specify compliance measures is bounded by the obligations enacted in Articles 6 and 7. For measures within that power, Article 8(7) separately requires effective compliance and proportionality. [1, Articles 8(2) and 8(7)](https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng) Those questions require an account of the statutory obligation, the particular access arrangement, feasible alternatives, implementation costs and benefits, and the relevant rights. The August 2025 Apple implementation decision records five requests to waive or modify features measures; that procedural record does not establish either the claimed burdens or the adequacy of the Commission’s response to them. [18, paras 9–16](https://ec.europa.eu/competition/digital_markets_act/cases/202538/DMA_100203_1809.pdf)

The Article 6(11) comparison establishes acceptance of preventive recipient obligations in a distinct statutory setting; the sufficiency of those controls remains contested. Recipient eligibility and common-name combinations require their own assessment, as explained in the [legal-duties section](#integrity-other-duties). For the wider draft/final comparison, see [Google Search data sharing under Article 6(11) DMA](/dossiers/google-search-data-sharing-dma/).

Further assessment needs the complete reasoned Android decision, the technical basis for restrictions and alternatives, concrete programme and interface designs, and observed performance of user controls and protective measures. My conclusion is that effective protection belongs in the interpretation of the interoperability obligation from the outset, as well as in the assessment of its implementation. The Commission’s specifications need to be assessed against that obligation, rather than used to define its limits.

## Sources

### My publications

#### Apple and EU DMA: a road to leave the EU?

- **Source ID:** `barczentewicz-apple-road-2024`
- **Issuer:** Mikołaj Barczentewicz
- **Document type:** Commentary
- **Date:** 2024-12-21
- **URL:** <https://eutechreg.com/p/apple-and-eu-dma-a-road-to-leave>

Discussion of granular permissions, protective defaults and the burden on users of preserving privacy and security through user-controlled safeguards.

#### Google and Apple Determinations Show How Little Users Matter Under the DMA

- **Source ID:** `barczentewicz-user-burden-2025`
- **Issuer:** Mikołaj Barczentewicz
- **Document type:** Commentary
- **Date:** 2025-03-26
- **URL:** <https://truthonthemarket.com/2025/03/26/google-and-apple-determinations-show-how-little-users-matter-under-the-dma/>

The Apple section revisits the December 2024 argument about the time and knowledge users would need to preserve privacy and security. The cited assessment concerns the March 2025 decisions.

#### Trustworthy privacy for AI: Apple's and Meta's TEEs

- **Source ID:** `barczentewicz-trustworthy-ai-2025`
- **Issuer:** Mikołaj Barczentewicz
- **Document type:** Commentary
- **Date:** 2025-06-01
- **URL:** <https://eutechreg.com/p/trustworthy-privacy-for-ai-apples>

Distinguishes processing data an app already holds from obtaining new cross-app context, and proposes access through protected infrastructure. The June 2025 technical descriptions are considered alongside the later documentation cited here.

#### ICLE Comments on the Interplay Between DMA and GDPR

- **Source ID:** `barczentewicz-dma-gdpr-comments-2025`
- **Issuer:** Mikołaj Barczentewicz / ICLE
- **Document type:** Consultation submission
- **Date:** 2025-12-04
- **URL:** <https://laweconcenter.org/resources/icle-comments-on-the-interplay-between-dma-and-gdpr/>

Full December 2025 submission, including the Article 8(1) analysis in section III and the Article 6(7) discussion in section V and footnote 31. Responds to the October 2025 draft joint guidelines.

#### Opening Pandora’s Interface: AI Assistants and the DMA

- **Source ID:** `barczentewicz-pandora-2026`
- **Issuer:** Mikołaj Barczentewicz
- **Document type:** Commentary
- **Date:** 2026-04-14
- **URL:** <https://truthonthemarket.com/2026/04/14/opening-pandoras-interface-ai-assistants-and-the-dma/>

Analysis of sensitive AI interfaces and the relationship between Articles 6(4), 6(7) and 8(1). Predates both the April draft and July final Android measures.

#### Meta AI’s Incognito Chat: a new bar for confidential AI

- **Source ID:** `barczentewicz-incognito-2026`
- **Issuer:** Mikołaj Barczentewicz
- **Document type:** Commentary
- **Date:** 2026-05-14
- **URL:** <https://eutechreg.com/p/meta-ais-incognito-chat-a-new-bar>

Argument for confidential AI processing and analysis of the trade-off between confidentiality and provider monitoring. Read with the white paper's treatment of controlled external web-search requests.

#### The European Commission’s Search-Data Trust Fall

- **Source ID:** `barczentewicz-search-trust-fall-2026`
- **Issuer:** Mikołaj Barczentewicz
- **Document type:** Commentary
- **Date:** 2026-05-27
- **URL:** <https://truthonthemarket.com/2026/05/27/the-european-commissions-search-data-trust-fall/>

May 2026 critique of the April preliminary search-data measures. Its analysis of names, recipient controls and enforceability must be distinguished from the July final requirements.

#### Interpreting the EU Digital Markets Act Consistently with the EU Charter’s Rights to Privacy and Protection of Personal Data

- **Source ID:** `barczentewicz-charter-2023`
- **Issuer:** Mikołaj Barczentewicz
- **Document type:** Research paper
- **URL:** <https://www.medialaws.eu/wp-content/uploads/2023/08/Interpreting-the-EU-Digital-Markets-Act-consistently-with-the-EU-Charters-rights-to-privacy-and-protection-of-personal-data11.pdf>

August 2023 paper, full MediaLaws version. The central example is Article 6(6); the paper predates the Apple and Android measures examined here. Pinpoints use PDF page numbers.

### Legislation

#### General Data Protection Regulation — Regulation (EU) 2016/679

- **Source ID:** `gdpr-2016`
- **Issuer:** European Parliament and Council
- **Document type:** Regulation
- **Date:** 2016-04-27
- **URL:** <https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng>

Articles 24, 25 and 32 provide the primary basis for the discussion of binding duties and a choice of appropriate technical and organisational measures.

#### Commission proposal COM(2020) 842 final

- **Source ID:** `commission-proposal-2020`
- **Issuer:** European Commission
- **Document type:** Primary material
- **Date:** 2020-12-15
- **URL:** <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52020PC0842>

Original proposal; Article 6(1)(c) and (f), and Recital 47 reviewed.

#### DMA general-approach text, Council document 13801/21

- **Source ID:** `council-2021`
- **Issuer:** Council of the European Union
- **Document type:** Primary material
- **Date:** 2021-11-16
- **URL:** <https://data.consilium.europa.eu/doc/document/ST-13801-2021-INIT/en/pdf>

Document dated 16 November 2021 containing the proposed general approach; relevant text at printed pp. 71–72. The Council agreed its position on 25 November.

#### Parliament amendments to the DMA proposal, P9_TA(2021)0499

- **Source ID:** `parliament-2021`
- **Issuer:** European Parliament
- **Document type:** Primary material
- **Date:** 2021-12-15
- **URL:** <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52021AP0499>

Amendments adopted in December 2021, including Amendments 122 and 126–128. Negotiating position, not adopted legislation.

#### DMA final compromise text, Council document 8722/22

- **Source ID:** `compromise-2022`
- **Issuer:** Council of the European Union
- **Document type:** Primary material
- **Date:** 2022-05-11
- **URL:** <https://www.consilium.europa.eu/media/56086/st08722-xx22.pdf>

Final compromise submitted with a view to agreement. Article 6(4) and (7), printed pp. 107–108; not the subsequently adopted act.

#### DMA — Regulation (EU) 2022/1925

- **Source ID:** `dma-2022`
- **Issuer:** European Parliament and Council
- **Document type:** Primary material
- **Date:** 2022-09-14
- **URL:** <https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng>

#### Cyber Resilience Act — Regulation (EU) 2024/2847

- **Source ID:** `cra-2024`
- **Issuer:** European Parliament and Council
- **Document type:** Primary material
- **Date:** 2024-10-23
- **URL:** <https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng>

Annex I, Part I, points 1 and 2, and Article 13(2) reviewed as context for the Commission’s integrity analogy.

### Case law

#### Rewe-Zentral (Cassis de Dijon), Case 120/78

- **Source ID:** `cassis-1979`
- **Issuer:** Court of Justice of the European Communities
- **Document type:** Judgment
- **Date:** 1979-02-20
- **URL:** <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:61978CJ0120>

Paragraph 13 concerns information through labelling as an alternative to minimum alcohol-content requirements.

#### Microsoft v Commission, T-201/04

- **Source ID:** `microsoft-2007`
- **Issuer:** Court of First Instance of the European Communities
- **Document type:** Judgment
- **Date:** 2007-09-17
- **URL:** <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62004TJ0201>

The cited paragraphs 1165 and 1220 concern Windows Media Player tying and the remedy, rather than the separate interoperability part of the judgment.

#### Promusicae v Telefónica de España, C-275/06

- **Source ID:** `promusicae-2008`
- **Issuer:** Court of Justice of the European Communities
- **Document type:** Judgment
- **Date:** 2008-01-29
- **URL:** <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62006CJ0275>

Paragraphs 61–70 concern balancing fundamental rights in interpreting and implementing EU directives. Included as an additional comparator, not as a DMA holding.

#### Scotch Whisky Association and Others, C-333/14

- **Source ID:** `scotch-whisky-2015`
- **Issuer:** Court of Justice of the European Union
- **Document type:** Judgment
- **Date:** 2015-12-23
- **URL:** <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62014CJ0333>

Free-movement/public-health judgment; paragraphs 28 and 53–55 examined for the proportionality and evidence analogies.

#### Ligue des droits humains, C-817/19

- **Source ID:** `ligue-des-droits-humains-2022`
- **Issuer:** Court of Justice of the European Union
- **Document type:** Judgment
- **Date:** 2022-06-21
- **URL:** <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62019CJ0817>

Paragraph 86 states the principle of interpretation consistent with primary law; paragraphs 248–262 apply Charter requirements to the PNR Directive’s five-year retention provision.

#### European Superleague Company, C-333/21

- **Source ID:** `superleague-2023`
- **Issuer:** Court of Justice of the European Union
- **Document type:** Judgment
- **Date:** 2023-12-21
- **URL:** <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62021CJ0333>

Sports-governance judgment; selected criteria, review and proportionality passages examined.

#### International Skating Union v Commission, C-124/21 P

- **Source ID:** `isu-2023`
- **Issuer:** Court of Justice of the European Union
- **Document type:** Judgment
- **Date:** 2023-12-21
- **URL:** <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62021CJ0124>

Appeal judgment; paragraphs 137–138 concern reviewable criteria and constrained discretion.

#### Alphabet and Others v AGCM, C-233/23

- **Source ID:** `alphabet-agcm-2025`
- **Issuer:** Court of Justice of the European Union
- **Document type:** Judgment
- **Date:** 2025-02-25
- **URL:** <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62023CJ0233>

Article 102 TFEU interoperability judgment; paragraphs 73 and 78–79 are central here.

#### Apple and Apple Distribution International v Commission, T-354/25 — notice of action

- **Source ID:** `apple-features-challenge-2025`
- **Issuer:** General Court of the European Union
- **Document type:** Official Journal notice of action
- **Date:** 2025-10-06
- **URL:** <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62025TN0354>

Action brought on 30 May 2025 concerning the features decision, DMA.100203. The notice reports the applicants’ requested relief and thirteen pleas, including Charter compatibility, implementing powers and interpretation of Article 6(7).

#### Apple and Apple Distribution International v Commission, T-359/25 — notice of action

- **Source ID:** `apple-process-challenge-2025`
- **Issuer:** General Court of the European Union
- **Document type:** Official Journal notice of action
- **Date:** 2025-10-06
- **URL:** <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62025TN0359>

Action brought on 30 May 2025 concerning the process decision, DMA.100204. The notice reports the applicants’ requested relief and six pleas, including Charter compatibility, implementing powers and interpretation of Article 6(7).

#### Apple and Apple Distribution International v Commission, T-354/25 — Curia case record

- **Source ID:** `apple-features-case-status`
- **Issuer:** Court of Justice of the European Union
- **Document type:** Case record
- **URL:** <https://curia.europa.eu/juris/liste.jsf?num=T-354/25&language=en>

Main proceedings listed as pending when checked on 11 September 2026. The record also lists orders dated 6 May 2026; their reasoning is outside this dossier’s review.

#### Apple and Apple Distribution International v Commission, T-359/25 — Curia case record

- **Source ID:** `apple-process-case-status`
- **Issuer:** Court of Justice of the European Union
- **Document type:** Case record
- **URL:** <https://curia.europa.eu/juris/liste.jsf?num=T-359/25&language=en>

Main proceedings listed as pending when checked on 11 September 2026. The record also lists orders dated 6 May 2026; their reasoning is outside this dossier’s review.

### Administrative proceedings

#### Apple connected-devices interoperability: case summary and proposed measures

- **Source ID:** `apple-preliminary-2024`
- **Issuer:** European Commission
- **Document type:** Primary material
- **Date:** 2024-12-18
- **URL:** <https://ec.europa.eu/competition/digital_markets_act/cases/20253/DMA_100203_1283.pdf>

Published consultation document, not the full preliminary findings. Used to identify the earlier proposed-measures stage.

#### Apple features specification decision, DMA.100203

- **Source ID:** `apple-features-2025`
- **Issuer:** European Commission
- **Document type:** Primary material
- **Date:** 2025-03-19
- **URL:** <https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100203_1655.pdf>

Published non-confidential decision of 19 March 2025, including its annex. The cited party submissions are described through the decision where their full text is not public.

#### Apple process specification decision, DMA.100204

- **Source ID:** `apple-process-2025`
- **Issuer:** European Commission
- **Document type:** Primary material
- **Date:** 2025-03-19
- **URL:** <https://ec.europa.eu/competition/digital_markets_act/cases/202523/DMA_100204_2073.pdf>

Published non-confidential decision of 19 March 2025, including its annex.

#### Decision on implementation of the Apple features measures

- **Source ID:** `apple-waiver-2025`
- **Issuer:** European Commission
- **Document type:** Primary material
- **Date:** 2025-08-04
- **URL:** <https://ec.europa.eu/competition/digital_markets_act/cases/202538/DMA_100203_1809.pdf>

Published non-confidential decision concerning Apple’s requests to waive or modify specified measures. Selected procedural passages reviewed.

#### Google Android draft-measures annex, DMA.100220

- **Source ID:** `android-draft-2026`
- **Issuer:** European Commission
- **Document type:** Primary material
- **Date:** 2026-04-27
- **URL:** <https://ec.europa.eu/competition/digital_markets_act/cases/202619/DMA_100220_2145.pdf>

Published draft-measures annex of 27 April 2026; it precedes the July final measures.

#### Google Android published final measures, DMA.100220

- **Source ID:** `android-final-2026`
- **Issuer:** European Commission
- **Document type:** Primary material
- **Date:** 2026-07-16
- **URL:** <https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf>

Provisional non-confidential final-measures extract. The full reasoned decision was not available in the material reviewed.

#### Google Search final measures, DMA.100209

- **Source ID:** `search-final-2026`
- **Issuer:** European Commission
- **Document type:** Published final-measures extract
- **Date:** 2026-07-16
- **URL:** <https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100209_2712.pdf>

Provisional non-confidential extract of the measures adopted on 16 July 2026, not the full reasoned decision. Cited for recipient eligibility, the technical pipeline and contractual safeguards; their adequacy remains contested.

### Other sources

#### Balancing Security and Fair Competition

- **Source ID:** `owa-2025`
- **Issuer:** Open Web Advocacy
- **Document type:** Advocacy commentary
- **Date:** 2025-06-23
- **URL:** <https://open-web-advocacy.org/blog/balancing-security-and-fair-competition/>

Advocacy commentary on security justifications, including Articles 6(4) and 6(7). The claims about app-store performance are not independently audited here.

#### Joint Guidelines on the Interplay between the Digital Markets Act and the General Data Protection Regulation — consultation draft

- **Source ID:** `joint-guidelines-2025`
- **Issuer:** European Commission and EDPB
- **Document type:** Draft guidance for public consultation
- **Date:** 2025-10-09
- **URL:** <https://www.edpb.europa.eu/system/files/2025-10/joint_com-edpb_gls_interplay_dma_gdpr_for_public_consultation_en.pdf>

October 2025 consultation draft. The complete EDPB version was reviewed, including footnotes. References use paragraph numbers; this is not final guidance.

#### Private Processing for WhatsApp Overview — Technical White Paper and Security Guide

- **Source ID:** `meta-private-processing-2026`
- **Issuer:** Meta
- **Document type:** Technical white paper, version 2
- **Date:** 2026-03-16
- **URL:** <https://ai.meta.com/static-resource/private-processing-technical-whitepaper>

Version 2, updated 16 March 2026; version 1 was published on 10 June 2025. Citations use printed page numbers. Describes the provider's architecture and security claims, including stateless processing, transparency limits and external web search; not an independent audit of deployed systems.

#### The European Commission’s ‘Six-Seven’ Theory of Interoperability

- **Source ID:** `auer-2026`
- **Issuer:** Dirk Auer
- **Document type:** Commentary
- **Date:** 2026-05-13
- **URL:** <https://truthonthemarket.com/2026/05/13/the-european-commissions-six-seven-theory-of-interoperability/>

Commentary on Apple and the Android draft. Predates the final Android eligibility scheme; its predictions are not evidence of implementation outcomes.

#### Incognito Chat with Meta AI announcement

- **Source ID:** `meta-incognito-announcement-2026`
- **Issuer:** Meta
- **Document type:** Product announcement
- **Date:** 2026-05-13
- **URL:** <https://about.fb.com/news/2026/05/incognito-chat-whatsapp-meta-ai/>

May 2026 announcement connecting Incognito Chat to Private Processing. Establishes the provider's product description, not independently verified operation.

#### Private Cloud Compute: A new frontier for AI privacy in the cloud

- **Source ID:** `apple-pcc-security`
- **Issuer:** Apple
- **Document type:** Technical architecture statement
- **URL:** <https://security.apple.com/blog/private-cloud-compute/>

Introductory account of attestation, runtime controls and confidentiality. Read with the later Multi-Turn Agent documentation for the treatment of encrypted state between turns. The system's deployed guarantees are not independently audited here.

#### Private Cloud Compute Security Guide — Multi-Turn Agent

- **Source ID:** `apple-pcc-multiturn`
- **Issuer:** Apple
- **Document type:** Technical documentation
- **URL:** <https://security.apple.com/documentation/private-cloud-compute/multiturnagent>

Chapter reviewed on 11 September 2026. Describes persistent connections, encrypted cache reuse with client-supplied keys and a registry of permitted tools. The additional rules in linked chapters on external tools are outside this review.

#### Security research on Private Cloud Compute

- **Source ID:** `apple-pcc-research`
- **Issuer:** Apple
- **Document type:** Security research announcement
- **URL:** <https://security.apple.com/blog/pcc-security-research/>

Describes the released virtual research environment and selected source components. It does not establish that the entire system is open source.