Security levels: pick how much your project deserves
Every IoT cloud makes you answer a security question before your first packet flies. Most of them only accept one answer: certificates, provisioning ceremonies, IAM policies — enterprise armor, mandatory, even for a soil-moisture sensor on your windowsill.
Warble asks the question differently: how much security does this device deserve, today? You pick a level, 0 through 2 — on the spec for a fleet, on the device itself until it joins one — and change it any time. Moving up never re-architects your system — your dashboards, decoders, and routines don’t change at all — but each level does ask a little more of the device: a token, then a hash.
The levels are one axis and they answer one question: who is allowed to send. Whether anyone can read what is sent is a second, independent question, and it has a switch of its own — Enforce TLS, armable per device at any of the three levels. Each level adds exactly one thing to what the device puts on the wire; the flag sits beside them, not above them:
- L0Openthe hardware id
- L1Token+ token
- L2Signed+ signature
The levels are best understood as a threat model — who can attack you at each one:
| Level | Name | The device sends | Who can still attack you |
|---|---|---|---|
| L0 | Open | its id + payload | anyone on the internet who learns the id — and ids are public by design (they’re on your dashboard, in screenshots, printed on the board) |
| L1 | Token | + a device token | only someone who can capture your traffic in flight — your LAN, an open Wi-Fi network, the path between. Off-path attackers are done. |
| L2 | Signed | + an HMAC of each payload | an on-path observer can still read, but can no longer alter or forge a single byte — without TLS on a tiny MCU |
| flag | Enforce TLS | the same message, over TLS | armed at any of the three levels, and it changes a different thing: nobody can read it. What’s left is whoever the level still lets send, plus endpoint security — your portal password, your device’s physical custody. Off by default; while it is off, nothing here claims confidentiality |
Neither axis dominates the other: against someone tapping your Wi-Fi, encryption wins; against a token that leaked into a proxy log, a signature wins, because the attacker still doesn’t have the key. Of the five ways into Warble — https., http., mqtt., tcp. and udp., listed with ports and one-liners in Send your first packet — only https. can carry TLS at all. The other four get the levels and nothing else.
The philosophy: security as a dial, not a gate
The reason most projects die in the AWS IoT console is that the armor is demanded before the idea has proven it deserves armor. Our order is reversed:
- 1Prove the idea naked (L0). Blink the LED, see the chart move, show a friend. Minutes, not evenings.
- 2Harden while still playing (still L0!). You control the payload and the decoder, so you can add your own protection without touching a security setting — see Level 0 for the full hardening ladder: payload HMAC verified in your decoder script, spam-blocking from your own scripts, claim-code binding.
- 3Graduate when it’s real (L1→L2, and arm the flag). Demonstrated the concept? Moving to production? Turn the dial. We give you the tools to re-provision the fleet from a browser — Web Serial for ESP32 (write Wi-Fi credentials and tokens over USB, no toolchain), and USB DFU for STM32 (the chip’s built-in bootloader, driven from the browser) — so “secure it now” is a re-provisioning pass, not a rewrite.
Moving up without going dark
The level on the spec is the design. What a device reports as is what its firmware has actually proven it can send. Those two are allowed to differ — and while they do, the portal says so everywhere that device appears: reporting as L1 · designed for L2.
That line is not a warning light. What protects a device is what it transmits — a device designed for L2 and reporting as L1 has L1’s protection, and nothing in the portal implies otherwise.
Closing the gap is a short numbered list, and it is the same list the device page counts you through — step 2 of 4, with the current one in bold:
- 1Send a valid token. L1’s one requirement, and the floor for everything above it.
- 2Get the signing key. One click on the device page. It changes nothing at the door — the device keeps reporting exactly as it did.
- 3Put it on the board. Over USB, or however your firmware gets its config. This is the one step the portal cannot see, so it is the one step that never gets a tick.
- 4Send one signed message. Nothing to do: the first message that arrives with a valid signature raises that device to L2 by itself, from that message on.
Enforcement follows the firmware, it never leads it, which is why there is no window where your data stops arriving.
There is no TLS step on that list. Pointing a device at https.chirpiot.com is real work, but it is work on the other axis: do it whenever you want Enforce TLS, at whatever level the device already reports as, with no signature required first.
The manual raise lives on the device page behind an advanced fold, for people who wrote the firmware and already know what it sends. It flips enforcement immediately — and a device whose firmware isn’t yet sending what that level asks for goes dark until it is.
How to choose
The level is who’s talking; the flag is who’s listening. Pick each on its own merits — all six combinations are real, and each one is right somewhere:
| Combination | What you get | When it’s the right one |
|---|---|---|
| L0 flag off | id and payload, in the clear | The first hour. Data you’d shrug at if it were spoofed, and gear you cannot modify. |
| L0 + TLS | confidential, but unauthenticated | Rare and legitimate: gear that can do HTTPS but can’t hold a secret, sending readings you’d rather nobody read. |
| L1 flag off | the default | Anything that stays plugged in unattended. Kills every off-path attacker. |
| L1 + TLS | authenticated and unreadable | The sweet spot for capable read-only sensors: business data, customer sites, no signing key to manage. |
| L2 flag off | integrity on a plaintext wire | Actuators, and MCUs with no room for a TLS stack. udp., tcp. and mqtt. live here. |
| L2 + TLS | signed and encrypted | Actuation at customer sites — the one combination that survives a token leaked through a proxy log. |