An over the air update replaces your app's JavaScript without a store release, so the update channel is part of your supply chain. Code signing lets the app verify each update against a certificate embedded in the build, so a compromised server or network cannot push code. In Expo, it is a plan gated feature.
The threat
Store releases go through review and signing by the platform. An over the air update does not. If someone can change what your update server returns, they can change what runs in every installed copy. Causes include a leaked deploy token, a compromised hosting account or a network attacker.
How Expo's signing works
According to the Expo docs, you sign each update with your own private key, and the expo-updates library verifies the signature on the device before applying the update. The docs say that this means network providers, CDNs, cloud providers and even the hosting service itself cannot tamper with the updates apps run. They also state the feature is available on certain paid plans, so check your plan.
The pieces:
- The private key signs updates. The docs say to keep it out of source control, for example in a key management service or password manager.
- The public key is not sensitive.
- The certificate contains the public key and verification method. It is embedded in the app build and can be committed.
- The CLI signs the update locally, so the private key never leaves your machine or build runner.
The client checks the update against the embedded certificate and the attached signature, and rejects it if either is invalid.
Important constraints
Enabling signing needs a new build with the certificate embedded, with a new runtime version. Certificates expire: updates signed with an expired certificate are no longer applied, and binaries with expired certificates will not apply new updates. Put expiry dates on a calendar.
Rotation
Rotate on suspected compromise, expiry or as routine practice. The documented steps are to back up old keys, generate a new pair, set a new runtime version and publish signed updates with the new key. Removing signing is treated as rotation to a null key and also needs a new runtime version. Because rotation requires a new binary, a leak response means a store release, so rehearse it.
Release controls to add
- Restrict who can publish updates, and require review for the publishing workflow.
- Keep update credentials in your CI secret store.
- Log every publish with who and what.
Try it yourself
Click through it at your own pace, or open it full screen.
See how a gate blocks a change before it merges. Apply the same idea to who can change the update publishing workflow.
Quick check
Does signing stop a bad update from my own team?
No. It stops anyone without the key. A faulty or malicious update from someone who holds the key is signed too, so control access and review changes.
Sources
Last reviewed: 19 October 2026.
