Why Strict "Zero Trust" Breaks Secret Management (And How We Built a Zero-Persistence Vault Instead)

Serge Zhuravel — Mon, 11 May 2026 20:13:43 +0000

This is a technical deep dive into the cryptography behind Ennote's enterprise architecture. You can read the original full-length post on our engineering blog.

When evaluating an enterprise secrets manager, the fundamental security question isn't just how data is encrypted, but where and for how long the plaintext keys exist.

Many platforms market themselves as strict "Zero Trust" (implying End-to-End Encryption where the server knows absolutely nothing). We don't make this claim. Why? Because mathematically strict E2EE fundamentally breaks enterprise secret management workflows.

If you use strict E2EE, there is no centralized authority. If Developer A creates a database password and the company later hires Developer B, the server cannot grant Developer B access. Developer A must manually come online, decrypt the payload locally, and re-encrypt it with Developer B's public key.

This destroys automated onboarding, makes central Role-Based Access Control (RBAC) impossible, and turns machine-to-machine Kubernetes syncing into a fragile nightmare.

We needed a different approach. We prioritized workable, highly governed enterprise security by guaranteeing Zero Persistence.

Here is the cryptographic stack we built to achieve it.

1. Hybrid Cryptography & Transient Envelope Encryption

To get the best of both worlds - centralized RBAC and absolute data security - we use Hybrid Cryptography.

We use the blazing speed of symmetric cryptography to encrypt the actual secrets, and the highly secure, identity-verified nature of asymmetric cryptography to protect and distribute the symmetric key itself.

Local Generation: The client generates a random 256-bit Data Encryption Key (DEK) locally in volatile memory (RAM).
Symmetric Payload Encryption: The payload is encrypted with this DEK using Client-Side AES-256-GCM.
Asymmetric Encapsulation: The DEK is then encapsulated using our Organization-level KMS Public Key.

At no point are plaintext DEKs written to disk, logs, databases, or persistent storage. They exist only in volatile memory for the duration of a cryptographic operation (measured in milliseconds).

2. The Root of Trust: Post-Quantum Kyber

Our architecture begins with absolute hardware security. The master seeds for our internal KMS are protected by Cloud HSMs (FIPS 140-2 Level 3 validation).

From this root, Ennote generates Post-Quantum asymmetric keys using CRYSTALS-Kyber (Kyber-1024), a NIST Post-Quantum standard that protects against "harvest-now-decrypt-later" attacks. Crucially, these Kyber keys are established at the Organization level, not the individual resource level, allowing us to enforce centralized RBAC.

3. Identity Verification: Why We Dropped RSA for X25519

To securely transmit secrets to your developers or our Kubernetes Smart Agent, we have to mathematically verify identity.

We could have used legacy RSA, but RSA requires massive 2048-bit or 4096-bit keys that are computationally expensive to generate on the fly. Instead, every client generates an ephemeral Curve25519 (ECC X25519) key pair for Elliptic-Curve Diffie-Hellman (ECDH) key agreement.

X25519 delivers equivalent or greater security with a fraction of the key size (256 bits). Because they are incredibly fast to generate and require minimal bandwidth, they allow our Kubernetes Agent to maintain an outbound-only gRPC stream for real-time, sub-1-second updates without exhausting cluster CPU.

4. Enterprise Sovereignty: BYOK & Confidential Computing

For teams that need an absolute "kill switch," we built a BYOK (Bring Your Own Key) integration with GCP and AWS KMS.

During an access request under BYOK, the DEK is briefly decapsulated inside a secure KMS enclave. To eliminate the risk of volatile memory extraction during this transient "re-wrapping" phase, our enclaves utilize Confidential Computing.

This hardware-based isolation encrypts the data while it is in-use within RAM, completely preventing memory dumps or hypervisor-level inspection by any party - including malicious actors, host OS admins, or even our cloud infrastructure providers.

The Result: Sub-Second K8s Sync

We engineered the heavy, centralized decryption bottlenecks out of the architecture. By combining Client-Side AES-256, Kyber-1024 encapsulation, ephemeral X25519 identity verification, and Confidential Computing, we achieved true Zero-Persistence.

This allows our lightweight Kubernetes Agent to sync secrets directly to Native K8s Secrets in under 1 second via an outbound-only gRPC stream - requiring zero code changes and zero unencrypted YAMLs.

Over to you! 👇

Building security tools always involves balancing usability, speed, and strict cryptography.

How is your team currently handling secret delivery in Kubernetes?
Are you still relying on polling loops, or have you moved to event-driven architectures?

Let’s chat in the comments! If you want to see this architecture in action, check out Ennote Security.