Your Secrets Aren't Quantum-Safe.
Here's How to Fix That Today.

The Secret Nobody's Talking About

Open up your secrets manager right now. Whether it's HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager, look at how it protects secrets in transit. Every single one uses RSA or ECDH for key exchange. Every single one uses TLS 1.2/1.3 with classical key agreement. Every single one is vulnerable to a quantum computer running Shor's algorithm.

This isn't a theoretical concern for 2040. It's a data-collection problem happening right now. Nation-state adversaries are recording encrypted traffic today — including the TLS sessions between your application servers and your secrets manager. When a cryptographically relevant quantum computer (CRQC) arrives, they'll decrypt those recordings and extract every secret that was ever transmitted.

The secrets themselves might be short-lived — a database password rotated every 24 hours, an API key that expires in 90 days. But the access patterns encoded in those sessions are permanent intelligence: which services talk to which databases, what infrastructure exists, how your architecture is connected. Even rotated secrets reveal the topology. Learn more about harvest-now, decrypt-later protection →

Harvest Now, Decrypt Later Applies to Secrets

The harvest now, decrypt later (HNDL) attack model is usually discussed in the context of long-lived data: medical records, classified documents, financial transactions. But it applies with equal force to secrets management traffic. Here's why.

Every time your application fetches a secret from Vault, it establishes a TLS session. That session uses ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) for key agreement. The session key protects the secret in transit. An adversary who records the TLS handshake and encrypted payload can, with a future quantum computer, recover the session key and decrypt the secret.

Now consider the timeline. Most security teams assume CRQC is 10-15 years away (2035-2040). But secrets captured today may still be valuable then:

• Database root passwords — even if rotated, the old password reveals the database existed and its connection string.
• API keys to third-party services — Stripe, AWS, Twilio keys reveal your vendor relationships and billing patterns.
• Private signing keys — used for JWT issuance, code signing, or certificate authorities. These are catastrophic if exposed.
• Encryption master keys — the key-encryption-keys (KEKs) that protect everything else. One KEK compromises the entire vault.

The HNDL window for secrets is shorter than for medical records, but the blast radius is larger. A single compromised KEK or signing key cascades into every system that trusts it. This is why secrets management is arguably the highest-priority migration target for post-quantum cryptography.

What Makes a Secrets Manager Quantum-Safe?

A truly quantum-safe secrets manager requires four capabilities. Not one. Not two. All four, operating together.

1. Post-Quantum Key Exchange (Kyber / ML-KEM)

Every secret retrieval, every seal/unseal operation, every replication handshake must use Kyber (ML-KEM, FIPS 203) for key encapsulation. This replaces RSA and ECDH in the transit layer. Without PQ key exchange, every secret in transit is harvestable.

2. Post-Quantum Signatures (Dilithium / ML-DSA)

Audit logs, seal attestations, and access tokens must be signed with Dilithium (ML-DSA, FIPS 204). Classical ECDSA or RSA signatures on audit records can be forged by a quantum adversary, making your compliance trail worthless retroactively.

3. Encrypted Computation (FHE)

The gold standard: secrets that are never decrypted, even during use. Fully homomorphic encryption allows operations on encrypted secrets — signing, authentication, key derivation — without the plaintext ever existing in memory. This eliminates the entire class of memory-dump and side-channel attacks.

4. Crypto Agility

The ability to swap algorithms without re-architecting. If NIST deprecates ML-KEM-1024 in 2030, your secrets manager must rotate to the replacement without downtime, without re-encrypting every secret, and without breaking client integrations. This is not a feature — it's a survival requirement.

Comparison: Secrets Managers vs. Quantum Readiness

Every incumbent scores zero on the three capabilities that matter: PQ key exchange, PQ signatures, and encrypted computation. HashiCorp Vault and Azure Key Vault get partial credit for crypto agility because they support pluggable backends — but neither ships a PQ backend today, and bolting one on after the fact requires re-sealing the entire vault.

H33-Shield vs H33-VaultKey

H33 offers two products for quantum-safe secrets management, designed for different threat models. Choosing the right one depends on whether you need to protect secrets at rest or eliminate secret exposure entirely.

H33-Shield: Encrypt Credentials at Rest

H33-Shield wraps your existing secrets with post-quantum encryption. Each secret is encrypted with Kyber-1024 + AES-256-GCM (hybrid encapsulation) and authenticated with HMAC-SHA3-256. The Kyber ciphertext encapsulates the AES session key; the AES-GCM ciphertext protects the secret payload. The HMAC binds the ciphertext to its metadata (secret path, version, access policy) to prevent ciphertext substitution attacks.

