Smartphone Security and Credentials: How Android and iOS Protect Digital Identity and Official Documents

Sep 5

9 min read

A digital identity is not secure simply because it appears on a smartphone. A password, passkey, government identity document, or driving licence depends on several separate controls: the way a credential is issued, the way a device stores cryptographic keys, the state of encrypted files, the authentication required before use, the treatment of backups, and the ability of an issuer to revoke or validate the credential.

Android and iOS now provide stronger foundations for these controls. Both platforms can keep important keys non-exportable, tie access to a device unlock method, and support passkeys that do not disclose a private key to the service. Government identity systems are also moving beyond static photographs of documents toward cryptographically verifiable presentations and selective disclosure.

These protections reduce exposure, but they do not remove every risk. A compromised application may still misuse a key that it is authorised to invoke. A lost device can still expose information if the wrong storage policy was chosen. A cloud recovery path can become a separate security boundary. The most reliable design therefore treats storage, authentication, backup, verification, and privacy as one system.

Key principle: encrypted storage protects data at rest; it does not replace secure application design, a strong device passcode, issuer-side validation, or careful recovery procedures.

Image: smartphone hardware used as the access point for digital credentials.

Android: credential exchange, protected keys, and file-based encryption

Android’s recommended Jetpack API for modern sign-in is Credential Manager. It brings passkeys, passwords, federated sign-in, and digital credentials into a unified user flow. A credential provider, such as a password manager or another authorised service, supplies the relevant credential. Credential Manager should therefore not be described as a single local database containing every credential on the phone 1.

Passkeys use public-key cryptography. The service keeps a public key, while the private key remains under the user’s credential-management system. Android describes passkeys as phishing-resistant and designed to avoid password reuse. The user normally authorises the operation with a fingerprint, face recognition, or device PIN 2.

Android Keystore limits key extraction

For application-held cryptographic keys, the Android Keystore system keeps key material outside the application process during Keystore operations and makes it non-exportable. A developer can restrict a key by algorithm, purpose, validity period, and recent user authentication 3.

This is a meaningful barrier against extraction, but it is not an absolute promise of safety. If an attacker compromises an authorised application process, that process may still be able to ask the Keystore to perform an operation that the key permits. Security level also depends on the device and the key configuration. Some devices provide a Trusted Execution Environment, while selected devices offer StrongBox KeyMint, which is intended for higher-threat situations but is slower and more limited than ordinary hardware-backed protection 3.

File-based encryption separates device states

Android 7.0 and later support file-based encryption (FBE). Its two important storage areas are:

Android storage area	Availability	Appropriate use
Credential-encrypted (CE) storage	Normally after the user unlocks the device	Private user data, passwords, tokens, and identity information
Device-encrypted (DE) storage	During Direct Boot and after unlock	Only the limited data needed before the first unlock

Android warns developers not to move passwords or authorisation tokens from CE storage to DE storage. DE is designed for narrowly defined pre-unlock functions, not as a general-purpose safe for private information 4. Sensitive application data should normally remain in internal storage, where application sandboxing restricts access. If encrypted content must be placed on external storage, the encryption key should be protected by Android Keystore and the content should be checked for integrity 5.

Backup is part of the security model

Android Auto Backup can include much of an application’s private data, including shared preferences, databases, internal files, and app-specific external files. Developers must configure which paths are included, excluded, or required to use client-side encryption. Android’s guidance also advises against storing credentials and authentication tokens in files or shared preferences intended for backup; it points developers toward Block Store for secure credential backup and restoration 6.

One important implementation note is often missed: Android documents the Jetpack security-crypto APIs as deprecated, with no further releases planned. EncryptedSharedPreferences should not be presented as the forward-looking default for new designs 7.

iOS: Keychain secrets, Data Protection, and passcode-gated access

