M&A | Quantum Computing

US Quantum Computing M&A: Acquiring Hardware Modality or Customer Access

Separate modality value from customer access and price technical uncertainty through falsifiable diligence and milestone-based consideration.

Four quantum-computing hardware modalities connect through a transaction gateway to enterprise, cloud, research and government access nodes.
Quick answer

Separate quantum hardware-modality value from transferable customer access, then structure technical diligence, valuation, consideration and integration around evidence that survives closing.

Abstract

Quantum-computing acquisitions are often presented as purchases of a superior hardware modality or a faster route to customers. Those labels are incomplete. A hardware company combines scientific claims, fabrication and control systems, error-correction progress, specialist talent, cloud distribution, public-sector eligibility, application partnerships and customer evidence. The buyer must determine which capability is scarce, which capability survives a change of control and which capability can create cash flow before the target's roadmap consumes the acquisition budget. This paper develops an evidence-led M&A framework for United States quantum-computing transactions. It compares superconducting, trapped-ion, neutral-atom and photonic approaches through the deal questions they create rather than through a single qubit-count ranking. It then separates modality value from customer-access value, maps technical milestones to commercial proof, tests intellectual-property and talent dependency, and integrates antitrust, export-control, foreign-investment, government-contract and data-rights considerations into valuation and transaction design. The evidence includes United States quantum policy, federal research programmes, export controls introduced for quantum-computing items, federal acquisition rules, cloud-platform documentation, company roadmaps and public securities filings. IonQ's 2025 acquisition of Oxford Ionics provides a disclosed example of a buyer combining an established customer and platform position with complementary trapped-ion technology. The filing evidence also shows why deal value cannot be inferred from announcement value alone: acquisition accounting later recorded a substantially different total consideration, and the acquired business had immaterial post-close revenue in the reported period. A wholly hypothetical transaction illustrates the method. A listed US quantum platform considers acquiring a private hardware company for USD 620 million. Management attributes USD 260 million to modality-specific technology and patents, USD 150 million to specialist teams and know-how, USD 110 million to customer and channel access, USD 60 million to government-program eligibility and USD 40 million to other net assets and option value. It proposes USD 360 million at closing, USD 140 million in milestone shares, USD 70 million in retention instruments and USD 50 million in customer-conversion payments. These amounts are management assumptions for analytical purposes; they are not observed deal terms or market forecasts. The central conclusion is that a quantum acquisition should buy an evidenced capability system. Modality can be valuable when it changes the buyer's fault-tolerance path, manufacturability, control architecture or application reach. Customer access can be valuable when contracts, data rights, security eligibility, cloud placement, technical support and renewal economics transfer with the target. A disciplined buyer values each component separately, prices uncertainty through milestones and holdbacks, and approves integration only when the combined roadmap has one accountable technical and commercial owner.

JEL Classification: G34, L22, L86, O32, O33, O38

Keywords: quantum computing, mergers and acquisitions, superconducting qubits, trapped ions, neutral atoms, photonic quantum computing, customer access, federal contracts, valuation, technology diligence

This Matchpoint Insight presents the web edition of Matchpoint Partners' research. The supporting paper contains the full framework, structures, worked examples and source material.

Register Before Download   Explore our M&A practice

Introduction

Quantum computing remains a field of competing technical paths, rapid scientific progress and limited commercial proof. Buyers can face a target with exceptional gate fidelity but no repeatable deployment model, a cloud-distributed processor with low customer concentration but uncertain differentiation, or a government contractor whose awards depend on key personnel, security controls and rights in technical data. Conventional software metrics do not describe those assets adequately. Hardware specifications alone also fail to answer the transaction question.

The practical decision is whether the acquisition changes the buyer's probability of reaching useful computation and monetising it. That probability depends on the interaction of modality, engineering system, error correction, manufacturing, software, applications, route to market, contracts, talent, capital and regulatory permissions. The interaction may create value, or it may combine two expensive roadmaps without resolving either party's bottleneck.

This paper treats modality and customer access as separate value pools that must be reconciled. It does not rank one quantum architecture as universally superior. It provides a diligence and structuring method for boards, corporate-development teams, investors and technical advisers evaluating US quantum-computing transactions.

1 Define the acquisition decision

The board should state the constraint the transaction is intended to remove. A buyer may need higher-fidelity operations, a manufacturable control architecture, an error-correction capability, a specialised team, access to a federal programme, a cloud channel, a customer application portfolio or a credible path into another geography. Each objective requires different evidence and produces a different integration plan.

The decision statement should identify the expected capability after closing and the counterfactual. Management should compare acquisition with internal development, partnership, minority investment, licensing, cloud distribution and targeted hiring. The comparison should include time, capital, execution risk, exclusivity and reversibility. An acquisition can accelerate a roadmap, yet it can also lock the buyer into an architecture before technical uncertainty has resolved.

