React Native OTA Bundle Signing: Secure & Verify Updates Before Installation

Why OTA Updates Need a Security Layer

Over-the-air (OTA) updates let React Native teams ship JavaScript and supported assets without publishing a new native app build for every change. That flexibility also means the update-delivery path becomes part of the application's software supply chain.

The important question is not only "Can users download the update?" but also:

Can the app verify that the update came from a trusted source and has not been modified before it is installed?

That's where bundle signing comes in.

React Native Stallion supports customer-managed bundle signing so teams can sign OTA bundles before publishing and have the Stallion SDK verify the signature before installation.

What Bundle Signing Actually Protects

Bundle signing uses public-key cryptography to let a device verify the authenticity and integrity of an OTA artifact.

A signing flow typically has two related keys:

Private key — used to sign the release. This should remain under the team's control and should never be committed to source control.
Public key — used by the application to verify the signature.

If the downloaded artifact does not pass signature verification, the update should not be installed.

Bundle signing helps protect against scenarios such as:

An OTA artifact being modified after it was signed.
An unauthorized party attempting to publish an artifact that the application will not accept because it is not signed by the trusted key.
A corrupted or altered update being accepted as a valid release.

Signing is one security control in an OTA system. It does not replace HTTPS, access control, CI/CD security, monitoring, or release governance.

TLS vs. Bundle Signing

HTTPS/TLS and bundle signing solve different problems.

TLS protects the connection. It encrypts data in transit and helps establish a secure connection between the device and the update service.

Bundle signing protects the artifact. The device can verify the cryptographic signature of the update before installation.

Using both gives you defense in depth:

CI / developer → signed bundle → HTTPS/CDN delivery → device verification → installation

This distinction matters because transport security alone is not the same thing as application-level verification of the artifact.

It's also worth distinguishing signing from encryption. Encryption protects confidentiality — it makes data difficult for unauthorized parties to read. Signing provides authenticity and integrity — it lets the receiver verify that the artifact was signed by a trusted key and has not been modified since signing. For OTA systems, both can be useful: TLS protects the network connection, encryption can protect sensitive data where applicable, and signing verifies the OTA artifact itself. These complement — rather than replace — access controls that restrict who can publish releases, CI/CD security, staged rollout controls, and rollback mechanisms that limit the impact of a bad release. A secure OTA architecture uses these controls together rather than treating any one control as a complete security solution.

How Stallion Bundle Signing Works

When bundle signing is enabled, the signing process can happen as part of your local or CI release workflow.

1. Generate a Key Pair

Use the Stallion CLI to generate a key pair:

stallion generate-key-pair

This produces a private key and a public key.

stallion/secrets/
├── private-key.pem
└── public-key.pem

The private key is used for signing. The public key is used for verification.

2. Add the Public Key to the Native App

The public key needs to be available to the native application so the Stallion SDK can verify signed OTA updates.

For Android, add the base64-encoded public key to strings.xml:

<string name="StallionPublicSigningKey">YOUR_PUBLIC_KEY_HERE</string>

For iOS, add it to Info.plist:

<key>StallionPublicSigningKey</key>
<string>YOUR_PUBLIC_KEY_HERE</string>

Only the public key belongs in the application. Never include the private signing key in the app.

For the exact configuration and key format, see the Bundle Signing documentation.

3. Protect the Private Key

The private signing key is the most sensitive part of the workflow.

Store it in a secure secret manager or CI/CD secret store. Do not commit it to Git, place it in a public repository, or expose it in build logs.

For production pipelines, access to the signing key should be limited to the people and automation that are actually allowed to publish production OTA releases.

4. Sign the Bundle Before Publishing

Publish the bundle using the private key:

stallion publish-bundle \
  --upload-path=my-org/my-project/my-bucket \
  --platform=android \
  --release-note="Secure OTA release" \
  --private-key=./stallion/secrets/private-key.pem

Stallion attaches the cryptographic signature to the bundle metadata as part of the publishing workflow.

5. Verify the Signature on the Device

When the update is received, the React Native Stallion SDK verifies the signature using the corresponding public key.

The signed update is accepted for installation only when signature verification succeeds.

This creates a trust boundary between the party authorized to sign releases and the device that is about to execute the update.

Customer-Managed Signing Keys

One important advantage of customer-managed signing is that your team controls the private signing key.

The key can remain in your own development environment, CI system, or secret-management infrastructure rather than becoming another credential managed by the OTA provider.

This can be useful for teams with:

Strict software supply-chain requirements
Enterprise security reviews
Separation of deployment responsibilities
Internal key-management policies
Regulated or security-sensitive applications

Stallion's bundle-signing workflow is designed around this model: sign the artifact before it is uploaded, keep the private key under your control, and verify the update on the device.

For enterprise teams, customer-managed signing can fit into broader software-supply-chain governance alongside SSO, audit logging, role-based access control, CI/CD controls, regional data hosting, and deployment policies.

Bundle Signing in CI/CD

Bundle signing fits naturally into an automated release pipeline.

A production workflow can look like:

Code merge
   ↓
CI build
   ↓
Retrieve signing key from secret manager
   ↓
Generate OTA bundle
   ↓
Sign bundle
   ↓
