Why Rotating Your Encryption Key Resets Every Credential in Your Tenant (On Purpose)

Every PAM vendor says "zero-knowledge" in their pitch deck. Most of them mean "we encrypt your data at rest." That's not zero-knowledge - that's just encryption. Real zero-knowledge means the vendor is mathematically incapable of reading your secrets, even under a subpoena, even if their own staff account is compromised, even if they wanted to. Building that for real, instead of just saying it, is what turned out to be the hard part of PAM-Pro's vault design - and it's the reason rotating your encryption key resets every managed credential in your tenant.

I want to walk through why that's true, because it's the kind of design decision that looks like a bug in a demo and looks obviously correct once you understand the threat model it's solving for.

Dual-Keying Isn't Optional If You Mean It

PAM-Pro's vaults are dual-keyed: a Microsoft platform key protects the physical storage volume, and a second, customer-owned Tenant Root Encryption Key wraps the actual secret payloads on top of that. Both the secret name and the secret value are independently encrypted with the customer's key before they ever leave the client boundary. That second layer is the entire point - it's what stops Microsoft's infrastructure key from being sufficient to read your data, and it's what stops a Huntoso engineer with production access from reading it either.

The customer generates and owns that root key. We store it wrapped as AES-256-GCM ciphertext in their dedicated Key Vault. We never see it in plaintext. That's not a policy promise - it's a structural fact of how the envelope encryption works. If you want a vendor to actually be unable to read your secrets rather than just promising not to, this is what that looks like implemented, not described.

The Tradeoff Nobody Wants to Ship

Here's the part that's uncomfortable: if the customer rotates that root key, every payload encrypted under the old key becomes mathematically unrecoverable. Not "hard to recover." Unrecoverable. There is no backdoor, no master key, no support ticket that gets it back, because the entire design goal was making sure nobody - including us - holds a key that can decrypt without the customer's key present. Rotating the key doesn't re-encrypt anything under the hood; it just orphans everything under the old one. The practical consequence is a mandatory password reset event across every managed device in that tenant.

I went back and forth on this more than almost anything else in the platform. The easy version of this feature quietly keeps a recovery path - an escrowed key, a break-glass procedure, something a support engineer can reach for at 2am when a customer panics about losing access. Every version of that path is also a version an attacker, a subpoena, or a rogue insider can reach for. You cannot build "we cannot read your data" and "we can help you recover if you lose the key" as the same system. I picked the first one, because the entire value proposition is that the guarantee is real.

Engineering Around the Consequence, Not the Cause

Once I'd committed to that tradeoff, the actual engineering work was making the blast radius survivable instead of catastrophic. Root key rotation is rare and deliberate - it's not something that happens by accident - but "rare" isn't the same as "safe to ignore," so the configuration stores that reference the current key are backed by Azure Blob Versioning with immutability locks, specifically to prevent an accidental payload-lock from a fat-fingered rotation. The failure mode I'm defending against isn't "attacker steals the key" - the encryption model already handles that. It's "administrator rotates the key on purpose, on a Tuesday, without fully internalizing that it's a tenant-wide reset event." Compliance minimum on the whole chain is FIPS 140-2 Level 1, non-negotiable, because a zero-knowledge claim that doesn't hold up to a compliance audit isn't a real claim. The full breakdown of the tri-layer protection model and the shared-responsibility boundary it creates is on the Technical Architecture page, if you want the diagram version of what I just described in prose.

Why I'm Telling You This Instead of Hiding It

A lot of vendors would bury this in a security whitepaper nobody reads. I'd rather put it in front of the people evaluating whether to trust us with privileged credentials, because I think the tradeoff itself is the credibility signal. A PAM platform that can always recover your secrets for you is a PAM platform that can always be compelled to hand them over, by us, by a court order, or by whoever gets access to whatever recovery path exists. Ours can't. That's the whole point, and it's worth the operational sharp edge it creates.