Integrity under the DMA: sources, interpretation and safeguards

Article 6(7) DMA requires access and effective interoperability and expressly permits strictly necessary, proportionate and duly justified measures to protect integrity. [DMA, Article 6(7)] 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. [Apple features decision, paras 100⁠–⁠107] 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). [Barczentewicz 2023, PDF pp. 1⁠–⁠2 and 15⁠–⁠17] [DMA–GDPR comments, section V and fn 31]

The statutory analysis addresses interpretation and the limits of specification powers. The section on integrity and other legal duties examines how binding duties constrain implementation, including where they leave a choice of protective measures. The access-arrangements comparison and practical applications 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. [Android final measures, paras 13(c), 15(e), 33(b)(3), 35(i), 44(e) and 120⁠–⁠138] 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.

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. [DMA, Article 6(4), second subparagraph]

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. [DMA, Article 6(4), third subparagraph]

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. [DMA, Article 6(7), second subparagraph]

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. [DMA, Article 7(9)]

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. [DMA, Articles 6(4), 6(7) and 7(9)]

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. [DMA, Articles 6(7) and 8(1)] In my Pandora analysis, 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]

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. [DMA, Recital 50]

The recital addresses third-party applications and stores. The Commission applies its account of integrity to Article 6(7) in both Apple decisions. [Apple features decision, para 101] [Apple process decision, para 81] 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. [Barczentewicz 2023, PDF pp. 1⁠–⁠2, 9 and 15⁠–⁠17] The underlying principle comes from 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] 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]

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 confers no 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. [Barczentewicz 2023, PDF pp. 15⁠–⁠17]

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. [Barczentewicz 2023, PDF p. 17] Compliance with the GDPR and other applicable duties therefore cannot substitute for assessing the interoperability obligation itself against the Charter. The legal-duties analysis 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. [DMA, Articles 8(2) and 8(7)] 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. [Apple features decision, paras 116⁠–⁠118] The central question is whether each disputed requirement gives effect to an obligation already contained in Article 6(7), properly interpreted, or supplements 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. Adequate protection must be demonstrated independently of the decision to reject the gatekeeper’s proposed safeguard. [DMA, Articles 6(7) and 8(7)]

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] [Apple process action, form of order sought; pleas 1⁠–⁠3] Both main proceedings were listed as pending in the Court’s case records on 11 September 2026. [T-354/25 status, case overview] [T-359/25 status, case overview]

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. [DMA, Article 10(1)⁠–⁠(5); Article 13(3)⁠–⁠(6)]

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. [Apple features decision, para 103 and fn 95]

Footnote 95 points to Parliament’s December 2021 position. [Apple features decision, para 103 and fn 95] Amendment 126 expressly added end-user data protection and cybersecurity. That wording is absent from final Article 6(7). [Parliament DMA amendments, Amendment 126] [DMA, Article 6(7)] The Commission infers a deliberate exclusion of those justifications. I consider the drafting sequence insufficient to choose among three explanations. The omission may have reflected a considered exclusion, an assumption that integrity or other provisions supplied protection, or incomplete and imperfect drafting. Evidence about the negotiations is needed to choose among them. Even proof of a restrictive intention would leave the Charter-compatible interpretation 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. [Apple features decision, para 103]

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 Cyber Resilience Act (CRA), the platform-interoperability judgment in Alphabet, and Microsoft’s treatment of operating-system functionality. The CRA is one supporting source in that chain. [Apple features decision, paras 101⁠–⁠104 and fns 92⁠–⁠98]

Authorisation and privacy controls

The decision says:

User authorisation may in certain cases be sufficient to address an integrity concern. [Apple features decision, para 104]

“May in certain cases” matters. Even on the Commission’s own view, consent does not eliminate 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. [Apple features decision, paras 104⁠–⁠106 and fns 97 and 99]

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 makes the Commission’s boundary explicit. Even assuming an iOS device could be used to harm nearby bank cardholders, the Commission places that harm outside integrity because the use need not impair iOS or the NFC feature. [Apple features decision, paras 578⁠–⁠581] On that reasoning, correct functioning and harmful use are distinct. The user-choice analysis and practical applications address whether other applicable duties and 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. [Apple features decision, para 107]