On iOS, Keychain Services is designed for passwords, login tokens, cryptographic keys, and similar small secrets. It is not a general application database. Apple describes access controls enforced by the securityd service, which checks the application identity, entitlements, and Keychain access groups before allowing access 8.

Keychain protection depends on an accessibility class selected by the developer. WhenUnlocked is the default. AfterFirstUnlock can support selected background operations. For extremely sensitive information that should not be backed up or synchronised, Apple recommends WhenPasscodeSetThisDeviceOnly. Developers can also require user presence, biometric authentication, or a passcode through SecAccessControl 9.

Data Protection secures files at rest

Keychain policy and file encryption are related but separate. iOS uses per-file keys and Data Protection classes to control when application files can be accessed. Third-party application data receives Data Protection automatically, with Protected Until First User Authentication as the default unless the app chooses another class 10.

With Complete Protection, the relevant key is discarded shortly after the device locks, so the file remains unavailable until the user authenticates again. With Protected Until First User Authentication, data remains available after the first unlock until the device restarts. No Protection still stores the file in encrypted form, but Apple states that its keys remain on the device; this class is mainly useful for rapid remote wipe rather than passcode-gated confidentiality 11.

Secure Enclave, passcodes, and passkeys

Apple’s Secure Enclave is an isolated security subsystem that is separate from the main processor. Apple states that it is designed to protect sensitive information even if the main processor’s kernel is compromised 12. A device passcode activates important Data Protection properties, contributes to relevant key derivation, and is subject to escalating delays after failed attempts. Biometrics provide convenient authorisation, but they do not replace the passcode’s role in protection and recovery 13.

Apple passkeys use a unique public/private key pair for each account. The service receives the public key but not the private key. Face ID or Touch ID can authorise use on supported devices 14. iCloud Keychain is a separate synchronisation and recovery service. Apple describes eligible passwords and passkeys as end-to-end encrypted during synchronisation, but this does not remove the need to protect enrolled devices, the Apple Account, recovery channels, and relying-party accounts 15.

Android and iOS compared

Security question	Android	iOS
Credential exchange	Credential Manager brokers passkeys, passwords, federated sign-in, and digital credentials	Passkeys and Keychain-integrated credentials are authorised through system and app frameworks
Key protection	Android Keystore supports non-exportable keys and, on some devices, hardware-backed security or StrongBox	Keychain protection works with Data Protection and the Secure Enclave for selected operations
Data available before first unlock	Device-encrypted storage exists for limited Direct Boot needs; private secrets belong in credential-encrypted storage	Data Protection classes determine availability; Complete Protection can block access after locking
Most restrictive secret policy	Require user authentication and use Keystore-backed keys where appropriate	Use restrictive Keychain accessibility, such as WhenPasscodeSetThisDeviceOnly, with SecAccessControl when justified
Backup and synchronisation	Auto Backup requires deliberate inclusion, exclusion, and encryption decisions	iCloud Keychain synchronises eligible credentials under Apple’s stated end-to-end encryption design
Passkey model	Public-key credential authorised through Credential Manager	Public-key credential authorised through system authentication and, where applicable, iCloud Keychain

Neither platform has one setting that makes every document and credential safe in every device state. The final result depends on the developer’s storage class, authentication policy, backup configuration, and recovery design.

Designing secure digital identities and official documents

A robust mobile identity system should follow five practical rules.

Prefer verifiable credentials over document photographs. A photograph of an identity card can be copied and altered. A verifiable credential can connect an issuer, a holder or wallet, and a verifier through cryptographic evidence.
Minimise local retention. Store only the attributes needed for the user’s task. Keep compact secrets in Keychain or an Android Keystore-backed design, and keep confidential document data in the platform’s protected post-unlock storage.
Authenticate high-impact actions. Presenting a complete identity, exporting a document, or approving a financial or government transaction should require an explicit user action and an appropriate authentication step.
Design for loss, revocation, expiry, and recovery. A credential must have a clear response when a phone is lost, a physical document expires, a certificate is revoked, or an account is restored on a new device.
Show the disclosure clearly. Before presentation, the user should know which fields are being requested, who is requesting them, why they are needed, and how long the presentation remains valid.

