Competition Law and Cloud Service Interoperability Obligations

1. Introduction

Cloud service interoperability refers to the ability of customers, applications, workloads, data, and services to communicate, operate, migrate, or function across different cloud providers without being technically or commercially trapped within one provider's ecosystem.

Competition law becomes relevant where a cloud provider with substantial market power:

• refuses or restricts interoperability;
• withholds technical interfaces or APIs;
• prevents third-party cloud services from working effectively with its services;
• imposes discriminatory interoperability conditions;
• uses proprietary formats or protocols to create switching barriers;
• makes interoperability available only on commercially disadvantageous terms;
• ties interoperability to the purchase of other services;
• imposes licensing restrictions that disadvantage rival cloud providers;
• charges excessive or discriminatory fees for access;
• restricts multi-cloud deployment; or
• degrades interoperability after a customer begins using a competing cloud.

The issue is increasingly important because interoperability can determine whether customers can multi-home, switch providers, migrate workloads, and negotiate effectively.

The EU Data Act expressly addresses this problem by requiring providers of data-processing services to facilitate switching and interoperability, including open interfaces and machine-readable data for certain services and functional equivalence for infrastructure services.

The UK's 2025 cloud-services market investigation likewise identified barriers to interoperability as restricting switching and multi-cloud, alongside egress fees and licensing practices.

2. Meaning of Cloud Service Interoperability

Interoperability may operate at several levels.

A. Data interoperability

Customers should be able to move:

• databases;
• files;
• metadata;
• configuration information;
• logs;
• application data; and
• other customer-generated information

between providers.

B. Application interoperability

Applications hosted with Provider A should be capable of interacting with services hosted with Provider B.

Examples include:

• API compatibility;
• identity-management interoperability;
• database interoperability;
• authentication;
• monitoring;
• storage;
• messaging;
• security services.

C. Infrastructure interoperability

Infrastructure-as-a-Service customers may need compatibility between:

• virtual machines;
• containers;
• storage systems;
• networking;
• orchestration systems;
• virtualization technologies.

D. Multi-cloud interoperability

A customer may simultaneously use:

AWS + Azure + Google Cloud + private cloud.

Competition concerns arise when a dominant provider deliberately makes such multi-cloud arrangements technically or economically difficult.

E. Functional equivalence

Interoperability does not necessarily mean that every provider must reproduce every feature of another provider.

A more realistic standard is that equivalent workloads should achieve materially comparable outcomes where comparable services exist.

The EU Data Act specifically contemplates functional equivalence for certain infrastructure services.

3. Competition-Law Framework

Cloud interoperability can potentially be analysed under several competition-law doctrines.

4. Why Interoperability Matters for Competition

Interoperability can reduce switching costs.

Suppose:

Customer → Cloud A → proprietary database → proprietary APIs → proprietary security tools → proprietary management platform.

After several years, moving to Cloud B may require substantial redevelopment.

The customer may therefore remain with Cloud A even if Cloud B offers:

• lower prices;
• better performance;
• better security;
• better AI services; or
• more innovative products.

This creates a potential lock-in effect.

Interoperability can therefore promote:

1. customer mobility;
2. multi-cloud adoption;
3. entry by smaller cloud providers;
4. innovation;
5. price competition;
6. service-quality competition; and
7. technological neutrality.

The CMA's cloud investigation found significant market-power concerns involving Amazon and Microsoft and identified interoperability barriers as one factor limiting switching and multi-cloud competition.

5. Refusal to Interoperate as Abuse of Dominance

The classic competition-law question is:

When does a refusal to provide interoperability become an unlawful refusal to deal?

Competition law generally does not impose a universal obligation on every company to make its technology compatible with rivals.

A particularly strong case normally requires factors such as:

1. substantial market power;
2. control over an important input, interface or facility;
3. lack of realistic alternatives;
4. significant competitive harm;
5. inability of competitors to compete effectively without access;
6. potential elimination of effective competition; and
7. absence of adequate objective justification.

These principles originate partly in the European refusal-to-deal jurisprudence.

6. Six Important Case Laws

