Security · Coming soon

Signed OTA updates, verified on the device

Every release is checked by the device itself before it writes a byte. Not otalite, and not anyone who breaks into it, can make your devices install anything you didn't sign.
Signed releases

Code signing that the device checks.

Signed firmware updates and app bundles: every release carries an Ed25519 signature in a COSE manifest. The device verifies it before it installs, and keeps the previous version for rollback.
In development
1

Sign

With your Ed25519 key, kept offline
2

Deliver

The signed manifest rides the next check-in
3

Verify

The device checks it before it downloads
4

Switch

Installed beside the old one, then switched
A failed check ends there, before the download: nothing is written, and the outcome is reported on the next check-in.
Your key, or managed signing

Keys you hold. Or keys we hold, knowingly.

Sign with your own key and keep it offline, or let us build and sign for you.
In development
otalite stores your public key only
The release key never has to touch otalite's servers
Device keys are provisioned by the CLI, separate from the release key
Recommended

Your key, kept offline

You sign each release with your own Ed25519 key. otalite holds public keys only, so neither otalite nor anyone who breaks into it can make your devices install anything.
Lighter option

Managed signing

We build and sign for you with a key for your organisation. Simpler, but a key your devices trust is then held by the service: if otalite were breached, code could be signed and shipped to your devices, and they couldn't tell. We offer no protection against that, and choosing it takes an explicit, recorded acknowledgement.
Check-ins

Devices ask. Nothing barges in.

A device asks otalite whether there is an update, on a wake it already makes. otalite can only answer: it can't wake a device, reach into it, or make it install.
In development
OSCORE
Every check-in encrypted end to end and authenticated. Replays are refused.
Device-first
The device starts every exchange. It listens for nothing, so nothing can push code to it or force it to install.
Floor
Check-in intervals have a minimum, so no setting can make a fleet check in so often that it drains.
A device's own key only proves which device is checking in: a leaked one lets someone imitate that device's check-ins, never install code, and is revoked alone.
Rollback and anti-rollback

Never stuck. Never sent backwards.

A bad update undoes itself, and an old, vulnerable release can't be slipped back in.
In development
↺

Rollback

Each update installs beside the running version. If it never confirms it's healthy, the device goes back by itself.
≥ 7

Anti-rollback

Each device refuses any release below the highest security version it has installed, so a fixed vulnerability can't return.
Vulnerability advisories (CVE)

Know when a CVE affects your fleet.

otalite tells you when your code, the packages it uses or the firmware underneath has a known CVE, with its severity, a link to its cve.org record, and the update that fixes it. ESP-IDF vulnerabilities, MicroPython's and your mip packages', across the whole fleet.
Planned
Each release's contents inventoried on our servers, at no battery cost: MicroPython and ESP-IDF versions, frozen modules, mip packages and our client
Matched daily against OSV.dev, NVD and cve.org, GitHub Security Advisories, Espressif's advisories, MicroPython's advisories
In the pre-flight report and a fleet-wide view; alerts to Discord, email and webhooks
A suggested fix and a draft release with each advisory; a critical one blocks a rollout unless an admin acknowledges it
The same inventory as an SBOM export for IoT releases, in CycloneDX or SPDX (planned)
Upstream update watch: a security and battery report for each new package version ›
Advisory matching is best-effort: it finds the vulnerabilities that are published and that match your inventory. "No advisories found" doesn't mean there are no vulnerabilities.
Guidance for ESP32 Secure Boot

Secure Boot and flash encryption, on your devices.

Signed updates protect what arrives over the air. Espressif's Secure Boot V2 and flash encryption protect the device in someone's hands: the key in flash can't be read out, and the firmware can't be replaced over USB. otalite's guides will walk you through turning them on for production.
The EU Cyber Resilience Act and OTA updates ›
Recommended
Secure Boot V2 and flash encryption on every production device.
Lighter option
Flash encryption only. Keys stay encrypted, but someone with the device in hand can flash other firmware, and we offer no protection against that.
Compliance, honestly

Audited infrastructure. Our own audit is Planned.

otalite runs on Fly.io and Tigris, which hold SOC 2 Type 2 reports. Those reports are theirs: otalite itself is not SOC 2 audited, and signs no BAAs.

Audited infrastructure

Built on Fly.io and Tigris, which hold SOC 2 Type 2 reports. Those reports are theirs, not otalite's.
In development

Data Processing Agreement

A Data Processing Agreement covering the data otalite processes for you.
Planned

otalite's own SOC 2 audit

An independent audit of otalite itself. Until then, the SOC 2 reports are our providers'.
Planned

HIPAA workloads

Looking at what HIPAA workloads would need. No HIPAA claim, and no BAAs from otalite.
Exploring
otalite makes no HIPAA claim and offers no BAAs. Designed with the EU Cyber Resilience Act's update requirements in mind; that is not a claim that your product, or otalite, complies with it.
Status

Where each piece stands.

Nothing here is available yet. In development is being built for the first release; Planned is on the plan, not started; Exploring is still being researched.
Security

Signed releases

Ed25519-signed manifests, checked on the device before it installs, with the previous version kept for rollback.
In development
Security

Your key, or managed signing

Sign with your own key and keep it offline, or let us build and sign for you.
In development
Delivery

Low-power check-ins

CoAP and OSCORE: a few hundred encrypted bytes per check-in, and no TLS handshake.
In development
Security and compliance

Vulnerability advisories (CVE)

Known CVEs in your code, packages or firmware, with severity, the cve.org record and the fixing update.
Planned
Security and compliance

SBOM export

Each release's inventory as a software bill of materials, in CycloneDX or SPDX.
Planned
Energy and security

Upstream update watch

A security and battery report for every new version of a package you use, with a draft release.
Planned
Security and compliance

Audited infrastructure

Built on Fly.io and Tigris, which hold SOC 2 Type 2 reports. Those reports are theirs, not otalite's.
In development
Security and compliance

Data Processing Agreement

A Data Processing Agreement covering the data otalite processes for you.
Planned
Security and compliance

otalite's own SOC 2 audit

An independent audit of otalite itself. Until then, the SOC 2 reports are our providers'.
Planned
Security and compliance

HIPAA workloads

Looking at what HIPAA workloads would need. No HIPAA claim, and no BAAs from otalite.
Exploring
See the whole roadmap ›
Related

Keep exploring.

Rollouts

Rollouts that stop themselves.

Waves that widen only when it's safe, and pause on failures.
Learn more ›
Workflow

Ship from where you already work.

Git, CI, the CLI, your phone, Discord and your coding agent.
Learn more ›
Battery

Built for devices that sleep.

Schedules, battery targets, and months of battery simulated in minutes.
Learn more ›
Community

Follow the build.

otalite isn't available yet. Register your interest to hear first, or join the Discord to see what we're building and tell us what your fleet needs.
Register interest
Join the Discord
See the roadmap
© 2026 otalite · Coming soon
FeaturesBatterySecurityRolloutsInsightsWorkflowRoadmapMicroPython OTA optionsBattery life calculatorCyber Resilience ActAboutRegister interestDiscordGitHub