HSM, cloud KMS or local PFX: choosing where signing keys live
22 April 2026 · 7 min read · Nextarp B.V.
A signature is only as trustworthy as the protection around its private key. Where that key lives - a file, a cloud KMS, or a hardware module - shapes both your security posture and your compliance story.
Local PFX/PKCS#12
A certificate and key in a password-protected file is the simplest option: easy to deploy, fully offline, good for air-gapped installs. The risk is that the key material exists on disk and in memory, so file handling, permissions and secret management matter enormously.
Cloud KMS
Services like Google Cloud KMS and Azure Key Vault hold the private key and perform the signing operation for you - the key never leaves the provider. You get access control, rotation, and audit logging for free, at the cost of a network dependency and per-operation charges.
Hardware security modules (HSM)
An HSM, accessed via PKCS#11, keeps keys in tamper-resistant hardware and is often mandatory for qualified signatures. It offers the strongest assurance and the most operational overhead.
Bring your own key
Whatever the backend, insist on BYOK: you generate and own the key, and the platform merely uses it. That keeps trust with you, not the software vendor.
A practical rule
Match the key store to the assurance level. Internal AdES? A well-managed KMS is plenty. Qualified signatures? Expect an HSM. Air-gapped? A carefully handled local key. DocsNG supports all three behind the same signing interface, so you can change your mind without changing your code.
Related articles
- Encryption and PDF permissions, done right · Security
- eIDAS explained: AdES, QES and QSeal for documents · Compliance
- AI-assisted template authoring in Microsoft Word · Product