Case 1: Magill TV Guide / RTE, ITP and BBC

Case

Radio Telefis Éireann (RTE) and Independent Television Publications Ltd v Commission, joined cases C-241/91 P and C-242/91 P.

Principle

The case concerned copyright information concerning television programme schedules.

The European Court recognised that exceptional circumstances could transform refusal to license intellectual property into an abuse of dominance.

The important conditions included:

• the information was indispensable;
• refusal prevented the appearance of a new product;
• refusal was unjustified; and
• the conduct reserved a downstream market to the dominant undertaking.

Relevance to cloud interoperability

A cloud provider may possess:

• proprietary APIs;
• technical specifications;
• authentication mechanisms;
• interoperability documentation;
• data formats.

If those are indispensable for effective competition and withholding them prevents meaningful rival services from developing, the Magill principle may become relevant.

Limitation

A cloud provider cannot automatically be required to disclose every proprietary technology.

The exceptional circumstances test remains important.

7. Case 2: Bronner v Mediaprint

Case

Oscar Bronner GmbH & Co. KG v Mediaprint, Case C-7/97.

Principle

The Court adopted a demanding test for refusal-to-deal cases.

A facility generally must be indispensable, meaning that there is no actual or potential substitute and duplication is not realistically possible.

Cloud application

A cloud provider could argue:

"Our API is proprietary, but competitors can create their own alternative infrastructure."

In such a case, an interoperability obligation may be more difficult to establish.

Conversely, if:

• the interface is uniquely controlled;
• duplication is technically or economically impossible;
• access is indispensable for competition; and
• refusal eliminates effective competition,

the Bronner test becomes particularly relevant.

Importance

Bronner prevents competition law from becoming a general rule requiring businesses to share their assets with competitors.

8. Case 3: IMS Health v Commission

Case

IMS Health GmbH & Co. OHG v NDC Health GmbH & Co. KG, Case C-418/01.

Principle

The Court refined the exceptional circumstances doctrine.

The relevant considerations included:

• indispensability;
• elimination of effective competition;
• prevention of a new product for which consumer demand existed; and
• absence of objective justification.

Cloud relevance

Consider a dominant cloud provider controlling a proprietary interoperability layer that competing cloud-management providers need.

If refusal prevents competitors from offering innovative multi-cloud solutions, the IMS Health reasoning becomes relevant.

For example:

Cloud Provider A controls a technically indispensable interface → competing cloud-management services cannot function effectively → customers are effectively locked into A.

The competition-law question would then be whether the IMS-type exceptional circumstances are satisfied.

9. Case 4: Microsoft Corp. v Commission

Case

Microsoft Corp. v Commission, Case T-201/04.

Facts

The European Commission found competition concerns involving Microsoft's refusal to provide interoperability information necessary for work-group server products to interoperate effectively with Microsoft's dominant PC operating-system environment.

Principle

This is one of the most directly relevant precedents for interoperability.

The case demonstrated that interoperability information can become a competition-law issue where:

• a dominant firm controls an important technological interface;
• rivals require interoperability to compete effectively;
• refusal substantially restricts competition; and
• the refusal cannot be objectively justified.

Cloud application

The analogy to cloud computing is strong.

Potential examples include:

• proprietary identity systems;
• cloud management APIs;
• workload orchestration interfaces;
• storage APIs;
• database interfaces;
• networking protocols.

If a dominant cloud provider controls a critical interface and uses that control to prevent rival cloud services from interoperating effectively, Microsoft provides an important analytical precedent.

10. Case 5: Slovak Telekom

Case

Slovak Telekom a.s. v European Commission, Joined Cases C-165/19 P and C-166/19 P.

Principle

The case concerned access to infrastructure and exclusionary conduct in telecommunications.

The Court considered the relationship between refusal-of-access principles and Article 102 TFEU.

Cloud relevance

Cloud infrastructure has similarities to telecommunications infrastructure because:

• networks create dependencies;
• infrastructure can generate significant switching costs;
• access restrictions can disadvantage downstream competitors.

The case is useful for analysing whether a dominant infrastructure operator is using control over infrastructure to foreclose competitors.