The surrounding text conditions competition between models on compliance with applicable legislation. The preceding discussion also recognises sectoral obligations, proportionality and Charter rights. [Apple features decision, paras 105⁠–⁠107] A controller-selected safeguard may implement a binding duty even when the law leaves room for another effective design. The legal-duties section 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. [Apple features decision, para 109]

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. [Apple features decision, paras 108⁠–⁠110] 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. The assessment must consider both protection under ordinary conditions of use and the resulting user friction.

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. [Apple features decision, para 111]

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. [Apple features decision, paras 111⁠–⁠113] 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] 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 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. [Apple features decision, para 115]

Paragraph 115 includes the gatekeeper’s treatment of comparable risks, enforcement and monitoring, and the effectiveness of the measure after adoption. It therefore requires a continuing suitability inquiry. An initial justification alone is insufficient. [Apple features decision, para 115]

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. [Apple process decision, paras 80⁠–⁠95] [Apple features decision, paras 100⁠–⁠115]

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. [DMA, Article 8(1)] This provides an additional route for assessing safeguards alongside the Charter argument concerning Article 6(7) itself. 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. [Apple process decision, paras 39⁠–⁠40] 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). In my comments on the DMA–GDPR guidelines, I observed that 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] 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] 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] 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] 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] 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] 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] The first proposition leaves the relevance of particular information open. 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 identifies the requester and verifies the required authorisation. User understanding and practical risk management require separate evidence. 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] Whether those mechanisms preserve the level of protection depends on their operation under realistic conditions of use.

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. [Barczentewicz 2023, PDF p. 8] In my December 2024 analysis of Apple and the DMA, 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] 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 screen, dashboard or revocation facility provides an adequate substitute only if ordinary users can use it effectively. 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] 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] This establishes the Commission’s acceptance of that regulatory technique. The adequacy of the particular safeguards requires a separate assessment. 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] 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] 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)] 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]

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. [Android final measures, paras 15(e), 33(b)(3), 35(i) and 44(e)] 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.

The Cyber Resilience Act: 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. [Cyber Resilience Act, Annex I, Part I, point 2(f)]

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. [Cyber Resilience Act, Annex I, Part I, points 1 and 2(d)⁠–⁠(f); Article 13(2)]

The Commission uses point 2(f) to support the link between integrity and unauthorised manipulation, and the possible relevance of user authorisation. [Apple features decision, paras 103⁠–⁠104 and fns 93⁠–⁠97] 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. [Cyber Resilience Act, Article 13(2)⁠–⁠(3)] 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. [Cyber Resilience Act, Articles 69 and 71]

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. [Alphabet v AGCM, para 73] The Apple features decision invokes the platform as the protected object. [Apple features decision, para 103, fn 92] 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]

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. [Alphabet v AGCM, paras 78⁠–⁠79] 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. [DMA, Article 6(7)]

Microsoft: functionality in the tying remedy

The Commission cites Microsoft, paragraphs 1165 and 1220, by analogy. [Apple features decision, para 104, fn 96] 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. [Microsoft v Commission, paras 1165 and 1220]

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. [European Superleague Company, paras 135⁠–⁠136] ISU similarly examines whether the authorisation discretion was linked to specific verifiable objectives and reviewable criteria. [ISU v Commission, paras 137⁠–⁠138]

The Apple decisions use such authorities to support objective conditions and independent verification. [Apple features decision, paras 111⁠–⁠113 and fns 103⁠–⁠109] The analogy concerns an access-controlling body with conflicting incentives. It supports transparent criteria and review of a refusal or restriction. Suitability remains specific to the architecture and the demonstrated exposure. 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. [Android final measures, paras 115 and 117(a)⁠–⁠(c)]

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. [Scotch Whisky Association, paras 28 and 53⁠–⁠55] 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. [Cassis de Dijon, para 13] The Commission uses it by analogy when discussing a permission prompt instead of a general computing-resource limit. [Apple features decision, para 110, fn 102] 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 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] 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. [Promusicae v Telefónica de España, paras 61⁠–⁠70, especially 68] These authorities supply the method developed in the statutory analysis: identify the interference with protected rights and examine how the interoperability obligation can be interpreted consistently with them.

