Quantum Origin incorporates multiple security layers to secure the distributions of cryptographic keys. This document provides an overview of the onboarding process. Please contact your account representative or email Quantinuum’s Quantum Origin team for any onboarding questions or to start the process at origin-support@quantinuum.com.

The Quantum Origin API is only available to requests from designated IP ranges. During the onboarding process we may request confirmation of your IP range.

The Quantum Origin platform supports two ways to onboard a user. First one is certificate based enrolment and a second method where a user can self-onboard.

Certificate based enrolment

The Quantum Origin platform utilizes mutual TLS authentication, where both the server and client are issued with X.509 certificates. A user certificate must be provided for onboarding.

After your client certificate has been enrolled, a post-quantum AES-256 key - the shared secret - is generated using verifiable quantum randomness. This is transmitted to you using an out-of-band channel. The shared secret is unique to each client certificate and forms the root of trust. All keys generated using the API detailed in this guide are encrypted using the unique AES-256 shared secret. It is the organization’s shared responsibility to ensure that the shared secret is secured at all times.

First time users

  • An ongoing Quantum Origin platform agreement.

A new customer must provide the Quantum Origin support team with their company name or identifier. This is then enrolled into the appropriate system (UK or US) as per your use case. The customer should be aware that export licenses may be required if the cryptographic keys are to be exported to certain jurisdictions and/or for certain end uses. Please refer to the platform access agreement for additional details.

You will be given a unique customer number. You can then use this to register your IP and certificates.

Adding client certificates

  • The client certificate.

To enroll a client certificate, you must provide the client certificate to us.

We will then perform client enrollment. This will generate the shared secret which will be transmitted out-of-band (and in multiple XOR parts as required) to you for the local decryption of our cryptographic keys. If you provide a secure public key, EC521 is recommended, we can transmit the shared secret to you under encryption. This is recommended for all production use cases.

Once this is complete, you can request keys using our API, and decrypt them with your shared secret.

If you lose your shared secret, we cannot recover it. We must delete or disable your client certificate and then re-enroll you. Please follow the process as above.

If the certificate is time-limited, you must contact us prior to expiry and provide a new certificate for re-enrolment. Our systems reject invalid certificates.

User initiated enrolment

User initiated enrollment is a two stage process. The first stage involves, customer’s to get in touch with their representatives and an out-of-band registration takes place. Second stage is called self-onboarding. The credentials provided to the customer at the end of first stage is used in second stage during onboarding process.

Quantum Origin team will register the new customer into one of our cluster backends, in a previously agreed region/zone. As a result of this registration the following identifiers will be handed over back to customer.

The Quantum Origin onboarding binary is required for this onboarding method.




An identifier generated after registration


API key that will be used for onboarding and keygen


A secret that will be used once during onboarding

The qo-api-key and onboarding-secret will be consumed by cli tool during onboarding. Alternatively onboarding can be done using curl requests using the qo-subscription-id

To onboard a new user and then to request keys from our API, customers can use two binaries qo-onboard and qo-keygen. These binaries will be provided by Quantum Origin Team.

./qo-onboard onboard -a <qo-api-key> -s <onboarding-secret> -u <url for cluster>

The url for cluster in above command will be the cluster url, identifying the zone/region of the user. The user can be onboarded only on the pre-registered cluster. This is accomplished when the onboarding-secret is created.

A successful execution of the above command will produce something similar to

{"shared_secret":"ea1db50a1...d1225b19c0e", "client_id":"7d76354c...e21a93b5e44"}

The client_id will be used to make keygen requests and the shared_secret will be used to decrypt the keygen response.

To make a key request from our API using the freshly onboarded-user

export QO_URL=<url for the cluster that the user is onboarded>
export QO_NONCE=<random nonce value for each query>
export QO_SECRET=<shared secret obtained from successful onboarding>

./qo-keygen keygen -a <qo-api-key> -C <client_id> -t EC -p "{\"curve\":\"SecP521r1\"}" -K hex -O pem