For cloud services, the relevant infrastructure could include:

• network interfaces;
• connectivity;
• storage infrastructure;
• identity infrastructure;
• cloud management infrastructure.

11. Case 6: Google Android

Case

Google and Alphabet v Commission, Case T-604/18.

Principle

The General Court examined Google's contractual arrangements involving Android and found competition concerns concerning restrictions that could reinforce Google's position in related markets.

Although this was not a pure cloud-interoperability case, it illustrates the broader principle that contractual and technical ecosystem restrictions can reinforce dominance across interconnected digital markets.

Cloud relevance

Cloud providers increasingly operate ecosystems containing:

• operating systems;
• productivity software;
• databases;
• cybersecurity;
• AI;
• developer tools;
• identity systems;
• cloud infrastructure.

Interoperability restrictions can therefore have effects beyond the immediate cloud market.

12. Additional Important Precedent: Microsoft 2007

The European Commission's later Microsoft proceedings are also highly relevant.

Microsoft's interoperability obligations ultimately illustrate an important competition-law concept:

Interoperability remedies may be imposed to restore competitive conditions rather than to transfer ownership of the dominant firm's technology.

This distinction is important for cloud regulation.

A remedy might therefore require:

• API disclosure;
• technical documentation;
• protocol access;
• non-discriminatory interoperability;
• compatibility testing;

without necessarily requiring disclosure of source code or transfer of intellectual property ownership.

13. Cloud-Specific Regulatory Development

The legal environment is moving beyond traditional abuse-of-dominance litigation.

EU Data Act

The EU Data Act establishes specific switching and interoperability requirements for data-processing services.

It seeks to address:

• switching barriers;
• interoperability problems;
• data portability;
• cloud lock-in;
• egress charges;
• contractual obstacles.

For PaaS and SaaS, providers must make open interfaces available and provide data in commonly used, machine-readable formats.

For IaaS, measures can include mechanisms supporting functional equivalence when moving between comparable services.

The Data Act therefore converts some interoperability principles from a case-by-case competition-law question into ex ante regulatory obligations.

14. UK Cloud Competition Developments

The UK's CMA completed its public-cloud infrastructure market investigation in 2025.

The investigation identified:

• significant market power associated with Amazon and Microsoft;
• egress-fee concerns;
• barriers to interoperability;
• restrictions affecting switching and multi-cloud;
• licensing issues involving Microsoft's business software. 

In March 2026, the CMA reported that Microsoft and Amazon had taken material steps concerning interoperability and cloud egress fees, while stating that further steps concerning switching and multi-homing remained under review.

This illustrates an important development:

Competition authorities increasingly view interoperability and switching together rather than as completely separate problems.

15. EU Digital Markets Act and Cloud

The European Commission launched cloud-related DMA market investigations in November 2025.

The investigation specifically considers whether the DMA can address practices affecting cloud competitiveness and fairness, including:

• obstacles to interoperability;
• restricted or conditioned access to business-user data;
• tying and bundling;
• contractual conditions. 

In June 2026, the Commission announced a preliminary position that AWS and Microsoft Azure should be designated as gatekeepers for their cloud services, despite not meeting the quantitative DMA thresholds, because of their importance as gateways and their entrenched positions.

The Commission's 2026 cloud investigation specifically includes interoperability and technical features as a central topic.

16. Types of Interoperability Obligations

A competition authority or regulator could theoretically impose several forms of remedy.

1. API access

The dominant provider may be required to provide appropriate access to APIs.

2. Technical documentation

Competitors may receive sufficient documentation to make interoperable products.

3. Data portability

Customers may export their data in:

• structured;
• machine-readable;
• commonly used formats.

4. Functional equivalence

A workload migrated to another provider should obtain materially comparable results for equivalent services.

5. Non-discrimination

The provider should not give its own services privileged access to interfaces while disadvantaging competitors.

6. Multi-cloud compatibility

Providers may have to remove unnecessary technical restrictions preventing customers from using multiple clouds.

7. Migration assistance

Customers may receive technical mechanisms facilitating workload migration.

