Security

N-Hub is designed with security built in at every layer — authentication, authorization, data isolation, encryption, and operational security.

Authentication

Identity Provider

All user authentication flows through a dedicated identity provider via OpenID Connect (OIDC).

• Invitation-only access — no self-service signup; accounts are provisioned by administrators
• Federated identity — users sign in with their corporate credentials (Microsoft Entra ID, Google Workspace)
• Multi-factor authentication (MFA) — configurable per organization
• Time-bound access — user accounts can have validity start and end dates

API Authentication

The REST API supports multiple authentication methods:

Method	Use Case
Session authentication	Browser-based access (portal)
JWT (OAuth 2.0)	Machine-to-machine, service accounts
Personal Access Token (PAT)	Developer API access

All API endpoints require authentication. Unauthenticated requests receive 401 Unauthorized.

Authorization

Role-Based Access Control

Users are assigned roles that control what they can see and do:

Role	Access
Manager	Administrative access for assigned enterprise
Operator	Operational access (view data, manage devices)
Viewer	Read-only access to data and dashboards

Enterprise Isolation

All data queries are scoped by enterprise. A user assigned to Enterprise A cannot access data belonging to Enterprise B, even through the API. This isolation is enforced across all interfaces — portal, API, and MQTT.

Data isolation

Cross-tenant data access is not possible through any customer-facing interface. All queries are filtered by enterprise at the application layer, and MQTT subscriptions are scoped to the authenticated enterprise.

Encryption

In Transit

• All external connections use TLS 1.2+ — HTTP, API, and portal traffic is encrypted
• MQTT connections use mutual TLS (mTLS) with per-device X.509 certificates
• Internal service communication uses private encrypted channels
• Database connections use SSL/TLS

At Rest

• All stored data is encrypted using AES-256 at rest
• Encryption keys are managed by the platform — customers do not need to manage keys
• Secrets and credentials are stored in dedicated secrets management infrastructure, never in application code

Network Security

• All public access is over HTTPS only — HTTP requests are redirected to HTTPS
• The application runs in isolated network segments with no direct internet access to internal services
• Only designated entry points (API gateway, MQTT broker) are publicly accessible

MQTT Security

MQTT connections require TLS and support two authentication methods:

• X.509 client certificates (recommended) — each certificate is bound to a specific API key (service account). Certificates can be revoked immediately, blocking the client on next connection attempt. The private key is returned once at creation and never stored by the platform.
• Username/password — uses the API key's username and token, validated against the identity provider. Simpler setup for development and integrations that don't support client certificates.

Both methods scope data access to the API key's enterprise — a client can only subscribe to topics for their own organization.

See the MQTT Streaming guide for setup instructions.

Operational Security

• Audit logging — all authentication events and administrative actions are logged with actor, action, timestamp, and affected resources
• Distributed tracing — every request and message carries a trace ID for end-to-end investigation
• Data residency — deployments can be provisioned in specific geographic regions (AU, EU, US)