Skip to main content

Security Model

ESP RainMaker Neo runs entirely in your own AWS account, so its security model is one you can audit end to end. This page is written for the reviewer who has to sign it off: what proves a device is genuine, what proves a person is who they claim, who can do what, and which parts remain your responsibility.

Device identity​

Every node has its own X.509 certificate and private key, provisioned before it can connect. The key never leaves the device, and the certificate must be registered in your deployment before the broker will accept a connection.

Two ways to get credentials onto a device:

  • Assisted claiming — the node generates its own key on first setup and receives a certificate. Nothing secret is pre-flashed. This is typically done for evaluations.
  • Factory NVS — credentials are generated and flashed at manufacture, for production runs.

Either way the credentials survive a factory reset, because identity is not user data. See Device credentials.

User identity​

Users authenticate against Amazon Cognito and receive a JWT.

  • For calls to the REST API that token is the credential.
  • For direct MQTT access the client exchanges it for temporary AWS credentials and signs requests with SigV4 — so a user's MQTT access is bounded by an IAM role and expires on its own.

The full chain, with the actual calls, is in API getting started.

Authorization​

Three layers, each independently enforced:

  • IoT policies scope what a device may publish and subscribe to, so a compromised node cannot read another node's topics.
  • Group membership decides which nodes a user can see at all — see User–node association.
  • Role-based access control separates admins from end users, and super admins from admins, in the Admin Dashboard and admin APIs.

The admin role is deliberately narrower than people expect. It is worth knowing what it cannot do:

Not grantedConsequence
iot:GetThingShadow, iot:UpdateThingShadowThe dashboard cannot read or write shadows through the REST API
iot:DeleteThingShadowCannot delete shadows
iot:ListNamedShadowsForThingCannot enumerate shadow names
iot:DescribeIndexCannot inspect the Fleet Indexing configuration
Any dynamodb:*No direct database access; everything goes through the Lambda APIs

That last row is the important one: there is no path from an admin session to raw table data.

Shadow access needs more than IAM

The IoT data plane also requires an IoT policy attached to the Cognito identity. Adding a shadow action to the admin IAM role alone does not grant it — a useful thing to know before concluding a permission is missing by mistake.

Data in transit and at rest​

Device and client traffic is TLS throughout. Data at rest sits in AWS managed services inside your account, under your account's encryption settings — which means the answer to "where is our data" is simply "your region, your account".

What remains yours​

  • AWS account hygiene — root access, IAM users, CloudTrail, who can deploy.
  • The admin temp password. A one-time password is generated at deploy and must be changed at first sign-in. Treat it as a secret until then; see Configuration.
  • Manufacturing custody of factory credentials, if you pre-flash them.
  • Turning off development conveniences before shipping — the serial console and permissive local-control security are on by default in examples. The pre-production checklist is the list.