Europe's digital ID: How dependent is the EUDI wallet on Google and Apple?

Xpert Pre-Release

Available in 27 languages 📢

Published on: November 5, 2026 / Updated on: November 5, 2026 – Author: Konrad Wolfenstein

Europe's digital ID: How dependent is the EUDI wallet on Google and Apple? – Creative image on the topic, created with AI: Xpert.Digital

EUDI Wallet: Europe's digital identity between progress and platform power

Europe's digital wallet: More convenience – but also new dependencies?

Digital sovereignty on the smartphone: Who controls Europe's new wallet?

The European Digital Identity Wallet, or EUDI Wallet for short, is intended to simplify everyday digital life: It will allow citizens to present identity documents and other proof of identity on their smartphones, share personal information more selectively, and complete digital processes more easily. Member states must provide at least one such wallet by December 24, 2026, at the latest. But behind the promise of a unified European infrastructure lies a fundamental question: Who will ensure that the technical requirements for its functionality on a smartphone are met?

To verify the security of a device and wallet, providers can rely on services whose rules are largely shaped by Google or Apple. This can simplify development and facilitate security audits. At the same time, there is a risk that alternative operating systems or devices will be excluded—not necessarily because of a specific security flaw, but because they do not meet the criteria of a particular platform ecosystem.

This makes the EUDI wallet a litmus test for Europe's digital sovereignty. It can accelerate administrative and business processes, reduce costs, and strengthen data protection. However, whether it simultaneously promotes freedom of choice and competition depends on who sets the security rules, how transparent these rules are, and whether equivalent technical alternatives are recognized. Europe must therefore not only provide a digital identity but also decide how independent its use should be from private platforms.

Europe's digital ID: How the EUDI wallet stands between economic progress and platform dependency

Confident on paper, dependent on the smartphone

Europe wants to shape its own digital identity. The European Digital Identity Wallet, or EUDI Wallet for short, is intended to create a central infrastructure for this: people should be able to identify themselves with their smartphones, present digital evidence, and, in the future, legally sign documents. The ambition goes far beyond a more convenient ID app. It's about a common digital trust space that facilitates cross-border transactions, reduces administrative burdens, and strengthens control over personal data. According to the European timetable, member states must provide at least one such wallet by December 24, 2026, at the latest. Its use will remain voluntary for citizens.

However, a fundamental conflict of objectives arises precisely at the interface between this public infrastructure and the private smartphone. To verify the security of the device and the application, wallet providers can rely on services whose rules are largely determined by Google and Apple. Thus, the practical usability of a digital identity is not solely determined by the European legal framework. The security architecture of the mobile platforms and the interpretation of their test results also become prerequisites for access.

The economically crucial question, therefore, is not whether American technology is fundamentally unsuitable. It is under what conditions a public identity infrastructure may use private platform services without permanently entrenching their market structure. A technically convenient decision may save development costs in the short term but simultaneously create long-term dependencies. Conversely, a more open architecture is not automatically cheaper or more secure. It requires its own auditing capabilities, clear approval rules, and continuous maintenance.

The EUDI wallet is thus a particularly revealing example of a fundamental European problem: Digital sovereignty does not arise simply through European laws or government-developed apps. It arises where public authorities can actually define, monitor, and, if necessary, amend the crucial technical rules.

A digital wallet as basic economic infrastructure

The EUDI wallet is intended to do more than simply serve as an electronic representation of an identity card. At its core, it consists of digitally signed documents whose authenticity can be verified automatically. These can include identity data, driver's licenses, educational qualifications, or other authorizations. The European target vision also includes qualified electronic signatures and the option to verify only selected attributes. For example, a person could confirm their legal age without disclosing their address and full date of birth.

Economically, this affects an often underestimated cost factor: building trust between parties who don't know each other. Banks have to identify new customers. Companies check qualifications. Landlords review documents. Authorities compare information with registers. Many of these processes involve breaks in the workflow, waiting times, and repeated verification of the same information.

A standardized, digitally verifiable document can simplify such processes. However, the economic benefit doesn't arise from simply storing a document on a smartphone. The crucial factor is whether a receiving system can immediately understand the document, verify its authenticity, and process the information in a legally compliant manner. A digital driver's license file that subsequently has to be manually read only realizes a small fraction of the potential productivity gains.

The wallet is therefore more comparable to a shared trust infrastructure than to a single management app. Its value increases with the number of meaningful verification methods and connected services. At the same time, this also increases the demands on availability, user-friendliness, data protection, and non-discriminatory access.