Shield is a drop-in replacement for your existing secrets manager's encryption layer. Your application still fetches secrets and uses them in plaintext — the difference is that the transit and storage layers are now quantum-safe. This is the fastest migration path.

H33-VaultKey: FHE-Encrypted Secrets That Never Leave the Vault

VaultKey is fundamentally different. Secrets are stored as FHE ciphertexts that are never decrypted — not at rest, not in transit, not during use. When your application needs to sign a request with an API key, VaultKey performs the signing operation on the encrypted key using fully homomorphic encryption. The plaintext key never exists anywhere.

This is the proxy execution model: your application sends the operation to the vault, and the vault executes it on encrypted data. The result (a signature, an HMAC, a derived key) is returned to your application. Even if an attacker gains root access to the vault server, they see only FHE ciphertexts — computationally indistinguishable from random noise without the FHE private key.

Most organizations start with H33-Shield for immediate quantum-safe compliance and migrate high-value signing keys to H33-VaultKey over time. The two products share the same API surface and can run side by side. Read more about quantum-resistant API security →

The Proxy Execution Model

VaultKey's proxy execution model is its defining feature. Traditional secrets managers follow a fetch-and-use pattern: the application requests a secret, receives it in plaintext, uses it, and (hopefully) zeroes the memory. This creates a window of exposure — the secret exists in application memory, is visible in core dumps, and can be extracted by side-channel attacks.

VaultKey inverts this. Instead of bringing the secret to the computation, it brings the computation to the secret:

Migration from HashiCorp Vault

Migrating from HashiCorp Vault to H33-Shield is a three-step process: export, re-encrypt, update references. No downtime required. The migration can run in parallel — both systems serve secrets simultaneously until cutover is complete.

Step 1: Export Secrets from Vault

# Export all secrets from a Vault KV v2 mount
# Requires VAULT_ADDR and VAULT_TOKEN environment variables

export VAULT_ADDR="https://vault.internal:8200"
export VAULT_TOKEN="hvs.your-token-here"

# List all secret paths
vault kv list -format=json secret/ | jq -r '.[]' > /tmp/vault-paths.txt

# Export each secret (encrypted output)
while IFS= read -r path; do
  vault kv get -format=json "secret/$path" > "/tmp/vault-export/$path.json"
done < /tmp/vault-paths.txt

echo "Exported $(wc -l < /tmp/vault-paths.txt) secrets"

Step 2: Re-Encrypt with H33-Shield (Kyber + AES-256-GCM)

# Re-encrypt each secret with H33-Shield
# Uses Kyber-1024 key encapsulation + AES-256-GCM

while IFS= read -r path; do
  # Extract the secret value from Vault export
  SECRET=$(jq -r '.data.data' "/tmp/vault-export/$path.json")

  # Encrypt with H33-Shield
  curl -s -X POST https://api.h33.ai/v1/shield/encrypt \
    -H "Authorization: Bearer $H33_API_KEY" \
    -H "Content-Type: application/json" \
    -d "{
      \"path\": \"$path\",
      \"data\": $SECRET,
      \"encryption\": \"kyber-1024-aes-256-gcm\",
      \"sign\": true
    }" > "/tmp/h33-import/$path.json"

  echo "Re-encrypted: $path"
done < /tmp/vault-paths.txt

# Verify import
curl -s https://api.h33.ai/v1/shield/secrets \
  -H "Authorization: Bearer $H33_API_KEY" | jq '.total_secrets'

Step 3: Update Application References

# Before (HashiCorp Vault):
curl -s -H "X-Vault-Token: $VAULT_TOKEN" \
  "$VAULT_ADDR/v1/secret/data/myapp/database" | jq -r '.data.data.password'

# After (H33-Shield):
curl -s -X POST https://api.h33.ai/v1/shield/decrypt \
  -H "Authorization: Bearer $H33_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"path": "myapp/database", "field": "password"}' | jq -r '.plaintext'

# The response includes Dilithium signature verification:
# {
#   "plaintext": "...",
#   "signature_verified": true,
#   "key_exchange": "kyber-1024",
#   "encryption": "aes-256-gcm",
#   "signature": "dilithium-5"
# }

CI/CD Integration

H33-Shield replaces the vault inject pattern in your CI/CD pipelines. Here are drop-in replacements for the three most common platforms.

GitHub Actions