The board should avoid using market growth projections as a substitute for transaction logic. The decision should rest on a measurable change in capability, customer access or strategic position. The transaction case should specify the evidence that would disprove the thesis before signing and the milestones that will test it after closing.

2 Separate modality value from access value

Modality value arises from the physical and engineering path by which the target creates, controls, connects and reads qubits. It includes device architecture, fidelity, connectivity, coherence, gate speed, control electronics, cryogenic or optical systems, fabrication, calibration, error correction, software integration and the ability to reproduce performance. It may also include patents and tacit know-how that are difficult to transfer.

Customer-access value arises from the target's ability to reach, qualify, contract with and support users. It includes cloud listings, direct reservations, government vehicles, security eligibility, application partnerships, workflow integration, data rights, technical-support teams, renewals and customer trust. Access should be evidenced by transferable rights and behaviour rather than by a logo list or memorandum of understanding.

The two value pools interact. A strong modality can make a route to market more valuable. A strong customer base can provide workloads and feedback that improve hardware. The buyer should still model them separately so that one attractive narrative does not conceal weakness in the other.

3 Compare modalities through transaction requirements

Superconducting systems use fabricated electrical circuits at cryogenic temperatures and can support fast gate operations and semiconductor-style process learning. They can require complex cryogenic, packaging, calibration and interconnect systems. Trapped-ion systems use atomic ions controlled through electromagnetic and optical techniques, often with high-fidelity operations and flexible connectivity, while facing engineering questions around speed, optical control and scale.

Neutral-atom systems arrange atoms with lasers and can offer large, reconfigurable arrays and application-specific analogue operation. Their path to universal fault-tolerant computation depends on control, gate, error-correction and continuous-operation progress. Photonic approaches use light and integrated optical components, with potential manufacturing and networking advantages alongside demanding source, detector, loss, switching and system-integration requirements.

The transaction comparison should connect each modality to the target's actual product and evidence. Public roadmaps and demonstrations describe direction; they do not guarantee reproducibility, scale, cost or commercial timing. The buyer should compare the acquired system against the buyer's intended workloads, manufacturing base, cloud model and capital plan.

4 Build a capability map rather than a qubit league table

A qubit count can describe system size without describing useful performance. The buyer should map physical qubits, logical qubits, gate fidelity, connectivity, circuit depth, error-detection and correction, uptime, calibration burden, job throughput, latency, software compatibility and workload results. Each measure should state test conditions, date, version and independent verification.

The map should distinguish scientific demonstration, engineering prototype, available product and contracted service. A result obtained on a selected device under laboratory conditions may be strategically important. Its transaction value depends on whether the target can reproduce it across devices, maintain it over time and expose it through an operable service.

Cross-modality comparison requires caution because native operations, compilation, analogue versus gate models and performance metrics differ. The buyer should use workload-level tests and resource estimates where possible. A conclusion should explain the trade-off rather than compress unlike systems into a single score.

5 Test the path to fault tolerance

Fault tolerance is a programme of architecture, codes, logical operations, decoding, control, fabrication and system engineering. The target should show how physical performance converts into logical capability, which error model applies, what overhead is expected and which milestones have been demonstrated. The buyer should examine the assumptions behind resource estimates and the sensitivity to fabrication yield, loss, crosstalk, control error and decoder performance.

Company roadmaps can support diligence when reconciled with published results, internal test data and engineering plans. Google's Willow announcement emphasised below-threshold error correction on increasing surface-code arrays. IBM's roadmap describes fault-tolerant modules and a longer-term system path. QuEra's roadmap emphasises neutral-atom error-correction demonstrations and continuous operation. Those statements concern different architectures and milestones.

The transaction model should value achieved evidence separately from future milestones. A large portion of modality value may depend on a fault-tolerance claim that remains unproven at the required scale. Contingent consideration can align payment with independently defined demonstrations.

6 Diligence the full hardware stack

The target's moat may sit outside the qubit device. Control electronics, lasers, cryogenics, vacuum systems, packaging, photonics, calibration software, firmware, compilers, test methods and manufacturing recipes can determine performance and cost. The diligence team should identify each critical component, its owner, supplier, replacement time and qualification status.

The buyer should request a system bill of materials and dependency graph. It should identify single-source items, export-controlled components, custom tooling, university licences, foundry agreements and long-lead equipment. Supply agreements should be reviewed for change-of-control rights, volume commitments, price resets, exclusivity and access to failure analysis.

Capital expenditure should be linked to roadmap milestones. A target may need a new fabrication line, cleanroom, cryogenic facility or optical assembly capability before it can deliver the forecast system. The purchase price and integration budget should include that requirement rather than treating it as ordinary post-close growth investment.

7 Verify reproducibility and manufacturing evidence