8. Interoperability testing

Providers may need to support reasonable compatibility testing.

17. Interoperability and Egress Fees

Interoperability cannot be analysed separately from data egress fees.

Suppose:

Cloud A charges a substantial fee to export data → Customer wants to migrate to Cloud B → Migration becomes economically unattractive → Customer remains with A.

Even where Cloud A technically permits interoperability, excessive switching charges may produce a similar competitive effect.

The EU Data Act provides for the eventual removal of switching charges, including data-egress charges, from 12 January 2027, with a transitional regime allowing certain costs to be charged until then.

18. Interoperability and Tying

A cloud provider may potentially engage in tying where:

Access to Cloud Service X is conditioned on purchasing Service Y.

Example:

"To obtain full interoperability with our cloud platform, you must also purchase our proprietary security-management service."

Competition concerns become stronger where:

1. the provider is dominant;
2. the products are distinct;
3. customers are forced to purchase the tied product;
4. rivals are foreclosed; and
5. competition is weakened.

19. Interoperability and Self-Preferencing

A cloud provider operating an ecosystem could potentially favour its own services.

For example:

Third-party database service → limited API access
Provider's database → full API access.

Or:

Third-party security provider → delayed technical integration
Provider's security product → immediate integration.

This can create a self-preferencing problem if the conduct disadvantages competitors through the provider's control over an essential ecosystem interface.

20. Interoperability and Standardisation

Interoperability frequently requires technical standards.

Industry participants may cooperate to establish:

• APIs;
• container standards;
• data formats;
• identity protocols;
• security protocols;
• workload portability standards.

Such cooperation can benefit competition.

However, standardisation can itself create competition concerns where competitors use the process to:

• exclude rival technologies;
• fix prices;
• divide markets;
• restrict innovation;
• manipulate technical standards.

Therefore:

Interoperability standardisation is generally pro-competitive, but the method of creating the standard matters.

21. Objective Justifications

A cloud provider may have legitimate reasons for limiting interoperability.

Possible justifications include:

Security

Unrestricted access may create cybersecurity vulnerabilities.

Privacy

Interoperability may create risks involving personal or confidential data.

Intellectual property

The provider may possess legitimate proprietary technology.

System integrity

Opening interfaces may interfere with reliability.

Technical feasibility

Complete interoperability may not be technically possible.

Performance

Certain restrictions may be necessary to maintain service quality.

Abuse prevention

Interoperability may facilitate fraud, cyberattacks or misuse.

Competition law should therefore distinguish:

genuine technical necessity

from

strategic interoperability restrictions designed to exclude competitors.

22. Competition-Law Test for Cloud Interoperability

A useful analytical framework is:

Step 1 — Define the relevant market

Possible markets include:

• IaaS;
• PaaS;
• SaaS;
• cloud storage;
• cloud databases;
• cloud security;
• cloud management;
• specific vertical cloud services.

Step 2 — Determine market power

Consider:

• market share;
• switching costs;
• customer lock-in;
• economies of scale;
• network effects;
• ecosystem effects;
• technical barriers;
• data advantages.

Step 3 — Identify the interoperability restriction

Determine whether the conduct concerns:

• API access;
• data formats;
• protocols;
• licensing;
• technical documentation;
• authentication;
• workload migration;
• egress fees.

Step 4 — Determine foreclosure

Ask:

Does the restriction materially impair a rival's ability to compete?

Step 5 — Apply the refusal-to-deal principles

Use the reasoning from:

• Magill;
• Bronner;
• IMS Health;
• Microsoft.

Step 6 — Examine objective justification

Determine whether the restriction is genuinely necessary and proportionate.

Step 7 — Examine consumer effects

Consider:

• higher prices;
• reduced choice;
• lower innovation;
• lower quality;
• slower switching.

Step 8 — Consider remedies

Potential remedies include:

• API access;
• interoperability standards;
• data portability;
• functional equivalence;
• non-discrimination;
• reduction/removal of switching charges.

23. Competition Concerns Created by Cloud Interoperability Restrictions

24. Relationship Between Ex Post and Ex Ante Regulation

