Current support line
NexinID supports device-bound activation, offline leases, lifecycle audit, certificate credential lifecycle, OAuth device authorization when enabled and provisioned, and a backend mTLS contract for certificate-bound machine and gateway clients.
Installed-device activation
Seat-bound activation, pending approval, heartbeat, offline lease renewal, transfer, revoke, and deterministic audit diagnostics.
OAuth device flow
Browserless or input-constrained devices can use OAuth Device Authorization when the endpoint is enabled and a device-flow client is provisioned.
mTLS gateways
Certificate-bound machine and gateway clients can use mTLS token endpoints when the trusted proxy or direct termination path is safe.
Device-aware tokens & CAE
Prove device possession at /connect/token for device-aware, policy-gated access tokens, then re-check live device trust at resource access. See the device-token integration guide.
What the device trust model persists
The current device trust layer separates device identity, installation identity, license activation, and offline lease state. New device risk starts as Unknown, then operator or policy decisions can transition state with audit-visible reasons.
| Record | Role |
|---|---|
| Device | Organization-scoped hardware identity. |
| Device installation | Application-specific installed instance. |
| License activation | Seat-bound permission for one installation. |
| Offline lease | Signed offline execution token with expiry and counter. |
| Device credential | Public key, JWK, X.509 thumbprint, or compatibility credential metadata. |
| Posture snapshot | Minimized compliance state used by policy. |
Certificate metadata without private material
Device credential APIs accept public key hash, normalized certificate thumbprint metadata, subject, issuer, serial number, validity windows, expiry, and expiry warning timestamps. They do not store private keys, certificate bodies, raw hardware identifiers, or raw attestation secrets.
Onboarding & attestation
A pluggable onboarding-provider seam accepts standards-based adapters; a BRSKI reference adapter (config-enabled preview) validates an onboarding voucher into a bootstrap claim. It is not a full FDO/BRSKI (RFC 8995) implementation. A modular attestation-adapter interface (TPM, Secure Enclave, Android Key, WebAuthn) folds optionally into the trust level; hardware-backed attestation adapters and automated risk transitions remain preview/roadmap, not GA. See the onboarding foundation below.
Device onboarding foundation
Secure factory→field onboarding is built as an archetype-neutral foundation — a pluggable provider seam, not a single device or protocol. It is not tied to any device type, and standards adapters are optional.
- Onboarding-provider seam: a method-keyed provider establishes device identity from a manufacturer/voucher artifact, then hands off to the existing activation + offline-lease lifecycle. Onboarding precedes device existence — it yields a bootstrap reference, and the device + credential are established later at activation.
- BRSKI reference adapter (preview): validates a BRSKI-style onboarding voucher and creates a bootstrap claim. Enabled by configuration; not a full RFC 8995 implementation — no CMS voucher-signature verification or EST enrollment.
- Modular attestation (optional): a pluggable attestation-adapter interface (TPM, Secure Enclave, Android Key, WebAuthn) folds into the computed trust level when present — an optional trust upgrade, never mandatory. Hardware-backed adapters are preview/roadmap.
A foundation, not a GA onboarding product.
This is the seam that lets a concrete device and standards-based onboarding plug in later. Full FDO/BRSKI onboarding and a specific device program are roadmap, not current GA claims.
Device trust is GA. Full IoT IAM is not claimed yet.
NexinID supports the device trust controls documented here, while zero-touch IoT bootstrap and hardware-backed attestation stay preview or roadmap scope.