The Skills a Quantum-Ready Security Team Needs

NIST published FIPS 203, FIPS 204 and FIPS 205 on August 13, 2024, and the argument about what to migrate to largely ended that day. ML-KEM handles key establishment. ML-DSA handles general-purpose signatures. SLH-DSA offers a more conservative signature option built on hash functions rather than lattices, and a fourth signature standard, FN-DSA, was announced as forthcoming. The algorithms are no longer the hard part of the problem; who does the work is.

Where the guidance stops

Every serious piece of public guidance agrees on the tasks. The joint fact sheet from CISA, the NSA and NIST tells organizations to build a quantum-readiness roadmap, run a cryptographic inventory and start engaging their vendors. OMB Memorandum M-23-02 makes that inventory mandatory for US federal agencies. The UK’s National Cyber Security Centre has published a phased timeline that expects discovery and a migration plan by 2028, the highest-priority systems migrated by 2031, and everything else by 2035. NIST’s draft transition guidance, IR 8547, proposes deprecating RSA-2048 and ECDSA-256 after 2030 and disallowing them after 2035.

Read those four documents end to end and you will find a complete task list and not one job title. None of them says who owns the inventory, who signs the contract clause, who tests whether the load balancer survives a larger handshake. That silence is reasonable, because staffing is an internal matter, and it is also where a great many migration programs quietly stop.

Why the skills gap is misdiagnosed

The usual sequence runs like this. A security leader reads the guidance, concludes the organization needs a cryptographer, discovers that experienced cryptographers are scarce and expensive, and defers the program to next quarter. Then the same thing happens next quarter.

The conclusion is wrong. Almost none of the migration work is cryptography. It is asset inventory, certificate lifecycle management, protocol configuration, contract drafting, regression testing and budget planning, all performed by people who already do those things every week.

A network engineer doesn’t need to know why lattice problems resist quantum attack. They need to enable a hybrid key exchange, which combines a classical algorithm with a post-quantum one so that the session stays protected as long as either one holds, and then measure what it did to handshake latency and connection success rates. An administrator of your public key infrastructure, or PKI, doesn’t need the security proof behind ML-DSA. They need to know that its signatures are considerably larger than ECDSA’s, and to find out which enrollment systems, databases and network appliances have a hard size limit before those systems find out in production.

That is the shape of nearly all of it. The scarce ingredient is not quantum expertise. It is crypto-agility as an organizational property, meaning the ability to change cryptographic algorithms without rebuilding the systems around them, and that property is built out of ordinary engineering and governance skills that happen to be spread across seven different teams who do not currently talk to each other.

So the staffing question is whether seven capability areas are covered, and whether each one has a name attached. We teach these as seven areas because that is how the work divides in practice, and because a leader can hold seven boxes in their head while assembling a program. For each one below: what the work actually is, who in a typical enterprise already has most of the skill, and what evidence tells you it is being done.

Seven capability areas

Program governance and strategy

The work. Charter a working group with real authority to set enterprise cryptographic policy and to grant exceptions, drawn from architecture, security operations, application development, privacy, legal and procurement. Translate quantum risk into service-level business impact, so that “RSA is at risk” becomes “these eleven services and these three regulatory obligations depend on RSA.” Rank systems for migration, and rank them on the right variable.

That variable is confidentiality lifetime rather than perceived sensitivity, because of harvest now, decrypt later: an adversary can copy encrypted traffic or archives today and hold them until decryption becomes feasible, which means anything that must stay confidential into the 2030s is exposed by today’s inaction rather than by a future event. A system holding data with a twenty-year confidentiality requirement outranks a more sensitive-sounding system whose data is worthless in six months.

The last part of the job is money. Cryptographic modernization needs a budget line, and it usually gets one by being attached to an existing cycle such as a hardware refresh, a cloud migration or a compliance program.

Who already has it. A deputy CISO, an enterprise security architect, or a risk and compliance manager who is already practised at translating technical exposure into board language and at moving cross-functional groups that don’t report to them. Holders of management-track credentials such as CISM (Certified Information Security Manager) or CRISC (Certified in Risk and Information Systems Control) tend to have the coordination instincts this needs, even where they have never touched a certificate.

Evidence it’s working. A written inventory exists rather than being planned. A dated roadmap has been through a risk committee. Internal standards and reference architectures have been amended to require algorithm agility in new systems. The working group produces decisions and minutes rather than attendance.

Cryptographic discovery and the CBOM

The work. Find every use of cryptography in the estate and record it in a form a machine can query. The output has a name now: a cryptography bill of materials, or CBOM, which lists the algorithms, key lengths, certificates, protocols and cryptographic libraries in use along with where each one is used. It is the cryptographic sibling of the software bill of materials, or SBOM, and the CycloneDX specification added support for it in version 1.6, so this is a format rather than a local spreadsheet convention.

