Building a Quantum-Ready Team: Hiring, Training, and Sequencing

NIST published the first three post-quantum standards on August 13, 2024: FIPS 203 for ML-KEM, which establishes shared keys, and FIPS 204 and FIPS 205 for ML-DSA and SLH-DSA, which produce digital signatures. Within weeks, security leaders started writing job descriptions. Most of those postings describe a person who doesn’t exist, and the search for that person is now the single most common reason a migration program has nothing to show after a year.

This is the third part of our series on post-quantum migration. The first two covered the work itself. This one covers who does it, in what order, and what you actually have to teach them.

Why the job description is the problem

A typical posting asks for research-level familiarity with lattice-based cryptography, hands-on enterprise certificate operations, software supply chain analysis, and enough regulatory fluency to brief an audit committee. A handful of people fit that description worldwide. They’re employed, and they’re not answering your recruiter.

The description is also wrong about the work. Almost none of the migration requires understanding why module-lattice problems resist a quantum attack. A network engineer enabling a hybrid key exchange – a handshake that runs a classical algorithm like elliptic-curve Diffie-Hellman alongside ML-KEM, so the connection stays safe even if one of the two is later broken – needs to know how to configure it, how to measure the handshake, and what breaks when the message grows past a single packet. A certificate administrator needs to know which signature algorithms their certificate authority can issue and how large the resulting certificates are. Neither needs the mathematics.

What the work does require is coordination across seven functions that already exist in most organizations, and a sequence that respects the dependencies between them. That is a program management problem with a cryptography vocabulary attached, which is a very different hiring brief.

Seven capabilities, and who already has most of them

The migration decomposes cleanly. Each of these is a capability rather than a headcount, and in a mid-sized organization one person often carries two of them.

One term in the table below carries the whole program, so we’ll bind it first. A software bill of materials, or SBOM, lists the components inside a piece of software. A cryptography bill of materials, or CBOM, lists the cryptography: which algorithms are in use, at what key sizes, in which libraries, protecting what, on which systems. The CycloneDX specification added CBOM support in version 1.6, which means the format is settled and your discovery output can be machine-readable rather than a spreadsheet that goes stale in a month.

Capability	Nearest role you already have	The gap to close
Program governance and strategy	Security risk manager, deputy CISO, enterprise security architect	Standards and national timelines; how to translate algorithm risk into service-level business impact
Cryptographic discovery and CBOM	Vulnerability management analyst, application security engineer	Discovery methods across code, network, storage and firmware; the CycloneDX CBOM schema
PKI, key management service (KMS) and hardware security module (HSM) engineering	Certificate administrator, IAM infrastructure engineer	New signature and key sizes; vendor firmware roadmaps; hybrid certificate hierarchies
Protocol and application engineering	TLS or VPN engineer, senior backend developer	Hybrid key exchange configuration; larger handshake behavior; fallback design
Assurance, testing and performance	QA lead, penetration tester, site reliability engineer	Interoperability matrices; fuzzing new parsing paths; load testing signature operations
Data governance and compliance	Privacy officer, compliance manager	Data lifetime as a prioritization input; mapping regulatory deadlines to systems
Procurement and vendor management	Third-party risk manager, sourcing lead	Crypto-agility contract language; how to read a vendor roadmap for evidence rather than intent

Three waves, not seven parallel tracks

Standing up all seven at once is the second common failure. Teams that try it produce seven partial deliverables that don’t compose. The dependencies are real, and they group into three waves.

Wave one, roughly the first six months: governance, discovery, data classification, and procurement language. The steering group charters the program and gets authority to set enterprise crypto standards. Discovery starts building the inventory. Data governance classifies systems by how long their data has to stay confidential, which is the input that makes prioritization possible. And procurement starts inserting crypto-agility requirements into contracts immediately, because a five-year hardware agreement signed this quarter with no algorithm-change clause is a constraint you inherit for the rest of the program.

The data classification piece often gets deferred, and it shouldn’t be. The CISA, NSA and NIST joint factsheet on quantum readiness frames the near-term risk as harvest now, decrypt later: an adversary collects encrypted traffic today and decrypts it once the capability exists. That threat model only bites data with a long confidentiality requirement. Patient records, personnel files, sealed contracts, source code, state secrets. Telemetry you delete in a week isn’t the problem. Without the classification, discovery produces a list of four thousand findings with no ranking, and engineering has nowhere to start.

