Germany's secrets in Google's cloud: How unsovereign is the planned ND cloud?

Offline, but dependent? The risky price of Google technology for Germany's news services

Google's cloud for German intelligence agencies: What happens if the provider fails?

A cloud service isolated from the internet can effectively protect classified information – yet it can also create a long-term dependency on its technology provider. The planned ND Cloud for the Federal Intelligence Service (BND), the Federal Office for the Protection of the Constitution (BfV), and the Military Counterintelligence Service (MAD) exists precisely within this tension. It is intended to enable the secure exchange of highly sensitive information while operating without a direct connection to the public internet. However, this so-called air gap doesn't answer all the questions: Who can maintain, update, and further develop the platform over the years? And what options remain for the state if the technical or political landscape changes?

For a project with a publicly stated budget of at least €500 million, more is at stake than just server locations and security measures. The crucial question is whether Germany can control the platform in the long term and switch to a different one if necessary. This requires considering not only data protection but also software provision, expertise, migration costs, and potential alternatives. The planned cloud can represent an important step toward modernization – but true digital sovereignty will only be achieved when the state not only controls ongoing operations but also has viable options for the future.

Related to this:

• German Armed Forces deal with Google: How much sovereignty is Germany really giving up for the Google Cloud?

Germany's secrets, Google's technology: The price of digital sovereignty

Offline is far from being independent

A cloud service isolated from the internet can effectively protect classified information, yet still create a long-term dependency on its technology provider. The planned joint data platform of the Federal Intelligence Service, the Federal Office for the Protection of the Constitution, and the Military Counterintelligence Service lies precisely within this tension: The intended technical isolation answers the question of external network access, but not yet the question of lasting technological freedom of action.

The economically decisive question is therefore not whether an American or European company logo appears on the platform. What matters is who determines the conditions for further development, troubleshooting, operation, and potential migration throughout its lifecycle. A convincing sovereignty strategy must combine performance, security requirements, and long-term freedom of choice, rather than solely considering the location of the servers.

A data platform with strategic implications

According to the publicly available planning status as of October 28, 2026, the so-called ND Cloud is intended to enable the electronic exchange of information up to the SECRET classification level between the three federal intelligence services; later, the state offices for the protection of the constitution could also be included. The technical basis is apparently Google Distributed Cloud in a secure configuration, with the information to be stored in Germany and Google not to have direct access to the data.

This is not about storing government secrets on an ordinary internet service. Rather, it envisions a separate infrastructure that can operate without a direct connection to the public internet or the general Google Cloud. This distinction is crucial because it alters the threat landscape: A technically isolated, nationally operated network must be assessed differently than a standard cloud service administered from the outside.

The publicly stated figure is at least €500 million; this is an estimate and not a fully published cost breakdown. A launch originally planned for the first quarter of 2027 is likely to be delayed, while key details regarding architecture, scope of services, and ongoing costs are not publicly available. Based on this information, it is impossible to calculate a reliable return on investment or to definitively claim that a particular alternative would be a fixed percentage cheaper.

However, the sheer scale of the project demonstrates that the platform would be more than just an ordinary IT system. It would shape workflows, data models, and qualifications for years to come. The more government agencies align their specialized procedures with shared technical services, the greater the strategic importance of those decisions that initially appear to be purely infrastructure matters.

Why shared infrastructure can make economic sense

The need for modernization is fundamentally plausible: Exchanging high-level information between protected government systems is currently cumbersome, while storage requirements and demands for automated analysis are increasing. A shared platform can simplify data transfers, provide standardized tools, and accelerate collaboration, provided that permissions and responsibilities are clearly defined.

From an economic perspective, potential advantages arise from economies of scale. If computing power, data backup, monitoring, and security processes are provided jointly, not all authorities need to develop the same capabilities in parallel. This can improve utilization and relieve the burden on scarce skilled personnel; BWI describes standardized and automated cloud infrastructure accordingly as a means to achieve more flexible and efficient IT services.

Added to this is the benefit of faster information processing. A high-performance technical environment can prevent existing intelligence from becoming available too late due to cumbersome processes. This benefit is difficult to quantify in euros for intelligence services, but it is not therefore economically insignificant. However, a plausible security gain must not be used as an arbitrarily flexible argument to retrospectively justify any technological dependency.