Protected processing and the scope of access

In my June 2025 analysis of Apple’s and Meta’s trusted execution environments for AI services, I distinguished processing information an app already holds from giving it new access to data across the device. Technical solutions I discussed there can reduce the additional exposure of information an app already holds. The question of access to new data 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] 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. Paragraph 35(i) permits specified confidentiality conditions. [Android final measures, paras 33(b)(3) and 35(i)] 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] 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] Meta’s March 2026 white paper instead describes client-supplied conversation history and disabled persistent inference cache. [Meta Private Processing white paper, p. 15] The relevant assessment concerns retained information and who can access it.

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] 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] These controls identify a bounded disclosure route. The remaining assessment must consider whether a sensitive query could identify someone or disclose information about them. The access-arrangements comparison therefore separates use of a model API, new data access, executable code and external outputs.

Confidentiality and provider monitoring

In my Incognito Chat analysis, 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] A hypothetical requirement to send flagged conversations to a human-review queue would create an additional disclosure route. That route requires assessment against confidentiality obligations. Its description as a safety measure supplies no evidence of necessity or safeguard adequacy. Confidentiality also leaves the assistant’s actions and outputs to be assessed for safety.

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] 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] 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. [Apple features decision, paras 425⁠–⁠429]

The Commission compares a one-time consent screen with separate consent screens for every network. It applies equivalent standards to 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. [Apple features decision, paras 429⁠–⁠431] These propositions identify possible alternatives. A finding of equivalent risk would require evidence covering information scope, recipients, retention, and onward use.

The assessment should ask what an ordinary user can understand and control when agreeing once to future sharing. That consent screen may identify the recipient while leaving the extent of future disclosure difficult to foresee. It may reduce 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] 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]

In my December 2024 Apple analysis, 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. [DMA, Article 6(4), third subparagraph] [GDPR, Article 25(2)] 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.

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. [Android final measures, paras 13(c)⁠–⁠(e) and 15(c)⁠–⁠(e)] Context-aware intelligence and ambient access permit specified isolation, encryption, telemetry and user-control conditions, also applying to Alphabet. [Android final measures, paras 35(i) and 44(e)] General provisions permit consent, indicators, dashboards and revocation, subject to equal treatment and effectiveness. [Android final measures, paras 112⁠–⁠113]

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. [Android final measures, paras 120⁠–⁠122] 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. [Android final measures, paras 125⁠–⁠126] 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. [Android final measures, paras 127⁠–⁠134]

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. [Android final measures, paras 135 and 137] 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 some 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. [Android final measures, paras 136 and 138]

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 develops an alternative interpretation. It reads 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] [Barczentewicz 2023, PDF pp. 15⁠–⁠17]

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. [Apple process decision, paras 39⁠–⁠40] My legal-duties analysis 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. [Apple features decision, para 104] 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]

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. [Android final measures, paras 112⁠–⁠113 and 135] The evidence needed concerns the actual consent flow, comprehension, frequency of decisions, scope of disclosure and protections remaining after opt-out.

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. [Auer 2026, “From Pairing Animations to Ambient Surveillance” and concluding proposals] The operative texts permit objective evidence and do not restrict proof to past incidents. [Apple features decision, paras 108⁠–⁠110] [Android final measures, para 117(c)] 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. [Android final measures, para 117(h)]

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. 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. [Android final measures, paras 33(b)(3), 35(i) and 44(e)] They qualify the prospective concern that access must bypass that architecture.

The Apple and Android measures impose parity and consistency requirements on protective conditions. [Apple features decision, paras 111⁠–⁠115] [Android final measures, paras 115 and 117(a)⁠–⁠(c)] 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] 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. [DMA, Articles 8(2) and 8(7)] 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. [Apple implementation decision, paras 9⁠–⁠16] That procedural record does not establish either the claimed burdens or the adequacy of the Commission’s response to them.

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. For the wider draft/final comparison, see Google Search data sharing under Article 6(11) 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 must remain within the limits of that obligation.