Cryptographic Competence: What Your Engineers Need to Know

An X25519 public key is 32 bytes, as specified in RFC 7748. The ML-KEM-768 encapsulation key that sits beside it in a hybrid handshake is 1,184 bytes, and the ciphertext it produces is 1,088, both fixed by NIST’s FIPS 203. Nothing in that substitution requires lattice mathematics to understand, and no single step in it is hard. The difficulty is cumulative. Those extra bytes travel through load balancers with buffer assumptions baked in, certificate databases with fixed column widths, embedded clients with static receive buffers, and network appliances written by engineers who assumed a TLS handshake fits in one packet.

That is the shape of the post-quantum migration for the people who will actually perform it. It is an engineering problem made of ordinary engineering problems, arriving all at once, across systems that were never inventoried together. The organizations that struggle with it won’t struggle because their staff can’t read a lattice paper. They’ll struggle because nobody could produce a list of every place RSA appears.

This article describes what cryptographic competence looks like across the four domains that carry the technical work: discovery, key management, protocol and application engineering, and assurance. For each one, we set out what the work is, where it goes wrong in practice, and what evidence tells you someone can do it.

What the Migration Actually Asks of Engineers

Start with the good news, because it changes hiring and training decisions. Your existing engineers are closer to competent than most managers assume.

A network engineer does not need to know why module-lattice problems resist quantum attack. They need to know how to enable a hybrid key exchange, how to measure the handshake cost, and what to do when a firewall silently drops the larger ClientHello. A public key infrastructure administrator – the person who runs your certificate authorities and certificate lifecycle tooling – does not need quantum physics. They need to update certificate profiles for larger keys, work out whether their hardware can generate the new key types at all, and plan a hierarchy that serves both old and new clients through a transition measured in years.

What is genuinely new is a small, specific body of knowledge sitting on top of skills your teams already have:

• The algorithms and their shapes. ML-KEM (FIPS 203) for key establishment, ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for signatures, with a fourth signature standard, FN-DSA, following behind. A key encapsulation mechanism, or KEM, is the post-quantum replacement for the key-agreement half of a handshake: one side generates a keypair, the other encapsulates a shared secret against the public key, and both derive the same session key. Engineers need the sizes and the performance profile far more than the internals.
• Hybrid construction. Nearly every near-term deployment combines a classical algorithm with a post-quantum one so that the result is at least as strong as the stronger of the two. Knowing why that is the default, and how it changes negotiation and fallback, determines whether a fallback path is safe.
• Crypto-agility. The property of a system that lets you change algorithm without rebuilding it: algorithm selection in configuration rather than in code, key and certificate formats that tolerate different sizes, and an inventory good enough to find every affected component. Crypto-agility is the durable deliverable here. The specific algorithms will change again.

Everything else – scanning, config management, certificate operations, load testing, fuzzing, capacity planning – is work your teams already do.

Cryptographic Discovery and the CBOM

The first competence is finding what you run. The output is a Cryptography Bill of Materials, or CBOM: a structured, machine-readable inventory of the cryptographic components in your estate, listing algorithms and parameters, libraries and versions, keys and certificates with their attributes, and the context in which each is used. The CycloneDX specification added support for this in version 1.6, documented in the specification’s own CBOM material, which means the format question is settled and the remaining question is coverage.

What the work is

Discovery runs across four layers, and skipping any one of them produces an inventory that looks complete and isn’t.

Network and protocol scanning finds supported TLS versions and cipher suites, SSH configurations, IPsec and VPN settings, and the certificates presented by every listener you can reach. This is the layer that existing vulnerability management teams already have tooling for.

Host and configuration scanning finds what network scanning cannot: keys sitting in filesystems, cryptographic settings in configuration files, certificate stores on endpoints, and the contents of key management services and hardware modules.

Code and build scanning finds calls into cryptographic libraries. Static analysis across your repositories will surface direct calls to OpenSSL, BouncyCastle, or a language’s standard library. Build-time analysis surfaces the transitive dependencies your developers never chose. This layer is where a Software Bill of Materials, or SBOM – the equivalent inventory for software components – earns its place, because linking SBOM to CBOM tells you that a container image you deploy ships a library version pinned to an algorithm you have already deprecated.