The buyer should distinguish one high-performing device from a repeatable process. Evidence can include yield, variation, calibration time, failure modes, component life, rework, acceptance testing and performance distribution across systems. The diligence sample should cover multiple devices and production periods where available.

Manufacturing plans should identify which steps are internal, outsourced or shared with research institutions. Intellectual property may protect device design while manufacturing know-how remains concentrated in a small team. The buyer should assess whether process records, tooling, supplier relationships and quality systems can survive staff turnover or a site disruption.

Reproducibility can be made a closing or payment condition. An independent team can build or qualify a device using controlled documentation. The test should protect sensitive technology while demonstrating that the acquired capability is organisational rather than personal.

8 Diligence intellectual property by dependency

Patent counts do not show freedom to operate, enforceability or operational importance. The buyer should map patents, applications, trade secrets, copyrights, licences and know-how to the product architecture and roadmap. It should identify inventors, assignees, prosecution status, geographic scope, government support, university rights and encumbrances.

The map should show which claims protect the current system and which address future architectures. It should also identify design-around risk and blocking rights held by others. Where the moat depends on trade secrets, the buyer should examine access controls, employee agreements, laboratory records and the extent to which knowledge is documented.

Government-funded and university-originated work may carry licence, reporting, march-in or data-rights considerations depending on the instrument. Qualified counsel should confirm the applicable rights. The transaction should not value an asset as exclusive until ownership and third-party rights are clear.

9 Assess talent as a technical system

Quantum hardware companies can depend on a small number of physicists, device engineers, control specialists and application leaders. The buyer should identify who owns each critical decision, relationship and undocumented method. An organisation chart should be supplemented by a capability and succession map.

Retention design should reflect the work required after closing. Founders may be essential for architecture, but senior engineers, technicians, programme managers and customer scientists can carry equally important knowledge. Retention instruments should use service, transfer and milestone conditions that are achievable and consistent with employment law.

The buyer should evaluate cultural and scientific governance. A large corporate process can improve quality and scale while slowing experimentation. Integration should preserve protected research paths with accountable milestones, peer review and access to shared engineering resources.

10 Define customer access precisely

Customer access can mean a signed contract, cloud listing, reservation, funded research award, pilot, application partnership, reseller arrangement or informal relationship. Each category has different economics and transferability. The buyer should classify the portfolio and avoid treating all named counterparties as revenue customers.

For each material relationship, diligence should cover legal counterparty, product, term, committed and optional value, cancellation, acceptance, pricing, renewal, data rights, intellectual property, exclusivity, security, change of control and required personnel. Usage data should show jobs, reservations, support demand and movement from experimentation toward recurring workloads.

Customer access is valuable when it shortens the buyer's path to paid, repeatable use. A relationship that depends on the target's independent status, founder or modality may weaken after acquisition. The buyer should validate transfer through contract language and customer conversations conducted under an approved process.

11 Separate cloud distribution from customer ownership

Cloud platforms broaden access and reduce the need for customers to procure each provider directly. Amazon Braket documents access to trapped-ion, superconducting and neutral-atom systems, with task, shot and reservation economics. Azure Quantum has also provided access to multiple hardware providers. These channels can create discoverability, workflow integration and billing infrastructure.

A listing does not by itself create a defensible customer asset. The platform may control the billing relationship, usage data, placement and commercial terms. Customers can compare or switch providers. The target's value depends on contractual rights, differentiated performance, support relationships and the ability to convert platform usage into durable demand.

The buyer should map who owns customer identity, workload metadata, application code, results and support records. It should test whether the acquisition creates a conflict with a platform or other hardware participants. Channel continuity and equal-treatment provisions can matter to valuation.

12 Evaluate government and national-laboratory access

United States quantum programmes involve the Department of Energy, National Science Foundation, Department of Defense, NIST, intelligence organisations and national laboratories. A target may hold research awards, prototype agreements, subcontracts, cooperative agreements or facility access. Each instrument creates distinct rights and obligations.

Government contracts can include termination rights, funding contingencies, security requirements, cost rules, audit, domestic sourcing and rights in data or software. Federal Acquisition Regulation Part 35 addresses research and development contracting, while Part 27 addresses patents, data and copyrights. The contract schedule should state the instrument, funding status, deliverables, data rights, intellectual-property provisions and change-of-control requirements.

Eligibility can depend on personnel, facilities, cybersecurity and ownership. The buyer should confirm whether the combined entity can continue performance, access sites and protect controlled information. Revenue should be valued with the relevant option, cancellation and appropriation risks.

13 Map federal data and software rights

Government-funded work can create value and restrictions simultaneously. Technical data, software, reports, interfaces and test results may be delivered with unlimited, limited, restricted or negotiated rights depending on contract terms and funding. The target may own intellectual property while the Government holds broad use rights.

