Hi @InfQNAP ,
Thank you for taking the time to share your KMIP deployment.
I’d like to offer some context on QNAP’s design intent here, because the “client but no server” split is deliberate rather than an oversight.
When an organization reaches the point of needing KMIP, it usually means encryption keys across the entire environment need centralized governance — not just the NAS. In a typical enterprise that includes virtualization platforms (VMware vSphere/vSAN VM and datastore encryption, Hyper-V, Nutanix), self-encrypting storage arrays, database TDE (Oracle, SQL Server), backup systems (Veeam, Commvault), and SED/tape libraries — often across multiple sites. Because the KMS becomes the single root of trust for all of that, it carries a much higher bar than the devices it serves: an HSM-backed key store, strict separation of duties, a full auditable key lifecycle, and independent cryptographic-module validation.
For that reason, our position is that a storage appliance should sit on the client side of KMIP — as a managed endpoint whose keys are escrowed to a trusted, audit-recognized authority — rather than acting as the KMS itself. Having the same box both store production data and serve as the organization’s key authority works against the separation-of-duties principle that most security audits are specifically looking for.
In practice, that’s why we’d suggest the following, in order:
For audit-grade deployments: pair QNAP’s KMIP client with an established, certified KMS — for example Thales CipherTrust Manager, Entrust KeyControl, IBM Guardium Key Lifecycle Manager, or HashiCorp Vault Enterprise (KMIP secrets engine). These are purpose-built to satisfy the cryptographic-module and key-lifecycle requirements auditors expect, and QNAP’s client is designed to interoperate with standard KMIP servers like these.
Where budget is the primary constraint: a self-hosted KMIP server in a container on a dedicated, controlled, auditable host is a reasonable path. Options that implement KMIP include HashiCorp Vault / OpenBao with the KMIP engine, Cosmian KMS, or PyKMIP for non-production/testing. For audit purposes, what matters is less which box runs it and more that the host is hardened, access-controlled, and produces the audit trail your assessor requires.
One distinction worth making for anyone in this thread with a hard audit requirement, because these three things often get conflated:
Interoperability — the KMS connects and works over KMIP.
Algorithm validation (NIST CAVP) — a vendor’s AES/SHA/RSA implementations are verified as correct.
Cryptographic-module validation (NIST CMVP, FIPS 140-2/140-3) — the module itself, including its key management and security boundary, holds a validation certificate.
Auditors typically care about the third, and it’s the highest bar. A vendor having CAVP algorithm validation, or a module merely listed as “Implementation Under Test,” is not the same as holding an active CMVP module certificate that actually covers the key-management component you intend to rely on. Whatever KMS you choose, it’s worth verifying its exact status directly on the NIST CMVP validated-modules list and confirming the certificate’s scope with your assessor.
Thanks again for the suggestion and for the thorough report — we’ll take the demand for a lower-cost, audit-acceptable KMS path for QNAP-centric environments back for internal discussion. In the meantime, the certified-KMS or hardened-container routes above should keep your key authority on a footing that stands up to audit scrutiny.