It is precisely this infrastructural nature that makes technological dependencies relevant from an economic policy perspective. With a typical leisure app, limited device compatibility is primarily a product issue. With a government-approved identity tool, however, the same limitation can impact access to particularly efficient administrative and business processes.

What the European deadlines actually mean

The introduction is often reduced to a simple statement: Every EU country will have a digital ID app by the end of 2026. In reality, three levels must be distinguished: the legal obligation to provide the app, its technical operational readiness, and its subsequent widespread use in everyday life.

The relevant European deployment date is December 24, 2026, not simply December 31. This date results from the temporal relationship between the amended eIDAS Regulation and the relevant implementing acts. For certain private companies obligated to implement strong user authentication, the adoption obligation generally follows one year later. This is not a blanket obligation for every company and every business process. Separate, more specific requirements regarding wallet availability apply to public online services.

Likewise, a common legal framework does not mean that all member states will offer identical functionality on the same day. Germany plans to launch the first version of its national digital wallet, based on its publicly described development status, in early 2027. Initially, the focus will be on identity and verification functions. Further functions will follow gradually. This timeline demonstrates that the legal target date and the actual national implementation date do not coincide everywhere.

This difference is important for economic evaluation. A formally available app does not automatically generate widespread use. Companies must integrate their systems, issuers must provide proof of purchase, and users must perceive a tangible benefit. Furthermore, support, recovery after device loss, and reliable procedures for handling technical malfunctions are essential.

The productivity gains are therefore unlikely to materialize suddenly on a single date. A multi-year development process is more probable, with some use cases becoming functional sooner than others. The quality of the architecture will determine whether this expansion can be achieved with manageable effort or whether new, isolated technical solutions emerge.

Why a digital ID needs to verify their smartphone

A digital identity verification is only reliable if not only its origin but also its use is adequately protected. A validly issued verification must not be arbitrarily copied and used by other people. Likewise, it must be prevented that manipulated applications can initiate transactions undetected or misuse cryptographic keys.

This is where attestation comes in. In simple terms, it's a technically verifiable proof of certain properties of an application, operating system, or protected key environment. A receiving system can then assess whether it wants to trust a specific wallet instance.

Several questions are answered in this process. Does the application originate from the intended publisher? Has it been modified? Is the device startup protected against unauthorized changes? Are keys generated in a protected hardware environment? Does the security level meet the defined minimum requirements?

Such checks are objectively justified. A wallet with a high level of trust cannot derive its security solely from the fact that the user has installed an app. The German development approach therefore describes a multi-layered security architecture with cryptographic key attestation and other protective mechanisms.

Problems arise when technical security and membership in a specific platform ecosystem become too closely linked. A device can provide relevant proof of security without fulfilling all of a platform operator's commercial requirements. Conversely, approval by a platform operator does not replace a comprehensive security assessment of all conceivable risks.

The political issue is therefore not whether devices should be tested. It concerns the criteria, the decision-making body, and the possibility of providing equivalent safety evidence through different technical means.

When a security audit simultaneously regulates the market

Google's Play Integrity API provides developers with standardized test results for applications and devices. This is attractive for providers because they can leverage an existing infrastructure instead of building each test component themselves. At the same time, the evaluated criteria can encompass not only technical device characteristics but also the system's acceptance within the Google ecosystem.

The use of Play Integrity is documented for wallet developments in the Netherlands and Italy. This creates the risk that alternative Android operating systems may fail mandatory testing criteria, even though a more nuanced technical security audit would be possible.

The common claim that every alternative operating system automatically fails every Play Integrity test is too simplistic. The decisive factors are the required test levels and the rules the application uses to evaluate the result. The GrapheneOS documentation, in particular, describes how applications can also consider alternative operating systems by directly utilizing Android hardware attestation. This does not imply that all applications with any Play Integrity connection will react identically.

It would also be inaccurate to equate GrapheneOS and /e/OS from a security perspective without further examination. Alternative operating systems differ in terms of device support, update provision, boot protection, and the integration of security features. Therefore, the appropriate alternative to a blanket exclusion is not blanket approval, but rather a transparent evaluation based on verifiable requirements.

The economic core remains the same: If recognition by a dominant platform becomes a mandatory prerequisite for a public identity product, this recognition gains additional market value. It then determines not only compatibility with private apps, but also the usability of a state-run trust service.

Google and Apple embody different dependencies

The discussion often treats Google and Apple as a single problem. However, for a precise analysis, a distinction must be made between the platforms.