The diligence team should trace each deliverable to its funding source and clause. It should examine markings, repositories, subcontractor flow-downs and whether the company has preserved restrictions correctly. Missing markings or inconsistent records can weaken the assumed exclusivity of an asset.

The buyer should also identify data needed for future competition, maintenance or reprocurement. A government customer's rights may facilitate alternative suppliers. This does not eliminate value; it changes the durability and pricing of customer access.

14 Analyse revenue quality and concentration

Quantum revenue can include hardware sales, cloud usage, reservations, consulting, development contracts, grants and milestone awards. The buyer should separate each stream by margin, cash conversion, recurrence, cancellation and technical dependency. Reported growth can be driven by a small number of awards or acquisitions.

IonQ's 2025 annual filing describes customer concentration, long sales cycles and government-contract risks. It also records significant continuing losses and acquisition activity. Those disclosures illustrate the need to value revenue with its cost and risk rather than applying a mature software multiple.

The buyer should build customer cohorts and contract waterfalls. It should identify how much revenue depends on one agency, platform, research partner or application team. Concentration can be acceptable when the relationship creates technical learning and renewal evidence; it should still be reflected in scenario analysis and liquidity planning.

15 Test application evidence and willingness to pay

The transaction thesis should name the workloads that the combined system is expected to serve. Chemistry, materials, optimisation, machine learning and security are broad categories. The buyer should identify the problem instance, classical baseline, quantum resource requirement, accuracy, total workflow cost and decision value.

Scientific advantage, computational advantage and commercial value are separate tests. A benchmark can show performance beyond a classical method under defined conditions without establishing a paid workflow. An application pilot can show customer interest without establishing scalability or renewal.

Customer diligence should ask what decision changed, what classical method was displaced or complemented, which budget funded the work and what evidence would support expansion. Willingness to pay should be based on contracts and observed behaviour where available. Future application value should remain a scenario until supported.

16 Build the regulatory perimeter

US quantum-computing transactions can involve antitrust, export control, sanctions, foreign-investment review, government contracting, data security and sector-specific obligations. The perimeter depends on parties, technology, ownership, customers, locations and information access. Counsel should confirm current requirements for the specific transaction.

The Bureau of Industry and Security introduced controls in 2024 covering specified quantum computers and related equipment, components, materials, software and technology. Classification affects diligence access, integration teams, cross-border collaboration, cloud environments and future sales. The transaction timetable should include classification and licensing work rather than treating export control as a post-signing detail.

Foreign investors and cross-border buyers should assess CFIUS implications, including whether the business involves critical technologies and whether a mandatory declaration or voluntary filing is appropriate. The structure should protect sensitive technology without preventing the combined organisation from operating.

17 Evaluate antitrust and route-to-market foreclosure

The DOJ and FTC Merger Guidelines address transactions that may limit rivals' access to products, services or routes to market and transactions involving multi-sided platforms. A quantum acquisition may combine a hardware provider with a cloud, software, application or customer-access platform. The relevant question can extend beyond direct hardware competition.

The buyer should map competitors, customers, suppliers, platforms and complementors. It should identify whether the combined firm could restrict access to a scarce control technology, fabrication capability, cloud channel, benchmark data or customer programme. It should also consider access to rivals' competitively sensitive information.

Remedies and operating commitments should be considered early when the deal depends on an open ecosystem. Interoperability, information barriers, non-discrimination and supply commitments can preserve route-to-market value while addressing risk. The board should understand how any remedy affects the acquisition thesis.

18 Design technical diligence around falsifiable tests

Technical diligence should begin with management's most consequential claims. Each claim should have a test, dataset, version, owner, acceptance threshold and failure implication. Examples include a reproducible fidelity level, logical-error trend, calibration time, job throughput, manufacturing yield or workload result.

The buyer should use independent experts who can evaluate the modality without disclosing restricted information improperly. Clean-room or staged access may be necessary. The diligence report should state what was observed, what was reproduced, what was reviewed only as documentation and what could not be verified.

Claims that cannot be tested before signing can move into transaction mechanics. Holdbacks, milestones, access rights and termination provisions can allocate the uncertainty. A generic warranty that all technology works as intended provides limited protection against roadmap risk.

19 Construct a modality-adjusted valuation

Valuation should separate achieved assets from roadmap options. Achieved value can include functioning systems, patents, software, contracts, qualified facilities and reproducible know-how. Option value can include future fault-tolerance milestones, manufacturing scale, application breakthroughs and new markets. The discount rate or probability should reflect technical and commercial dependencies.

The model can use cost, income and market evidence selectively. Replacement cost may support specialised facilities and documented development, although it does not measure the probability of success. Income analysis can support contracts and customer relationships when cash flows are identifiable. Market transactions require careful normalisation because consideration, stage, modality and strategic context differ.

