European Digital ID Wallets and the Hidden Power of Remote Attestation

A wallet that only works on “approved” phones

Imagine you finally get access to a digital ID wallet for public services. You install the app, follow the steps, and then—at the moment of verification—something blocks you. The phone is yours, the app is yours, but the system says: not certified. For many people, that moment turns “digital public infrastructure” into a gated service.

That situation is increasingly caused by a technology pattern called remote attestation. Remote attestation is a way for an app (the wallet) to ask a server (often controlled by a platform provider) whether the phone’s software and security state match what the provider expects. In practice, it can become a gatekeeper mechanism for who gets to use identity wallets—especially on Android and iOS variants that replace or modify parts of the ecosystem.

This article connects the dots between European digital ID wallets and the attestation services embedded in them—most notably Google Play Integrity API and Apple’s Managed Device Attestation.

The core idea: attestation is about trust, but it carries incentives

Let’s translate the jargon into something tangible.

• Attestation means “proof.”
• Hardware-backed security means a trusted part of the device (often rooted in security hardware) can sign evidence that certain conditions are met.
• Remote attestation adds a second step: the wallet’s backend checks that evidence with the help of a cloud service.

The security motivation is real. Wallet apps need to reduce abuse such as automated fraud, replay attacks, and tampered-device risk. A classic threat is the attacker who modifies an app or intercepts authentication flows. If a platform provider can reliably detect tampering, it can deny service to dangerous devices.

But trust systems don’t exist in a vacuum. The providers who supply attestation also control enforcement logic and, often, the policy signals that decide what “acceptable” means. That’s where power accumulates.

Google Play Integrity API: security feature or ecosystem lever?

On Android, Play Integrity API is marketed as an integrity-checking tool. Integrity checks help developers determine whether their app is running on a “genuine certified Android device” and whether the app/device has been tampered with.

So far, so good: a wallet app must resist bots and manipulation.

What changes the stakes is that Play Integrity doesn’t only verify “no tampering.” It also reflects ecosystem conditions—for example:

• Whether the device is running a Google-licensed version of Android.
• Whether the app was installed through Google Play.
• Whether certain account or licensing expectations are present.

In other words, remote attestation can start functioning like a selective door. Even if a phone is technically secure in a security-hardening sense, it may still fail a platform provider’s expectations about certification, licensing, or distribution.

That creates a subtle form of platform lock-in: governments and wallet developers may believe they are outsourcing “security,” while they are also importing “platform policy” into a public-facing system.

Why de-Googled phones get punished

A large group of users deliberately choose de-Googled Android ecosystems—systems that remove or replace Google components to reduce tracking, reduce dependency, and improve user control.

Two well-known examples are:

• e/OS (an Android-based mobile operating system that aims to reduce reliance on Google services)
• GrapheneOS (a privacy- and security-focused Android variant)

These alternatives often use devices and software stacks that differ from what mainstream Play-based certification assumes. When an ID wallet relies on Play Integrity for approval, devices that fail integrity signals can be excluded from a service that should be universally reachable.

This exclusion doesn’t have to be malicious. It can happen as a side effect of how attestation providers decide the meaning of “integrity.”

And the real-world consequence is disproportionately large: inability to use an ID wallet for government services makes alternative operating systems less adoptable, which indirectly strengthens the dominant ecosystem’s position.

“But isn’t attestation necessary?” Yes—yet the enforcement model matters

The hard part to explain to beginners is that “security” and “vendor control” can be entangled.

A wallet does need defenses against attackers. Remote attestation can provide that.

The question becomes: who defines the acceptance criteria and who holds the power to update it?

When remote attestation is delivered through a private provider’s infrastructure, the following issues appear:

• The provider can change what it considers acceptable.
• The provider can correlate integrity decisions with ecosystem signals (licensing, distribution, account expectations).
• The provider can effectively require a specific device/software environment to function.

Public infrastructure shouldn’t behave like a private app store gate. Identity wallets are meant to be a utility for accessing public services, not a mechanism for encouraging compliance with a particular vendor’s mobile stack.

Apple’s Managed Device Attestation: similar pattern, different ecosystem