The awkward corners. Mainframes running cryptographic routines nobody has read since the 1990s. Operational technology and building systems with proprietary or hardcoded crypto. Vendor appliances that terminate TLS on your behalf and won’t tell you how. Partner connections whose configuration lives at the other end. These are found by asking people, not by scanning, and the asking is part of the skill.

Where it goes wrong

Two failure modes recur. The first is treating discovery as a project with an end date. An inventory produced once and filed is wrong within a quarter, because every deployment changes it. Competent discovery is wired into the pipeline: builds emit a CBOM, changes update the inventory, and the security event pipeline alerts on newly observed deprecated configurations.

The second is accepting tool output without verification. Scanners produce false positives, and they produce confident-looking entries for systems they only partially reached. An engineer who spot-checks a sample of findings by hand, and who tracks “unknown algorithm” entries as open items rather than closed ones, will produce an inventory you can plan against. One who exports the scanner report as-is will not.

What competence looks like

Ask for coverage as a percentage of known systems, with the denominator explained. Ask what proportion of entries carry algorithm, parameters, library version, and usage context rather than just an algorithm name. Ask how many “unknown” entries existed at the first pass and how many remain. Ask to see the inventory queried live: a competent owner can answer “where do we still use RSA-2048 for signing?” in under a minute, and an inventory that can’t answer that question isn’t doing its job.

Keys, Certificates and Hardware

The second competence is the key management backbone: public key infrastructure (PKI), the systems that issue and validate your certificates; key management services (KMS), the software systems that generate, store and control access to keys; and hardware security modules (HSMs), the tamper-resistant devices that hold your highest-value keys and perform operations with them.

What the work is

Key management practice comes first, and most of it transfers directly. Generation, distribution, rotation, escrow, backup, destruction – NIST SP 800-57 still describes the discipline. What changes is that several procedures were built around key sizes that no longer hold. A key backup routine written for a 256-bit elliptic curve private key may not accommodate an ML-DSA private key. Split-knowledge and dual-control ceremonies assume a key can be divided a particular way. Some current HSM firmware will not export post-quantum private keys at all. Each of these is a solvable operational problem, and each one becomes an emergency if it is discovered during a production cutover.

Certificate work is the larger piece. Certificate policies and certification practice statements need to name the approved post-quantum algorithms and their permitted uses. Certificate profiles need updating for the new object identifiers coming out of the IETF LAMPS working group. Chain validation logic has to tolerate mixed hierarchies during transition, because you will run a classical root and a post-quantum issuing tier side by side for a long time. Revocation deserves specific attention: if your certificate revocation lists grow with signature size, the operational answer is usually to lean harder on the Online Certificate Status Protocol (OCSP) than on distributing certificate revocation lists.

Then there is hardware. HSM support for post-quantum algorithms arrives as firmware, firmware upgrades on production HSMs are scheduled events with change windows and rollback plans, and FIPS 140-3 validation of the new firmware lags its release. An engineer who knows which of your modules support which algorithms, under which firmware, with which validation status, and when the vendor expects the next milestone, is holding information that determines your entire migration sequence. Most organizations do not have that person yet.

Choosing signature schemes

This is the one place where the engineering choice is genuinely branched.

ML-DSA and SLH-DSA are stateless: sign as often as you like, no bookkeeping. ML-DSA-65 signatures run around 3.3 KB at the parameter set defined in FIPS 204. The smallest SLH-DSA parameter sets in FIPS 205 produce signatures near 7.8 KB, and the larger ones go up sharply, in exchange for security resting only on hash function assumptions.

LMS and XMSS, profiled in NIST SP 800-208, are stateful hash-based schemes. Each signing operation consumes a one-time key from a tree, and the signer has to guarantee that no index is ever reused. Reuse breaks the scheme. In return the signatures are smaller than SLH-DSA and the security argument is conservative, which is why NSA’s CNSA 2.0 guidance, published in its 2022 algorithm fact sheet, directs national security suppliers toward stateful hash-based signatures for firmware and software signing.

