Almost nobody carries only a laptop anymore. The encrypted message arrives while you are on a train, and the question becomes immediate: can I read and answer this from my phone without wrecking the security model that made PGP worth the trouble in the first place? The honest answer is a split one. Reading and replying to encrypted mail on iOS or Android is entirely workable today. Generating and using your long-term signing key on a phone is where good practice ends.
The key question: where does the secret key live
Every mobile PGP setup comes down to one design decision: which key lives on the phone. Your key pair has two halves, and only the secret half is sensitive. A setup that puts your primary secret key on the phone makes the phone a full stand-in for your identity, and phones are the device most likely to be lost, stolen, or grabbed while unlocked. A setup that keeps the primary key on your computer and gives the phone only a subkey with limited usage is the arrangement most long-term PGP users converge on.
The standard shape is a primary key for certification (signing other people's keys) plus a separate encryption subkey and signing subkey. You export the subkeys to the phone and leave the primary key offline or on the machine you control best. If the phone is compromised, the attacker can read your mail and forge your messages for as long as those subkeys stay valid, but they cannot extend your web of trust or reconfigure your identity. You revoke the subkeys from the safety of the primary key and carry on. That is a bad afternoon, not a catastrophe.
What the apps actually do
On iOS, the flow most people land on is a mail app paired with an encryption provider that exposes the key operations to other apps through the system's app-extension mechanism. The secret key never leaves the provider's storage; the mail app asks it to decrypt or sign and gets a result back. On Android, OpenKeychain has been the standard encryption provider for years, and several mail clients plug into it the same way. In both cases the practical effect is the same: one app holds the key material, another handles mail, and neither needs full access to the other.
What none of these apps can fix is the passphrase story. Typing a strong passphrase on a phone keyboard is miserable, which pushes people toward weak passphrases, which undermines everything else. Biometric unlock on the key store is a reasonable compromise on both platforms: the passphrase still protects the key at rest, and your fingerprint gates the unlock during use. It is not a hardware token, but it beats a four-character passphrase chosen for typing comfort.
Two setups, ranked
The subkey setup. Primary key stays on your computer, encrypted subkey and signing subkey go to the phone. You can read and reply to encrypted mail from anywhere, and the damage ceiling of a lost phone is bounded. The cost is a one-time key-management session: generating the subkeys, exporting them, importing into the mobile app, verifying the fingerprint on both ends. If you have never handled subkeys before, budget an evening, not ten minutes.
The decryption-only setup. Only the encryption subkey goes to the phone. You can read everything, but replies from the phone go unencrypted or wait until you are back at a real keyboard. This is the right choice for people whose incoming mail is sensitive but whose replies rarely are, and it is the setup to choose if the phone is a shared or work-managed device you do not fully trust.
What you should not do is generate a brand-new identity on the phone on day one and treat it as your permanent key. Phone-generated keys work, but they start your identity on the device with the shortest expected lifetime and the weakest physical security, and migrating a primary key later is exactly the chore that key expiry and revocation planning exists to soften. Build the key where you will keep it.
Verifying keys from a phone
Checking a fingerprint on a phone deserves the same care as on a desktop, and the mechanism is identical: compare the full fingerprint through a channel that is not the same email system your encryption is protecting. The mistake specific to phones is trusting a truncated key ID shown in a small dialog, because short IDs are collidable on purpose by anyone motivated to do it. If the app only shows you eight hex characters, dig into the key details screen for the full 40-character fingerprint. Our walkthrough of verifying a key before you trust it covers why the full fingerprint matters regardless of screen size.
For the first-time key, resist doing it from the phone at all. Use the browser-based generator on the EasyPGP home page on the machine where the primary key will live, then move subkeys to the phone afterward. The generator never transmits the secret key, which is exactly the property you want when the key you are creating is the one everything else will hang from.
The realistic picture
Mobile PGP is no longer a novelty; it is a solved problem with a known-good architecture and a handful of mature apps. The failure mode is not the software, it is the shortcuts: permanent keys born on phones, weak passphrases typed for convenience, fingerprints read but not compared. Get the key layout right once and the phone becomes what it should be, a window onto your encrypted mail that you could throw into a canal without losing your identity.