MAX IoT

From people to machines

MAX App works on the human side: identity, signature, vault, login and communication. MAX IoT applies the same principle to the machine side: device identity, roles, signed rules, manifests and controlled communication.

The central shift is identity

In the MAX model, a person is not only an account, and a machine should not be only a network address or a device waiting for commands.

A person can have a MAX ID as the public verifiable root of a digital identity. MAX IoT brings the same idea to devices: a machine can have a MAX ID, be recognized, receive a role and apply verifiable rules.

This is close to extending the idea of an identity card from people to machines: not only “this device exists”, but “this device is this one, it can do this, and it can produce evidence of that behavior”.

The same questions run through the ecosystem: who you are, what you can do, how you can prove it.

Technical note

MAX IoT uses the same operational cryptographic family used by MAX App: SPHINCS+ for signatures and verification, FrodoKEM for post-quantum key exchange or agreement flows, together with hashes, public keys and signed manifests. MAX IoT does not present MAX Prime Theory as a replacement for established cryptography.

Why this is not ordinary IoT

Many IoT systems start from the command: an app, a server or a dashboard sends instructions to a device. MAX IoT starts earlier: from the digital identity of the device, its MAX ID, its assigned role and the signed rules it is allowed to apply.

1

Common IoT

Command first

In many systems, the central point is sending a command to a device registered on a platform or associated with an account.

2

MAX IoT

MAX ID first

MAX IoT makes explicit which device is acting, which MAX ID identifies it, which role it has received and which rule authorizes the behavior.

3

Verification

Then evidence

A node should not only receive instructions. It should leave readable evidence: applied manifest, active role, operational state and alignment reports.

What the prototype already demonstrates

The current prototype uses Raspberry Pi to demonstrate a real flow: MAX Chat, server, gateway, peer node, command, response and reporting.

ID

Device MAX ID

Machine identity

Each node can have a device MAX ID. This makes it possible to distinguish the machine, connect it to a fleet, assign a role and apply specific rules.

FM

Fleet Manifest

Signed rules

A Fleet Manifest describes devices, roles, peers, gateways, operators and services. Each node applies only the section that concerns its own identity and role.

↔

Gateway / peer

Controlled communication

A gateway can receive commands and forward them to authorized peers. A peer can respond, and the result can return to the user through MAX Chat.

The command-response flow

MAX Chat becomes the most readable bridge between a person and a machine.

From iPhone to device, and back

A command can start from MAX Chat on iPhone, reach the server, be received by an authorized Raspberry gateway, reach a peer node and return as a response to the user.

1. MAX Chat The user sends a command from an interface already connected to MAX identity.

2. Server The server coordinates messages, manifests, reports and response routing.

3. Gateway The gateway node receives the command and forwards it only to authorized peers.

4. Peer The peer node receives, processes or simulates the response according to its role.

5. Report The node can communicate status, manifest application and alignment state.

6. Response The response returns to the user through the controlled flow.

Why it matters

The value is not simply “turning something on remotely”. The value is connecting command, identity, role, signed rule and response inside an observable flow.

Same post-quantum layer as MAX App

MAX IoT is not a separate experiment with unrelated security logic. It uses the same core post-quantum components already present in MAX App.

SPX

Signatures

SPHINCS+

SPHINCS+ is used for signatures and verification. In the IoT model, signatures connect identities, manifests, approvals and verifiable actions.

FK

Post-quantum exchange

FrodoKEM

FrodoKEM is used as the post-quantum component for secure exchange or agreement flows, aligned with the communication model already used in MAX App.

MAX

Architecture

MAX-specific integration

The original part is not a new cryptographic algorithm. It is the way MAX ID, signatures, public keys, manifests, roles, devices and reports are connected.

Known components, MAX architecture

MAX IoT integrates known and studied cryptographic components, including post-quantum components, inside a verification-oriented architecture. MAX Prime Theory remains connected to the identity model and deterministic structure, not to replacing SPHINCS+, FrodoKEM, hashes or public-key verification.

What a technical evaluator can inspect

MAX IoT should be evaluated as a verification-oriented device identity architecture, not as a finished industrial IoT platform.

✓

Inspectable objects

Evidence, not claims

Device MAX ID, public keys, signatures, hashes, signed manifests, applied configurations and node reports make the system more readable.

R

Roles

Behavior from rules

A node should not act only because it receives a command. It should act because its identity, role and signed rules authorize that behavior.

!

Validation

External review

Implementation, server security, key handling, provisioning, recovery, scale behavior and UX security require independent technical review.

What already exists

There is a working Raspberry Pi prototype with device MAX ID, gateway, peer, Fleet Manifest, commands from MAX Chat, responses back to iPhone, apply reports and local panels for status and diagnostics.

The real flow already demonstrated is: iPhone MAX Chat → Raspberry gateway → Raspberry peer → response → iPhone.

Current phase

MAX IoT is an advanced working prototype. The installable package exists, the main tests have been executed and the model has already demonstrated device identity, signed manifests, local apply, gateway, peer and response.

The next phase is mainly public documentation, independent audit, operational hardening, larger-scale testing and external technical evaluation.

IoT

What MAX IoT is not

MAX IoT is not yet an industrially certified product, it is not a third-party audited system, it does not promise absolute security and it does not automatically replace existing industrial IoT platforms.

It is not simply a Raspberry project either. Raspberry Pi is the technical proof. The model is device identity through MAX ID, SPHINCS+ signatures, FrodoKEM-based post-quantum communication flows, signed Fleet Manifests, verifiable roles, controlled communication and observable reports.