Category
Designing, reviewing and migrating the cryptography, key management and certificate systems a product depends on.
Cryptography rarely fails because a primitive was broken. It fails because a key lived somewhere nobody intended, a certificate expired on a weekend, an algorithm choice was hard-coded across a dozen services, or nobody could say which systems used which construction. This category covers applied cryptographic architecture, key management, PKI and hardware security modules, cryptographic inventory and agility, and the readiness and migration work that the move to post-quantum standards now requires. The emphasis is on the surrounding engineering—where keys live, who can use them, how an algorithm is replaced, and what the product does when any of that changes.
A certificate that expires in production was not forgotten by an individual. It was issued by a process that did not include renewal, into a system that had no way to reload it.
Agility is not a property of the algorithms you chose. It is a property of how your code, your data formats and your protocols name them—and whether anything can change without a coordinated rewrite.
Every post-quantum migration plan begins with an inventory, and most inventories stall because the team looks for algorithms instead of looking for the places algorithms are decided.
The question that sequences a post-quantum programme is not which algorithm to adopt. It is which of your data, recorded by an adversary today, would still matter when it can be decrypted.
Choosing a well-regarded library settles very little. The decisions that determine whether cryptography protects anything are about where keys live, what a compromise reaches, and which threat you are actually addressing.
A plan that lists algorithms and a target year is a statement of intent. A plan that survives review names sequenced workstreams, dependency owners, interim states and the decisions that are already overdue.
Platform-managed encryption satisfies a procurement question and defends against one threat. Knowing which threat it covers—and which of your actual risks it leaves untouched—changes what you build next.
Most organisations can describe their intended key management and cannot answer the question for a specific key. The gap between the two is where incidents and failed audits come from.
Combining a classical and a post-quantum key exchange is now the default for TLS. Understanding why the combination is used—and what it adds to every handshake—makes the deployment decision straightforward.
Key exchange migration is largely a configuration change. Signature migration runs into certificate sizes, fixed-width image headers, verifiers you cannot update and archives that must stay verifiable for decades.
Bring one agent workflow and the decision in front of you. Gaurav Tiwari replies personally within 1 working day.