The correct comparison, therefore, is not between a modern cloud and a risk-free existing infrastructure. Fragmented legacy systems also incur costs and security risks, for example through complex maintenance and manual processes. A proper assessment must consider the risks of migrating as well as the costs of inaction; however, the need for modernization alone does not prove that every platform offered for this purpose is economically viable in the long run.

The air gap only solves part of the problem

The term "air gap" here refers to a separation from the public internet and other external networks, not necessarily the complete isolation of each individual computer from one another. Within a protected government network, systems can continue to collaborate, while strict boundaries exist for external access. Google explicitly describes the platform as being permanently operable without a connection to the public Google Cloud.

This feature is a significant security advantage and should not be underestimated. The absence of external connections limits certain attack vectors and creates better conditions for controlled operation. However, this does not mean that the platform can be securely maintained or functionally expanded indefinitely without further services from the manufacturer; technical network independence and independence of software provision are distinct properties.

This can be illustrated by comparing it to a production plant located entirely on a German factory site. The location protects physical control, but doesn't guarantee the availability of spare parts, control software, and specialized knowledge at all times. Just because someone operates the plant doesn't mean they can independently develop it further. The same economic logic applies to a highly complex cloud environment.

Sovereignty is therefore not a single switch. Data sovereignty, administrative control, legal certainty, supply chain transparency, and technological adaptability must be considered separately. A platform can have strong characteristics in some of these dimensions and exhibit significant dependencies in others; it is precisely this differentiation that makes a sound assessment possible.

Updates as an interface of economic power

Google's security documentation describes a controlled update process: The manufacturer signs software packages, the infrastructure operator reviews them, and then deploys them to the isolated environment. This process encompasses not only cloud software but also operating systems, firmware, and other security-relevant components. An automatic internet connection is not required, but the ongoing technical supply relationship remains in place.

This is initially a normal part of professional software operation and not evidence of manufacturer misconduct. The situation becomes problematic when only one provider can deliver reliable updates in a timely manner. In such cases, the system's practical security depends not only on the national operator but also on an external development organization and its legal and economic framework.

The extent of such dependencies is demonstrated by the publicly available standard terms and conditions for Google Distributed Cloud air-gapped. These stipulate that new versions must be installed within 30 days of notification; they also contain rules regarding the termination of maintenance and the end of software use after the expiration of the license period. However, these general terms and conditions should not be equated with unknown special provisions of the planned messaging platform.

This distinction is crucial. It cannot be publicly verified what individual operational rights, audit periods, or additional security measures are in place for the ND Cloud. Likewise, it would be unfounded to infer from a continuing dependency on updates that there is secret remote access or a technical shutdown mechanism. What is documented is the manufacturer's ongoing role in software provision, not arbitrary external access.

The dangerous difference between runtime and safety

In the event of a manufacturer support outage, several scenarios must be considered. An already installed system may initially continue to function technically, while newly discovered security vulnerabilities will no longer be patched. At the same time, usage rights, spare parts availability, and support for dependent applications may be affected. Therefore, the question of how long the computers will remain powered on is less meaningful than the question of how long responsible operation would be possible.

A fixed, general lifespan cannot be derived from this. It would depend, among other things, on existing vulnerabilities, local repair options, the use of additional services, and the availability of qualified personnel. Blanket statements that an isolated cloud inevitably becomes unusable after a certain number of months would be just as imprecise as claiming unlimited independence.

Economically, this creates an options problem: A state needs not only current functionality but also the ability to act in the event of changed circumstances. This option has value, even if it remains unused for years. Financing it is similar to insurance against a rare but potentially very costly loss of technological decision-making power.

A robust emergency plan would therefore have to differentiate between limited continued operation, full restoration, and migration to another platform. Separate prerequisites would need to be examined for each of these scenarios. For example, a simple backup of the data is of limited help if the programs needed to process the information effectively and enforce the relevant access rules are lacking.

Dependence increases with each specialized procedure

The frequently used term "lock-in" describes a situation in which switching providers remains theoretically possible, but becomes increasingly complex in practice. In cloud systems, this lock-in arises from the interplay of platform functions, interfaces, data structures, and established operational processes. The more specialized applications require specific services from a particular vendor, the greater the effort required to replicate equivalent functionality elsewhere.