name: Deploy
on: [push]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # Before (HashiCorp Vault):
      # - uses: hashicorp/vault-action@v2
      #   with:
      #     url: https://vault.internal:8200
      #     secrets: secret/data/prod/db password | DB_PASSWORD

      # After (H33-Shield):
      - name: Fetch secrets from H33-Shield
        run: |
          # Single curl call — Kyber-encrypted transit, Dilithium-signed response
          export DB_PASSWORD=$(curl -s -X POST https://api.h33.ai/v1/shield/decrypt \
            -H "Authorization: Bearer ${{ secrets.H33_API_KEY }}" \
            -H "Content-Type: application/json" \
            -d '{"path": "prod/db", "field": "password"}' | jq -r '.plaintext')
          echo "::add-mask::$DB_PASSWORD"
          echo "DB_PASSWORD=$DB_PASSWORD" >> $GITHUB_ENV

      - name: Deploy
        run: ./deploy.sh

GitLab CI

deploy:
  stage: deploy
  image: alpine:latest
  before_script:
    - apk add --no-cache curl jq
  script:
    # Fetch all secrets in one batch call
    - |
      SECRETS=$(curl -s -X POST https://api.h33.ai/v1/shield/batch-decrypt \
        -H "Authorization: Bearer $H33_API_KEY" \
        -H "Content-Type: application/json" \
        -d '{"paths": ["prod/db", "prod/redis", "prod/stripe"]}')
      export DB_PASSWORD=$(echo $SECRETS | jq -r '.secrets["prod/db"].password')
      export REDIS_URL=$(echo $SECRETS | jq -r '.secrets["prod/redis"].url')
      export STRIPE_KEY=$(echo $SECRETS | jq -r '.secrets["prod/stripe"].secret_key')
    - ./deploy.sh
  variables:
    H33_API_KEY: $H33_API_KEY  # stored in GitLab CI variables

Jenkins

pipeline {
    agent any
    environment {
        H33_API_KEY = credentials('h33-api-key')
    }
    stages {
        stage('Fetch Secrets') {
            steps {
                script {
                    // Fetch secrets with Kyber-encrypted transit
                    def response = sh(
                        script: """
                            curl -s -X POST https://api.h33.ai/v1/shield/decrypt \
                              -H "Authorization: Bearer ${H33_API_KEY}" \
                              -H "Content-Type: application/json" \
                              -d '{"path": "prod/db", "field": "password"}'
                        """,
                        returnStdout: true
                    )
                    env.DB_PASSWORD = readJSON(text: response).plaintext
                }
            }
        }
        stage('Deploy') {
            steps {
                sh './deploy.sh'
            }
        }
    }
}

CNSA 2.0 Compliance

The NSA's CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) mandates post-quantum algorithms for all new National Security Systems acquisitions starting January 1, 2027. If you sell to the U.S. federal government, the Department of Defense, or any CNSA-bound agency, your secrets manager must be post-quantum.

The timeline is not optional:

• 2027 — All new software acquisitions must use CNSA 2.0 algorithms (ML-KEM, ML-DSA, SLH-DSA).
• 2030 — All existing NSS software must be upgraded to CNSA 2.0.
• 2033 — All firmware and custom applications must be CNSA 2.0 compliant.
• 2035 — Full migration complete, including legacy systems.

Secrets management is explicitly covered. CNSA 2.0 requires that all key establishment use ML-KEM-1024 (Kyber) and all digital signatures use ML-DSA-87 (Dilithium-5) or SLH-DSA (SPHINCS+). A secrets manager using ECDHE for key exchange fails CNSA 2.0 compliance — even if the at-rest encryption is AES-256.

Beyond government, CNSA 2.0 compliance is becoming a competitive differentiator in healthcare (HIPAA), financial services, and critical infrastructure. Organizations that move early lock in compliance before the deadline rush. See the full migration plan →

Pricing

Both H33-Shield and H33-VaultKey are available on credit-based pricing. No subscriptions, no minimums, no lock-in. You pay for what you use.

Volume discounts apply above 100K operations/month. Enterprise plans include dedicated Kyber key pools, custom rotation policies, and SLA-backed latency guarantees. See full pricing for details.

The Bottom Line

Every major secrets manager on the market today protects your secrets with encryption that has a known expiration date. RSA and ECDH will be broken by quantum computers — the only question is when. Adversaries aren't waiting. They're harvesting your encrypted secrets traffic right now.

H33-Shield gives you quantum-safe secrets in a single API call. H33-VaultKey eliminates secret exposure entirely with FHE proxy execution. Both are CNSA 2.0 compliant, available today, and free to start.