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. 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. 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).

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. 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.

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.

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.

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.

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.

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. 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.

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.

The recital addresses third-party applications and stores. The Commission applies its account of integrity to Article 6(7) in both Apple decisions. 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. 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. 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.

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.

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. 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. 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. 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.

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. Both main proceedings were listed as pending in the Court’s case records on 11 September 2026.

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.

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.

Footnote 95 points to Parliament’s December 2021 position. Amendment 126 expressly added end-user data protection and cybersecurity; that wording is absent from final Article 6(7). 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 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.

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.

Authorisation and privacy controls

The decision says:

User authorisation may in certain cases be sufficient to address an integrity concern.

“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.

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. The user-choice analysis and practical applications 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.

The surrounding text conditions competition between models on compliance with applicable legislation. The preceding discussion also recognises sectoral obligations, proportionality and Charter rights. 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.

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. 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.

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. In my March 2025 analysis, I challenged the assumption that users’ trust in a particular provider could be dismissed when assessing equivalent protection. 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.

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.

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.

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. 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. 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. 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. 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. 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. Paragraph 96 also recognises that network-encryption measures outside the integrity and end-user-security safeguards may nevertheless be required by the GDPR. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.

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. 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.

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.

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.

The Commission uses point 2(f) to support the link between integrity and unauthorised manipulation, and the possible relevance of user authorisation. 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. 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. 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. The Apple features decision invokes the platform as the protected object. 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.

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. 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.

Microsoft: functionality in the tying remedy

The Commission cites Microsoft, paragraphs 1165 and 1220, by analogy. 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.

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. ISU similarly examines whether the authorisation discretion was linked to specific verifiable objectives and reviewable criteria.

The Apple decisions use such authorities to support objective conditions and independent verification. 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.

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. 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. The Commission uses it by analogy when discussing a permission prompt instead of a general computing-resource limit. 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. 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. 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. Neither an appeal to competition nor an assertion of a privacy risk supplies the necessary assessment on its own.

Protected processing and the scope of access

In my June 2025 analysis of Apple’s and Meta’s trusted execution environments, 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. 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. 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. 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. Meta’s March 2026 white paper instead describes client-supplied conversation history and disabled persistent inference cache. 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. 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. 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 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. 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. Meta’s white paper describes access to auditable artifacts for eligible researchers while keeping models and system prompts private. 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.

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. 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. 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.

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. 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. 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).

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). 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. 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. Context-aware intelligence and ambient access permit specified isolation, encryption, telemetry and user-control conditions, also applying to Alphabet. General provisions permit consent, indicators, dashboards and revocation, subject to equal treatment and effectiveness. 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. 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. 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.

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. 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. 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.

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 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.

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. 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. 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.

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. 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. The operative texts permit objective evidence and do not restrict proof to past incidents. 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.

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. 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. They qualify the prospective concern that access must bypass that architecture.

The Apple and Android measures impose parity and consistency requirements on protective conditions. My concern is that an insistence on identical treatment can obscure differences in exposure, control and users’ reasons for trusting a provider. 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. 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.

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 need to be assessed against that obligation, rather than used to define its limits.