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.
Warblet asks the question differently: how much security does this device deserve, today? You pick a level — Open, Token or Signed — 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 — Encrypted, per device at any of the three levels. Each level adds exactly one thing to what the device puts on the wire; the switch sits beside them, not above them:
- Openthe hardware id
- Token+ token
- Signed+ signature
The levels are best understood as a threat model — who can attack you at each one:
| Level / switch | API field | The device sends | Who can still attack you |
|---|---|---|---|
| Open | securityLevel: 0 | 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) |
| Token | securityLevel: 1 | + 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. |
| Signed | securityLevel: 2 | + 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 |
| Encrypted | enforceTls | the same message, over TLS | a switch 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 Warblet — https., http., mqtt., tcp. and udp., listed with ports and one-liners in Send your first packet — only https. and mqtt. on port 8883 can carry TLS at all. The other three 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 (Open). Blink the LED, see the chart move, show a friend. Minutes, not evenings.
- 2Harden while still playing (still Open!). You control the payload and the decoder, so you can add your own protection without touching a security setting — see Open 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 (Token→Signed, and switch on Encrypted). 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 Token · designed for Signed.
That line is not a warning light. What protects a device is what it transmits — a device designed for Signed and reporting as Token has Token’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. Token’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 Signed 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.warbletiot.com is real work, but it is work on the other axis: do it whenever you want Encrypted, 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 switch 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 |
|---|---|---|
| Open not encrypted | id and payload, in the clear | The first hour. Data you’d shrug at if it were spoofed, and gear you cannot reprogram that can post to a URL. |
| Open + Encrypted | confidential, but unauthenticated | Rare and legitimate: gear that can do HTTPS but can’t hold a secret, sending readings you’d rather nobody read. |
| Token not encrypted | the default | Anything that stays plugged in unattended. Kills every off-path attacker. |
| Token + Encrypted | authenticated and unreadable | The sweet spot for capable read-only sensors: business data, customer sites, no signing key to manage. |
| Signed not encrypted | integrity on a plaintext wire | Actuators, and MCUs with no room for a TLS stack. udp., tcp. and mqtt. live here. |
| Signed + Encrypted | signed and encrypted | Actuation at customer sites — the one combination that survives a token leaked through a proxy log. |