> ## Documentation Index
> Fetch the complete documentation index at: https://docs.neuro-tech.io/llms.txt
> Use this file to discover all available pages before exploring further.

# IoT security model

> Layer identity, TLS, federation, consent, provisioning, P2P, and end-to-end encryption

No single mechanism protects a Neuro IoT interaction. Security is layered.

## Layers

| Layer                      | Protects                                              |
| -------------------------- | ----------------------------------------------------- |
| SASL authentication        | Entity connection to its XMPP broker                  |
| TLS transport              | Each TCP/WebSocket/BOSH hop                           |
| Federation validation      | Broker domain identity across S2S links               |
| Roster/presence consent    | Who may establish a social communication relationship |
| Tokens                     | Additional device, service, or user assertions        |
| Provisioning               | Owner-defined operation authorization                 |
| P2P authentication         | Direct peer channel establishment                     |
| End-to-end encryption      | Stanza content across brokers/intermediaries          |
| Legal identities/contracts | Legally meaningful actors and agreed policy           |

## Bindings

Clients can connect through supported XMPP bindings such as TCP, WebSocket, or BOSH depending on the implementation. Use a secure transport and validate the broker certificate/host name. Browser constraints do not weaken the authorization model.

## End-to-end encryption

The Neuro E2E interface publishes asymmetric key material, negotiates supported algorithms, and protects message and IQ stanzas with hybrid encryption. Supported families can include RSA, elliptic-curve and post-quantum algorithms, with AES-256 or ChaCha20/Poly1305 symmetric protection depending on endpoints.

Feature-detect algorithms, reject downgrade, rotate compromised keys, and bind keys to the authenticated peer.

## Federation

In federation, brokers validate each other's domains and forward stanzas between clients on different domains. An application must still authenticate the end actor and authorize the requested operation; a valid remote domain is not blanket trust.

## Threat checklist

* replayed commands and stale tokens;
* malicious or compromised broker/package;
* device claim-code theft;
* over-broad provisioning cache entries;
* prompt/script injection through sensor labels or messages;
* metadata/location leakage through discovery;
* unsafe control retries;
* lost key revocation and software-update signing keys.