Android presents a tension between its fundamentally open operating system foundation and proprietary services that play a central role in many commercially available devices. Alternative Android systems can implement their own security concepts on suitable hardware. Whether a wallet accepts these systems therefore also depends on which authentication methods the wallet provider recognizes.

The situation is different for Apple. Hardware, operating system, and essential security features are more tightly organized within a unified product ecosystem. This dependency particularly affects access to the functions, interfaces, and distribution channels provided by Apple.

The product names used should also not be confused. Managed Device Attestation, App Attest, and DeviceCheck refer to different Apple mechanisms. Which one a specific wallet uses cannot be deduced simply from iOS support. For example, a technical description of the German wallet lists iOS DeviceCheck and App Attest alongside Android methods. Therefore, the blanket statement that all European wallets are based on Apple's Managed Device Attestation would not be reliable.

This distinction is crucial for economic policy classification. Android primarily requires a discussion about alternative trust pathways within a more diverse operating system environment. With iOS, the focus is more on how public infrastructure can function under the conditions of a tightly controlled overall system.

Both issues relate to platform power. However, the specific technical and regulatory solutions are not identical.

Switzerland is showing a different path, but not complete independence

The Swiss identity infrastructure swiyu provides a concrete counterexample to the assumption that a government wallet necessarily requires Google's Play Integrity service. For Android, requirements have been defined that directly target verifiable device characteristics: a secure device boot, sufficient operating system and patch levels, valid hardware certifications, and the app signature matching the government-provided application. These checks are to be performed using the operating system interface instead of Play Integrity.

Switzerland is not an EU member state. Its approach should therefore be viewed as a technical comparison, not as a national implementation of the same European provision obligation.

The key difference lies in the shift of decision-making authority. A wallet operator can evaluate technical evidence themselves based on defined rules, instead of making acceptance entirely dependent on a single, aggregated platform judgment. This allows alternative operating systems to be considered, provided they demonstrate the required characteristics.

However, this does not mean complete vendor independence. Even direct hardware attestation requires trusted hardware, certificate chains, secure implementations, and procedures for handling compromised keys. On many devices, manufacturers and their security infrastructure remain part of the chain of trust.

The realistic improvement, therefore, does not consist of eliminating all dependencies. It consists of avoiding additional reliance on a specific proprietary assessment service and making the approval decision more subject to public scrutiny.

It is precisely this limited but concrete form of independence that is economically valuable. It expands the scope of action without denying the technical capabilities of modern smartphones.

Germany demonstrates that architecture can still be shaped

The European wallet landscape is not a technically unified entity. National decisions differ, and development stages can change. Germany describes Android Key Attestation as the primary mechanism for verifying device integrity and secure key usage. Additional signals such as Play Integrity are evaluated as potential complements. A final decision is explicitly not claimed; without a demonstrable additional security benefit, such mechanisms should not be included in the final architecture.

This position is significant for the debate. It contradicts the notion that all European wallets are already irrevocably locked into the same proprietary verification service. At the same time, the use of hardware attestation alone does not guarantee that every alternative operating system will be supported at launch.

Germany initially envisions Android and iOS as the target platforms. Support for alternative operating systems is described as technically feasible in principle, but must be compatible with the high security requirements.

This leads to a nuanced assessment. On the one hand, there is political and technical scope for design. On the other hand, an open basic architecture can remain practically restrictive if approval rules are lacking or alternative systems are not permanently tested.

Therefore, simply keeping an interface theoretically open is not enough to guarantee genuine freedom of choice. What is needed are verifiable requirements, a procedure for recognizing suitable systems, and clear statements about which configurations are supported. Only then does a technical possibility become a reliable usage option.

Our EU and German expertise in business development, sales and marketing

Our EU and German expertise in business development, sales and marketing - Image: Xpert.Digital

Industry focus areas: B2B, digitalization (from AI to XR), mechanical engineering, logistics, renewable energies and industry

More information here:

Expert Business Hub

A thematic hub offering insights and expertise:

Knowledge platform covering global and regional economies, innovation and industry-specific trends
A collection of analyses, insights, and background information from our key areas of focus
A place for expertise and information on current developments in business and technology
A hub for companies seeking information on markets, digitalization, and industry innovations

EUDI Wallet: Opportunities and challenges for companies

Why the most convenient development path can become expensive for the economy as a whole

From a development team's perspective, choosing an established platform service is often rational. Documentation, existing libraries, and standardized responses reduce the immediate effort. Under time pressure, it's tempting to rely on a widely used service rather than building a custom testing and evaluation process.

