Marin Ivezic
NIST released its first three post-quantum standards in August 2024: ML-KEM (formerly CRYSTALS-Kyber) for key establishment, ML-DSA (formerly CRYSTALS-Dilithium) and SLH-DSA (formerly SPHINCS+) for signatures. Within a year, job boards carried titles that barely existed before, including post-quantum cryptography engineer, crypto-agility lead, and cryptographic inventory analyst. Security leaders read that list and conclude they need to open four requisitions. Most don’t.
What a post-quantum cryptography (PQC) migration program needs is four capabilities. A capability is something the organization can do repeatedly, with a named owner and an output someone else can use. A role is one way to buy a capability, and for a mid-sized enterprise it is rarely the cheapest way. In a bank with 4,000 applications the four capabilities are four teams. In a 200-person software company they are two people and a consultant. The capabilities stay the same at both ends.
Discovery: knowing where cryptography lives
The output is a cryptographic inventory, kept current rather than produced once. Increasingly this takes the form of a cryptographic bill of materials (CBOM), which applies the idea of a software bill of materials to algorithms, key lengths, certificates, and their expiry dates.
National Security Memorandum 10, issued in May 2022, required agencies to inventory their cryptographic systems, and the Quantum Computing Cybersecurity Preparedness Act followed in December 2022. Both exposed the same finding across agency after agency: nobody could say where public-key cryptography was running. An inventory sounds like an administrative exercise until a program tries to skip it, at which point every later decision rests on an estimate.
Discovery also carries prioritization. Not every system moves first, and the ranking depends on data lifetime, exposure, and upgrade cost. Systems protecting data that stays sensitive for 15 years rank above systems protecting data that expires in 90 days, because encrypted traffic captured today can be stored and decrypted later once a capable machine exists. That is the harvest-now-decrypt-later (HNDL) problem, and it is the reason a migration deadline is set by the sensitivity horizon rather than by a qubit count.
The skills are investigative rather than mathematical: asset management, enough scripting to run scanners across repositories and network ranges, and the patience to interview system owners about embedded cryptography no tool will find. Discovery usually belongs in governance, risk, and compliance (GRC) or in security architecture, not in a cryptography team.
You are missing this capability if nobody can tell you, within a week, how many of your internet-facing services present RSA or ECDSA certificates, and which business owner is accountable for each.
Architecture: deciding the target state
The output is a written standard that says which algorithm is used for which purpose, whether hybrid deployment applies, and in what order systems move. Without it, each project team picks independently, and the organization acquires four incompatible answers before anyone notices.
Architecture also owns crypto-agility, which means the ability to change a cryptographic algorithm without changing the applications that use it. In practice that means configuration-driven algorithm selection, a central cryptographic service applications call rather than libraries each application links directly, and certificate handling that no longer assumes a fixed key size. Agility is an architectural property. It cannot be retrofitted by the engineer doing the migration.
This capability lives or dies on operational consequences. An ML-DSA-65 signature is roughly 50 times the size of an ECDSA P-256 signature, so certificate chains grow, handshake packets fragment, and constrained devices with fixed message buffers stop working. Someone has to hold both the algorithm choice and its downstream effect on the network, and that person is the architect.
You are missing this capability if two teams have piloted post-quantum key exchange using different libraries and neither pilot references a company standard.
Implementation: making the algorithms work
The output is working code and working infrastructure. Hybrid Transport Layer Security (TLS) negotiating successfully against real clients, updated cryptographic libraries in the build, hardware security module (HSM) firmware that supports the new algorithms, code-signing pipelines producing signatures the verifier accepts.
This is the capability closest to the traditional cryptography engineer, and it is the one most organizations assume they need first. They usually need it third. Implementation without discovery produces a well-engineered upgrade to a system that wasn’t the priority, and implementation without architecture produces a solution one team can maintain.
The skills combine applied cryptography with ordinary software engineering: familiarity with OpenSSL providers and libraries such as liboqs, comfort in C or Python, the ability to read a protocol specification and a NIST publication, and enough public key infrastructure (PKI) and HSM knowledge to work with the hardware rather than around it.
You are missing this capability if the program has a target-state document, a prioritized inventory, and no service in production negotiating a post-quantum algorithm.
Delivery: rolling it out and keeping it rolled out
The output is automation. Certificate lifecycle management that issues, deploys, and rotates without a change ticket per host. Pipeline checks that fail a build using a disallowed algorithm. Deployment tooling that pushes a new root to several hundred services and rolls back cleanly when one of them rejects it.
Delivery is where crypto-agility either becomes real or stays a slide. The first migration is expensive whatever the organization does. The second one, which arrives when an algorithm is deprecated or a new standard lands, should cost a fraction of the first, and the difference is almost entirely automation built during the first. Programs that treat migration as a project with an end date pay full price twice.
The skills sit in DevSecOps: scripting, continuous integration and delivery (CI/CD) tooling, container orchestration, infrastructure as code, and enough PKI to script against a certificate authority or a cloud key management service without breaking the trust chain.
You are missing this capability if the migration plan describes work in units of systems rather than units of pipelines.
How the four combine
Three patterns cover most organizations we work with.
The distributed pattern suits mid-sized enterprises. Discovery goes to GRC, architecture to the existing security architect, implementation to one senior engineer given protected time, and delivery to the platform team. Nobody is hired. One person, usually the architect, owns the program end to end and holds a standing forum, because four part-time owners with no coordination point is the arrangement that quietly stalls.
The core-team pattern suits large regulated institutions. Two to five people hold discovery, architecture, and program governance centrally, and implementation and delivery are pushed into the application and platform teams that already own the systems. The central team writes the standard and the playbooks. It does not do the migrations.
The augmented pattern suits smaller organizations with a heavy compliance obligation. Architecture is bought in for a defined engagement, and discovery and delivery stay in-house, because those two capabilities need to persist after the consultant leaves. Buying architecture and outsourcing the inventory is the wrong way round, though it is the more common instinct.
Hire or train
The external market for these skills is thin and priced accordingly. Cryptographic engineering was a specialism for a small population before 2022, and the recent supply comes mostly from people who retrained rather than from a pipeline that suddenly widened. A search for a post-quantum engineer with production experience is a two-quarter exercise in most markets, and it competes against organizations further along than yours.
Retraining is usually faster, and the reason is structural rather than economic. Three of the four capabilities depend on knowledge of your estate more than on knowledge of lattices. Discovery needs someone who knows which business unit runs the payments gateway. Delivery needs someone who already has commit rights to the pipeline. Architecture needs someone the application teams will listen to. What those people lack is the post-quantum specifics: what the standards actually require, how the algorithms behave under load, how to sequence a migration that touches PKI, and what a defensible inventory looks like. That is teachable material, and it is a smaller gap than institutional knowledge.
Regulatory pressure sets the schedule. CNSA 2.0 already sets transition dates for national security systems and their suppliers. Insurers and enterprise procurement teams are moving ahead of it. Whichever staffing pattern applies, the capability needs to exist before the first client questionnaire asks who owns it.
Where to build the skills
Quantum Academy’s post-quantum certification track is organized around these capabilities rather than around job titles, so an existing team member can build the specific competency their role is missing without retraining for a job they don’t hold. The inventory and risk-assessment material supports discovery, the architecture and migration-planning material supports target-state design, the engineering material supports implementation, and the operational material supports delivery at scale.
Browse the programs and their prerequisites at quantumacademy.com/. For the migration methodology these capabilities execute against, the PQC Framework sets out the phases in detail, and the August 2024 NIST announcement remains the primary reference for the standards themselves.