The board should see a value bridge by capability. A single enterprise value can conceal whether management is paying for technology, talent, channel, contracts, strategic defence or market signalling. Each component should have evidence and a post-close owner.

20 Use milestone-based consideration

Quantum roadmaps create a strong case for contingent consideration when milestones are objective, material and controllable. Technical milestones can include independently reproduced performance, a logical-qubit demonstration, manufacturing yield, continuous operation, system delivery or acceptance. Commercial milestones can include funded awards, customer conversion, renewals or gross-margin thresholds.

The agreement should define the test environment, responsible evaluator, permitted changes, data access, timing, dispute process and treatment after integration. A milestone should not depend entirely on the buyer's discretionary resource allocation. Sellers should have visibility into the work needed to achieve it.

Consideration can combine closing payment, milestone shares, retention instruments and customer-conversion payments. The allocation should distinguish purchase price from compensation and consider accounting and tax consequences. Qualified advisers should confirm the treatment.

21 Protect the roadmap through integration governance

The combined company needs one accountable roadmap. Modality teams may retain distinct research programmes, but shared capital, customers and engineering dependencies require explicit governance. The integration plan should identify which architecture remains primary, which capabilities are experimental and which decisions require board review.

A technical integration council can reconcile hardware, control, software, error correction, manufacturing and application priorities. It should own interfaces, resource conflicts and milestone evidence. Commercial teams should not promise capabilities outside the approved roadmap.

Integration should preserve useful scientific independence while removing duplicated corporate functions deliberately. Early consolidation of laboratories, toolchains or supplier relationships can destroy evidence and slow development. Sequencing should follow technical dependencies.

22 Retain customers during the change of control

The buyer should communicate the combined product, support model and data treatment before uncertainty drives customers to alternatives. Material customers may require consent, security review or revised ordering arrangements. Government counterparties may require notification or novation depending on the instrument.

The retention plan should identify customer owner, workload, contract status, technical dependency, change-of-control requirement, next decision and risk. It should protect continuity of cloud access, reservations, support and application teams. Pricing changes should follow evidence of improved capability rather than the announcement alone.

Customer conversion payments can align deal value with retained and expanded business. The metric should use collected or contractually committed value, defined margin and a clear attribution period. Pilots and non-binding collaborations should not receive the same treatment as recurring paid workloads.

23 Govern security and controlled information

Quantum companies can hold controlled technology, government information, customer data, source code, fabrication records and sensitive research. The integration perimeter should classify repositories, identities, laboratories, devices and collaboration tools before broad access is granted.

The buyer should preserve least privilege, export-control restrictions, contractual access limits and incident evidence. Employees and contractors should be mapped by nationality, location, role and authorisation where legally relevant. Sensitive diligence material should not migrate automatically into ordinary integration systems.

The Day One plan should define security authority, incident escalation, key custody, logging and continuity. A transaction can create risk if two strong control environments are connected without a common design. Security integration should follow a documented architecture and regulatory advice.

24 Build the capital and liquidity plan

Purchase price is one part of the capital requirement. The buyer may need to fund facilities, equipment, foundry commitments, component inventory, research programmes, retention, customer support and operating losses. The integrated model should show liquidity under technical delay and customer-conversion scenarios.

Equity can absorb roadmap risk. Debt may suit predictable assets or contracted cash flows when covenants recognise development volatility. Government awards and customer prepayments can support milestones, subject to restrictions and performance obligations. The financing mix should not force a premature technical claim to satisfy a near-term covenant.

The board should approve an acquisition reserve for technical and commercial remediation. It should identify conditions that trigger capital reallocation, partnership or programme closure. Strategic importance does not remove the need for portfolio discipline.

25 Define the first 100 days

The first 100 days should protect evidence, people, customers and roadmap accountability. Day One priorities include security, permissions, payroll, customer continuity, laboratory safety, supplier access and decision rights. The integration team should freeze destructive system changes until baselines are captured.

By Day 30, the company should reconcile the capability map, contracts, intellectual property, controlled information and capital plan. By Day 60, it should approve the combined roadmap, customer ownership and supplier actions. By Day 100, it should publish an internal milestone baseline with accountable owners and board reporting.

The plan should include explicit non-actions. Facilities, code repositories, brands and research programmes may remain separate until evidence supports consolidation. Delay can be a controlled decision when it preserves technical value.

26 Monitor value through a deal dashboard

The board dashboard should connect technical, commercial and financial evidence. Measures can include independently verified performance, system availability, job throughput, manufacturing yield, roadmap spend, critical retention, contract value, customer conversion, gross margin, government eligibility and integration risk.

Each measure should state baseline, target, owner, source and decision threshold. Metrics should remain comparable across periods and system versions. A technical improvement that increases cost or reduces availability should be visible as a trade-off.