Wave two, roughly months six to eighteen: key infrastructure and protocol pilots. This is where the PKI team, meaning the people who run your public key infrastructure and issue certificates, work out whether their certificate authority can issue an ML-DSA certificate at all. Alongside them, the engineers who manage hardware security modules and cloud key management services, the devices and services that generate and protect private keys, need to establish which firmware version supports which algorithm and when their vendor expects validation. Protocol engineers pilot a hybrid key exchange on a non-critical service and measure what happens.

Wave three, from roughly month twelve onward: assurance, scale-out, and vendor evidence. Testing runs against the pilots before they widen. Procurement moves from writing clauses to collecting proof that vendors have met them.

The waves overlap, deliberately. Procurement and data governance never stop. But the ordering constraint holds: engineering can’t prioritize without classification, and can’t pilot without a certificate.

Where the handoffs break

Four failure points recur, and each is a handoff rather than a skill gap.

Discovery hands engineering a list with no context. An inventory that records algorithm and key length but not owner, exposure, or the data being protected is not actionable. The fix is a scoping decision made before scanning starts: the discovery role owns context fields, not just cryptographic fields. Every entry answers who owns this system, is it internet-facing, what data does this key protect, and how long does that data stay sensitive. That takes longer and produces a shorter list. The shorter list gets used.

Application teams ask PKI for a post-quantum certificate the week they need it. The lead time is quarters, not weeks. Firmware upgrades on key-protection hardware are scheduled maintenance events. Certificate policy documents need revision to permit new algorithms. Validation status matters if you have compliance obligations tied to certified modules. The fix is a standing pilot capability: a test certificate authority that can issue post-quantum certificates on request, stood up in wave two, before anyone asks.

Protocol pilots run without assurance in the loop. Post-quantum key exchange makes handshake messages larger, and larger handshakes surface behavior that nobody sees in a lab. Network middleboxes that assumed a handshake fits in one packet have dropped or mangled connections that no longer do. Those failures appear in the field, at a subset of clients, intermittently. The fix is that assurance joins at pilot design rather than at pilot review, and that the pilot ships with telemetry on handshake success rate from day one.

Procurement signs before the standard exists. If the steering group hasn’t yet defined what quantum-safe means for your organization, contract language defaults to something vague that a vendor can satisfy with a roadmap slide. The fix is an interim clause in wave one, tightened later: the supplier commits to supporting NIST-standardized post-quantum algorithms within a stated window, provides a CBOM or equivalent disclosure on request, and supports algorithm change without hardware replacement.

What’s worth training, and what isn’t

The training instinct runs in the wrong direction. Teams sign up for quantum computing fundamentals and lattice mathematics, which are interesting and almost entirely inapplicable. Nobody on the migration will choose parameters or evaluate a security proof.

What people need instead is narrow and teachable.

For everyone on the program: the standards by name and function. ML-KEM for key establishment, ML-DSA and SLH-DSA for signatures, with their FIPS numbers. The distinction between an algorithm being standardized and a product supporting it. The difference between what a vendor has announced and what a vendor has shipped.

For governance: the deadline structure they’re actually working against. In the United States, OMB M-23-02 requires federal agencies to maintain cryptographic inventories and submit migration plans. The date that binds a given system comes from the guidance covering it rather than from a single government-wide target. NSA’s CNSA 2.0 guidance, which applies to national security systems, sets earlier dates for software and firmware signing than for general network equipment. The UK’s National Cyber Security Centre has published a phased timeline built around discovery and planning by 2028, highest-priority systems migrated by 2031, and completion by 2035. The EU has issued a coordinated roadmap on a comparable arc. A governance lead who can cite the specific instrument that binds their sector will win budget arguments that a generic risk narrative loses.

For discovery: the CycloneDX CBOM schema, and NIST’s National Cybersecurity Center of Excellence practice guide SP 1800-38, which is effectively a free manual on structuring discovery at scale. Then scripting practice, because most of the job is parsing configuration files and scan output at volume.

