Hold Your Own Key: Your Data in AWS and Azure, Your Keys in Europe
Most European companies already encrypt their data in AWS or Azure. Encryption at rest is switched on, the box is ticked, the auditor moves on.
But ask one more question: who holds the key? In the default setup, the answer is the same company that holds the data. Your files sit in the cloud provider's storage, and the keys that protect them sit in the cloud provider's key management service. Both are run by a US company.
That matters because of the US CLOUD Act, which allows US authorities to demand data from US providers wherever it is stored, including in an EU region. If the provider holds both the data and the key, encryption protects you from many things, but not from the provider itself, and not from whoever can compel the provider.
There is a model that changes this: Hold Your Own Key (HYOK). Starting with QuantumAPI 0.25.0, you can try it with a key that stays in Europe.
Hold Your Own Key: the cloud asks, you decide
AWS and Microsoft both publish a way to keep the key outside their own infrastructure.
AWS KMS External Key Store (XKS) lets you create KMS keys whose key material lives in an external key manager. Azure Key Vault Managed HSM External Key Management (EKM) does the same for the Azure services that support customer-managed keys.
The idea is simple. Your data stays where it is: in S3, EBS, Azure Storage or Azure SQL. But every time the cloud needs to encrypt or decrypt a data key (on AWS), or wrap or unwrap one (on Azure), it has to call your key manager and ask. The key itself never enters the cloud provider.
That gives you something default cloud encryption cannot: a switch outside the cloud. If you cut off access, the cloud can no longer unlock its data keys, and your data in that cloud becomes unreadable. Not deleted, not moved. Locked, until you decide otherwise.
What QuantumAPI adds
QuantumAPI implements the public AWS XKS and Azure EKM proxy specifications. You create an external key in QuantumAPI, connect your AWS key store or your Managed HSM to it, and from then on AWS or Azure asks QuantumAPI every time it needs that key. This is what you get on our side of the line:
- A key held in the EU. The key material is generated and kept by QuantumAPI, a European company, on EU infrastructure. AWS and Microsoft never receive it.
- Keys born from quantum randomness. External keys are generated from quantum entropy supplied by a QRNG service (currently the ANU QRNG of the Australian National University). If the quantum source is unavailable, a standard cryptographic generator (CSPRNG) takes over. Either way, the source actually used is recorded on each key, so a fallback is never hidden.
- Post-quantum protection at rest. Your key is stored encrypted under a key chain protected by ML-KEM-768 (FIPS 203), the NIST post-quantum standard.
- Every call audited. Each operation appears in your Key activity log: who asked (the IAM principal on AWS, the Managed HSM pool on Azure), through which service, the outcome and the latency.
- A kill switch. Disable a key or disconnect a key store in the portal, and QuantumAPI starts refusing that cloud's requests straight away.
- Usage-based pricing. Each successful cloud key operation counts as one API call against your plan. External keys and key stores are free and unlimited, like every other key in QuantumAPI.
On AWS there is a bonus. KMS uses double encryption: it encrypts first inside AWS, then with your external key. Neither AWS nor QuantumAPI can decrypt your data alone. Azure's protocol works differently (QuantumAPI wraps the data key directly), so we do not make that claim for Azure.
What it does not do (and we would rather say it first)
Post-quantum security is our whole brand, so it would be tempting to call this "post-quantum AWS". It is not, and we will not sell it that way.
The cloud protocols are classical. The traffic between AWS or Azure and our proxy uses what the cloud providers define: TLS, AES-256 and, on Azure, RSA-based client certificates. None of them negotiates ML-KEM today. AES-256 itself holds up well against quantum computers; the classical key exchange inside TLS does not, and that part is controlled by the cloud provider's client, not by us. Your S3 bucket or Azure Storage account does not become quantum-safe because of this feature. What is post-quantum is how we store your key.
It is not an HSM. Version 1 is a software key manager without FIPS 140-3 certification. If your policy requires a certified HSM, this is not the product for you yet.
The kill switch stops new requests, not cached keys. Some cloud services keep data keys in memory for a while (S3 Bucket Keys, attached disks, Azure Storage). Those keep working until the service asks again. Revocation reaches everything within that cache lifetime, not in the same second.
It is a preview. If the cloud cannot reach QuantumAPI, it cannot use your key, and the data behind it is unavailable. That is the whole point of HYOK, and also why we ask you to start with test or non-critical workloads. We are not an AWS or Microsoft certified partner, and Google Cloud is not supported.
How it works
From the cloud's point of view, QuantumAPI is simply an external key manager. A typical request goes like this:
- An application reads a file from S3, or an Azure SQL database starts up. The cloud service needs its data key.
- AWS KMS or Azure Managed HSM sends a signed request to the QuantumAPI proxy: "decrypt this with key X" (AWS) or "unwrap this with key X" (Azure).
- QuantumAPI checks who is calling (the AWS signature or the Azure client certificate), that the key belongs to that connection, and that neither the key nor the connection has been switched off.
- If everything checks out, QuantumAPI performs the AES-256 operation with your key and returns the result. The call is written to your Key activity log and counted as one API call.
- If you have used the kill switch, QuantumAPI refuses, and the cloud cannot unlock the data key.
Watch: Your Azure keys, held in Europe
Duration: 2:39EnglishOpen the video page
Watch: Encrypt at rest with your own key, and erase it in one click
Duration: 2:32EnglishOpen the video page
Who it is for, and how to try it
External key stores are built for regulated European companies that run on AWS or Azure and have to show who controls access to their data. Think of DORA and its ICT third-party risk rules for financial entities, NIS2 for essential and important entities, or the GDPR debate on international transfers that followed Schrems II. HYOK does not make you compliant on its own, but it gives you a concrete, auditable answer to the question "can our cloud provider read our data without us?"
A hypothetical example: an EU insurer keeps policy documents in S3 in Frankfurt. Its risk team wants the keys out of the provider's hands and a record of every access. With an external key store, the bucket uses a KMS key backed by QuantumAPI. Every decryption shows up with the IAM role and the service that asked for it, and if the insurer ever needs to cut access, one action in QuantumAPI stops new decryptions.
Want full control? Run it in your own data centre. If the whole reason for HYOK is that nobody else controls your keys, the strongest setup is not our SaaS. It is QuantumAPI installed on-premises, in your own data centre. The key manager, its database, the random-number path (quantum source or its fallback), the audit log and the kill switch then sit under your own control, and no third party, including us, is in the path. External key store support is coming to the on-premises edition; it is not there yet. The SaaS preview is the quickest way to try the idea today. On-premises keeps the same usage model: priced by API calls and storage, never per seat and never per key.
The trade-off, said plainly: if you run it yourself, you also own its availability. If your proxy is down, the cloud cannot decrypt your data. That cuts both ways, and it is the price of full control.
What we measured. On 2026-10-24 we tested the Azure path end to end against a real Azure Key Vault Managed HSM in North Europe. Azure's ekm-connection check identified QuantumAPI, wrap and unwrap round trips worked, clicking Disconnect in QuantumAPI made the next Azure unwrap fail immediately with "disconnected in QuantumAPI" (the Managed HSM does not cache unwraps), and Reconnect restored access. Inside QuantumAPI, each wrap or unwrap took about 2 to 14 ms once the key was cached, and about 100 ms on the first call, which loads the key. That is processing time on our side only: the network path to the cloud comes on top, and the total must stay within the cloud's 250 ms budget, which is why the service has to run close to the cloud regions it serves. The AWS XKS proxy is implemented but has not yet been tested live against AWS; we will publish those results when we have them.
External key stores are available as a preview in QuantumAPI 0.25.0. The step-by-step setup for AWS and Azure is on docs.quantumapi.eu. If you want to run a pilot or talk through your scenario, get in touch: we would rather hear your requirements now, while the feature is still taking shape.