Marin Ivezic
Recruiters describe the quantum talent market as chronically short of qualified candidates, and the description is accurate for the jobs it covers. It covers jobs most organisations will never post.
The roles behind that shortage are qubit calibration specialists, cryogenic technicians, quantum hardware engineers and algorithm researchers. They belong to the companies building quantum computers. If you run technology or risk for a bank, a hospital network, a utility or a defence supplier, you are not building a quantum computer. You will buy access to one eventually. Long before that, you have to re-engineer the cryptography that holds your organisation together, and you have to do it against published regulatory dates.
Those are two different problems with two different staffing answers. Conflating them is the most expensive mistake we see executives make in this area, because it sends a hiring team into a market where they cannot win, to solve a problem they do not have.
The hiring market is the wrong place to start
Suppose you decide to hire your way into quantum capability. Your competition for a quantum physics PhD is IBM, IonQ, Quantinuum, PsiQuantum, three national laboratories and a well-funded startup that will offer equity. You will lose most of those contests, and you should. The candidate who takes your offer instead of theirs is often the candidate the others passed on.
Now consider what that hire would do on arrival. They would spend their first six months learning your certificate infrastructure, your vendor contracts, your embedded device fleet and your change-management process. Those are the things standing between you and a completed cryptographic transition, and they are things your existing staff already know. The physics is the part you can teach in weeks. The institutional knowledge is the part that takes years.
So the sensible starting question is not how many quantum specialists to hire but which of the people already on the payroll need to understand what, and to what depth.
What the work actually is
Break the demand into three streams. They have different sizes, different urgency, and almost no overlap in skills.
The cryptographic transition
This is the bulk of the work, and it will stay the bulk for the rest of the decade. Post-quantum cryptography (PQC) means encryption and signature algorithms designed to resist attack by a quantum computer. NIST published the first standards in August 2024: ML-KEM (formerly CRYSTALS-Kyber) for key establishment, ML-DSA (formerly CRYSTALS-Dilithium) and SLH-DSA (formerly SPHINCS+) for digital signatures. NIST has not issued universal deprecation dates for RSA or elliptic-curve cryptography, and the dates that actually bind any given organisation come from elsewhere: CNSA 2.0 for U.S. national security systems, OMB memoranda for federal civilian agencies, and sector regulators for everyone else.
The urgency isn’t speculative. Two things drive it. The first is harvest now, decrypt later, or HNDL: an adversary copies encrypted traffic today and stores it until a machine capable of breaking it exists. Anything you transmit with a confidentiality requirement longer than the remaining life of RSA is already exposed. The second is procurement. Your customers, regulators and insurers are starting to ask what your migration plan is, and the question arrives whether or not you have an answer.
Two terms do most of the work in this stream. A cryptographic bill of materials, or CBOM, is a complete inventory of every place your organisation uses cryptography: which algorithm, which key length, which library version, in which system, owned by whom. Crypto-agility is the property of being able to swap one algorithm for another without redesigning the system around it. Most enterprises have neither, and building the first is what tells you how far you are from the second.
Look at the skills that requires. Asset discovery. Public key infrastructure and certificate lifecycle management. Key management and hardware security modules. Application dependency mapping. Vendor and contract management. Embedded and operational technology engineering, if you have devices in the field. Change control at scale. Not one of those requires quantum mechanics. All of them require someone who can find every place a cryptographic primitive is buried and name the person accountable for it.
The applications question
This stream is small on purpose, and it should stay small for several years yet.
Somewhere in your organisation, someone will be pitched a quantum computing use case. Portfolio optimisation, molecular simulation, logistics routing, risk modelling. Some of those will eventually be real. Most of what is currently pitched is not, and the difference is not obvious to a non-specialist.
The distinction that separates a serious claim from a promotional one is usually physical versus logical qubits. A physical qubit is a piece of hardware; it is noisy and it loses its state quickly. A logical qubit is an error-corrected abstraction built from many physical qubits working together, and it is the unit that useful computation needs. A vendor announcing a thousand physical qubits and a vendor demonstrating a handful of logical ones are making claims that differ by orders of magnitude in significance. So does the gap between announced and demonstrated.
You need one or two people who can read a vendor deck, ask what the error rate was, ask whether the result was benchmarked against a classical solver running on comparable hardware, and say no without embarrassment. That capability protects a budget line. It does not require a research group.
If you operate in a sector where quantum sensing matters, add a third person here. Quantum sensors use quantum effects to measure magnetic fields, gravity, rotation or time with precision that classical instruments can’t reach, and in energy, aerospace, defence and some medical imaging contexts they are commercially closer than quantum computing.
Procurement, assurance and governance
The smallest stream, and the one most often forgotten until it blocks something.
Contracts need PQC language: what algorithms a supplier must support, by when, and what evidence they will provide. Internal audit needs to know what a competent migration plan looks like so they can test whether yours is one. The board needs a briefing that is honest about timelines without theatre in either direction. Legal and compliance need to track the regulatory position in every jurisdiction you operate in.
These roles need literacy rather than depth. They need to understand what changes and what the deadlines are, and they need enough vocabulary to challenge an answer that doesn’t hold together.
A capability map, worked through
Take a reference organisation: 1,200 staff, around 180 of them in technology, regulated, with a mix of cloud services, legacy internal systems and a modest field-device estate. Nothing exotic. Here is what the staffing actually comes to.
One programme owner. Half an FTE at the outset, closer to full-time once migration work is running across multiple platforms. This person owns the plan, the reporting line to the board and the inventory. They come from your existing security or architecture leadership.
One cryptographic architect. Full-time, and the deepest technical role in the map. They set the target-state design, decide the hybrid approach for each protocol, review vendor claims and adjudicate the hard cases. This is the role most likely to need an external hire if no internal candidate exists, and the one worth being patient about.
Three to five platform engineers with real cryptographic depth. One per major platform: identity, network, application, data at rest, and field devices if you have them. They do the work. They are almost always people you already employ who currently know PKI at an operational level and need to know it at a design level.
Roughly twenty-five to thirty application and system owners with working literacy. Two to three days of structured training each. They need to answer inventory questions accurately, recognise when their system is affected, and not stall the programme by misunderstanding what is being asked.
Two people in procurement and legal, one in internal audit, with governance-level literacy. Half a day to a day of training, refreshed annually as the regulatory position moves.
Add it up. Two new full-time roles, one of which is probably internal. Around thirty-five people who each need somewhere between half a day and a week of training. That is a workforce plan you can fund and defend. It is a different object entirely from “we need to hire a quantum team,” which is unfundable, undefendable, and would not solve the problem if it succeeded.
Buy, build, or borrow
Each role in that map resolves to one of three answers, and the choice has consequences beyond cost.
Borrow for the inventory sprint and the initial architecture review. A capable consultancy will get you to a first CBOM faster than you will get there alone, and an outside review of the target-state design is worth paying for. What you can’t borrow is the migration itself, because it runs for years and touches every change window you have. If the knowledge leaves when the engagement ends, you have bought a document rather than a capability.
Build for almost everything else. Your PKI operations people, your identity engineers, your security architects and your embedded developers are the natural population. They already hold the context that takes longest to acquire. What they need is structured training with a credential attached, and then a mandate to use it.
Buy for the one or two roles where no internal candidate exists at all, most often the cryptographic architect. Accept that this hire takes months and hire for cryptographic engineering judgment rather than quantum credentials.
One caution on retention. People you train and certify become visible to recruiters, and quantum-adjacent security skills are in demand. Budget for that rather than pretending it away. In practice the cheapest retention lever is a combination of interesting work, a recognised credential, and a visible role in a programme the board is watching. A trained engineer who is bored will leave regardless of what you pay.
Sequencing over twenty-four months
The order matters more than the pace, because the wrong order produces training nobody can act on.
- Months 0 to 3. Governance-level literacy for the decision-makers: the programme owner, the CISO’s leadership team, procurement, legal, internal audit. Start the inventory. The purpose of this phase is a funded plan and an accurate picture of scope, not technical progress.
- Months 3 to 9. Depth for the architect and the platform engineers. Certification-level training in PQC algorithms, hybrid deployment, key management and migration planning. This is where the target-state design gets written and the first pilot runs, usually on a system you control end to end.
- Months 9 to 18. Working literacy across the application and system owners, timed to arrive just before each team’s remediation work does. Training delivered a year before it is needed evaporates. Delivered a month before, it holds.
- Months 18 to 24. Assurance and refresh. Internal audit tests the programme against the plan. Procurement language goes into the contract templates. Everyone trained in the first phase gets an update, because the standards, the deadlines and the vendor position will all have moved.
Four ways this goes wrong
The physics detour. A team spends its first quarter learning Shor’s algorithm in detail and its second quarter discovering that nothing in the migration plan depends on that knowledge. Understanding why RSA falls takes an afternoon. Understanding where RSA is used across your estate takes months, and it is the part that determines whether you finish.
The single expert. One person is trained, becomes the bottleneck for every decision, and then resigns. Depth in one head is a liability disguised as an efficiency. Train at least two people to architect level even in a mid-sized organisation.
Training without a mandate. People are certified and then returned to a backlog that contains no migration work. Six months later the knowledge is stale and the programme has not started. Training should land within weeks of the work it enables, and the work should already be scheduled when the training is booked.
Literacy mistaken for capability. An awareness session for four hundred staff produces a good completion metric and no ability to execute. Broad literacy is worth having, but it is the cheap layer. The expensive layer is a small number of people who can actually design and run the transition, and no volume of awareness training substitutes for it.
Where to start
Two weeks of work will tell you most of what you need to know. Name the person who owns quantum readiness. Count the systems that use cryptography you can identify today and estimate the ones you can’t. Map the three streams above onto your organisation chart and mark each role as buy, build or borrow. Then price the training, which will come in well below the hiring budget somebody has probably already sketched.
Two tracks in the Quantum Academy catalogue map onto that split directly: governance-level certification for the executives, procurement staff and auditors who need to ask the right questions, and technical certification for the architects and platform engineers who will design and run the migration. Both are listed at quantumacademy.com/, and the useful move is to match the depth to the roles in your map rather than to job titles.
For the migration methodology itself, pqcframework.org sets out the phased approach in detail. For deeper technical background on the algorithms and the threat model, PostQuantum.com covers both at length. And if you are mapping career paths for the people you are about to train, QuantumCareers.com tracks how these roles are being defined across the market.
The talent shortage is real. It is also, for most organisations, someone else’s shortage. Yours is a training problem with a deadline attached, and that’s a considerably better problem to have.