The dashboard should separate observed results from management forecasts. It should also show milestone consideration and liquidity exposure. The purpose is to support capital allocation and intervention rather than to present a favourable narrative.

27 Prepare downside and exit paths

The buyer should plan for technical delay, modality reprioritisation, customer loss, regulatory restrictions and key-person departure. The downside plan can include licence structures, asset sales, team carve-outs, partnerships, research discontinuation and preservation of transferable intellectual property.

Transaction documents should secure access to records, source, tooling, suppliers and personnel needed to maintain acquired assets. Contingent consideration should adjust when milestones fail for defined reasons. Retention packages should avoid trapping capital in a programme that the board has rationally discontinued.

Exit value depends on clean ownership and separability. The integration design should record which assets and contracts belong to each programme. Excessive technical entanglement can make a future sale or partnership difficult.

28 Set the board decision agenda

The board should ask whether the deal removes a defined constraint, whether the target's capability has been reproduced, whether customer access transfers, whether regulatory paths are viable and whether the combined roadmap can be funded. It should understand the portion of value attributable to achieved evidence and the portion dependent on future milestones.

Approval conditions should include technical tests, intellectual-property confirmation, material contract consents, regulatory analysis, retention, security controls and a funded integration plan. The decision record should identify unresolved matters and the mechanism that prices or controls each one.

The final question is accountability. One executive should own the combined technical roadmap, one executive should own customer conversion and one board process should reconcile capital with evidence. Without that alignment, the acquisition can increase optionality while reducing the probability of execution.

Conclusion

A US quantum-computing acquisition should be valued as a system of evidenced capabilities. Hardware modality matters when it changes the buyer's path to useful, reproducible and scalable computation. Customer access matters when contracts, channels, security eligibility, data rights and support relationships survive closing and convert into paid work.

The transaction should separate those value pools, test their dependencies and connect consideration to milestones. Technical diligence should be falsifiable. Customer diligence should distinguish access from ownership. Regulatory diligence should shape information access, structure and timetable. Integration should preserve scientific value while establishing one roadmap and one capital-allocation process.

Boards can then make a disciplined choice among acquisition, partnership and internal development. The goal is a combined company with a higher probability of technical and commercial success, supported by evidence that can be reviewed after the announcement.

Appendix A Modality acquisition test

The modality test asks whether the target changes the buyer's fault-tolerance path, system performance, manufacturability, control architecture, application reach or time to an independently verified milestone. Each claimed change should identify evidence, dependency, capital requirement and responsible team.

The test should compare the target with an internal or partnered alternative. It should state which assets are transferable and which depend on individuals, suppliers, universities or government permissions. A result that cannot be reproduced should remain contingent value.

The test should be repeated after material changes in roadmap, regulation, supply chain or technical evidence.

Appendix B Customer-access test

The access test asks whether the target holds a transferable contract, platform right, security eligibility, application workflow or trusted support relationship. It should identify who controls customer identity, data, billing, renewal and technical support.

Each relationship should be classified as paid recurring work, committed project, funded research, pilot, platform usage, partnership or prospect. Value should reflect cancellation, concentration, change-of-control and key-person risk.

The test should use customer confirmation and observed usage where available. Future demand should remain a scenario until supported by commitment or collected revenue.

Appendix C Quantum M&A data room

The data room can contain architecture, performance evidence, test protocols, device history, error-correction plans, manufacturing records, bills of materials, supplier agreements, software repositories, patent schedules, invention records, university and government rights, employee agreements, customer contracts, cloud arrangements, security documentation and financial models.

Restricted technical material should use a controlled review process. The diligence report should record information that could not be reviewed and the resulting decision limitation. Missing evidence should become a condition, holdback or milestone.

The final data room should support integration and future financing. Records required to reproduce claims, operate systems and evidence rights should move into controlled repositories with named owners.

Appendix D Decision figures and tables

Figure 1. Acquisition-thesis decision tree
Figure 1. Acquisition-thesis decision tree
Proposed sequence for separating modality, access and integration value.
Figure 2. Hypothetical capability value allocation
Figure 2. Hypothetical capability value allocation
Wholly hypothetical management assumptions; USD million.
Figure 3. Illustrative modality diligence profile
Figure 3. Illustrative modality diligence profile
Proposed scoring framework; scores are management assumptions, not comparative performance claims.
Figure 4. Hypothetical consideration release
Figure 4. Hypothetical consideration release
Wholly hypothetical transaction structure; USD million.
Figure 5. Proposed 100-day integration sequence
Figure 5. Proposed 100-day integration sequence
Sequencing should preserve technical evidence and customer continuity.
Table 1. Modality diligence matrix
AreaSuperconductingTrapped ionNeutral atomPhotonic
Core engineeringCryogenics, fabrication, packaging and calibrationTraps, lasers, optics and controlAtom arrays, lasers, control and continuous operationSources, detectors, loss, switching and integration
Scale questionYield, wiring, interconnect and error correctionOptical control, speed, modularity and manufactureGate quality, universal operation and correctionComponent loss, fusion, feed-forward and manufacture
Deal evidenceMulti-device performance and process controlReproducible fidelity and scalable controlRepeated arrays, gates and logical evidenceManufacturable components and end-to-end loss budget
Integration riskFacility and stack duplicationSpecialist-team and optical-system dependencyRoadmap and application-model transitionSupply chain and system-assembly dependency