Not every use of proprietary technology is uneconomical. A specialized tool can offer a significant productivity advantage. The difficulty lies in the fact that the short-term benefits are often readily apparent, while future switching costs remain uncertain. This risks creating a systematic imbalance: current convenience is fully considered, while future dependency is only mentioned in abstract terms.

The application-level binding is particularly relevant. A virtual machine can be transferred relatively easily, whereas a complex business application with vendor-specific database, identity, and analytics services cannot. Therefore, the fact that a platform supports containers is not sufficient proof of its interchangeability. The crucial factor is whether the entire business functionality can be deployed in a different environment with reasonable effort.

A consistent architecture would have to weigh the benefits of specific platform services against the resulting barriers to switching. The goal would not be complete technical uniformity, but rather deliberate differentiation: Standardized basic functions should remain interchangeable as much as possible, while essential specialized functions would be examined separately for their added value and dependencies.

Europe's market problem begins with the scale

The structural challenge extends far beyond German intelligence services. The European market for cloud infrastructure services reached a volume of approximately €61 billion in 2024, roughly six times larger than in 2017; this figure includes infrastructure and platform services as well as hosted private clouds, but not the entire software market. European providers more than tripled their corresponding regional revenues during this period, but nevertheless lost relative market share.

Their combined share fell from 29 percent in 2017 to approximately 15 percent in 2022 and subsequently remained at roughly that level; Amazon, Microsoft, and Google together accounted for around 70 percent in the market survey published in mid-2025. These figures refer to the European market and should not be equated with a market limited exclusively to the EU, nor with the specific segment of closed intelligence systems.

This development demonstrates why revenue growth alone does not guarantee technological independence. European companies can become more successful while simultaneously falling behind the largest platforms. The leading providers spread development costs and investments across very large customer bases; accordingly, scalability and long-term financed investments play a crucial role in the European infrastructure market.

A realistic European strategy would therefore not need to copy every function of the largest hyperscalers. It would be more plausible to develop robust alternatives for particularly critical application areas and to jointly advance established technical foundations. A security-oriented niche market may have different success factors than the mass market for standardized computing power. A corporation's general market leadership does not automatically translate into its superiority for every governmental application.

The state as a driver of technological learning curves

When many public institutions have similar requirements for data sovereignty and secure collaboration, common standards can create a larger, more reliable market. Companies then have a better foundation for investing in documentation, security audits, and professional operations. The openDesk ecosystem, with its multiple software and operations partners, demonstrates that such a collaborative approach is already being implemented in practice.

This provides an economic policy argument for the targeted use of suitable European solutions. Their benefits are not limited to the individual workplace but can extend to later applications and other facilities. Reusable components, qualified personnel, and proven operating models potentially reduce the entry costs for subsequent users. These additional effects are easily underestimated when considering only the initial implementation.

At the same time, this must not create an entitlement to permanent protection. European providers, too, must demonstrate performance, reliability, and economic viability. A policy that protects every local solution regardless of its quality could generate high costs and new dependencies. The crucial point is not the elimination of competition, but the creation of genuine technical and economic alternatives.

It is also crucial to prevent an international monopoly from being replaced by a barely verifiable national dependency. Open interfaces, transferable operational knowledge, and multiple qualified service providers are therefore just as important as the company's headquarters. Ultimately, sovereignty should enhance the user's ability to act, not merely change the origin of their most important supplier.

The Security and Defence Hub offers expert advice and up-to-date information to effectively support companies and organizations in strengthening their role in European security and defence policy. Working closely with the SME Connect Defence Working Group, it particularly promotes small and medium-sized enterprises (SMEs) that wish to further develop their innovative capacity and competitiveness in the defence sector. As a central point of contact, the Hub thus creates a crucial bridge between SMEs and European defence strategy.

Related to this:

• The SME Connect Defence Working Group – Strengthening SMEs in European Defence

OpenDesk is relevant, but not a complete cloud replacement

The office and collaboration suite openDesk was launched in October 2024 and, according to the responsible Centre for Digital Sovereignty, was installed at approximately 100,000 administrative workstations by October 2026. This figure represents the reported adoption rate, not proof of 100,000 daily active users or a corresponding number of highly confidential workstations. Nevertheless, it demonstrates that European open-source collaboration has long since moved beyond small demonstration projects.

