--- title: "Axiad Cloud" slug: "axiad-cloud" updated: 2026-02-26T12:17:19Z published: 2026-02-26T12:17:39Z canonical: "docs.axiad.com/axiad-cloud" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.axiad.com/llms.txt > Use this file to discover all available pages before exploring further. # Axiad Conductor ## What It Is Axiad Conductor is a **cloud-delivered orchestration platform** that manages the **lifecycle of high-assurance credentials** (PKI, FIDO2, smart cards, Derived PIV, mobile credentials, etc.) across users, devices, and applications. Instead of siloed credential management tools, Axiad Conductor provides a unified control plane for identity security. ### Core Capabilities #### Credential Orchestration Automates issuance, renewal, recovery, suspension, and revocation of digital credentials for both users and non-human identities. #### Multi-Technology Support - PKI credentials (certificates, smart cards, Derived PIV) - FIDO2 passkeys - Support for multiple IdPs (Microsoft Entra, Okta, Ping, ForgeRock, etc.) #### Secure Device Issuance with GlobalPlatform - Native support for **GlobalPlatform standards** to securely initialize, personalize, and manage cryptographic devices (smart cards, tokens) - Ensures consistent, tamper-resistant provisioning aligned with industry security baselines #### Auditing & SIEM Integration - **All credential and device operations are fully audited** (issuance, recovery, suspension, revocation, lifecycle changes) - Audit logs can be **optionally exported to a SIEM** via syslog for centralized monitoring, compliance, and threat detection #### Self-Service & Recovery - Users can recover credentials securely without IT helpdesk intervention #### Compliance & Security - Phishing-resistant MFA aligned with **NIST SP 800-63**, **EO 14028**, **CMMC**, **CJIS**, and **FedRAMP** #### Deployment Flexibility - SaaS (FedRAMP-authorized) or air-gapped for regulated/classified environments - Integrates with CAs (EJBCA, IdenTrust, WidePoint-ORC), IAM systems, and device ecosystems ### Device Usage: What Users Can Do After Issuance Once credentials are provisioned to secure devices, **users can immediately leverage them for high-assurance access and security operations**, including: #### Certificate-based Authentication (CBA) - Log into Windows, macOS, or Linux systems with smart card/PIV authentication - Access VPNs, VDI sessions, and secure portals requiring certificate login - Authenticate to enterprise and federal apps that mandate X.509 or PIV credentials #### FIDO2 / Passkey Authentication - Phishing-resistant login to modern SaaS and cloud apps (e.g., Microsoft 365, Salesforce, ServiceNow) - FIDO2-based passwordless access across browsers and platforms - Hybrid deployments combining PKI and FIDO2, depending on policy #### Advanced Use Cases - Digital signature for documents, code, or transactions - Secure email encryption and signing (S/MIME) - Authentication for non-human identities (servers, IoT, DevOps pipelines) ### Why It Matters - **Unified credential lifecycle** across PKI, FIDO2, and device issuance - **Audit-ready by design:** complete traceability of all credential and device events, with SIEM export for proactive monitoring - **Enhanced security:** GlobalPlatform provisioning guarantees device integrity - **User empowerment:** once issued, devices provide secure access to apps, systems, and services via CBA or FIDO2 - **Operational efficiency:** automation reduces manual processes and dependency on specialists - **Compliance:** supports government and industry mandates ### Differentiators - **GlobalPlatform support** for secure device issuance - **Comprehensive auditing**, with optional SIEM/syslog integration - **Credential-centric orchestration:** not only issuing credentials, but enabling secure usage in CBA and FIDO2 contexts - **Vendor-agnostic** across IdPs, CAs, and devices - **Air-gap & SaaS parity** for both classified and enterprise environments - **Automation-first** vs. manual credential/device management ## Licensing Axiad Conductor is licensed as a subscription SaaS, with pricing and entitlement driven primarily by: - Human Identity (HI) licenses – counted per active user identity - Non‑Human Identity (NHI) licenses – counted per machine identity or active certificate, depending on the PKI generation - Optional connectors and add‑ons – licensed per connector or instance, or tier - Platform / bundle entitlements – base Conductor subscription + bundled capabilities ### Human Identity (HI) licensing #### What qualifies as an HI license A **user identity** is defined as an account in Conductor that is provisioned through **SCIM or Active Directory**. An **HI license** is consumed only when: - The user is **active**, and - At least **one Conductor-managed device** is assigned to that user. #### Key implications - Assigning **multiple devices** to the same user does **not** increase the number of licenses consumed. - If a user is **disabled**, no license is consumed - even if a device remains assigned. - Devices or credentials that are **not primarily managed by Conductor** (for example, TAP or WHFB discovered via Entra ID) do **not** consume a license. - If credentials on a device assigned to an active user are **expired**, the license is **still considered active**. - **Derived PIV credentials** each consume **one HI license**. - When a **temporary or interim credential** is revoked and **no devices remain**, the license is released and the active user count is reduced. ### Non‑Human Identity (NHI) licensing #### What qualifies as an NHI license An **NHI (Non‑Human Identity)** represents a **machine or workload identity**, not a person. In Axiad Conductor, NHI licensing applies to **certificates issued to non‑human entities** such as devices, servers, applications, or services managed through the Conductor PKI stack. Typical NHI identities include: - Servers (physical or virtual) - Network devices - Cloud workloads and services - Applications and service accounts - Managed endpoints using certificate‑based authentication NHI licenses are therefore **machine‑based**, not user‑based. #### How an NHI license is consumed An **NHI license is consumed per unique non‑human identity**, and counting is driven by **certificate issuance and lifecycle management**. Key characteristics: - NHI licenses are associated with **issued NHI certificates**, not with human users. - License consumption is generally determined by the **certificate subject (Subject DN)**, which represents a unique machine or workload identity. - If **multiple machines share the same identity**, they collectively consume **a single NHI license**. - **Short‑lived certificates** issued to the same identity consume **only one NHI license**. - A **single machine** may consume **multiple NHI licenses** if it is represented by multiple distinct identities, depending on how certificates are modeled. - **Revoked or expired certificates** are not counted toward NHI license usage. ### Connectors, instances, and add‑ons Axiad can further tailor the solution to meet your specific requirements. For advanced licensing scenarios involving **connectors, additional instances, or optional add‑ons**, your Axiad sales representative will work with you to determine the appropriate licensing structure.