payment HSM modernisation
Payment system key architecture: removing keys-at-rest from the chain
Payment cryptography is one of the oldest and best-engineered key-management domains: zone master keys, zone PIN keys, derivation hierarchies, and certified payment HSMs are all decades-mature. They are also, structurally, a very large estate of stored, long-lived keys, exactly the kind of estate that grows in value as a target and gets harder to retire as it ages. Zero-persistence reconstruction adds per-operation key derivation without disturbing the HSM substrate underneath.
By Sue Pontius, Chief Executive Officer, Lokblok · Published 22 April 2026
How payment key estates accumulate risk
Issuer and acquirer environments rely on a key hierarchy: master keys (LMK/ZMK), zone keys (ZPK/ZAK), working keys for PIN translation, MAC, and derivation. Each layer is a long-lived, certified-HSM-protected secret. The certifications (PCI HSM, FIPS 140-3) are real and necessary; they describe how the keys are protected, not whether the keys need to exist.
The estate grows monotonically. Every new acquirer relationship adds zone keys; every key rotation creates an overlap window with both old and new keys present; every legacy scheme adds derivation keys that cannot be retired without coordinated migration. The net effect is an ever-larger set of long-lived secrets concentrated in HSM clusters.
Modernisation programs (PCI HSM v3, post-quantum readiness, cloud HSM migration) all run into the same wall: the keys outlive the projects that try to refactor them.
Per-operation derivation on top of the certified substrate
Zero-persistence reconstruction does not replace payment HSMs, it runs on top of them. The certified secure element remains the hardware root; the runtime layer derives the working key inside the element only at the instant of use, performs the PIN translation or MAC, and destroys the working key before returning. The persistent inventory shrinks to the public Regen Token material; the certified hardware still bounds the cryptographic operation.
For PCI scope and certification, the substrate is unchanged. For risk and modernisation, the long-lived working-key estate disappears, taking with it the multi-year migration burden and the HNDL exposure of the symmetric working keys.
Side by side
| Dimension | Conventional approach | Zero-persistence reconstruction |
|---|---|---|
| Working keys at rest | Held in HSM clusters across the estate | Derived on demand; nothing persists |
| Key rotation | Coordinated across acquirers and issuers | Per-operation derivation makes rotation a runtime parameter |
| PCI HSM substrate | Required and used | Required and used (unchanged) |
| Quantum migration of working keys | Estate-wide rotation project | Runtime algorithm swap |
| Audit | Per-key inventory | Per-operation cryptographic chain |
What this looks like in practice
- An acquirer with hundreds of zone-key pairs stops maintaining the bulk of the working-key inventory by deriving zone working keys per transaction inside the existing HSM fleet.
- An issuer modernising its card platform treats the new BIN as a clean greenfield, no working keys to provision, no rotation calendar, and migrates legacy BINs over time.
- A processor preparing for PCI HSM v3 + PQ readiness addresses both with one architectural move: per-operation derivation removes the long-lived estate that v3 and PQ migration would otherwise have to refactor.
Related Lokblok material
- the payments solution overview
- Phantom Secrets™ as a runtime layer for any HSM substrate
- the underlying threshold-reconstruction architecture
About the author
Sue Pontius
Chief Executive Officer, Lokblok
Sue Pontius is CEO of Lokblok, where she leads the company's work on zero-persistence cryptography for digital assets, identity, and high-assurance custody.
View LinkedIn profile →FAQ
- Does this break PCI HSM certification?
- No. PCI HSM certifies the secure element and its operational profile. Zero-persistence reconstruction runs cryptographic operations inside the certified element exactly as the certification expects. The change is in what persists between operations, not in how the operation itself is performed.
- What about latency at acquirer line rates?
- Per-operation derivation adds the threshold reconstruction step inside the secure element. For modern HSMs and well-placed recovery agents this is sub-millisecond for the cryptographic step plus the network round-trip to the quorum; in many deployments the quorum is co-located with the issuer or acquirer and the added latency is negligible relative to the message envelope.
- How does this interact with existing key-block standards (TR-31, ASC X9.143)?
- Key blocks are an interchange format for keys that are exchanged between parties. Zero-persistence reconstruction reduces the population of keys that need to be exchanged in the first place; the working keys are derived locally on demand. Where key blocks remain necessary (e.g. for legacy partner integration), they can be produced on demand from the same primitive.
- Can this run alongside an existing payment HSM estate during migration?
- Yes, and that is the common adoption shape. The runtime layer is introduced for new BINs, new acquirer integrations, or specific high-value working-key categories first; the existing HSM estate continues to serve traffic during the migration period and ramps down as workloads move over.