Technically, the comparison must remain precise. OpenDesk bundles applications for office work and collaboration, while Google Distributed Cloud is a much broader infrastructure and service platform. A collaboration suite does not automatically replace the storage architecture, databases, computing resources, and specialized services of an entire intelligence environment. Anyone who presents both offerings as directly interchangeable, complete solutions is confusing different technical levels.

Nevertheless, openDesk is important for the debate because not every everyday collaboration needs to require a consistently proprietary platform. Where public authorities jointly edit documents, coordinate projects, or communicate, open applications can offer concrete alternatives. This can at least reduce some of the dependency, even if different infrastructures are still used underneath.

In October 2026, the operation of openDesk in completely isolated environments was demonstrated and tested; concurrently, the focus was on securing it for the "VS-NUR FÜR DEN DIENSTGEBRAUCH" (Restricted - For Office Use Only) classification. This should not be interpreted as proof of operational readiness for all processing tasks up to the "GEHEIM" (Secret) level, as these classifications are clearly distinct. A functioning offline demonstration is an important technical step, but not a blanket proof of suitability for all highly sensitive use cases.

The matrix demonstrates the benefits of open communication

Element and the open Matrix protocol also provide practical starting points. The BwMessenger is based on these components and is operated by BWI in the Bundeswehr's own data centers; the BundesMessenger transfers this approach to public administration. Thus, concrete experience with state-controlled communication on an open technical basis already exists.

The economic advantage of such foundations lies in the fundamental separability of software, operation, and service. If a public authority operates its own infrastructure or can choose between suitable operators, better conditions for competition arise. Control over the ongoing service then does not necessarily have to remain with the original software manufacturer.

However, even a messenger service is not a complete analytics platform. Secure messaging, collaborative document editing, and the processing of large datasets are distinct tasks. Furthermore, each specific configuration must meet the necessary security requirements; government use does not automatically imply suitability for every security classification level. Open communication is therefore an important component of a sovereign architecture, but not a universal solution to all infrastructure problems.

Openness does not replace one's own competence

Open-source software can expand control options because its structure is transparent and further development can, in principle, be distributed among multiple stakeholders. However, this possibility only unfolds its full potential if genuinely qualified specialists, suitable development tools, and sustainably funded responsibilities are available. Transparent source code alone does not automatically eliminate security vulnerabilities or problematic dependencies.

Especially with complex systems, it is not enough to simply be allowed to modify individual programs in theory. What is needed is knowledge of how they interact, the creation of reliable installation packages, and the testing of new versions. The focus on hardened core components and secure supply chains in the government's open-source ecosystem demonstrates how essential this organizational level is.

Openness is therefore more of a prerequisite for additional courses of action than a free guarantee. Its economic benefit lies in the fact that investments in knowledge and development can be more easily reused between institutions. For this to succeed, adaptations should ideally be fed back into jointly maintained foundations. Many permanently separate, specialized versions, on the other hand, would increase maintenance costs and security risks.

Staffing shortages must also be addressed realistically. An agency does not become sovereign by taking on all the work itself. A more sensible model is one in which the state possesses sufficient in-house assessment and control authority while simultaneously being able to draw on several professional service providers. This does not eliminate dependencies entirely, but it makes them more easily verifiable and manageable.

The German Armed Forces present a more nuanced picture

For contextualizing the ND Cloud, the German Armed Forces' private cloud is relevant because it also incorporates Google technology and BWI plays a central role. However, this platform is not synonymous with a single Google Cloud: The German Armed Forces pursue an approach using several technologically separate environments, including VMware, Google, and open-source software.

The first phase of the rollout was introduced in 2025; the development and integration of the Google stack were outlined starting in 2026, with completion planned for the end of 2027. The SAP Business Technology Platform is cited as a specific use case, while two separate environments are planned for open and classified information (VS-NfD). This published timeline should not be interpreted as a final operational status.

This example illustrates that fundamental software decisions can lead to further infrastructure decisions. If a specialized platform is needed whose supported operating environments are narrowly defined, the actual selection narrows even before considering individual cloud providers. A sovereignty analysis must therefore examine the entire technical chain and cannot end at the visible infrastructure marker.

However, multiple platforms only create true scalability if essential applications can actually be moved between them. Three separate environments, each with its own tightly bound procedures, initially mean diversity, but not yet mutual interchangeability. BWI explicitly cites the reduction of vendor dependencies and the effortless migration of applications as goals of its approach.