Proposed transaction questions; no modality is universally preferred.

Table 2. Acquisition-thesis evidence
ThesisRequired evidencePrincipal dependencyTransaction treatment
Acquire modalityReproduced performance and manufacturable roadmapTechnical team, suppliers and facilitiesMilestone consideration and retention
Acquire customer accessTransferable contracts, usage and renewal evidenceChannel control and key relationshipsConsent conditions and conversion payments
Acquire government positionEligible entity, funded instruments and data-rights mapSecurity, appropriations and personnelRegulatory condition and contract-by-contract review
Acquire strategic optionDefensible IP and funded experiment planFuture technical and market evidenceLimited upfront value and staged capital

Proposed minimum evidence by thesis.

Table 3. Customer-access quality ladder
Access typeEvidenceValue supportMain risk
Recurring paid workloadContract, usage, invoices and renewalCohort cash flow and marginConcentration and switching
Committed projectExecuted scope, funding and acceptanceContracted backlogCancellation and delivery
Funded researchAward, milestones and data rightsFunded learning and option valueRights, budget and non-recurrence
Cloud-platform usagePlatform records and support activityObserved demand and discoverabilityPlatform control and low switching cost
Pilot or collaborationDefined work and decision gateEvidence of interestNo commitment or budget

Proposed classification for valuation and integration.

Table 4. Hypothetical valuation allocation
Value componentIllustrative amountEvidence gateDownside treatment
Modality technology and patentsUSD 260 millionReproduced system tests and rights confirmationMilestone shares and holdback
Talent and know-howUSD 150 millionCritical-team retention and transfer planService-based retention instruments
Customer and channel accessUSD 110 millionConsent, usage and conversion evidenceCustomer-conversion payments
Government-program eligibilityUSD 60 millionEligibility and contract continuity confirmedClosing condition and specific indemnity
Other net assets and option valueUSD 40 millionAsset verification and board-approved roadmapCapped upfront allocation

Wholly hypothetical management assumptions; not observed transaction terms.

Table 5. Regulatory and contract gate map
GateDiligence questionEvidenceDecision consequence
Export controlWhat technology and access are controlled?Classification, licences and access mapInformation perimeter and closing timetable
Foreign investmentDoes ownership or access create a filing issue?Ownership, technology and customer analysisFiling, mitigation or structure
AntitrustCan the deal restrict a route to market or platform?Market, channel and information mapRemedy risk and thesis adjustment
Government contractsDo awards and rights survive change of control?Instrument, clauses, consents and eligibilityNovation, consent and valuation
Data securityCan systems and repositories be combined lawfully?Classification, architecture and controlsStaged integration and information barriers

Qualified counsel should confirm the current transaction-specific requirements.

Table 6. First 100-day board dashboard
MeasureDay 10Day 30Day 60Day 100
Technical evidenceBaselines securedCapability map reconciledRoadmap approvedMilestone tests scheduled
CustomersContinuity owners assignedConsents and risks mappedConversion plan activeRetention evidence reported
PeopleCritical roles confirmedRetention executedSuccession gaps fundedCapability transfer measured
RegulationAccess controls preservedFiling and licence map currentMitigation actions fundedCompliance dashboard active
CapitalLiquidity protectedIntegration budget reconciledScenario triggers approvedPortfolio allocation reviewed

Proposed evidence schedule.

Table 7. Board approval thresholds
Decision areaGreen evidenceAmber conditionRed condition
ModalityReproduced capability changes roadmap probabilityMaterial milestone remains testable and pricedCore claim cannot be reproduced or transferred
Customer accessContracts, usage and consents support conversionAccess depends on manageable channel or key-person riskRelationship is non-binding or non-transferable
RegulationViable classification, filing and operating pathDefined approval risk with protected timetableRequired access or ownership is unlikely to be permitted
IntegrationOne roadmap, owners and funded sequenceTemporary duplication with decision dateConflicting architectures and no accountable owner
EconomicsValue bridge and downside funding are explicitOption value is capped and milestone-linkedPrice depends on unsupported market projection

Proposed decision framework.