However, this approach shifts costs. Initially, some of the development work is eliminated for the wallet provider. However, this may lead to later expenses due to limited compatibility, additional support requests, and a difficult service replacement.

Economically, this differs from microeconomic optimization. A project budget primarily covers the development, implementation, and operation of the application itself. It does not automatically consider the disadvantages for alternative providers, the burdens placed on excluded users, or the long-term weakening of switching options.

A free interface can therefore come at a high economic price. "Free" simply means that no immediate fee is charged for a specific use. It says nothing about the service's impact on the market structure or the costs of a later migration.

This mechanism does not presuppose any malicious intent. Many dependencies arise precisely because numerous actors each choose the most obvious standard path. What seems expedient for each individual team can, in aggregate, create an infrastructure that is difficult to change.

The correct conclusion, therefore, is not to ban established platform services outright. Rather, their advantages must be weighed against the long-term costs of limited interchangeability.

Real market power arises at the entry threshold

The strategic importance of a security audit lies in its ability to determine access. If a wallet cannot be set up or used based on a specific audit result, the audit mechanism becomes an economic control point.

This presents a particular challenge for alternative operating systems. They not only have to be technically convincing and attract users, but they also have to be compatible with the applications that users consider indispensable. These include, in particular, payment services, banking applications, and government identity tools.

A study involving 120 participants in the context of alternative mobile software underscores this connection: For many participants, the usability of essential payment and identity applications was a prerequisite for switching. This figure does not allow for a representative statement about the entire European population. However, it demonstrates a plausible mechanism by which critical apps influence the choice of operating system.

This allows the wallet to have an indirect impact on competition. Even if only a small percentage of the population uses alternative systems, their exclusion affects the future prospects of competing ecosystems. A product doesn't need to be used by the majority to act as a potential alternative and exert a disciplining influence on established providers.

The economic and political significance of a minority is therefore not measured solely by its current size. It also depends on whether its existence keeps options open and enables innovation outside of dominant platforms.

How public acceptance can solidify private standards

Digital identity is a market with strong interdependencies. A wallet becomes more attractive to users when many services accept it. Integration is more worthwhile for companies when many users adopt it. Issuers, in turn, benefit when their credentials are widely accepted.

The European framework is intended to accelerate this coordination process. Common standards and mandatory acceptance can prevent each industry from developing its own identity system. This represents a significant economic advantage.

However, this same mechanism can also reinforce undesirable technical constraints. If a particular platform service is integrated into many wallets early on, other participants will follow suit. Integrations, security concepts, and operational processes adapt accordingly. With each additional connection, the costs of a fundamental change increase.

This is a classic case of path dependency: decisions made early on influence later choices more strongly than their original technical significance would suggest.

This places a special responsibility on public infrastructure during the implementation phase. Interfaces and approval rules are comparatively easier to modify when final usage is still limited. After widespread implementation, the same correction may require extensive adjustments at government agencies, banks, trust services, and software providers.

Architectural decisions should therefore not be judged solely on whether they enable an initial launch. It is also crucial to consider what competitive landscape they are likely to produce after several years.

Where the productivity gains actually occur

The economic opportunities presented by the EUDI wallet are substantial, but should not be confused with savings already realized. A figure mentioned in connection with the European impact assessment places net benefits between €800 million and €6.5 billion. This wide range is a model-based expectation, not a measured return on investment for the wallets currently available.

The magnitude of the data highlights how heavily the outcome depends on assumptions about adoption, process improvements, and avoided harm. An app with low usage and numerous manual exceptions will produce different results than a widely accepted infrastructure with well-integrated evidence.

The immediate benefits can arise from shorter processing times, fewer repeated data entries, and simpler authentication. Furthermore, there is the potential to make certain forms of fraud more difficult, because signed documents cannot be altered like ordinary document images.

This is offset by integration costs. Companies must adapt their data models, permissions, user interfaces, and legal processes. Furthermore, technical reviews remain necessary. A genuine proof does not automatically demonstrate that a business deal is economically viable or that an application is substantively justified.

A sound cost-benefit analysis must therefore differentiate at least between technical authentication, identity verification, and expert decision-making. The wallet can significantly support the first two areas. It does not replace the entire business logic.

Applications with high case numbers, recurring evidence, and previously complex media breaks are particularly attractive. The benefits are less clear where a process occurs infrequently or where the actual difficulty lies outside of identification.

Logistics and industry need more than a digital identity card