Getting there takes several methods at once. Network scanning for TLS versions and cipher suites. Certificate collection from stores, appliances and certificate authority logs. Source code and binary scanning for calls into cryptographic libraries. Configuration file parsing. Queries against cloud key management policies. And then the uncomfortable corners, which are where the surprises live: mainframes, operational technology and industrial control systems, embedded devices, and appliances where a vendor chose the cryptography on your behalf. NIST’s National Cybersecurity Center of Excellence (NCCoE) practice guide, SP 1800-38, is a useful reference for what a discovery capability needs to cover.

Who already has it. Vulnerability management analysts, who already run and interpret estate-wide scans. Application security engineers, who already read code for insecure patterns. Identity analysts who maintain certificate inventories and can widen their scope from identity certificates to all cryptography. A DevOps engineer can add CBOM generation to a build pipeline in a way that keeps the inventory alive after the initial push.

Evidence it’s working. Coverage stated as a percentage of a defined asset list rather than as an impression. Spot-check audits of a few critical systems that match what the CBOM says. A shrinking count of “unknown algorithm” entries. Most importantly, updates triggered by change management rather than by an annual project, because a snapshot inventory is out of date the week it is finished.

PKI, key management and HSM engineering

The work. This is the plumbing every other team depends on. A hardware security module, or HSM, is tamper-resistant hardware that generates and holds keys; a key management service, or KMS, does the equivalent job in a cloud platform. Both need firmware or platform support for the new algorithms, and both need that support to arrive with the validation your auditors expect, which means tracking FIPS 140-3 validation timing rather than product announcements.

Around that sits the certificate work. Certificate policies and practice statements have to be amended to permit the new algorithms. Certificate profiles need new object identifiers. Larger keys and signatures collide with size assumptions buried in enrollment systems, certificate revocation lists and database columns, and those collisions are cheap to find in a lab and expensive to find at renewal time. Most organizations will run classical and post-quantum hierarchies side by side for years, so someone has to design that coexistence deliberately.

Stateful and stateless signatures

One decision belongs squarely to this team, and it is unfamiliar. ML-DSA and SLH-DSA are stateless: sign as often as you like, and nothing has to be remembered between signatures. LMS and XMSS, profiled by NIST in SP 800-208, are stateful hash-based schemes, which means each signature consumes a one-time key index that must never be reused. Reuse breaks the security of the scheme, so the state has to be tracked with real rigour. In exchange, signatures can be smaller than SLH-DSA’s, though sizes vary by parameter set and may be comparable to or larger than ML-DSA’s. The NSA’s CNSA 2.0 suite specifies these schemes for software and firmware signing, where a single controlled signer produces a modest number of signatures.

The practical consequence is that most organizations will end up running more than one signature algorithm for different purposes, which is new. Today most enterprises live comfortably with one.

Who already has it. PKI administrators, certificate lifecycle managers, HSM operators and identity infrastructure engineers. These people are often invisible on an org chart and indispensable in practice, and they already understand key ceremonies, dual control and the cost of getting key material wrong.

Evidence it’s working. The clearest single signal is whether a test certificate authority can issue an ML-DSA certificate today, with the key held in a lab HSM, and whether some other team has successfully used one. Beyond that: updated certificate policy documents, key backup and rotation procedures that have actually been exercised against post-quantum keys, and no audit findings introduced by the change.

Protocol and application engineering

The work. Turning the new algorithms on where traffic actually flows. Hybrid key exchange in TLS 1.3 first, since it is the highest-value and best-supported move, then SSH and IPsec as implementations mature. Inside applications, upgrading or replacing cryptographic libraries, and reworking any custom encryption logic so it can accept new algorithms through configuration rather than a code change.

Then the part teams underestimate. Post-quantum handshakes are bigger, and size has consequences out on a real network. Google and Cloudflare’s hybrid key exchange experiments in TLS found that when a handshake message no longer fits in a single packet, some network middleboxes misbehave, because they were written against an assumption that no longer holds. The engineering skill is instrumenting the pilot well enough to see a two percent connection failure rate against an old appliance in one regional office, and having a tested way to turn the change off while it gets fixed.

Who already has it. The engineers who configure your load balancers and TLS termination. VPN administrators. Application developers who maintain services that touch cryptography directly. Site reliability engineers, who bring the measurement discipline this area lives on.

Evidence it’s working. A pilot running somewhere real, with telemetry on handshake success rates and latency percentiles rather than an assurance that it seems fine. A documented fallback and a documented way to disable the change. Runbooks handed over to operations in language the on-call engineer can use at three in the morning.

Assurance, testing and performance

The work. Independent verification that the new cryptography behaves, interoperates and scales. Interoperability matrices across the combinations you actually run, since implementations of new standards diverge in their early years. Known-answer test vectors from NIST, run against every implementation in the estate. Fuzzing the new parsing paths, because larger signatures and unfamiliar object identifiers are exactly the sort of input that finds a buffer assumption. Negative testing, so that a malformed key is rejected cleanly rather than crashing a service. Load testing signing throughput, because a signing service sized for ECDSA is not automatically sized for its replacement.

Who already has it. Security QA engineers, penetration testers with a taste for protocol work, and performance specialists. The mindset this area needs is professional scepticism: a vendor claim that an implementation is constant-time is a hypothesis until someone measures it.