Legal risks demand technical precision

Debates about American technology often refer to the CLOUD Act. The legal premise is that companies subject to US law can be compelled to disclose data in their possession, custody, or control, regardless of where it is stored. Therefore, simply being located in Germany does not automatically eliminate all legal risks.

Conversely, a legal right to disclose data does not create technical access that did not previously exist. If a provider genuinely has neither access to the data nor control over the necessary keys, this architecture must be considered in the legal assessment. Therefore, an isolated platform cannot simply be equated with a conventional, manufacturer-operated internet service.

For the ND Cloud, details that are not publicly known remain crucial: Which roles are available locally, how do emergency access procedures work, what information is needed for error analysis, and who controls the cryptographic keys? The general Google documentation outlines separate operational roles and specific emergency procedures, but this does not automatically describe the final German implementation. A blanket all-clear would therefore be just as inappropriate as the unsubstantiated claim of automatic American data access.

This must be distinguished from the risk of disruption to services. Even if data access is technically impossible, legal or geopolitical conflicts could affect services such as software maintenance and support. A comprehensive sovereignty assessment must therefore examine both control over information and the continuity of essential services.

What an honest cost calculation should contain

A comprehensive economic analysis would need to encompass more than just hardware and initial software costs. It must also include integration, personnel, energy, training, security monitoring, data backup, restart capabilities, and the ongoing adaptation of specialized processes. For the ND Cloud, publicly available detailed data is lacking to reliably quantify these components; the known estimate of at least €500 million does not replace this breakdown.

Additionally, costs that only arise during a migration must be considered. These include data transfer, program adaptation, temporary parallel operation, and renewed security audits. Accordingly, European regulations on cloud migration distinguish between several technical steps, from data extraction to migration to a target environment. A financially significant migration therefore involves far more than simply downloading a file archive.

It is also important to distinguish between household costs and macroeconomic effects. Services provided by German data centers and service providers can generate local added value, even if the core software comes from an international corporation. Conversely, a European provider is not free from global supply chain dependencies. A sound analysis would therefore have to consider the actual distribution of expertise and revenues, rather than simply attributing all expenditures to a single country of origin.

Ultimately, different crisis scenarios would need to be assessed separately. A short-term support outage, a longer-term cessation of updates, and a short-term platform switch would each have different consequences. Instead of generating a seemingly precise single figure for all risks, it would be more appropriate to make bandwidths, assumptions, and particularly severe consequences transparent. Sufficient publicly available project data is currently lacking to determine such values.

Measurable autonomy instead of reassuring labels

With the Criteria enabling Cloud Computing Autonomy, published in April 2026, the German Federal Office for Information Security (BSI) has presented a framework designed to make the self-determined use of cloud services more systematically assessable. These criteria complement the security-oriented C5 requirements, but do not have a regulatory effect on their own. Security and sovereignty are thus explicitly treated as related, yet distinct, assessment issues.

The framework distinguishes between strategic, legal, data-related, operational, supply chain-related, and technological aspects. Specific test metrics, such as the transferability of operational knowledge, the availability of independent maintenance, and the ability to continue operations in the event of a third-party failure, are relevant here. Such characteristics are more meaningful for a high-security platform than a general self-description as sovereign.

For practical operation, a regularly tested restart procedure would be particularly valuable. This would demonstrate whether existing backups, documentation, and expertise are sufficient to restore essential functions under clearly defined failure conditions. It would also allow testing of which data and applications are actually usable on a secondary environment. A successful test would be more effective than a purely theoretical option for switching.

Even regulatory advances do not change this technical challenge. The Data Act prohibits switching fees for covered data processing services from January 12, 2027. However, this does not automatically mean that every specific intelligence environment falls under this prohibition, nor does it eliminate internal migration, development, and security costs. Cost-free switching for the provider and actual technical interchangeability are not the same thing.

More computing power requires clear access limits

A shared platform can facilitate cooperation, but it must not level the playing field by simplifying technical aspects and minimizing differing legal responsibilities and data rights. A shared infrastructure does not automatically grant blanket permission for all parties to freely use all information contained therein. Particularly when exchanging information between intelligence services and the police, there are heightened constitutional requirements that must not be confused with mere exchanges between intelligence services.