There are now two complementary approaches.

Traditional competition law

A competition authority generally asks:

Has a dominant undertaking engaged in conduct that unlawfully restricts competition?

This involves a fact-specific assessment.

Ex ante regulation

Modern digital regulation may instead establish:

Certain interoperability or switching obligations apply automatically to designated services.

The EU Data Act is an important example for cloud switching and interoperability.

The UK and EU developments concerning cloud markets also demonstrate increasing regulatory attention to interoperability as a structural competition issue.

25. Key Case-Law Principles at a Glance

26. Indian Competition-Law Perspective

In India, the principal statutory framework is the Competition Act, 2002, particularly Section 4 concerning abuse of dominant position.

Cloud interoperability restrictions could potentially be examined through concepts such as:

• denial of market access;
• discriminatory conditions;
• unfair conditions;
• leveraging dominance;
• tying/bundling;
• exclusionary conduct.

The critical issue would be establishing dominance in the relevant market and then demonstrating that the interoperability restriction constitutes abusive conduct rather than merely legitimate product design.

Indian competition analysis can therefore draw upon the international jurisprudence on:

• refusal to deal;
• essential facilities;
• interoperability;
• technological foreclosure;
• tying;
• ecosystem leverage.

27. Hypothetical Example

Assume CloudCo controls 60% of a relevant enterprise cloud market.

CloudCo operates a proprietary database platform.

A competing cloud provider, RivalCloud, requests API access.

CloudCo:

1. refuses access;
2. prohibits customers from using the API with RivalCloud;
3. charges RivalCloud substantially more than its own internal cloud division;
4. makes migration technically difficult; and
5. charges high data-egress fees.

The competition-law analysis would examine:

Dominance

Is CloudCo dominant?

Indispensability

Can RivalCloud realistically reproduce the required interface?

Foreclosure

Does refusal prevent effective competition?

Discrimination

Does CloudCo favour its own downstream service?

Switching costs

Do egress charges and technical restrictions lock customers in?

Justification

Are security or technical reasons genuinely responsible?

Effect

Are prices, innovation, choice or quality adversely affected?

Remedy

Could API access, non-discrimination, portability or functional-equivalence requirements restore competitive conditions?

28. Key Legal Distinction

The most important distinction is:

Interoperability is not automatically a right under competition law.

Competition law traditionally intervenes cautiously where a firm is required to share proprietary assets.

The strongest case for intervention generally arises where market power + indispensability + foreclosure + lack of objective justification are established.

However, modern digital regulation is increasingly creating specific ex ante interoperability and switching obligations, reducing the need to rely exclusively on the exceptional refusal-to-deal doctrine.

29. Conclusion

Cloud service interoperability has become an important competition-law issue because cloud markets can produce high switching costs, ecosystem dependency, technical lock-in and barriers to multi-cloud deployment.

The foundational cases of Magill, Bronner, IMS Health and Microsoft provide the principal legal framework for assessing when control over proprietary technology or interfaces can become an abuse of dominance. Slovak Telekom contributes important infrastructure-access reasoning, while Google Android illustrates how contractual and ecosystem restrictions can reinforce market power across interconnected digital services.

The modern approach is increasingly broader than traditional Article 102-style litigation. The EU Data Act expressly establishes cloud-switching and interoperability requirements, while the UK CMA's cloud investigation and subsequent regulatory work have treated interoperability barriers and switching costs as significant structural competition issues.

Accordingly, cloud interoperability obligations can be understood through three complementary principles:

1. Competition law — prevents dominant providers from using interoperability restrictions to unlawfully foreclose rivals;
2. Sector/digital regulation — may impose specific interoperability, portability and switching obligations; and
3. Technical standards — can reduce lock-in and facilitate multi-cloud competition while themselves remaining subject to competition-law scrutiny.

The central legal question is therefore not simply whether a cloud provider has proprietary technology, but whether control over that technology is being used in a manner that materially prevents effective competition and whether interoperability intervention is legally justified and proportionate.

We're doing a quick check to keep ChatGPT reliable. Try again in 18 minutes.