Current support line
NexinID supports independent device identity, device-bound activation, bounded offline leases, lifecycle audit, credential lifecycle, OAuth device authorization when enabled and provisioned, DPoP-protected access, and live device evaluation for qualified profiles.
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.
DPoP protected resources
The qualified DPoP profile binds access to the device proof key and rejects missing, stale, replayed, nonce-invalid, or token-mismatched proofs.
Live device evaluation
Prove device possession for device-aware, policy-gated access, then re-check current lifecycle, credential, risk, and posture state at the protected resource. 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 device identity, independent of commercial application use. |
| 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 provider-neutral seam exists for future onboarding adapters, but NexinID does not currently claim FDO, BRSKI, or generic manufacturer zero-touch support. One narrowly bounded TPM 2.0 backend verification profile is Preview; a deployed physical-device attestation path and broader platform adapters are not claimed.
Device onboarding foundation
Secure factory→field onboarding has an archetype-neutral provider seam, not a supported public standards implementation. It is not tied to any device type, and any future standards adapter must qualify its own protocol, custody, and deployment profile.
- 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.
- Standards adapters: FDO, BRSKI, CMS voucher verification, EST enrollment, and generic manufacturer zero-touch onboarding remain Roadmap and are not current supported profiles.
- Modular attestation: one TPM 2.0 backend verification profile is Preview. Secure Enclave, Android Key, WebAuthn, and deployed physical-device qualification retain separate Roadmap or evidence gates.
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.
Qualified Device Trust profiles are available. Full IoT IAM is not claimed.
NexinID supports the bounded Device Trust controls documented here. Zero-touch IoT bootstrap, every hardware family, production external posture connectors, every SDK platform, and complete device-management or threat-protection products are not current claims.