Your upload key is disposable

Every Android release I ship passes through two keys, and for years the documentation described them as if they were siblings. They are not. Under Play App Signing, the upload key does one job: it proves to Google that the bundle came from the account that owns the app, and if it is lost or leaked it can be reset from the console in a day. The app signing key does a different job: it is what a device checks when it decides whether an update is really an update, and on older Android versions its loss or compromise is permanent, because the devices in the field will trust nothing else. Two keys, two security classes, and in 2026 Google sharpened the difference in a way that moves almost all of the operational risk onto the key you handle every release.

Two keys, two classes

The Play App Signing documentation is clear once you read it for the distinction. The upload key is yours: an RSA key of at least 2,048 bits in a keystore you hold, used to sign the bundle before upload, used by Google to verify your identity, and resettable if compromised or lost by generating a new one, exporting its certificate and requesting a reset in the console. The app signing key is Google's to hold: it signs the APKs that reach devices, you can let Google generate it or upload your own, and the page's warning is unambiguous about the alternative, that a key you manage yourself outside Play App Signing cannot be reset if you lose it.

What changed in 2026

The 2026 change is the introduction of quantum-ready hybrid signing. New apps are now enrolled by default with Google-generated keys, and the app signing key becomes a pair: a classical RSA 4096-bit key and a post-quantum ML-DSA-65 key, combined so that a device can verify either. Developers can request an annual key upgrade that applies to all installs on Android 17 and above, and only Android 17, API level 37, and later strictly enforces the upgraded hybrid key. The page also notes a limitation that matters for release engineering: apps using hybrid signing are excluded from v4 signing, the signature scheme that supports optimised distribution on Android 11 and later, because the two are not yet compatible.

Read from the seat of someone who owns release engineering for a set of apps, the change does two things. It removes the last reason to hold your own app signing key, because a Google-generated hybrid key is now the default and the post-quantum half is something no team is going to generate and rotate correctly by hand. And it makes the enforcement of the new key a property of the device population rather than of the app, which means the fleet decides how much the new key matters. The fleet, per the version distribution compiled from April 2026 data, is where the honest picture is.

The distribution says the new key is, for now, a future-proofing measure and not an operational one: in April 2026 no active device enforced it, over two thirds of devices enforced the latest classical key, and a quarter were on versions where the classical key is verified through Play's own protections. The hybrid key will matter as Android 17 devices ship, and by then the apps enrolled today will already be signed with it, which is the point of doing it by default.

The upload-key firewall

If the app signing key is Google's and the devices' concern, then everything the release process can get wrong is concentrated in the upload key, and the practice I call the upload-key firewall follows. Treat the upload key as a disposable credential. Rotate it on any suspicion, not on proof; the reset is a form and a day, and the cost of an unnecessary rotation is nothing. Keep it in the continuous integration system's secret store and nowhere else: not in a repository, not in a shared drive, not in a keystore file on a laptop that also has the source code. And never let the two keys share a machine, a person or a backup: the app signing key should not be held at all, and if a legacy app's key is still held, it lives in a place the release pipeline cannot reach.

The firewall is a practice, not a product, and it has a few specific rules. The upload keystore is generated on the build machine or in the secret store's own key generation, never on a personal laptop, and its password lives in the same secret store under a separate entry. The certificate, which is public, is what gets registered with Play; the keystore itself never leaves the pipeline. The reset procedure is rehearsed once, on a test app, so that the day it is needed for a real one it takes an hour and not a weekend. And the release process records which upload key signed which release, so that a rotation is a dated event in the log rather than a mystery a year later.

What still cannot be reset

The honest exception is the legacy app. An app published before Play App Signing existed, still signed with a key its developers hold, is outside the model: its signing key is the one devices trust, Google does not hold a copy, and the help page's warning applies in full. For those apps the right move is to enrol, which for an existing app means uploading the current key to Google once, under the enrolment's protections, and then treating it as gone from the team's hands. The firewall's rules apply from that day. Until it is done, the legacy key is an asset that a lost laptop or a departed colleague can destroy, and the annual key upgrade that the hybrid scheme offers cannot reach it.

There is also a class of device the new key will never help, and it is the quarter of the fleet on Android 7 to 12. Those devices verify the classical key, and they will keep verifying it for as long as they are in use, which for budget hardware in the markets I ship to is years. The hybrid key protects the future fleet against a threat that does not exist yet; the classical key protects the present fleet against threats that do, and Google's holding both is what makes the arrangement work. The upload key, meanwhile, protects neither. It protects the account, for one release at a time, and that is why it can be thrown away.

Why the split matters more now

For a small team shipping several apps under one account, the practical effect of the 2026 change is that the risk profile got simpler. There used to be two keys to protect, one of them irreplaceable. Now there is one key to protect, it is replaceable, and the irreplaceable one is held by a party whose job is to hold it, in a form, hybrid post-quantum signing, that a small team could not produce on its own. The right response is not to relax about the upload key but to treat it as what it has become: the only credential in the release process that a mistake can expose, and one whose exposure costs a day. Disposable is the correct word, and a disposable credential is handled by assuming it will be disposed of.