Quantum Computing in Aerospace and Automotive: What Executives Are Actually Deciding

UN Regulation No. 155 requires a certified cybersecurity management system covering a vehicle type from development through decommissioning, and in the EU and other jurisdictions that have adopted it, it has applied to all new vehicle registrations since July 2024, and to new vehicle types in the EU since July 2022. Applicability and dates vary by market. Decommissioning is a long way off. A car built this year will still be accepting over-the-air (OTA) software updates well over a decade from now, and the public keys that verify those updates sit in hardware nobody intends to replace. Aerospace runs the same arithmetic on a longer scale: an airframe delivered today can still be in revenue service several decades later.

So when a board in either sector asks what quantum computing means for the business, two different answers arrive, on two different calendars, under one word. They get confused with each other constantly, and the confusion is expensive in both directions.

Two Decisions Wearing One Word

The first decision is a bet on future computing capability. Quantum computers may eventually solve design and optimisation problems that classical high-performance computing cannot solve at all: battery electrolyte chemistry, high-temperature alloy behaviour, combustion in a new engine geometry. The size of that payoff is unknown and so is its date. Nobody can give you either honestly.

The second decision is a maintenance obligation with dates already attached. The public-key cryptography protecting design data, flight and vehicle telemetry, supplier links, and above all software update signatures rests on mathematics that a large enough quantum computer would break. In August 2024, NIST published three replacement standards: FIPS 203 defines ML-KEM, a key encapsulation mechanism, which is the method two parties use to agree a shared secret over an open channel; FIPS 204 and FIPS 205 define ML-DSA and SLH-DSA, two digital signature algorithms, which prove a message or a firmware image came from who it claims and has not been altered. A fourth signature scheme, FN-DSA, has been announced but isn’t final yet.

The two decisions need different budgets, different reporting lines, and different people. The compute bet is research and development, measured in learning. The cryptographic migration is engineering and compliance, measured against a schedule. A proof-of-concept press release about battery simulation tells a board nothing about whether the 2031 model year can verify a post-quantum firmware signature, and we have sat in meetings where it was offered as if it did.

The Compute Bet, Honestly

Start with the state of the hardware, because most vendor material skips it.

Today’s machines are what the field calls NISQ, for noisy intermediate-scale quantum: tens to hundreds of qubits, with error rates high enough that a calculation degrades before a useful-sized problem finishes running. The fix is error correction, which bundles many physical qubits into one logical qubit that behaves reliably. A physical qubit is the hardware device. A logical qubit is the corrected abstraction built on top of it, and published estimates of how many physical qubits each one costs run from the hundreds into the thousands, depending on the hardware and the correcting code. Machines with enough logical qubits to run industrial chemistry end to end don’t exist yet.

The honest summary for a board: no published result has shown a quantum computer beating the best available classical method on a production-scale aerospace or automotive problem. Every credible pilot to date has been a small instance, run alongside a classical baseline, to see how the methods compare. That is a reasonable thing to be doing. It is not a capability you can put on a product roadmap.

Simulation and materials

This is the most physically motivated case, and the one we would fund first. Simulating a quantum system is what a quantum computer does natively, so molecular and materials modelling is the application with the clearest theoretical footing. Ford has worked with Quantinuum on lithium-ion battery chemistry. Hyundai and IonQ have run simulations aimed at battery electrolytes and catalysts. Germany’s DLR has commissioned materials work with Planqc and d-fine, targeting lighter alloys and longer-lived components for both aircraft and vehicles. Airbus has pointed at hydrogen fuel cell chemistry as a problem classical software models poorly.

The constraint is size. The molecular systems reachable on current hardware are small, and classical quantum chemistry hasn’t stood still. Density functional theory, coupled-cluster methods, and machine-learned interatomic potentials keep extending what a well-run HPC cluster can do. Your quantum pilot is racing a moving classical baseline, and your own computational chemists should be the ones holding the stopwatch.

Optimisation

This is the most oversold. Volkswagen ran a widely reported trial with D-Wave in Lisbon in 2019, routing shuttle buses around congestion. BMW has piloted robot path planning on the factory floor with Amazon Web Services, and has worked with Pasqal on solving the partial differential equations behind metal forming. Airbus and BMW together launched the Quantum Mobility Quest, an open challenge covering aerodynamic design, supply chain, and automated driving.

Here is the pattern we see reported back from teams who ran these pilots, and it is worth planning for. Quantum annealing and variational optimisation results have generally been matched or beaten by good classical solvers on the same problem. What the pilots produced instead was a clean formalisation: an explicit objective function, a real constraint list, and a data pipeline that had never previously been written down. The classical solver then used all three and did better than the process the plant had before. That is a genuine return. Charge it to process engineering, not to quantum.

Machine learning and perception

Hyundai and IonQ have applied quantum machine learning to image classification, framed around how an autonomous vehicle recognises road features. The published work operates on very small image sets. There is no demonstrated advantage over classical vision models, which are the most heavily optimised software artefacts in the industry. We would not fund this ahead of the other two.

What the bet actually buys

Option value and fluency. A company running two or three small pilots a year develops people who can read a vendor claim, ask what the classical baseline was, and recognise a real result the quarter it appears rather than eighteen months later. Cloud access to quantum hardware is inexpensive next to a wind tunnel campaign or a single crash test series. The real cost is engineer time, so the budget question is how many people you can spare, not how many qubits you can rent.

The Cryptographic Decision

