Device Authentication
A connected device authenticates to Nexigon Hub with three factors:
- A valid deployment token for the project.
- A device certificate via mTLS which has been marked as accepted.
- A correct device fingerprint.
Deployment tokens can be programmed into device images and are not considered secret as an attacker may extract them from devices or updates. They may be shared between devices and are merely a first line of defense against attackers.
Upon provisioning, a device will locally generate a private key and a self-signed certificate for the purpose of mutual TLS (mTLS). This private key together with the certificate is the primary means of authentication and is used to establish a trusted end-to-end connection between Nexigon Agent and Nexigon Hub. Keep the private key on its device. An attacker with the key can impersonate that device if they also satisfy the token and fingerprint checks.
In addition, each device is required to have a unique (per project) fingerprint. This fingerprint is used to track the identity of a device, even when certificates and deployment tokens change or are rotated over time. Only a part of the fingerprint is stored in Nexigon. The full fingerprint is used as an additional authentication factor. A typical fingerprint might be based on a serial number programmed into one-time-programmable memory of a device or some other hardware-specific ID. A fingerprint can also be derived from a per-device secret stored in one-time-programmable memory. When deriving a fingerprint from a per-device secret, use a cryptographic key derivation function so the script does not expose the underlying secret as its output.
Deployment Tokens
Deployment tokens allow devices to connect to a specific project. They have the following form:
deployment_rKg4phta76ec5JBMmZFF2ja1M5xbar9WUPgD2t7KiwYdQUakxzcrKdpNkDAUgfE4VLDeployment tokens can be generated through Nexigon’s UI at Project → Tokens → Deployment Tokens.
Deployment tokens come with flags that allow for fine-grained control over specific behaviors:
- Auto Accept: If enabled, the first certificate presented by a new device is accepted automatically.
Provisioning Tokens
A provisioning token is a short-lived, one-use pairing key for onboarding one device to a project. The Add Device dialog generates a token valid for five minutes and includes the Nexigon Hub domain in the copied value.
When an unpaired Nexigon Agent redeems the token with its fingerprint, the Nexigon Hub creates a device and issues a deployment token bound to that device. This deployment token automatically accepts the device’s first certificate and cannot enroll other devices. The provisioning token cannot be reused.
The agent saves the issued deployment token and Nexigon Hub URL for subsequent connections. Provisioning still requires the device certificate and fingerprint for normal authentication.
We recommend enrolling devices with a dedicated provisioning image, then using Nexigon to supply their production image and configuration. Disable provisioning mode in the production image and retain the device’s credentials and TLS identity across the switch. Follow the device provisioning guide for the full workflow.
Device Deletion and Re-enrollment
Deleting a device permanently invalidates its certificates for connecting to Nexigon Hub, but its device fingerprint can be reused. Certificates retained for devices in deleted projects are also rejected, even with a token for another project.
Re-enrollment requires a fresh TLS certificate and a valid reusable deployment token for an active project. The device’s fingerprint script can remain unchanged. Nexigon Agent generates a fresh certificate and key when both configured TLS files are absent. Re-enrollment creates a new Nexigon Hub device ID; it does not restore the deleted device’s properties or permissions.
The fresh certificate follows the normal enrollment policy: Auto Accept accepts it automatically; otherwise, it requires approval on the newly enrolled device. A token bound to the deleted device cannot enroll its replacement. The device requires provisioning again or a reusable deployment token.