Sources

  1. National Quantum Initiative, National Quantum Initiative overview. Read the primary source
  2. National Quantum Initiative, Supplement to the President's Fiscal Year 2025 Budget. Read the primary source
  3. National Quantum Initiative, Strategy Documents. Read the primary source
  4. National Quantum Initiative Advisory Committee, Renewing the National Quantum Initiative and related reports. Read the primary source
  5. United States Bureau of Industry and Security, Department of Commerce Implements Controls on Quantum Computing and Other Advanced Technologies, 2024. Read the primary source
  6. United States Bureau of Industry and Security, Export Administration Regulations Part 734 Scope of the EAR. Read the primary source
  7. United States Bureau of Industry and Security, Export Administration Regulations Part 742 Control Policy. Read the primary source
  8. United States Department of Justice and Federal Trade Commission, 2023 Merger Guidelines. Read the primary source
  9. United States Department of Justice, Merger Guideline 5 concerning access to products, services and routes to market. Read the primary source
  10. United States Department of Justice, Merger Guideline 9 concerning multi-sided platforms. Read the primary source
  11. United States Department of the Treasury, CFIUS Fact Sheet on Mandatory Critical Technology Declarations. Read the primary source
  12. Federal Acquisition Regulation, Part 35 Research and Development Contracting. Read the primary source
  13. Federal Acquisition Regulation, Part 27 Patents Data and Copyrights. Read the primary source
  14. Federal Acquisition Regulation, Subpart 27.4 Rights in Data and Copyrights. Read the primary source
  15. IonQ, Agreement to Acquire Oxford Ionics, 9 June 2025. Read the primary source
  16. IonQ, Completion of Oxford Ionics Acquisition, 17 September 2025. Read the primary source
  17. IonQ, Annual Report on Form 10-K for the year ended 31 December 2025. Read the primary source
  18. IonQ, Quarterly Report on Form 10-Q for the quarter ended 30 June 2026. Read the primary source
  19. IonQ, IonQ Federal announcement, 10 September 2025. Read the primary source
  20. Google Quantum AI, Meet Willow, 9 December 2024, updated 12 June 2025. Read the primary source
  21. IBM Quantum, Quantum Development and Innovation Roadmap, updated 2025. Read the primary source
  22. QuEra Computing, Quantum Roadmap. Read the primary source
  23. PsiQuantum, Company and technology milestones. Read the primary source
  24. Quantinuum, Quantum Systems Reference. Read the primary source
  25. Quantinuum, H2 Product Data Sheet, 2025. Read the primary source
  26. Amazon Web Services, Amazon Braket Quantum Processing Units. Read the primary source
  27. Amazon Web Services, Amazon Braket Pricing. Read the primary source
  28. Amazon Web Services, Braket Overview and Quantum Hardware Technologies. Read the primary source
  29. Amazon Web Services, Expanded Collaboration with QuEra, 15 June 2026. Read the primary source
  30. Microsoft Azure Quantum, Quantum Hardware Providers and Implementation Levels. Read the primary source
Questions, answered

US Quantum Computing M&A: frequently asked questions

No single qubit count establishes useful performance or transaction value. The buyer should evaluate fidelity, connectivity, logical capability, circuit depth, throughput, uptime, reproducibility, manufacturing, workload fit and the full control stack under defined test conditions.

Compare each target against the buyer's intended workloads, fault-tolerance plan, manufacturing base, capital capacity and route to market. Use modality-specific tests and workload evidence. Avoid compressing unlike architectures into one unsupported ranking.

Customer access supports value when contracts, usage, data rights, security eligibility, platform rights, support relationships and renewals transfer with the target. A logo, pilot or non-binding collaboration should receive limited value until commitment and behaviour are evidenced.

Separate achieved capability from future options. Pay a larger portion of uncertain value through objective technical milestones, retention instruments, customer-conversion payments or holdbacks. Define tests, data access, timing and dispute procedures precisely.

Review the instrument, funding, termination, security, audit, intellectual-property, data-rights, software-rights, change-of-control and eligibility provisions. Confirm whether the combined entity and required personnel can continue performance.

A cloud platform can control customer identity, billing, usage data, placement and commercial terms. The hardware provider may receive valuable distribution without owning the relationship. Diligence should map contractual rights, support contact, switching behaviour and data access.

The combined company can retain two expensive roadmaps without resolving which architecture, control stack and capital plan is primary. One accountable roadmap, protected experimental paths and explicit decision gates reduce this risk.

Require a defined constraint, reproduced technical evidence, a capability and dependency map, verified intellectual-property rights, transferable customer evidence, regulatory analysis, retention, a funded integration plan, milestone consideration and downside liquidity.

This publication is general information for professional audiences. It is not investment, legal or tax advice, and it is not an offer or solicitation. Readers should verify current legal, regulatory and tax requirements with qualified advisers.

Apply this insight to a live decision

Discuss the financing, capital allocation or transaction implications with a Matchpoint partner.

WhatsApp