Android’s digital-credentials guidance describes an issuer–holder/wallet–verifier model and supports the broader idea of selective disclosure: the holder presents only the attributes required for a transaction 16.

Spain’s MiDNI: an official QR presentation, not a photograph

Spain’s DNI digital is the mobile version of the Documento Nacional de Identidad, delivered through the Police-backed MiDNI app. Royal Decree 255/2025 regulates the physical and digital forms. The digital version is generated for a holder with a valid physical DNI, follows the physical document’s validity, and has the same legal effect for identification under the decree 17.

The official process requires registration and activation. It includes the DNI and support-number details, creation of an app password, and SMS verification. One DNI is linked to one mobile number 18.

The most important distinction is between displaying a copy and presenting a verifiable identity. According to the Spanish Ministry of the Interior, MiDNI retrieves identity data in real time from the DNI management system rather than storing the citizen’s identity data in the app. At each presentation, the holder chooses one of three levels:

Presentation level	Information shown
DNI EDAD	Photograph, name, and proof of being over the required age
DNI SIMPLE	Photograph, name, surnames, sex, and DNI validity
DNI COMPLETO	All data contained on the physical document

The app then creates a short-lived QR code signed by the National Police. The verifier receives only the selected information for the presentation, and the Ministry states that the data are not retained on the verifier’s device 19. This is an official description of the service. It should not be expanded into a claim that no personal data are processed anywhere in the broader system.

The Ministry lists in-person uses such as age checks, hotel registration, vehicle rental, parcel collection, access control, face-to-face administrative or notarial matters, and commercial transactions that require a valid DNI. A data connection is required for presentation 19.

Status matters. In its 1 April 2026 update, the Ministry stated that the transition period had ended and that covered public and private entities would be required to accept MiDNI from the following day 19. The initial April 2025 launch announcement also stated that MiDNI was not initially an online-identification or electronic-signature service, a border travel document, or proof of identity in other countries 18. Those limits should remain attached to the relevant date unless a newer official source confirms a change.

MiDNI is not the EU Digital Identity Wallet

MiDNI is a Spanish national system. It should not be conflated with the European Digital Identity Wallet or with Apple Wallet IDs and Android digital credentials. The European Union framework aims to provide wallets under common specifications by the end of 2026. The European Commission describes a broader model in which people control the attributes they disclose across public and private services 20.

The platforms can provide the security foundations for these systems, but platform support alone does not prove that a particular government service uses Android Credential Manager, Apple Wallet, or any named credential standard. The issuer’s architecture and legal framework remain decisive.

Android and iOS now make it possible to build substantially stronger credential systems than those based on passwords, unencrypted files, or photographs of identity documents. Android combines Credential Manager, Keystore, file-based encryption, and configurable backup controls. iOS combines Keychain, Data Protection, Secure Enclave support, and passkeys authorised by device authentication.

The security value comes from the combination, not from any single feature. A trustworthy digital identity keeps keys difficult to extract, limits data availability before unlock, minimises disclosure, tests backup and recovery paths, and gives the user a visible role in every sensitive presentation. Spain’s MiDNI illustrates the same direction at government level: an official issuer, a short-lived signed QR presentation, and a choice about how much information to reveal.

References

[1] Android Developers: Credential Manager

[2] Android Developers: Identity

[3] Android Developers: Android Keystore system

[4] Android Developers: Support Direct Boot mode

[5] Android Developers: Sensitive data in external storage

[6] Android Developers: Auto Backup for Apps

[7] Android Developers: Cryptography

[8] Apple Platform Security: Keychain data protection

[9] Apple Developer: Restricting Keychain item accessibility

[10] Apple Platform Security: Data Protection overview

[11] Apple Platform Security: Data Protection classes