The practical division follows the state problem. Use a stateful scheme where signing is centralized, low-volume, and auditable: firmware images, code signing, secure boot. Use a stateless scheme everywhere signing is distributed or high-volume, because state management across a fleet of signers is a class of outage nobody wants to invent. Most enterprises will run both, which is itself a change – today, one signature algorithm usually covers everything.

What competence looks like

The clearest signal is a working test certificate authority issuing post-quantum and hybrid certificates that other teams can pull from. A PKI group that can hand a protocol engineer an ML-DSA-signed test certificate on request has moved from reading to doing. Beyond that: an updated certificate policy naming approved algorithms, a documented answer to the key backup question, and a firmware roadmap with dates against each HSM model in the estate.

Protocols and Applications

The third competence puts the new algorithms on the wire. Hybrid key exchange – running a classical exchange such as X25519 and a post-quantum KEM such as ML-KEM in the same handshake and combining both results into the session key – is where nearly every organization starts, because it degrades safely if either component turns out to be weak.

What the work is

For TLS 1.3, this means enabling a hybrid group such as X25519MLKEM768, the ML-KEM hybrid group defined in the IETF TLS working group’s hybrid key exchange draft, on both ends, ordering preferences so that hybrid wins where both sides support it and negotiation falls back cleanly where they don’t, and confirming that your terminating infrastructure passes the negotiation through rather than rewriting it. For SSH, upstream OpenSSH has shipped the hybrid method sntrup761x25519-sha512@openssh.com since release 8.5, per the project’s release notes, and ML-KEM-based methods exist in forks and patches rather than in mainline, so enabling hybrid SSH today is largely a configuration and version-floor exercise against that one method. For IPsec, the relevant Internet Key Exchange version 2 (IKEv2) work is further behind, and the honest answer for many estates is to schedule it rather than attempt it now.

Applications are messier than protocols. An application that wraps a symmetric key with RSA needs a designed replacement, not a substituted library call. An application that verifies signatures on plugins or updates needs to understand the new signature types before you sign anything with them. Anything with a custom certificate parser needs the new object identifiers. None of this is exotic work, and all of it takes longer than the estimate.

Where it goes wrong

Size, and the systems that assumed size would never change.

A ClientHello carrying a post-quantum encapsulation key can exceed the size that fits in a single packet. Some middleboxes – the transparent proxies, inspection appliances and load balancers that sit between client and server and read the handshake as it passes – were written on the assumption that the first flight arrives in one piece. They do not fail loudly. They drop, truncate or hang, and the symptom that reaches your team is an intermittent connection failure from one customer network. Early public deployments by browser vendors and content delivery networks surfaced exactly this class of fault, and it is now the first thing to look for when a hybrid rollout produces a small, stubborn failure rate.

The second recurring failure is unsafe fallback. A negotiation designed so that any confusion drops the connection to classical-only, with no signal, hands an attacker a downgrade path. Fallback should be explicit, logged, and countable, so that you can tell the difference between “this client is old” and “something is stripping our preferences.”

What competence looks like

Look for a pilot with numbers attached. A team that enabled hybrid key exchange on one service, measured handshake latency and failure rate before and after, identified which client populations could not negotiate it, and wrote that down, has demonstrated the whole skill. A team that enabled it and reported that nothing broke has demonstrated that they weren’t measuring. Ask what percentage of connections negotiated the hybrid group after rollout, and ask what happened to the remainder.

Assurance, Interoperability and Performance

The fourth competence is checking the work. This domain is habitually under-resourced, and it is the one that decides whether your migration is a series of controlled changes or a series of incidents.

Interoperability

Different implementations of the same standard disagree in their first year. Build a test matrix across the combinations you actually run: server library against client library, load balancer against origin, cloud service against on-premises endpoint, mobile client against gateway. Include the appliances, because a firewall that mangles a handshake counts as an interoperability failure even though it implements nothing. Every algorithm you deploy should also pass the published test vectors from its standard, which is a cheap check that catches a badly built library immediately.