For PKI and key infrastructure: signature and key sizes as operational facts. ML-DSA signatures run roughly 2.5 to 4.6 KB depending on parameter set, against 64 bytes for a common elliptic curve signature. SLH-DSA runs larger again, roughly 8 to 50 KB. Those numbers decide whether your certificate revocation lists still fit, whether your enrollment system accepts the request, whether the constrained device at the edge of your network can hold a certificate at all. Also worth an afternoon: the stateful hash-based schemes LMS and XMSS, which produce much smaller signatures but require that the signing system never reuse a one-time key index, a constraint that makes them suitable for firmware signing and unsuitable for high-volume distributed use.

For protocol and application engineers: hands-on work with an open-source post-quantum provider, building a hybrid handshake between a test client and server, then breaking it deliberately. Two days of that teaches more than two weeks of reading.

The pattern across all five: short, specific, and immediately applied. Training delivered six months before the work begins is training you pay for twice.

How to tell whether it’s working

Headcount trained and hours completed are vanity metrics. Six indicators are worth tracking instead.

• Inventory coverage with context. Not how many systems were scanned, but what share of scanned systems have an owner, a data-sensitivity rating, and an exposure classification attached.
• Inventory staleness. How many days between a system changing and the CBOM reflecting it. If the answer is measured in quarters, discovery is a project rather than a capability.
• Certificate lead time. How long from an application team requesting a post-quantum test certificate to holding one. Track it from the first request. It should fall.
• Pilot count and pilot survival. How many services have run a hybrid key exchange in production traffic, and how many are still running it. A pilot that was rolled back and never diagnosed is worse than no pilot.
• Contract coverage. What share of contracts signed since the program started carry crypto-agility language.
• Decisions made. Has the steering group approved an algorithm standard, a hybrid policy, and a prioritized system list? Three documents. If none exists after two quarters, governance is a meeting rather than a function.

The hires worth making from outside

Most of this staffs internally. Two exceptions are worth the budget.

The first is a program lead, if nobody internal has run a multi-year cross-functional infrastructure migration. The hire is for migration program experience rather than cryptography research. Someone who has driven a TLS 1.2 deprecation or a mainframe decommissioning across a resistant organization will do better here than a cryptographer who has never chaired a steering group.

The second is a key infrastructure engineer, if you genuinely have nobody who understands how keys move through your systems. Many organizations do have this person and cannot find them, because their title says identity or infrastructure and their certificate work is invisible until it breaks. Look before you post.

Everything else is better filled by moving people. The analyst who runs your vulnerability scans already knows your environment’s dark corners, and no external hire will learn that in under a year. Specialist expertise is better bought time-boxed, as engagement work on discovery tooling or interoperability testing, than as permanent headcount for a capability you need at intensity for eighteen months.

Training on a schedule

Sequence the training to the waves, and keep the group small at each stage.

Start with the governance lead and the data governance counterpart, in month one, before the steering group charter is written. They set the definitions everyone else inherits. Bring discovery in next, around month two, so the inventory is designed against the classification scheme rather than reconciled with it later. Key infrastructure follows at month four, since firmware and vendor conversations have long lead times and should start before anyone needs a certificate. Protocol and application engineers train just ahead of the first pilot. Assurance trains alongside them, not after. Procurement needs the least depth and the earliest start, because contract language written in month one protects you for years.

One habit is worth building into the schedule from the beginning. Whoever trains first teaches the next group. Not as a substitute for external training, but as the mechanism that turns individual knowledge into organizational knowledge. A discovery analyst who has to explain the CBOM schema to the application security team understands it differently afterward, and the program stops depending on any single person staying.

Where to start

If you take one thing from this piece, make it the ordering. The seven capabilities are not equally urgent, they are not independent, and the ones that feel most technical are not the ones to staff first. Governance, classification, discovery and contract language in the first six months. Key infrastructure and pilots in the second year. Assurance and scale after that.

For the migration methodology itself, including the phase-by-phase deliverables that sit underneath this staffing sequence, see the framework at pqcframework.org. For deeper technical treatment of the algorithms and the protocol behavior, PostQuantum.com goes considerably further than we have here. And if you’re working out which of these seven capabilities suits your own next move, QuantumCareers.com maps the roles.

To train the team itself, PQCM is the Quantum Academy program built around this sequence, structured so that the governance, discovery, key infrastructure, and assurance tracks can be taken by different people at different points in the program rather than all at once. Enrollment and the current module list are at quantumacademy.com/.