Workload identity
QHx PKI Server and the local PKI Agent provide the issuance path. A node first authenticates through its configured attestation method. The agent then identifies a requesting workload using supported selectors, such as its Kubernetes namespace, service account and process context. Registration rules determine which identity that workload is eligible to receive.
A proxy or identity-aware application obtains credentials and trust bundles through the SPIFFE Workload API. For a direct library integration, the application team takes responsibility for consuming updates, authenticating peers and applying authorization. A proxy handles those functions for its configured connections.
The resulting X.509-SVID is a short-lived certificate carrying a SPIFFE identity. A peer checks the certificate against trusted issuing material and verifies possession of the corresponding private key. The identity names what the authority registered; its assurance depends on the evidence and rules used at issuance.
Credentials rotate when the issuance path remains available. An extracted certificate and private key can still enable impersonation while accepted. Stopping the original process does not revoke those copies. Plan key protection and rotation and recovery together.
Node attestation
Where enabled, QHx Attestor checks TPM-backed evidence and Platform Configuration Register (PCR) policy before node identity is issued. Operators choose the trusted endorsement roots, accepted measurements and response to a platform change. Acceptance of that platform evidence does not itself grant service access or establish organizational authority to approve information release.
Measured boot can contribute evidence about platform state. It does not establish that every subsequent process is benign or that the host remains uncompromised. Workload identification still depends on the host supplying and protecting the relevant context.
TPM checks are a deployment choice. Without them, assurance depends on the configured node-attestation method and the authority behind its evidence. An evaluation should establish what each method proves, who can change its policy, and how legitimate firmware or operating-system updates affect issuance.
Federation
SPIFFE federation lets separate authorities recognize one another’s workload identities. A trust domain defines an issuing authority’s identity boundary. Its trust bundle provides the material needed to verify credentials; a bundle endpoint supports distribution and synchronization.
Operators explicitly configure the foreign domains they accept, how bundle endpoints are authenticated, and how updates and failures are handled. Each domain retains its own issuing authority.
Recognizing a credential establishes an authenticated identity. Access to a service or protected object still requires authorization policy. Bundle freshness, credential expiry and cached state also need a defined disconnected operating plan.
Cryptographic profiles
QHx provides post-quantum options for workload credentials and compatible proxy connections. ML-DSA is available for the issuing authority’s signature configuration; ML-KEM contributes to key establishment, including hybrid profiles that combine classical and post-quantum mechanisms in the compatible TLS runtime. Signing a credential and negotiating a connection’s keys are separate operations.
In the current namespace model, QHxPolicy selects a QHx authority. The authority determines issuance configuration; the namespace binding is not itself a transport algorithm selector. Inspect the actual certificate and negotiated connection profile for the deployed version. Both proxies, their cryptographic libraries and the relevant trust chain must support the selected algorithms.
For the paired proxy path, QHx uses TLS 1.3. Evaluate the proxy-to-proxy handshake, credential rotation, reconnects and resource costs with the intended profile. The local plaintext application legs do not gain post-quantum protection from that handshake. Post-quantum key establishment protects exchanges using that profile; changing the configuration later does not retroactively protect traffic recorded under classical key establishment. The security model describes the surrounding assumptions.
The identity is one part of the security model.
QHx authenticates a registered software principal. The operator then decides which services accept that identity; the application remains responsible for its own resource and action authorization. Identity does not prove that a sensor’s observation is truthful, that an AI answer is correct or that an effector carried out an action.
The security model sets out adversaries, control dependencies and residual risks, including host compromise, credential theft and loss of reach-back.