# HashiCorp Vault: PQC Roadmap and Plugins **Source**: https://quantumsequrity.com/blog/hashicorp-vault-pqc **Category**: Implementations --- [← Back to Blog](../../blog.html) Implementations # HashiCorp Vault: PQC Roadmap and Plugins 12 min read HashiCorp Vault sits at the center of secrets management for thousands of enterprises. It stores API keys, database credentials, certificates, encryption keys, and tokens. When a team encrypts a payload with Vault's transit secrets engine, that ciphertext is protected by the algorithms Vault chooses. Today those algorithms include AES-256-GCM, RSA, and various elliptic curves. Tomorrow, when a cryptographically relevant quantum computer becomes practical, the public key parts of that stack will need replacement. This post walks through where Vault stands on post-quantum cryptography, what its plugin architecture allows operators to do today, and how teams should think about migration planning. The information here reflects vendor primary sources from HashiCorp and the broader open-source ecosystem. ## Why Vault Operators Should Care About PQC Vault is the trust anchor for many production systems. A typical deployment holds: - Root certificates for internal PKI - Database master credentials - Cloud provider IAM keys - TLS private keys for service mesh - Encryption keys used by application code via the transit engine If an attacker harvests Vault traffic today and stores it, future quantum attacks against RSA or elliptic curve handshakes could expose every secret that flowed through that channel. This is the harvest now, decrypt later problem applied to a single high-value chokepoint. Read more in our explainer on [harvest now decrypt later](harvest-now-decrypt-later.md). The blast radius of a compromised Vault is usually catastrophic. PQC migration is therefore a question of when, not if, for serious operators. ## Vault's Cryptographic Surface Area Vault uses cryptography in several distinct places, each with its own migration considerations: 1. **TLS for client connections.** This is the channel between applications and the Vault API. It uses standard TLS, which is governed by the Go crypto library and any reverse proxies in front of Vault. 2. **Transit secrets engine.** This engine performs encryption, decryption, signing, and verification on behalf of clients without revealing the underlying keys. It supports AES-256-GCM, ChaCha20-Poly1305, RSA, ECDSA, and Ed25519. 3. **PKI secrets engine.** This engine acts as a certificate authority. It can issue X.509 certificates with RSA or ECDSA keys. 4. **Storage backend encryption.** Vault encrypts its own storage with a master key derived through Shamir secret sharing or unsealed via a cloud KMS. 5. **SSH secrets engine.** Vault can sign SSH certificates for client authentication. Each of these touches asymmetric crypto in ways that quantum computers would eventually threaten. AES-256-GCM and ChaCha20-Poly1305 remain safe at the symmetric layer per current NIST guidance, but everything that uses public keys needs a forward-looking plan. ## What HashiCorp Has Said Publicly HashiCorp tracks the NIST Post-Quantum Cryptography Standardization Process closely. Public communications and engineering blog posts indicate that the roadmap depends heavily on: - Final NIST FIPS standards for ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) - Upstream support in Go's standard library, since Vault is written in Go - Demand from large enterprise customers, who drive the prioritization of new transit engine key types The Go standard library added experimental ML-KEM-768 support in 2024 in an experimental package, with broader stable APIs expected to land as the algorithms mature. Vault's transit engine is well positioned to expose new key types once Go's crypto support stabilizes. ## The Transit Secrets Engine and PQC Key Types The transit engine is the most important migration target for most Vault users because it is the developer-facing encryption API. When applications need to encrypt user data, payment info, or PHI, they typically call transit rather than implementing crypto themselves. The transit engine already supports key versioning, which is essential for PQC migration. Key versioning lets operators rotate keys without breaking decryption of older ciphertext. A migration to ML-KEM hybrid would create a new key version under the same logical key name, with new ciphertext using the new version and old ciphertext still decryptable. For a deeper dive on ML-KEM and its parameter sets, see our [ML-KEM explained](ml-kem-explained.md) post. ## Plugin Architecture: What Operators Can Do Now Vault supports two kinds of plugins relevant to PQC: 1. **Secrets engine plugins.** These add new types of secret backends. An operator could in theory write a custom secrets engine that implements PQC primitives directly, perhaps wrapping a vetted Rust or C library through cgo. 2. **Auth method plugins.** These handle authentication, including signature verification. Writing a custom secrets engine that exposes ML-KEM key generation, encapsulation, and decapsulation is technically feasible. However, this approach has drawbacks for production use: - Custom plugins must be maintained as Vault upgrades - The plugin author is responsible for side-channel and constant-time properties - FIPS compliance becomes the plugin author's burden - Auditors will scrutinize custom crypto code more heavily than upstream-blessed code For most operators, waiting for HashiCorp to add native PQC key types is the lower-risk path. Building defense in depth at the application layer, using a tool like QNSQY for hybrid PQC encryption of files before they hit Vault, fills the gap during the transition. ## Hybrid Modes: The Pragmatic Bridge NIST and CISA both recommend hybrid post-quantum schemes during the migration period. A hybrid scheme combines a classical algorithm with a post-quantum algorithm so that breaking the construction requires breaking both. If ML-KEM is later found to have a flaw, the X25519 component still protects you. If quantum computers break X25519, the ML-KEM component still protects you. Read our [hybrid encryption](hybrid-encryption.md) explainer for a fuller treatment of the design rationale. Vault does not yet ship a native hybrid mode in the transit engine. Operators who want hybrid protection today must layer it themselves: - Encrypt the payload with QNSQY or a similar PQC tool first - Store the resulting ciphertext as a sealed secret in Vault - Use Vault's existing AES-256-GCM-based transit operations to wrap the QNSQY ciphertext for additional defense in depth This double-wrap approach trades a small amount of overhead for significantly stronger protection during the migration period. ## Migration Planning Checklist Operators planning a Vault PQC migration should map their cryptographic dependencies in four steps: 1. **Inventory all transit engine keys.** Use the Vault API to list every key, its type, and its usage pattern. Identify which keys protect long-lived secrets versus session-scoped data. 2. **Identify long-lived ciphertext.** Anything encrypted today that must remain confidential for more than five to ten years is at high risk from harvest now decrypt later attacks. 3. **Plan for key versioning, not key replacement.** Vault's transit engine supports rotation. Plan the migration so that new ciphertext uses PQC keys while old ciphertext can still be decrypted with classical keys. 4. **Test plugin compatibility.** Any custom plugins or third-party integrations that consume Vault outputs need to handle the larger ciphertext sizes that ML-KEM produces. For background on the NIST FIPS standards driving this work, our [NIST FIPS guide](nist-fips-guide.md) walks through the relevant publications. ## Performance Considerations ML-KEM-768 encapsulation produces a 1088-byte ciphertext. ML-KEM-1024 produces a 1568-byte ciphertext. Both are larger than the 32-byte X25519 shared secret that classical schemes produce. For Vault transit operations this is rarely a bottleneck because: - Network round trips dominate Vault latency, not crypto computation - Most transit calls already include token authentication overhead - Modern CPUs can perform tens of thousands of ML-KEM operations per second per core ML-DSA signatures are larger than ECDSA signatures. ML-DSA-65 signatures are around 3309 bytes. For PKI use cases that mint many certificates, this size increase affects storage and bandwidth, but not in ways that break workflows. ## Compliance and Audit Implications Many Vault deployments live inside compliance regimes that mandate FIPS 140 validated cryptographic modules. As of late 2025 and into 2026, NIST is rolling out FIPS 140-3 validation for modules that include ML-KEM and ML-DSA. Until those validations land for the specific modules a deployment uses, operators in regulated industries should: - Continue using FIPS 140-2 or 140-3 validated classical algorithms for compliance-mandated crypto - Layer PQC protection on top using non-validated implementations for defense against harvest now decrypt later - Plan for a full migration when validated PQC modules become available ## Real-World Deployment Patterns Operators running Vault in production today follow several patterns when planning for PQC. The most common is the dual-key pattern: maintain a classical key for backward compatibility with existing decryption needs, and add a PQC key for forward-looking encryption operations. The transit engine's key versioning makes this clean. New ciphertext gets created with the new key version. Old ciphertext continues to decrypt with the older key version. Another common pattern is the wrapping pattern. The application generates a fresh symmetric key per operation, encrypts the payload with that symmetric key using AES-256-GCM, then asks Vault to wrap the symmetric key. The wrapping operation is where PQC matters. If the wrapping key is migrated to ML-KEM hybrid construction, the entire stack becomes quantum-safe without changing the bulk encryption layer. This pattern is friendly to migration because the symmetric layer never changes. A third pattern is the audit-log pattern. For compliance purposes, operators often need to prove that specific data was encrypted with specific algorithms at specific times. The audit log records the key version used for every transit operation. As keys rotate from classical to PQC versions, the audit log captures the migration timeline automatically. Operators that integrate Vault with CI/CD pipelines have additional considerations. Build artifacts signed with Vault-managed keys need to remain verifiable for the entire support lifetime of the artifact. For software with multi-year support windows, the signing key choice matters more than for ephemeral operations. SLH-DSA may be preferred for long-lived signing because of its conservative cryptographic assumptions. ## Vault and the Broader Cryptographic Agility Story Cryptographic agility means designing systems so that algorithm choices are configuration parameters rather than baked-in assumptions. Vault's transit engine is reasonably agile: keys are typed, the type is queryable, and operations are routed through the type system. However, agility at the API layer does not automatically extend to the application layer that consumes Vault outputs. Application code that hardcodes assumptions about ciphertext sizes, signature lengths, or specific algorithm identifiers becomes a barrier to PQC migration. A pre-migration audit of every Vault-consuming application should look for: - Buffer allocations sized for specific algorithm output lengths - Hardcoded references to algorithm names in configuration - Assumptions about signature length in API contracts - Database column sizes that fit RSA or ECDSA but not ML-DSA Refactoring these assumptions before the migration starts avoids surprise bugs during the cutover. A well-designed application should ask Vault what algorithm a key is using and adapt accordingly. ## Operational Monitoring During Migration During a PQC migration, operators should add monitoring for several signals: - Transit engine performance: latency for encrypt, decrypt, sign, and verify operations broken down by key version - Error rates: any spike in errors during a key version rotation deserves immediate investigation - Storage growth: PQC keys and ciphertext are larger; storage usage should be tracked - Audit log volume: PQC operations may produce more verbose audit entries Vault's telemetry already covers most of these signals. Operators should ensure the monitoring captures per-key-version metrics, not just aggregate metrics, so the migration progress is visible. ## Frequently Asked Questions **Does Vault currently support any post-quantum algorithms in transit?** As of the latest stable release tracked by HashiCorp, the transit engine does not natively expose ML-KEM or ML-DSA key types. Roadmap signals suggest this will change once Go's standard library stabilizes its PQC support. **Can I use a custom plugin to add ML-KEM today?** Yes, technically. Vault's plugin architecture supports custom secrets engines. The downside is ongoing maintenance burden and the absence of FIPS validation for custom code paths. **Is AES-256-GCM safe against quantum attacks?** Per current NIST guidance, AES-256 with appropriate modes remains secure against known quantum attacks at a reduced effective security level. Symmetric crypto is not the urgent migration target. Public key crypto is. **How do I protect Vault traffic during migration?** Use TLS 1.3 with strong cipher suites today. Once major TLS implementations support hybrid PQC handshakes, upgrade. In the interim, wrap sensitive payloads with PQC at the application layer using a tool like QNSQY before they enter the Vault TLS channel. **What about Vault Enterprise versus open source?** HashiCorp generally rolls major cryptographic features into both editions. Compliance-focused features like FIPS-validated builds typically arrive in the Enterprise edition first. ## Sources 1. NIST. "FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard." National Institute of Standards and Technology. 2024. 2. NIST. "FIPS 204: Module-Lattice-Based Digital Signature Standard." National Institute of Standards and Technology. 2024. 3. HashiCorp. "Vault Transit Secrets Engine Documentation." https://developer.hashicorp.com/vault/docs/secrets/transit 4. HashiCorp. "Vault Plugin System Architecture." https://developer.hashicorp.com/vault/docs/plugins 5. NIST. "Post-Quantum Cryptography Standardization." https://csrc.nist.gov/projects/post-quantum-cryptography 6. IETF. "Hybrid Public Key Encryption (HPKE)." RFC 9180. ## Related Articles - [What Is Post-Quantum Cryptography](what-is-post-quantum-cryptography.md) - [ML-KEM Explained](ml-kem-explained.md) - [Hybrid Encryption](hybrid-encryption.md) - [Harvest Now Decrypt Later](harvest-now-decrypt-later.md) - [NIST FIPS Guide](nist-fips-guide.md) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)