On iOS, Apple uses Managed Device Attestation. The name already hints at the structure: it’s an attestation mechanism designed to confirm device integrity states.

Even though the implementation differs from Android, the pattern is comparable: a wallet’s ability to verify users can depend on Apple-controlled attestation logic.

The same central concern remains: remote attestation embedded into critical public apps can turn platform security into platform governance.

When governments choose “recommendations,” they may create enforcement

In Europe, the digital identity wallet space has an architectural framework that sets guidance for how wallets should work. Guidance may include recommendations about using attestation services.

However, recommendations can become de facto requirements when implemented inconsistently across countries.

The end result can be a patchwork where:

• Some countries choose not to use certain remote attestation mechanisms.
• Others implement them strictly.

That inconsistency harms interoperability: the same citizen carrying the same alternative device might be able to use an ID wallet in one jurisdiction and be blocked in another.

For people building alternative ecosystems, that’s not a small inconvenience. It affects the feasibility of adoption across borders—especially because public services are often the highest-value reason to choose an OS in the first place.

How remote attestation turns public infrastructure into a dependency

The dependency story is easiest to understand through a failure mode.

Consider this chain:

1. A citizen installs an ID wallet.
2. The wallet checks device integrity.
3. The integrity check depends on remote attestation.
4. Remote attestation success depends on private platform services.
5. The wallet denies or restricts service if the attestation doesn’t match the provider’s acceptance rules.

If any link changes—provider policy, verification logic, certificate formats, distribution expectations—the public service may break for certain devices.

That’s the opposite of what “public infrastructure” should mean: stable, broadly accessible, and not dependent on shifting private certification decisions.

A more open alternative exists: hardware attestation without the ecosystem strings

Not all attestation is created equal.

On Android, there is an alternative approach based on hardware attestation via Android’s Hardware Attestation API.

Hardware attestation means the device’s security hardware produces verifiable evidence about certain properties. The key difference in principle is that hardware attestation can be used in a way that focuses more on the hardware-backed security state rather than on ecosystem policy enforcement.

This can reduce the likelihood that “nonstandard OS choices” get treated as integrity failures.

In the broader framing, the open alternative supports an important goal: interoperability across different devices and operating systems.

Interoperability isn’t a buzzword—it decides who can use public services

Interoperability means that different systems can work together without special privileges or compatibility handshakes.

In the digital ID wallet context, interoperability means:

• alternative mobile OS choices can still access government logins
• wallet verification doesn’t require a specific preinstalled ecosystem stack
• citizens aren’t forced into one vendor’s distribution channel to use identity tools

When interoperability is weakened by remote attestation policy, the market effect is predictable: users adopt the mainstream ecosystem because critical apps demand it.

That transforms a citizenship tool into a distribution mechanism. Once that happens, the “choice” countries claim to defend starts to shrink.

The tricky part: designing for security while refusing vendor lock-in

The technical challenge is real: wallets must resist tampering and fraud.

But the architecture can be designed to prevent private platforms from becoming de facto policy governors.

A public-infrastructure oriented design direction tends to prefer:

• attestation mechanisms grounded in verifiable device properties
• fewer dependencies on cloud-side enforcement that can change acceptance criteria without democratic oversight
• consistency across jurisdictions so citizens aren’t blocked arbitrarily

In practice, this means pushing for architectural frameworks that don’t treat remote attestation from private platforms as the default path.

Conclusion: remote attestation is a security tool with governance consequences

European digital ID wallets are a foundation for accessing critical public services, and they deserve stability, openness, and interoperability. Remote attestation technologies such as Google Play Integrity API and Apple’s Managed Device Attestation provide strong security capabilities—but they also embed private ecosystem assumptions into a public utility.

When integrity checks depend on vendor-controlled verification logic, alternative operating systems can be excluded even when devices are genuinely secure. The result isn’t only a technical compatibility issue; it is a governance shift where public infrastructure becomes reliant on private enforcement.

A more sovereignty-friendly approach emphasizes hardware-based attestation patterns that reduce ecosystem gatekeeping. Security and openness don’t have to be enemies—but the architecture has to be intentional about where trust decisions come from.