Evidence it’s working. Defects found before production rather than after. A test report an auditor can read without a translator. Regression runs repeated when a library version or HSM firmware changes, rather than a single heroic test campaign that ages out.

Data governance, privacy and compliance

The work. Two jobs. The first is supplying the priority order that governance depends on, by classifying data on how long it must stay confidential. Twenty-year health records, sealed legal files, long-lived intellectual property and anything with a statutory retention period all outrank data that expires in a week, regardless of how sensitive the week-old data feels.

The second is keeping the paperwork ahead of the regulators. Internal cryptographic standards need rewriting so the approved algorithms sit in an annex that can be amended without reopening the policy. Audit artifacts, system security plans and third-party risk questionnaires need a post-quantum question in them. And someone has to watch the sectoral rulebooks, because the transition deadlines in NIST IR 8547 and the national roadmaps will filter into industry requirements over the next few years rather than arriving all at once.

Who already has it. Data governance leads, privacy officers and governance, risk and compliance analysts. This is the area most often left out of the working group entirely, and leaving it out is how organizations end up encrypting the wrong things first.

Evidence it’s working. Retention schedules and data classification linked to migration priority in a document someone can point at. An internal crypto standard with a maintainable algorithm annex. A vendor questionnaire that asks about post-quantum plans and records the answers.

Procurement and vendor management

The work. Most of your cryptography is not yours. It arrives inside purchased software, appliances, cloud services and embedded devices, which makes contract language a security control. That means crypto-agility requirements written into requests for proposal and into contracts, SBOM and CBOM delivery obligations, and terms covering what happens if an algorithm is broken during the contract term. It also means budgeting: hardware that cannot be upgraded in firmware has to be replaced, and that replacement belongs in a refresh cycle rather than in an emergency.

We will be blunt about the market, because buyers need to be. Vendor marketing has run well ahead of vendor engineering. “Quantum-safe” on a datasheet is not a statement about anything specific, and the question that separates a real answer from a slide is narrow: which validated cryptographic module, in which firmware version, available on what date, and can we test it in your lab this quarter. Ask it in writing and the field thins out quickly.

Who already has it. Sourcing and procurement specialists paired with a security architect who can read the answers. Third-party risk analysts, who already run the questionnaire process this bolts onto.

Evidence it’s working. At least one contract signed with algorithm-agility language. Vendor responses on file that name versions and dates. A supplier roadmap review scheduled rather than promised.

Three owners you name, four you borrow

Seven areas do not require seven hires. In our experience the workable minimum is three named owners with the work in their objectives: a program lead for governance, a discovery lead for the inventory, and a crypto infrastructure lead covering PKI, key management and HSMs. Those three carry the parts that nobody else will pick up spontaneously, and each one is a real time commitment rather than a title.

The remaining four can be borrowed from existing teams, on one condition. Borrowed means scheduled. A protocol engineer who has been told the migration is important and given no allocated hours will deliver nothing, and will be blamed for it later. Put the hours in the plan.

The failure pattern we see most often is the opposite of understaffing. One capable security architect is handed all seven areas, does the governance and discovery well, runs out of time before the protocol and procurement work, and the program is judged a failure eighteen months later on the two areas that were never resourced.

Turning the blanks into a training plan

The exercise takes an hour. List the seven areas. Write a name against each one, and only write a name where that person knows the work is theirs. Then look at the blanks.

Blanks come in two kinds, and they lead to different responses. Some are missing people, where no team in the organization owns the underlying function at all, and those get solved by hiring or by an outside partner. Most are missing knowledge, where the right person is sitting there with the wrong information: the PKI administrator who has not yet read SP 800-208, the procurement lead who does not know which question to ask a vendor, the privacy officer who has never heard the phrase harvest now, decrypt later. Those get solved with training, and they get solved quickly, because these are experienced professionals who need a specific body of knowledge rather than a career change.

Plenty of the raw material is free. The NCCoE practice guide SP 1800-38, NIST SP 800-208, the joint CISA, NSA and NIST fact sheet, the CycloneDX documentation and the Open Quantum Safe project between them cover a great deal of ground, and anyone who works through them will come out better informed. What public documents don’t provide is sequence, coverage and a way to demonstrate that a person is ready for the responsibility, which is what structured programs and credentials are for.

Where to start

Run the coverage exercise before you buy anything, choose an algorithm or write a roadmap. The inventory tells you what you have. The coverage map tells you whether anyone is in a position to do something about it, and that second answer usually arrives faster and changes the plan more.

For the migration methodology itself, the framework at pqcframework.org sets out the phases in more detail than we have here. For deeper technical background on the algorithms, the standards and the threat timeline, PostQuantum.com goes considerably further into the mathematics and the policy. For people mapping a longer-term move into this work, QuantumCareers.com covers the roles that are forming around it.

And for the training itself, Quantum Academy’s post-quantum work is built for exactly the people described above: the PKI administrator, the vulnerability analyst, the procurement lead and the security architect who now own a piece of this and want to be competent at it rather than merely assigned to it. You can see the current programs, formats and access windows at quantumacademy.com/.