The threat has a name that describes the mechanism: harvest now, decrypt later, or HNDL. An adversary copies encrypted traffic or stolen design files today, stores them, and decrypts them once a capable quantum computer exists. The data doesn’t need to be readable now to be worth taking now. For a programme whose design data stays commercially sensitive for 20 years and whose classified variants stay sensitive longer, the exposure window is already open.

That much applies to every industry. Two things make aerospace and automotive harder than most.

Signatures Bind Harder Than Encryption

Encryption is comparatively forgiving. When two systems negotiate a session, they can negotiate a new algorithm, and next year’s handshake can use ML-KEM even though last year’s did not. Signature verification is the opposite. A vehicle’s secure boot process and its hardware security module, the tamper-resistant chip that stores keys and performs cryptographic operations, verify firmware against a public key and an algorithm fixed at manufacture. If a control unit can’t verify ML-DSA, then no over-the-air update for that vehicle can carry an ML-DSA signature, for the life of the vehicle. Aviation has the same structure with more paperwork: loadable software parts are signed, and the security process for airborne systems is governed by DO-326A, the Airworthiness Security Process Specification, and its European equivalent ED-202A.

Size makes it physical rather than merely procedural. ML-DSA-44 produces a signature of roughly 2,420 bytes and a public key of roughly 1,312 bytes. ML-KEM-768 uses a public key of about 1,184 bytes and a ciphertext of about 1,088. Compare that with the classical signatures they replace, which are a few dozen to a few hundred bytes, and with a CAN FD frame, which carries at most 64 bytes of payload. A post-quantum signature has to be fragmented across dozens of frames, buffered in a control unit with kilobytes of RAM, and verified within a boot-time budget somebody already committed to. These are not cryptography problems. They are embedded engineering problems, and they are solved at design time or not at all.

The Supplier Problem

Neither industry builds most of its own cryptography. It arrives inside tier-one and tier-two components, inside telematics modules, inside avionics line-replaceable units, inside the plant’s operational technology. The manufacturer carries the regulatory obligation and the supplier holds the algorithm.

The instrument for this is a cryptographic bill of materials, or CBOM: an inventory of every algorithm, key, certificate, protocol, and library across the product, the supply chain, and the factory network, with an owner and a replacement path recorded for each. Building one is unglamorous and slow. Skipping it means discovering in 2029 that a safety-relevant module from a supplier who has since exited the business hard-codes an algorithm you need to retire. Aerospace adds certification drag on top: changing a signature algorithm inside a certified system is a change to a certified system, with the evidence burden that implies.

The migration methodology for this work is covered in depth at pqcframework.org, and the underlying cryptographic detail at PostQuantum.com.

Telling a Programme From a Press Release

Six questions separate work that will still make sense in three years from work that won’t. We teach variants of all six.

Which problem, at what size, against which baseline? A pilot without a stated problem size and a named classical comparison is a demonstration, not an experiment.

Who ran the baseline? If the vendor ran both sides, the result is marketing. Your own HPC or computational chemistry team runs the classical side.

What result would make you stop? Every pilot should carry a stopping condition written before it starts. Programmes without one run for years on momentum.

Where does the data go? Quantum hardware is reached through cloud services. For aerospace, that intersects export control immediately, and for both sectors it intersects design-data confidentiality. Answer this before the first job is submitted.

Do you have an inventory, and does it cover your suppliers? For the migration track, this is the only question that predicts whether the programme is real.

Who owns the output? Joint pilots with quantum startups produce algorithms and know-how. Settle the intellectual property in the contract, not in the retrospective.

Staffing the Two Decisions Differently

The compute bet needs depth in a small group: a handful of people who can read the algorithms literature, formulate a plant or design problem in a form quantum hardware accepts, and hold a classical baseline honestly. That group can stay small even at a large manufacturer. Some of them should be domain experts you already employ rather than physicists you hire.

The migration needs breadth, and the two are not the same order of effort. Security architects have to redesign key hierarchies. Embedded engineers have to fit new signature sizes into existing control units. Procurement has to write cryptographic requirements into supplier contracts and then assess the answers. Programme managers have to sequence the work against model-year and type-certification gates. Compliance has to map it all to R155, R156, and the applicable airworthiness security process. At a large manufacturer that is a cross-functional effort spanning several departments, and most of the people in it need working literacy rather than specialisation.

This asymmetry is where training budgets get misallocated. We regularly see organisations send two people to a deep quantum computing course and leave the procurement team, who will write the clauses that bind suppliers for a decade, with nothing. The deep course is the smaller need.

Where to Start

Four things are worth doing in the next 12 months, in this order.

1. Separate the two budgets and the two owners. One line for research pilots, reporting into engineering or advanced development. One line for cryptographic migration, reporting wherever product security already reports. Do not let either be used as evidence of progress on the other.
2. Start the cryptographic inventory with the software update chain. Signature verification in the field is the hardest thing to change later, so map it first: which control units, which algorithms, which keys, which of them can be updated in the field, and which cannot.
3. Put cryptographic agility into supplier requirements now. Every component specification written this year outlives this year. Ask suppliers what algorithms their parts implement and how those algorithms get replaced.
4. Build literacy at the width the migration needs, not just the depth the pilots need.

Quantum Academy’s certification programmes are built around those two populations: focused technical work for the small group running compute pilots, and broader migration and governance training for the engineers, architects, procurement leads, and programme managers who carry the cryptographic schedule. The current catalogue is at quantumacademy.com/. For individuals mapping where these skills lead, QuantumCareers.com covers the role paths in more detail.

The compute bet may pay off this decade or the next. The migration is on a calendar your regulators, your suppliers, and your own product lifetimes have already set.