Implementation security

Cryptographic implementations leak through timing. Constant-time code – code whose execution time does not depend on secret values – is the defence, and it is a property of the implementation rather than of the algorithm. Post-quantum libraries are younger than their classical counterparts, some ship optimized modes that trade constant-time behaviour for speed, and the configuration you inherit may not be the one you want. Verify rather than assume.

Fuzz the new parsing paths as well. Certificates with post-quantum object identifiers, signatures at unfamiliar sizes, malformed encapsulation keys: all of it is new input handling in code that used to see only well-formed classical structures. Malformed input should produce a clean rejection, not a crash and not a hang.

Performance under load

Single-operation benchmarks tell you almost nothing about production. Run handshake load tests at realistic concurrency and watch CPU on the terminating tier. Measure signing throughput on the HSM with the actual algorithm you plan to use, because a module that comfortably handles ECDSA at your peak rate may not handle ML-DSA at the same rate, and the answer to that question determines whether you buy hardware this year. Test on degraded networks too, since larger handshakes and packet loss interact badly.

What competence looks like

A written test report is the artefact. It should name the combinations tested, list the defects found and their resolution, and give before-and-after numbers for latency, throughput and failure rate. The strongest signal is a list of problems caught before production. A clean report with no findings usually means the tests were too gentle.

Building the Bench

None of the four domains requires a cryptographer. Each maps onto a role you probably already staff.

Discovery and CBOM fits a vulnerability management analyst or an application security engineer, and fits especially well if they already script. The adjacent skill is inventory work, and the new content is the CycloneDX cryptographic schema plus the discovery reference material published by the NIST National Cybersecurity Center of Excellence in its post-quantum migration project.

Keys, certificates and hardware fits your PKI administrator or identity infrastructure engineer. They already know how keys move through your systems, which is the part that cannot be taught quickly. The new content is algorithm properties, certificate profile changes, and vendor firmware roadmaps.

Protocols and applications fits network security engineers and the developers who own your TLS termination or client software. The new content is hybrid negotiation, size effects, and fallback design.

Assurance fits a security-minded QA engineer, a penetration tester with an interest in cryptography, or a site reliability engineer who already owns load testing.

Discovery has to be genuinely underway before the other three can be prioritized, since nobody can decide what to migrate first without knowing what exists. The PKI and hardware track has the longest lead time, because firmware, validation and vendor schedules are outside your control. Start that conversation with your HSM vendor before you need the answer.

A note on the market: ask any vendor whether they support post-quantum cryptography and the answer is almost always yes. Ask which algorithms, at which parameter sets, in which product versions, under which firmware, with what validation status and on what date, and the answers thin out fast. That second question is the one your engineers should be trained to ask, and the ability to ask it precisely is itself a measure of competence.

Free, hands-on practice exists for all four domains. Open Quantum Safe’s liboqs and its OpenSSL provider let an engineer generate post-quantum keys, issue test certificates and complete a hybrid handshake on a laptop, at no cost beyond an afternoon. The NCCoE migration project publishes reference material on discovery and migration architecture. Working through a hybrid handshake by hand, watching the packet capture, and then breaking it deliberately puts an engineer in front of the failure modes described above.

Turning This Into a Trained Team

The gap between reading about post-quantum cryptography and deploying it is the gap between knowing that FIPS 203 fixes an ML-KEM-768 ciphertext at 1,088 bytes and knowing what your load balancer does when one arrives. Closing it takes structured practice against the same four domains: an inventory built and queried, keys generated and backed up, a handshake negotiated and measured, a test matrix run and reported.

That is what our Post-Quantum Cryptography Specialist program is built around. It’s designed for engineers who already hold the classical skills and need the specific post-quantum content and lab time layered on top, and it assesses candidates on demonstrated work rather than recall.

For the migration methodology that surrounds these skills, see pqcframework.org. For deeper technical background on the algorithms and standards referenced here, PostQuantum.com covers them in detail, including the original skills analysis this article draws on. Engineers weighing where these skills lead can look at the role paths on QuantumCareers.com.