Fundamentum — Pillar 1 & 2

Every device. Every API.
A verifiable identity.

Identity in a governed IoT system is not a username and password. It is a cryptographic credential anchored to a specific physical entity — with a defined scope of authority and a formal lifecycle that tracks the device from manufacture through decommission.

Discuss your governance requirements → ← Back to Fundamentum

What identity means in Fundamentum

Identity in Fundamentum is not authentication — it is authorization context. A device that authenticates with a valid credential has proven it possesses the credential. A device that operates within Fundamentum's identity model has proven it is the specific physical entity it claims to be, operating within the role and scope that entity has been granted, in a lifecycle state that permits the requested action.

Device Identity

Cryptographic credential provisioned at manufacture. Hardware-anchored where a secure element is present. Tied to the specific physical device — not transferable. Includes scope of authority: what commands this device class can receive.

User Identity

Role-based identity for human operators. An engineer issuing a remote command is verified as an identity with the specific role required to issue that class of command to that category of device in its current lifecycle state.

API Identity (First-Class)

APIs are actors in the governance model — not implicitly trusted once they clear authentication. A CI/CD pipeline with a valid API key cannot push firmware to any device. It can push firmware to the device categories its identity is authorized to update, when those devices are in the permitted lifecycle state.

Service Identity

Automated processes — monitoring systems, analytics pipelines, deployment automation — each carry a distinct service identity with a scoped credential. "The system did it" is not an acceptable audit trail entry in Fundamentum.

The device lifecycle state machine

A device in a governed fleet is never simply "online" or "offline." It occupies a defined lifecycle state, and the actions available to it and to operators are determined entirely by that state.

Provisioned
Identity assigned, not yet deployed
Activated
Normal operation, full command set
Maintenance
Extended diagnostic commands permitted
Pending Update
Second OTA blocked until first confirmed
Decommissioned
All commands refused; credential revoked

State transitions are themselves governed actions. Moving a device from Activated to Maintenance requires an authorized identity with the Maintenance role. A decommissioned device cannot be reactivated without an explicit reactivation authorization from an identity with that specific privilege. State machines are not editable by application code — they are infrastructure-layer primitives.

Credential lifecycle management

  • Provisioning at manufacture: Device credentials are provisioned during the manufacturing process and associated with the device's hardware identity (serial number, secure element key).
  • Rotation: Credentials can be rotated remotely through a governed command — the outgoing credential authorizes the rotation, creating a verifiable chain of custody.
  • Revocation: Compromised credentials are revoked immediately. All subsequent actions by the revoked identity are refused and logged. The blast radius of a compromised credential is bounded by the scope it held.
  • Shelf device onboarding: Devices provisioned months before deployment (sitting in a warehouse) are activated through a formal onboarding workflow — not by simply powering on.
  • Ownership transfer: Devices transferred between customers or deployments follow a formal transfer workflow with full audit trail. A device's history is immutable — only its current owner changes.