For the architecture, this means that roles, purposes, origin, and permissible sharing of data must be appropriately mapped. Technical platforms can support fine-grained access rules and traceable logging; Google's documentation describes role- and attribute-based permissions as well as access logging. However, the lawful, practical application remains the sole responsibility of the responsible parties.

Furthermore, there is a risk of concentration. Shared infrastructure can pool security expertise, but at the same time, a serious disruption could affect multiple agencies. Therefore, logical separation, recovery, and independent control mechanisms must be considered together. The economic evaluation should not depend solely on data center utilization, but also on how well critical functions are maintained during partial disruptions.

AI shifts the dependency to the model level

Automated translation, summarization, and analysis of large datasets are plausible applications for a closed cloud; Google offers corresponding AI functions for this product family. This allows the technical integration to extend beyond infrastructure to include models, interfaces, and the organization of analytical workflows. The more specialized processes are aligned with specific AI services, the more important their interchangeability becomes.

A locally operated model, however, is not automatically sovereign. Usage rights, updatability, available model components, and the ability to continue using the tool under changed conditions are also relevant; the general product terms explicitly differentiate between various models and forms of use. Whether specific AI offerings are actually intended for the ND Cloud cannot be inferred from general product availability.

From an economic perspective, AI should therefore be measured by the quality of its results, not just by the number of documents processed. Additional expenditure can be valuable if it accelerates analysis and makes relevant insights easier to find. However, it can also generate follow-up work if erroneous summaries or incorrect links need to be checked; the provider generally points out potential errors in the output of generative systems.

A strategically robust design would therefore separate data storage, models, and user interfaces as cleanly as possible. This would allow individual analysis tools to be updated without necessarily having to replace the entire platform. Especially with rapidly evolving AI technologies, the ability to implement controlled updates is an economic advantage, not merely a political requirement.

International cooperation without permanent core dependency

Exchange with partner services may require compatible technical procedures. However, this does not necessarily mean that all internal work processes must take place on the same platform. The German Armed Forces (Bundeswehr) cites international interoperability as a key objective of its multi-platform strategy and explicitly links this to reducing vendor dependencies.

A sensible approach would be to differentiate between core national operations and clearly defined exchange functions. Specialized interfaces and approved transfer procedures could be used for international cooperation, while central data repositories and fundamental collaboration would remain independently manageable. The involvement of an international technology provider would thus be a functionally limited decision and not automatically the basis for all internal processes.

However, interfaces don't solve every problem. Different confidentiality levels, data models, and release rules create additional overhead. A more decoupled architecture can therefore initially be more expensive and complex. Its advantage lies in the fact that individual collaboration functions can be modified without affecting the national core operation in the same way. Whether this advantage justifies the additional costs would have to be examined based on specific requirements.

The crucial skill is the ability to switch

The most convincing perspective from a technical standpoint lies neither in a blanket rejection of American technology nor in the assumption that technical network separation resolves every sovereignty issue. The planned ND Cloud could address real performance problems; however, its isolated architecture and the continued reliance on external software provision must be evaluated separately.

For general collaboration, suitable open solutions deserve systematic evaluation because openDesk and Matrix-based services are already practically deployed building blocks. Different technical requirements may apply to highly specialized processing. Crucially, justified exceptions should not be extended into a blanket, permanent dependency, and the remaining risks should be explicitly identified.

A robust strategy would therefore need to combine in-house assessment expertise, transparent update processes, and proven contingency plans. Not every application requires a fully functional secondary platform that is immediately available. However, critical functions should be designed in such a way that an external performance failure does not necessarily lead to a loss of governmental capability. This requires technical safeguards as well as qualified personnel and long-term funding.

The real test of sovereignty doesn't occur during uninterrupted, normal operation. It begins the moment a vendor changes its terms, support fails, or political frameworks shift. A high-performance cloud is valuable to the state. It only becomes strategically manageable when the state not only controls its current operation but also has viable options for its future.

I would be happy to serve as your personal advisor.

Head of Business Development

Chairman SME Connect Defense Working Group

LinkedIn

 

 

I would be happy to serve as your personal advisor.

You can contact me at wolfenstein∂xpert.digital or

Just call me on +49 7348 4088 965 .

LinkedIn