Can your business survive without Google? Dr. Mark Eger, CEO of Kyiv Consulting, investigates realistic digital sovereignty.
APRIL 2026 | 11 mins read
This question arose from my practical experience, when it became clear how critically business infra-structure depends on BigTech platforms. Europe has been at odds with the oligopoly of the large tech platforms for years. The reasons are well known market power, data flows, competition, mod-eration obligations, security requirements and increasingly geopolitical issues. There are technical risks that don't feel like classic security vulnerabilities but can have the same effect: they don't arise from a bug in the code, but from a unilateral decision by a platform operator or by a regulatory intervention.
And the most interesting thing here is that the real impact of these restrictions and changes can manifest in the day-to-day operation of digital products and services: a business may find that certain applications stop working, integrations between systems become unavailable and key functions such as authentication, data synchronisation, or payment operations may become restricted, without any possibility for intervention from the user or the company.
I therefore asked myself what realistic risk minimisation might look like. Not as an ideological project, but as a practical answer to a sober question: How can I design my digital life so that it is not – or as little as possible – dependent on Google?
It is important to me to formulate the problem precisely. In this article I primarily examine the pos-sibility of becoming independent of Google Mobile Services (GMS). The key distinction lies in the fact that using Android without GMS still preserves Android as the technical foundation while minimising or avoiding Google’s proprietary service layer, whereas abandoning Android altogether involves moving to Linux-based mobile systems.
When it comes to the question of whether everyday life without dependence on Big Tech platforms is possible, it is decisive which Android layer is used. Android is a code base (Android Open-Source Project, AOSP) and Android is a platform ecosystem (GMS). AOSP is the openly developed core of Android, providing the fundamental building blocks required for a smartphone to function, including system services and frameworks, a user interface, basic hardware control and security mechanisms implemented within the open-source core. It serves as the technical foundation that makes it possible to operate Android devices without Google and underpins many alternative systems as well as “de-Googled” strategies. However, AOSP alone does not constitute a complete app ecosystem, as it does not offer a universal solution for app distribution, push notifications, or the provision of certain APIs (Application Programming Interface) this is where an additional layer beyond AOSP becomes necessary.
GrapheneOS and CalyxOS are two Android-based systems that aim to reduce dependence on GMS while improving privacy and security, but they do so in different ways and with clear practical limits. GrapheneOS follows a strict “security-first” approach, removing GMS by default while still allowing them to be installed as standard sandboxed apps if needed. CalyxOS takes a more usability-oriented approach by integrating microG as a compatibility layer to improve app functionality and push notifications, at the cost of a closer link to Google infrastructure. Both systems support standard Android app usage on selected devices, but neither eliminates the structural constraints of critical apps like banking, payments or DRM services (Digital Rights Management) and both depend heavily on long-term project maintenance. As a result, they represent not absolute independence, but different trade-offs along a spectrum between strict security boundaries and everyday usability with reduced Google dependency.
Ubuntu Touch is an open-source mobile operating system (OS) created as an alternative to Android and iOS, designed with a focus on independence from large ecosystems (notably without GMS). Ubuntu Touch is particularly relevant in Europe because it represents a serious attempt to operate a smartphone OS with more open structures and a different governance model. Ubuntu Touch is a Linux-based mobile OS that emphasises independence from dominant platform ecosystems by relying on open technologies, standard-based workflows and alternative governance. However, its main limitation is app availability: while communication tools and web-based services are generally well supported, many platform-specific apps, especially in areas like banking, payments and DRM stream-ing are difficult or impossible to replicate due to strict security requirements.
Waydroid helps bridge this gap by running Android apps in a container, but it introduces limitations in certification, stability and true independence, effectively shifting rather than eliminating dependen-cies. As a result, Ubuntu Touch works best in web-centric use cases, for users intentionally reducing app reliance, or within a hybrid approach where only a few essential Android apps are used, high-lighting a key trade-off between app compatibility (favouring Android without GMS) and control and independence (favouring Linux-based systems).
Personally, I prefer the German Volla as my primary smartphone, since it is specifically designed for alternative mobile strategies. Unlike most mass-market devices, it is not tightly bound to a single ecosystem and allows the use of different operating systems depending on one’s needs. This flexibility makes it a practical foundation for reducing dependence on platforms without losing convenience in everyday use.
While many aspects of digital independence, such as using smartphones without GMS or adopting Linux-based systems, appear technically feasible in Europe, the real challenge lies in critical app categories like banking, payments, ticketing and DRM, which operate under strict security and governance models beyond user control. These apps check whether they are allowed to run, relying on integrity checks, attestation and platform-specific trust models that often exclude devices outside mainstream ecosystems.
As a result, both Android without GMS and Linux-based systems face structural limitations: the former lacks expected infrastructure and trust signals, while the latter is outside standardised app ecosystems altogether. This makes such apps a decisive constraint rather than a minor inconvenience, requiring a pragmatic approach to digital sovereignty — classifying which functions are essential, replaceable, or optional and adopting realistic strategies such as prioritising web and standards-based solutions, isolating unavoidable dependencies in controlled environments and pursuing gradual rather than absolute independence.
Despite this, a significant ecosystem of alternatives and practical solutions already exists. For exam-ple, devices such as Fairphone or Volla Phone are actively used as a foundation for Android without GMS. Operating systems such as GrapheneOS and CalyxOS demonstrate that a fully or partially de-Googled ecosystem is viable for everyday tasks. At the same time, companies like Nextcloud or Info-maniak are already building infrastructure that replaces key Google services in the areas of synchro-nisation, email and collaboration.
I have also prepared a checklist of components for a strategy for working without GMS, covering hardware, operating systems, and applications, as well as an assessment of their suitability for use without GMS.
Microsoft 365 is an ecosystem of cloud services (a SaaS platform) consisting of separate but tightly integrated components: Exchange Online (email, calendar, contacts), OneDrive (file storage), Share-Point (content and documents), as well as Office web/desktop applications and collaboration services such as Microsoft Teams. Each of these components has its own dependency model, security policies, and integration mechanisms.
In the context of digital sovereignty, Microsoft 365 should be viewed not as a single product but as a bundle of services, email, calendar, contacts, cloud storage, office apps and collaboration, each with different dependency profiles. Standard-based components can usually be integrated into GMS-reduced setups using protocols such as IMAP (Internet Message Access Protocol), Exchange or CalDAV (Calendar Distributed Authoring and Versioning)/CardDAV (VCard Extensions to WebDAV) with modern authentication, making them relatively independent.
In contrast, services like OneDrive and native Office apps depend more on background processes, push notifications and platform-specific integrations, which can reduce reliability and convenience without GMS.
BREAKING DOWN
Anyone concerned with digital sovereignty quickly ends up looking at operating systems. That's understandable, but it's often the wrong place to start. In practice, many attempts to become more “independent” fail because of an incomplete strategy: one level is replaced, while the others remain unchanged. The hasty conclusion is then that independence is not possible. That's why I'm using a simple model in this series that separates decisions into three levels. It sounds trivial, but it prevents potential errors in thinking.
Anyone who is serious about resilience must consider the lifespan of the hardware. A device that ends up without updates or spare parts after three years creates dependency because it forces you to buy a new one.
Security architecture is also important because whether a system can be reliably protected against manipulation depends heavily on the hardware. This includes verified boot, secure key storage, protection against downgrade attacks, and an update path that delivers security fixes to the device.
“Kill switch” is often understood as a dramatic remote shutdown. A more realistic and subtle variant is dependencies in baseband, drivers, firmware update channels, or proprietary components that cannot be independently audited or replaced. The discussion about “kill switches” and “spyware” is often conducted emotionally. A sober assessment makes technical sense: At the hardware level, it's about control points that lie outside the operating system.
The operating system is the visible part of the debate, but it is not only the interface that is important, but also governance: Who controls the code, the updates, and the integrations?
Open code alone does not guarantee independence. If an open system still relies on proprietary infrastructure in everyday use, dependencies arise elsewhere. That's why the choice of operating system must always be considered together with Level 3.
Push is the timing of modern communication. Without push, the functionality of an app is not lost, but it becomes impractical: messengers, delivery services, mobility apps, in some cases identity and security mechanisms. Those who tie their identity to central providers are bound by their rules. This applies not only to account suspensions or contract terms, but also to technical integrations.
Many apps use map Software Development Kits (SDKs), captcha mechanisms, or integrity checks as building blocks, that are often difficult to replace because they are deeply embedded in the product design. This is exactly where the famous breaks occur: an app starts, but a core function is blocked.
A company based in the EU is subject to EU law, in particular data protection, consumer and compe-tition law. However, it is no guarantee that the supply chain is European or that there are no dependencies on third countries. The question here is whether there is a European production step that is more than just logistics. What is important here is the vertical range of manufacture: Is it just packaging, or does final assembly, testing, quality control and repair infrastructure take place on site? “European” is therefore a bundle of legal jurisdiction, manufacturing, transparency, update govern-ance and sustainability. Looking at only one dimension gives a distorted picture.
Email is one of the strongest real-world examples of digital sovereignty because it is built on open, decentralised standards rather than ecosystem lock-in. European email providers that support IMAP/SMTP with proper TLS security allow users to freely choose clients instead of being tied to app stores or platform APIs, while modern authentication methods like OAuth2 or TOTP-based (Time-based One-Time Password) two-factor authentication ensure security without forcing proprietary apps.
The crucial question is not only where a device comes from, but whether it is suitable as a stable basis for a more independent software and service setup. If a device is strong in security architecture, driver and firmware reality, updateability, manufacturer policy, it can be a very suitable foundation for reducing GMS dependencies without completely losing everyday functionality. This is precisely where the rational argument lies: platform dependency can be reduced at the service and OS level, even if the hardware does not originate in Europe.
At the hardware level, complete independence is hardly achievable today, regardless of the continent. The reason is trivial but important: many central components are proprietary, especially the mobile phone modem. The sensible approach is therefore not “100% independent,” but rather a sovereign hardware strategy is therefore a strategy of risk minimisation, transparency, and resilience, not absolute purity.
Without naming specific manufacturers, non-European devices can be divided into three profiles:
PROFILE A
Strong boot chain, reliable updates, solid key management. The best foundation for a GMS-independent setup, but often comes with the manufacturer's own ecosystem attached if you stay on the default OS.
PROFILE B
Such devices often low-cost and widely available. However, the key issue for sovereignty is how reliably security updates are provided over the years.
PROFILE C
Easy to unlock and popular in the community, these devices are good for testing alternative systems. Just keep in mind that unlocking might reduce security by affecting Verified Boot or other features.
For a sovereign strategy, Profile A is often significantly more valuable than Profile C. Independence without security is not sovereignty, but just another risk. Digital sovereignty is not about achieving 100% isolation, but about minimising risks through informed choices. By focusing on hardware transparency, long-term update paths, and security architecture, we can build a resilient digital life that survives even in Big Tech shifts.
STAY TUNED
Conclusion
Digital sovereignty is not about a complete rejection of large technology platforms, nor is it an ide-ology. It is about control, predictability, and risk reduction in an environment where key decisions can be made without the involvement of the user or business. The reality is that absolute independence is nearly unattainable today. The practical approach is different: clearly understand where dependencies arise, consciously limit them where possible and define alternative scenarios where they are critical.
This means thinking in terms of architecture: separating hardware, operating systems, and services. The key shift is in mindset not “how to completely abandon Big Tech” but how to build a system that remains operational even when individual dependencies stop working.
No, but it is possible to significantly reduce dependencies on specific platforms, services, and ecosys-tems through alternatives, open standards, and well-designed architecture.
Partially. They work well for web-based and basic tasks but are weaker when it comes to mainstream applications.
Android is the open-source code base (AOSP) that provides the technical foundation of the system, while GMS is Google’s proprietary service layer that includes apps, APIs, push infrastructure, and ecosystem integrations.
No. GrapheneOS and CalyxOS both reduce Google dependency, but they represent trade-offs. Gra-pheneOS focuses on strict security with optional sandboxed Google components, while CalyxOS prior-itises usability through microG.
Yes, partially. Microsoft 365 can be integrated via standard protocols like IMAP, Exchange, CalDAV, or CardDAV, making email and calendar relatively independent. However, services like OneDrive and native Office apps rely more on push notifications and background processes, which reduces conven-ience without GMS.
No. European jurisdiction improves legal transparency and data protection but does not guarantee supply chain independence or technical autonomy.
Because it is based on open, decentralised standards like IMAP/SMTP and can be combined freely with different clients. With protocols such as CalDAV, CardDAV, OAuth2, and TOTP, email systems remain portable across platforms and devices.
Ubuntu Touch offers a more open, Linux-based alternative but struggles with app availability. Waydroid bridges this gap by running Android apps in a container but shifts dependencies instead of removing them.
INSIGHTS
Explore how GovTech, digital public services and government technology platforms are evolving across Europe and Ukraine.
Get a comprehensive outlook on the negative and positive impact of COVID-19 on the environment, and an expert view on the future perspective and challenges.
Kyiv Consulting's HR Director, Kateryna Kuzmenko, shares her team's expert insights into the labor market situation in Europe and Ukraine.
READY TO TALK?
Please fill in the field.
Please fill in the field.
Please fill in the field.
Please fill in the field.
Please fill in the field.
Please fill in the field.