The potential benefits are particularly evident in industry and logistics. A driver could digitally prove their driver's license. An external technician could present a qualification or safety training certificate. A company could organize access to a site based on verifiable authorizations.

However, such applications would combine multiple pieces of evidence and decisions. A person's identity is not the same as their current employment, qualifications, or authority to act for a particular company.

A valid driver's license, for example, says nothing about whether a driver is authorized to handle a specific shipment. A vocational qualification does not automatically prove that required training is still up-to-date. Therefore, for economically sound processes, different issuing bodies and validity rules must work together.

The wallet can provide a common transfer and verification framework for this. However, it does not eliminate the need to provide current and trustworthy proof of identity.

Especially in these environments, device compatibility becomes a business issue. Companies use smartphones across different lifecycles and must coordinate security requirements, device management, and replacement processes. If identity functions are only available under narrowly defined platform conditions, additional device and support costs can arise.

Economic success therefore depends not only on the app's user-friendliness. It requires an architecture that integrates into real-world workflows and makes technical exceptions manageable.

Voluntary action loses its value when alternatives become worse

Voluntary use is one of the core security principles of the EUDI wallet. For Germany, it is explicitly stated that existing physical proofs of identity can continue to be used and that alternative methods should remain available.

From an economic perspective, a formal choice is not always sufficient. If the digital route is significantly faster, cheaper, or easier, while other methods gradually decline in quality, practical pressure to use it arises.

This pressure would not initially constitute proof of a legal violation. However, it would represent a significant distribution problem. People without a suitable smartphone, with limited digital skills, or with a consciously chosen alternative operating system might benefit less from the efficiency gains.

Different causes should not be conflated. Someone who doesn't own a smartphone needs different support than someone whose technically capable device is rejected due to a platform restriction. Accessibility, social inclusion, and open operating systems require different measures.

However, a common standard makes sense for public infrastructure: Access to basic services must not depend unduly on avoidable technical hurdles.

A successful digital channel therefore does not automatically justify the elimination of all other methods. The most economically viable solution also considers the costs incurred outside the app: additional appointments with authorities, the purchase of a new device, support costs, and time lost due to unsupported configurations.

Data privacy begins below the visible user interface

A wallet can be designed to be more data-efficient than many existing identification methods. Selectively disclosing individual attributes reduces unnecessary data transmission. In the German architecture, evidence is exchanged directly between the wallet and the receiving entity; issuers should not automatically know where their evidence is being used.

However, these advantages do not answer every data protection question. In addition to the actual content of a certificate, there is accompanying technical information. This can include test times, device classes, app versions, or security-related status information.

Whether such information is actually transmitted to an external provider and what conclusions can be drawn depends on the specific procedure. The use of an attestation service does not reliably imply that Google or Apple receives the complete contents of the ID card or can monitor every wallet transaction.

Conversely, it would be equally insufficient to only examine the visible data sharing within the app. A comprehensive data protection assessment must consider the entire chain, including the application, device verification, server communication, and operational logs.

This again highlights the importance of technical control. Public authorities should know which data creates a dependency, which of these are necessary, and whether alternative methods achieve the same security objective with less data processing.

Data minimization is therefore not just a feature of the user interface. It is an architectural decision.

Security and openness require the same level of care

The controversy is often portrayed as a conflict between security and freedom. This is an oversimplification. An open architecture can enforce high security requirements. A closed architecture can contain poorly configured checks.

Crucial are concrete criteria: secure device startup, sufficient up-to-dateness, protected keys, valid certificates, authentic app signatures, and a robust procedure for responding to security vulnerabilities. The Swiss approach describes precisely such a focus on verifiable properties.

Openness therefore does not mean accepting just any modified device. A smartphone with an unlocked bootloader, unknown firmware, or an unsupported security version can be excluded for objective reasons.

However, the requirements must be proportionate and comprehensible. Exclusion should ideally be based on a relevant lack of security features, not merely on a different brand or platform affiliation.

Wallet operators need their own expertise for this. Those who allow alternative trust paths must manage operating system keys, evaluate security information, and update decisions when components are compromised. This work is not free.

The appropriate political demand is therefore not to simplify security. It is to organize security decisions in such a way that they remain transparent, verifiable, and as neutral as possible in terms of competition.

Competition law cannot replace technical design

The integration of dominant platform services raises questions about potential restrictions of competition. This becomes particularly relevant when a service not only assesses actual risks but also indirectly hinders the use of other operating systems or distribution channels.