Publish to Stallion
   ↓
Release / rollout controls
   ↓
Device downloads update
   ↓
Signature verification
   ↓
Install verified update

This keeps signing close to the release artifact rather than making it a separate manual security step.

A CI system should also ensure that:

Production signing credentials are stored as secrets.
Pull requests and untrusted workflows cannot access production signing keys.
Signing keys are rotated according to your organization's security policy.
CI logs never print private key material.
Production publishing permissions are restricted to the appropriate workflow.

What Happens if Verification Fails?

If the downloaded update does not pass signature verification, it should not be treated as a trusted update.

That protects the application from accepting an artifact that does not match the expected cryptographic identity.

A failed verification can happen because:

The artifact was modified.
The signature does not match the artifact.
The wrong signing key was used.
The update was produced by an unauthorized release workflow.
The downloaded data is corrupted.

The important behavior is simple:

Unverified update → reject the update → continue using the existing trusted version.

Bundle Signing and Patch Updates

Differential or patch-based OTA delivery does not remove the need for update verification.

Whether an OTA platform delivers a full bundle or a differential patch, the resulting update should be verified before installation.

Stallion supports both on-demand differential patch delivery and bundle signing, and the two capabilities are designed to work together: differential delivery can reduce transfer size while signing provides a cryptographic verification layer for the update workflow.

The exact patch size depends on the changes between releases. Stallion's documented benchmark scenarios have reached up to 98% smaller payloads than corresponding full bundles. Actual patch size depends on the versions being compared and what changed.

Why Bundle Signing Matters for Production OTA

OTA updates are part of your production software supply chain.

A secure release process should therefore answer:

Who is allowed to publish an update?
How is the release artifact protected?
How does the device know the artifact is trusted?
What happens when verification fails?
Where are signing credentials stored?
Can the release be rolled back if something goes wrong?

Bundle signing addresses one of those questions directly: how the device verifies the authenticity and integrity of the OTA artifact.

For enterprise teams, that can complement broader controls such as access management, audit logging, CI/CD governance, staged rollouts, rollback mechanisms, and security monitoring.

Bundle Signing With React Native Stallion

Stallion combines bundle signing with the release controls needed to operate OTA updates in production.

Depending on your plan and configuration, the platform provides capabilities such as:

Customer-managed bundle signing
OTA release and rollout controls
Release analytics
Rollback controls
CI/CD integration
On-demand differential patch delivery
Enterprise deployment options

The goal is not simply to make OTA updates smaller or faster. It is to give teams more control over what gets published, who can publish it, how it reaches users, and whether the device accepts it.

Supported Versions

Check the current Stallion documentation for supported CLI and React Native SDK versions before implementation, as version requirements can change.

Getting Started

Generate your signing keys

stallion generate-key-pair

Add the public key to your native app

Add the public key as StallionPublicSigningKey in Android's strings.xml and iOS's Info.plist before publishing a signed release. See the Bundle Signing documentation for the exact format.

Publish a signed bundle

stallion publish-bundle \
  --upload-path=my-org/my-project/my-bucket \
  --platform=android \
  --release-note="Production release" \
  --private-key=./stallion/secrets/private-key.pem

For the complete setup, see the Bundle Signing documentation.

If you're integrating Stallion with Expo, the Expo integration documentation also covers configuring the public signing key in the native app.

Pro Tip:

Already using Stallion? Start signing your bundles today with stallion generate-key-pair.

Bundle Signing Security Checklist

Before enabling production OTA releases, verify that your team:

Frequently Asked Questions

What is bundle signing for React Native OTA updates?

Bundle signing uses cryptographic signatures to allow a React Native application to verify an OTA update before installing it. The device uses a trusted public key to verify an update that was signed with the corresponding private key.

Does bundle signing replace HTTPS?

No. HTTPS/TLS and bundle signing provide different protections. TLS protects data in transit, while signing provides artifact authenticity and integrity verification. Using both provides defense in depth.

Should the OTA provider hold my private signing key?

That depends on the provider's security model and your organization's requirements. Customer-managed signing lets your team retain control of the private key and use it from your own environment or CI/CD secret store.

How do I protect my OTA signing key?

Keep the private key in a secure secret manager, restrict access to authorized release workflows, never commit it to source control, and avoid exposing it in logs. Follow your organization's key rotation and incident-response procedures.

Does bundle signing protect against every OTA attack?

No. Bundle signing addresses artifact authenticity and integrity, but OTA security is broader. Teams should also use secure transport, strong access controls, protected CI/CD credentials, release governance, monitoring, and rollback mechanisms.

Is bundle signing useful with patch updates?

Yes. Differential delivery reduces the amount of data transferred, while signing provides a way to verify the update artifact before installation. The two controls address different parts of the OTA delivery problem.

Secure Your React Native OTA Release Pipeline

OTA updates give React Native teams a faster way to ship supported application changes. Bundle signing adds another layer of control by letting your team manage the signing key and verify updates before installation.

With React Native Stallion, you can combine customer-managed bundle signing with OTA release controls, CI/CD integration, rollback capabilities, and on-demand differential patch delivery.

Read the Bundle Signing Documentation →

Get Started Free →

Explore React Native Stallion →