Even Nabto can’t get into your devices.
By design.
The gatekeeper is your device, not our cloud.
This page explains how that is built, what it covers and what it does not.
The claim
Who can open a connection to your device
A Nabto Edge device keeps its own list of the users it has paired with. Each user is a key the device has learned, not a password held anywhere else. When a connection arrives, the device checks the key against its own list and decides on its own. Nabto’s servers hold no credential that any device accepts. This describes Nabto Edge and Nabto WebRTC when it is used with shared secret authentication; see the note on Nabto WebRTC below.
How it works
How a connection is admitted
Scroll the diagram sideways to see all of it →
Pairing
The device learns a user’s key and adds it to its own list during pairing. Nothing is registered with Nabto except the device’s public identity.
Connecting
Our servers find the device and route the connection, directly where the network allows, relayed and still encrypted where it does not.
Admitting
The device checks the arriving key against its own list. Nothing in that check involves Nabto.
If Nabto is breached
An outage, not an intrusion
For Nabto Edge and for Nabto WebRTC with shared secret authentication, a compromise of Nabto’s infrastructure is an availability incident for your devices, never an access incident. Nothing on those servers opens a device: No keys, no passwords, no override, no update path. An attacker holding all of them could stop connections from being made. They could not make one.
The limits
What we do see and what you still trust us for
Connection metadata
Our servers see which device was connected to, when and from which network address. Relayed traffic passes through us encrypted; we see its volume, not its content.
Our servers can refuse, never grant
Before a connection reaches a device, our servers check that the client holds a valid token. This is a shield against denial-of-service attacks on your devices. It can only say no. Saying yes is the device’s decision alone.
The SDK is code you build in
The Nabto Edge device SDK is the code inside your product that decides who may connect; its source is published. You can read it, build it yourself and compile it into a firmware image that you build and sign. You trust it the way you trust any library in your build: By inspection, not by reputation.
Nabto WebRTC has two models
With shared secret authentication, the client and the camera share a secret known only to them and Nabto’s signaling service cannot forge or validate their messages; that model has the same property as Nabto Edge. In the centralized model, Nabto’s signaling service checks your backend’s token and tells the camera the connection is authorized, so Nabto is a trusted third party there. Details in Nabto WebRTC security.
At a glance
Who can open a session to your device
| Nabto Edge | Typical cloud IoT platform | |
|---|---|---|
| Users the device has paired with | Yes | Yes |
| Your own backend | Only if paired like any user | Yes, as the platform’s tenant |
| Nabto (or platform vendor) staff | No | Yes, by design of the platform |
| An attacker holding all of the vendor’s infrastructure | No; can only block connections | Yes |
| A lawful order served on the vendor | Connection metadata, which Nabto hands over; device access, which Nabto does not hold | Can produce device access |
For assessors
The precise version
- Nabto Edge security overview (developer docs) →
- Nabto WebRTC security overview (developer docs) →
- Pairing and device-side access control (developer docs) →
- Reporting a vulnerability →
The developer documentation is the normative reference; this page is the plain-language statement of the same model.
Questions
- Could Nabto get into my devices, even in theory?
- For Nabto Edge and for Nabto WebRTC with shared secret authentication, no, not even in theory: A device admits only users it has itself paired with or that hold a secret known only to the client and the device; nothing Nabto holds or runs can change that. In Nabto WebRTC’s centralized model it is possible in principle, because the camera acts on the signaling service’s word that a connection is authorized. No feature does this, but the design relies on that word being honest, which is what makes Nabto a trusted third party there.
- Does Nabto Edge require me to trust Nabto’s servers?
- No. Nabto Edge does not require you to trust Nabto’s servers; they route connections and can refuse them, but cannot open one.
- What happens to my devices if Nabto is breached?
- For Nabto Edge and for Nabto WebRTC with shared secret authentication: Connections may stop being made until service is restored. No device can be opened as a result.
- What does Nabto see?
- Connection metadata: Which device was connected to, when and from which address. Relayed traffic is encrypted end to end.
- Can Nabto push a firmware update to my device?
- No. Nabto ships no firmware; you build and sign the image yourself. Your application can implement its own update path on top of Nabto Edge, for example over Nabto Edge Streams, but that is the application’s decision and code, not Nabto’s.
- What happens if Nabto receives a lawful order?
- Nabto complies and hands over what it holds: Connection metadata. It cannot hand over access to a device, because it has none. It cannot build one into a product it does not control either; the device and its keys are the customer’s.