Local Storage: Local Device Storage

Definition

Privacy and Data Sovereignty Benefits

The decision to store credentials locally is primarily driven by privacy considerations. In a cloud-based model, the wallet provider would have access to all stored credentials and could potentially track every presentation event -- knowing when, where, and to whom a user presents their identity. Local storage eliminates this surveillance risk entirely. The wallet provider has no visibility into the user's credential collection or usage patterns.

This approach aligns with the GDPR principle of data minimization: the wallet provider processes only the minimum data necessary for its function (providing the app), without collecting or storing personal identity data. It also supports the eIDAS 2.0 requirement that wallet providers must not be able to link credential presentations across different relying parties, a property known as unlinkability.

From a security perspective, local storage eliminates the "honeypot" risk of centralized databases. A breach of a cloud-based wallet service could expose millions of citizens' identity credentials simultaneously. With local storage, a security incident affects only the individual device, dramatically reducing the blast radius of any compromise.

Local storage also provides resilience against service outages. If the wallet provider's servers go down, users can still access and present their locally stored credentials. This is particularly important for identity services that citizens may need access to at any time, including in emergency situations.

Technical Implementation on Mobile Devices

EUDI Wallet apps implement local storage using a combination of platform-specific secure storage mechanisms. On Android, credentials are stored in encrypted databases (such as SQLite with SQLCipher encryption), with cryptographic keys protected by the Android Keystore backed by the Trusted Execution Environment (TEE) or StrongBox hardware security module. On iOS, the Keychain provides hardware-backed key storage with Secure Enclave protection.

The separation between credential data and cryptographic keys is critical. Credential payloads (the actual identity attributes) are stored encrypted in the app's sandboxed storage area, while the signing keys that prove possession of the credential are stored in hardware-backed secure elements that prevent key extraction. Even if an attacker gains access to the encrypted credential data, they cannot use it without the hardware-protected keys.

Both mDoc and SD-JWT credential formats are designed to work efficiently with local storage. The credential data structures are compact enough for mobile devices, and the cryptographic operations (signing presentations, computing selective disclosures) are performed locally using the device's secure hardware without requiring network connectivity.

Application sandboxing on both Android and iOS ensures that no other application on the device can access the wallet's stored data. Combined with full-disk encryption (enabled by default on modern smartphones), this provides multiple layers of protection for locally stored credentials.

Offline Capabilities and Use Cases

A key advantage of local storage is enabling offline credential presentation. Since credentials are stored on the device with their cryptographic proofs, users can present identity information without any internet connection. This is essential for scenarios like roadside police checks, age verification at rural venues, or identity presentation in areas with poor cellular coverage.

The ISO 18013-5 proximity presentation protocol is specifically designed for local-storage wallets, using NFC or Bluetooth Low Energy to transfer credential data directly between the wallet device and the verifier's reader. No network connectivity is required for either party during the credential presentation itself.

However, some operations do require connectivity. Initial credential issuance requires communication with the issuer's OpenID4VCI endpoint. Credential status checking (whether a credential has been revoked) requires periodic online checks, though EUDI Wallets can cache status information locally for a defined period to support offline verification within acceptable freshness parameters.

Backup, Recovery, and Device Migration

The primary challenge of local storage is handling device loss, damage, or replacement. Since credentials and keys exist only on the device, losing the device means losing access to all stored credentials. EUDI Wallet implementations address this through several approaches, depending on the Member State's technical choices.

Optional encrypted cloud backup allows users to store an encrypted copy of their credential data in a cloud service. The encryption key is derived from the user's authentication factors and is never stored on the server, ensuring the cloud provider cannot access the credential contents. During recovery, the user authenticates strongly (often requiring re-verification against their physical eID card) and reconstructs the decryption key to restore their credentials.

Importantly, device-bound cryptographic keys cannot be backed up -- they are inherently tied to the hardware security module of the specific device. During device migration, new keys must be generated on the new device, and credentials must be re-bound to these new keys. Some implementations handle this through a streamlined re-issuance process that is faster than the initial issuance because the user's identity has already been verified.

The eIDAS 2.0 framework recognizes the importance of backup and recovery, requiring wallet providers to offer users mechanisms to restore their wallet contents after device changes. The specific implementation -- whether through encrypted cloud backup, issuer-side re-issuance, or a combination of both -- is left to each Member State's wallet provider.

Related Terms