However, this does not automatically mean that every specific wallet integration violates the Digital Markets Act or other competition law. Such an assessment requires an examination of the respective service, the relevant obligations, and its actual implementation. Blanket claims of illegality do not replace this examination.

Nevertheless, the conflict is evident from an economic policy perspective. Europe is trying to make digital markets more open and improve switching options. At the same time, national identity systems can reinforce precisely those platform ties that are being sought to be limited elsewhere.

The most effective solution, therefore, does not lie solely in retrospective procedures. It begins with the design of public infrastructure. If equivalent safety certifications are permitted and critical components remain interchangeable, the risk of creating difficult-to-resolve dependencies in the first place decreases.

Regulation and technology must work together. A legal claim to interoperability remains weak if the practical architecture does not provide for alternative access. Conversely, a technically open interface does not create a fair market if the approval requirements remain opaque.

A realistic benchmark for digital sovereignty

Complete technological self-sufficiency is not a meaningful short-term benchmark for a smartphone wallet. Modern devices combine internationally developed processors, operating systems, security modules, and communication standards. A European app cannot simply replace these supply chains.

Digital sovereignty should therefore be understood as the ability to make essential decisions independently and to keep dependencies manageable.

For the EUDI wallet, this initially concerns authorization: Who determines which devices and operating systems offer sufficient security? Furthermore, there is the issue of auditability: Can public authorities trace how a crucial audit result is generated? Finally, it concerns switching options: Can a service be replaced without fundamentally rebuilding the identity infrastructure?

Open-source software must also be measured against this standard. Accessible app source code is valuable, but it doesn't eliminate the inherent dependency on an externally controlled service. Conversely, the limited use of a proprietary component can be justifiable if its function is clearly defined and its replacement is realistically possible.

The crucial difference, therefore, does not lie solely between European and American or between open and proprietary. It lies between controllable dependencies and those that are structurally difficult to change.

A credible European strategy would have to put precisely this distinction into practice.

Which key performance indicators should determine success?

A data-driven evaluation of a wallet should not be limited to installations and registrations. These figures demonstrate reach, but not yet economic benefit.

More important are successful usage processes, avoided processing time, and the frequency of necessary manual exceptions. Equally relevant are the costs per completed process, including operation, support, and recovery.

The platform issue under discussion requires additional metrics. How many setup attempts fail during device checks? What are the underlying causes? Are they due to missing security updates, technical errors, or the non-recognition of an alternative system? How long does it take to test a new operating system version?

Availability and the consequences of disruptions must also be assessed. A security architecture can be cryptographically robust yet operationally vulnerable if an external service is unavailable or a faulty update locks out many users simultaneously.

Finally, the interchangeability should be regularly tested in practice. A backup option that only exists on paper offers little protection if its activation takes months.

Such indicators would bring objectivity to the debate. Instead of arguing abstractly about sovereignty or insecurity, it would be possible to examine which architecture generates which benefits, whom it excludes, and how resilient it remains under realistic disruptions.

Europe's opportunity lies in an open system of trust

The EUDI wallet can enable significant economic progress. It can simplify cross-border processes, accelerate the verification of documents, and reduce unnecessary data sharing. These opportunities should be taken seriously precisely because they justify the development of a permanent infrastructure.

The critical point is not simply the use of American technology. The problem arises when private platform recognition, without an equivalent alternative, becomes a prerequisite for state-organized digital identity. Then, public reach merges with private access control.

The technically available alternatives show that this outcome is not inevitable. Direct hardware attestation can broaden the scope of decision-making. At the same time, the Swiss implementation and the nuanced German position make it clear that openness requires concrete security measures and should not be confused with complete vendor independence.

The economically compelling perspective is therefore neither a blanket retreat to established platform services nor the demand for immediate technological self-sufficiency. It lies in a common European order of trust that combines high security requirements with transparent approval rules, verifiable components, and genuine switching options.

If this succeeds, the wallet will become more than just an additional app. It will become an infrastructure that enables competition, rather than replacing existing barriers to access. If it fails, Europe could issue its own digital credentials, but would still only have limited control over the conditions of their practical use.

🎯🎯🎯 Data-driven B2B industry hub as a quasi-in-house solution

The quasi-in-house solution: How Xpert.Digital closes operational gaps in B2B marketing and sales – Smart Content-Driven Business - Image: Xpert.Digital

Xpert.Digital is a data-driven B2B industry hub led by Konrad Wolfenstein . The company acts as an external, quasi-in-house solution for industrial partners, closing operational gaps in marketing, content, and sales – without requiring additional resources on the client side.