For qualified profiles it includes reviewed publishers, immutable application revisions and environments, administrator consent, organization installation, explicit human assignment, runtime admission, configured provisioning and deprovisioning, logout, revocation, and removal. “Delivered” is not an OpenID conformance, certification, every-profile, or universal-production claim. See the application lifecycle guide.

The docs are curated from the implemented platform contract and publish public-safe summaries, API route families, and supported customer guidance.

A tenant is an isolated identity domain on the platform. Each tenant has its own organizations, members, clients, applications, governance rules, and audit trail.

OpenID Connect and OAuth 2.0, including authorization code with PKCE, client credentials for current machine-client scenarios, discovery metadata, and logout handling.

Developer starts at 3 organizations, 3 applications, 1,000 active identities, 10 OAuth clients, 1 environment, and 25 trusted devices. Launch increases to 10 organizations, 5 applications, 2,500 active identities, 25 OAuth clients, 2 environments, and 100 devices. Growth increases to 25 organizations, 15 applications, 10,000 active identities, 100 OAuth clients, 1 enterprise OIDC connection, 3 environments, and 500 devices. Business increases to 100 organizations, 50 applications, 50,000 active identities, 500 OAuth clients, 5 OIDC + SCIM connections, 6 environments, SIEM export, and 5,000 devices. Enterprise uses custom negotiated quotas.

Developer blocks overage and prompts an upgrade. Launch, Growth, and Business include PAYG meters for active identities, organizations, trusted devices, enterprise connections, environments, OAuth client packs, audit storage, and SIEM destinations. Paid self-serve plans start with a default 20% monthly spend cap and notifications at 50%, 80%, and 100%.

Roles, security groups, direct grants, and entitlement-backed seat assignments are part of the current tenant operating model. Commercial packaging is anchored to identity, application, environment, and support scale rather than charging per permission object or policy rule.

The public production posture is one deployable host and one relational database per deployed instance, with logical tenant isolation inside that instance. Per-tenant deployment isolation, region-pinning guarantees, and multi-region active-active commitments remain guided commercial review unless contracted.

The current platform targets PostgreSQL and SQL Server for deployed environments, with SQLite reserved for development and isolated testing scenarios.

Control-heavy buyers should treat dedicated deployment modes, customer-managed key commitments, documented region pinning, and public evidence-inventory workflows as guided commercial review or roadmap scope unless they are explicitly part of a written engagement.

Current positioning is limited to organization-scoped aggregate analytics for authentication activity, audit categories, and device-fleet posture. Counts below the published minimum cohort are intentionally suppressed, and raw telemetry exports or user-level risk scores are not exposed.

Device trust provides an independent device-identity and seat-bound application-use lifecycle with posture policy integrated into the identity layer. Qualified profiles cover protected credentials, explicit posture snapshots, approval before activation, DPoP-protected access, live device evaluation, and signed offline leases with bounded renewal and grace policies.

It is supported when the environment enables the device authorization endpoint and a device-flow client has been provisioned. The public docs do not publish a self-service device-client registration route.

No. NexinID supports qualified Device Trust profiles for activation, bounded offline leases, lifecycle audit, protected credentials, OAuth device authorization when enabled, DPoP-protected access, and live device evaluation. Generic FDO/BRSKI or manufacturer zero-touch onboarding, every hardware family, every SDK platform, complete device management, and threat-protection products are not current claims.

NexinID provides a tenant-admin setup path for enterprise OIDC connections, SCIM token rotation, and setup diagnostics today. Growth includes one enterprise OIDC connection, while SCIM lifecycle support starts with Business. Public setup guidance is centralized in the enterprise setup docs.

Current public guide entry points cover Okta, Microsoft Entra ID, Google Workspace, and generic OIDC or SAML providers. OIDC sign-in and SCIM lifecycle paths are the current supportable story.

Not yet. NexinID stores canonical SAML setup data and validates it through diagnostics, but host-side SAML assertion processing is still treated as a current limitation rather than a finished browser runtime.

Current tenant-admin flows include webhook subscription management, one-time secret rotation, delivery status history, and failed-delivery replay. Audit exports support CSV and NDJSON, with NDJSON documented for SIEM-friendly ingestion workflows.

No. The current sandbox panel builds request examples. Keep production tokens, private keys, raw hardware identifiers, voucher bodies, and attestation secrets out of browser-based tools.

Use the contact page for rollout, diligence, commercial onboarding, deployment, or provider-specific support questions.