Introduction
Public-key cryptography supports identity, secure communications, software signing, financial transactions, remote administration and trusted updates. A cryptographically relevant quantum computer could break widely used public-key algorithms. The timing of that capability remains uncertain. The exposure already matters because protected data can be collected now and decrypted later, and because large organisations need years to discover cryptographic dependencies, replace products, test interoperability and migrate critical systems.
NIST published FIPS 203 for ML-KEM, FIPS 204 for ML-DSA and FIPS 205 for SLH-DSA in August 2024 [1-4]. Its transition guidance identifies 2035 as the end point for removing quantum-vulnerable algorithms from NIST standards, with high-risk systems moving earlier [5]. The UK National Cyber Security Centre recommends that large organisations complete discovery and initial planning by 2028, complete the highest-priority migrations by 2031 and finish migration by 2035 [6]. The European Union coordinated roadmap asks Member States to start transition by the end of 2026 and move high-risk use cases no later than 2030 [7,8]. United States federal agencies have recurring inventory obligations under Office of Management and Budget guidance [9,10].
These dates create a credible implementation market. They also create conditions for overstatement. A vendor may describe a large addressable market while customers remain in unfunded assessment. A discovery tool may identify cryptographic artefacts without producing an accurate, complete and actionable inventory. A consultancy may have respected specialists but limited throughput. A product company may depend on third-party libraries, cloud providers, hardware-security modules or protocol standards that it cannot control. Acquisition diligence must trace the path from policy obligation to customer budget, delivery evidence and cash.
This paper is written for corporate buyers, private equity investors, cybersecurity platforms and investment committees evaluating post-quantum cybersecurity targets. It focuses on the commercial and operating questions that determine value. Technical validation, legal analysis and security assurance require qualified specialists and transaction-specific evidence.
1 Define the acquisition thesis as a customer decision
The acquisition thesis should identify the customer decision the target enables. A chief information security officer may need an enterprise cryptographic inventory and risk-ranked migration plan. A product manufacturer may need new cryptographic libraries, firmware, certificates and test evidence. A regulated financial institution may need protocol compatibility, supplier remediation and controlled production cutover. A government customer may need validated modules, procurement compliance and evidence against a mandated timeline.
Each decision has a different buyer, budget, procurement route, delivery cycle and acceptance test. An inventory engagement can be purchased from a consulting budget. Product remediation may sit within engineering roadmaps. Hardware replacement can require capital expenditure and long procurement lead times. Managed certificate or key-management services may enter recurring operating budgets. The acquirer should identify which budget pays and which executive can release it.
The thesis should state the target's role in the migration chain. A discovery vendor finds cryptographic use. An architecture firm prioritises systems and defines target states. A product company provides libraries, appliances or management software. An integrator changes applications and infrastructure. A testing specialist validates interoperability and security. A managed-service provider operates the resulting estate. Revenue quality and competitive position differ across these roles.
The board should approve a testable statement: the target can convert a defined customer obligation into a specified accepted outcome at a measured contribution and within an evidenced delivery capacity. Diligence should reject broad claims that post-quantum migration alone guarantees demand.
2 Translate policy timelines into customer-level demand
Official migration dates are market signals. They are not vendor orders. The commercial diligence team should map every material customer to the applicable authority, sector rule, data-lifetime risk, internal policy and procurement milestone. It should identify the named programme owner, approved budget, current phase, contracted deliverable and expected production decision.
The demand map should distinguish awareness, assessment, funded discovery, architecture, pilot, production migration and ongoing operation. A customer presentation is not a qualified opportunity. A free assessment is not paid demand. A paid pilot proves limited willingness to spend but may not establish production scope. A signed multi-year statement of work with accepted milestones provides stronger evidence. Invoices and collections remain the clearest evidence that the customer has converted concern into spending.
Long-lived sensitive data creates earlier urgency. OMB guidance prioritises high-value and high-impact systems [9]. NCSC guidance asks organisations to prioritise sensitive data, critical communications, infrastructure and long-lived hardware [6]. A target serving those environments may face stronger customer need, deeper qualification and longer sales cycles. The diligence model should capture both effects.
Management should provide customer evidence without exposing protected security information unnecessarily. Contracts, purchase orders, redacted budgets, acceptance records, invoices, collections and renewal correspondence can support the demand case. Pipeline should be weighted by completed procurement events, not sales judgement alone.
3 Test the cryptographic inventory capability
Migration begins with knowing where vulnerable cryptography exists. The inventory can span applications, source code, libraries, APIs, certificates, keys, protocols, hardware, firmware, identity systems, network devices, cloud services, operational technology and third-party products. It must link a detected artefact to the owning system, business service, data, supplier, lifecycle and remediation route.
CISA states that automated discovery tools may improve inventory, while manual work remains necessary because tools may lack visibility or compatibility across an estate [10,11]. A target's discovery claim should therefore be tested for scope, accuracy, repeatability and actionability. Diligence should examine supported environments, scanning methods, agent requirements, source-code access, false positives, false negatives, asset reconciliation, cryptographic bill-of-materials output and integration with configuration or security systems.
A representative customer test should use a controlled sample with a known ground truth. The target should identify embedded algorithms, certificates, libraries and protocol use and link them to accountable applications. Missed legacy systems, appliances, scripts, shadow cloud resources and supplier-managed services can materially weaken the inventory. A high count of detected objects can create noise rather than a migration plan.
The valuable output is a maintained decision register. It states what is vulnerable, why it matters, who owns remediation, which dependency must move first, which target standard applies, which vendor release is available, what testing is required and when the change can enter production. The acquirer should value evidence that customers keep using and refreshing this register.
4 Separate inventory revenue from migration revenue
Discovery creates an entry point. It does not automatically create implementation revenue. Customers may take the inventory to another integrator, wait for product vendors, defer budget or remediate internally. The target should demonstrate contractual or operating mechanisms that connect discovery to prioritisation, architecture, implementation, testing and operation.
Revenue should be segmented by stage and customer cohort. Cohort reporting should show the share of customers that purchase only assessment, proceed to architecture, enter production migration, expand to additional business units and renew managed services. The transition rate, time between stages, implementation value and contribution reveal whether the target owns a durable customer relationship.
Contract review should identify optional phases, break clauses, customer dependencies, change control, acceptance criteria and limits on access. A framework agreement with no committed work belongs in pipeline. A statement of work subject to customer inventory availability can slip. A product subscription with implementation included may conceal labour cost. A large migration contract can carry milestone, service-credit and remediation risk.
The acquirer should reconcile claimed annual recurring revenue. Software licences, subscriptions and managed services can recur. A renewable consulting retainer is not equivalent to committed recurring revenue. Project revenue should remain project revenue. Contracted backlog should be reduced for unfunded options, expired work orders, missing customer inputs and delivery beyond available capacity.
5 Verify production migration competence
A migration target must change live systems without weakening security, breaking interoperability or interrupting service. The work can include algorithm selection, hybrid deployment, certificate and key changes, code remediation, hardware replacement, protocol upgrades, vendor coordination, testing, rollout and rollback. NCSC guidance emphasises procurement, commissioning, testing, backup, business continuity and rollback [6].
Diligence should inspect completed production migrations rather than demonstrations alone. The evidence pack should identify the system, previous cryptography, target architecture, dependency map, test plan, change approvals, performance results, incidents, rollback route, final acceptance and operating support. Customer references should confirm the target's role and the result, subject to confidentiality.
Hybrid approaches can reduce transition risk when properly designed. IETF guidance defines hybrid schemes that combine traditional and post-quantum components, and later standards specify ML-KEM hybrid key agreement for TLS 1.3 [12-15]. A target should explain where it uses hybrid methods, how components are combined, which protocols are standardised, and how compatibility is tested. Proprietary combinations require careful review.
Production competence also depends on change management. The target needs release control, secure development, test environments, configuration evidence, incident response and customer communication. A skilled cryptographer does not automatically create an enterprise migration factory. The acquisition thesis should price the full delivery system.
6 Measure implementation capacity from named resources
Demand can exceed supply long before it becomes revenue. Capacity should be built from named employees, contractors, partner resources, product automation and customer dependencies. Roles can include cryptographers, security architects, application engineers, infrastructure specialists, hardware engineers, PKI experts, test engineers, project leaders and assurance personnel.
The diligence team should calculate available hours by skill, utilisation, billability, training, sales support, research, leave and management. It should map each signed project to required skills and calendar windows. A single senior architect may be the approval bottleneck across many teams. A partner network may provide scale but reduce margin and delivery control. Customer engineers may be required for code access, testing and production changes.
Management's capacity model should reconcile to payroll, contractor agreements, partner contracts, project plans and timesheets. The team should test whether new hiring is realistic in the required locations and whether security clearance, customer approval or export restrictions constrain deployment. Staff described as post-quantum specialists should have evidenced work relevant to their claimed roles.
Automation can improve throughput. Inventory connectors, prioritisation rules, code transformation, test harnesses and reporting workflows can reduce manual work. The buyer should measure their effect on hours, accuracy and acceptance. Demonstrated time savings matter. Marketing descriptions do not establish capacity.
7 Analyse delivery economics after scarce specialist effort
Gross margin can be overstated when scarce technical labour is classified as research, customer success or central engineering. The transaction model should allocate all delivery-related effort to the customer or product line it supports. It should include contractors, partner fees, cloud testing, laboratories, travel, certifications, warranty, support, incident remediation and unbilled pre-sales work.
The central hypothetical case assumes USD 36.00 million of revenue. Paid inventory and readiness work contributes USD 8.00 million, migration architecture and implementation contributes USD 18.00 million, software and tooling contributes USD 6.00 million, and managed assurance contributes USD 4.00 million. Direct delivery and support cost is USD 20.50 million, leaving USD 15.50 million of contribution before central overhead. These values are management assumptions.
The pilot-heavy case assumes USD 12.00 million of revenue and a USD 1.00 million contribution loss because demonstrations require senior staff, custom integration and unpriced support. The scaled platform case assumes USD 82.00 million of revenue and USD 36.00 million of contribution after reusable tooling, partner enablement and recurring assurance increase throughput. Neither case is a forecast.
The buyer should inspect contribution by cohort. Early regulated customers may carry heavy qualification costs. Later customers should show reuse of connectors, playbooks, test evidence and partner capacity. If every project remains bespoke, margin and scale assumptions should be reduced.
8 Diligence intellectual property and dependency control
The target's value may reside in source code, detection logic, protocol implementations, test suites, knowledge bases, migration methods, customer configurations and specialist know-how. The buyer should establish ownership, inventor assignment, contractor terms, patent status, trade-secret controls and third-party obligations. Each component should be linked to the revenue or delivery step it supports.
Open-source software can accelerate development and improve interoperability. It can also create notice, attribution, source-disclosure, patent or redistribution obligations. The buyer should obtain a software bill of materials, licence scan, remediation log and release process. Dependencies on cryptographic libraries require version, maintenance, validation and vulnerability review.
Standards dependencies deserve explicit treatment. NIST can publish revised guidance or additional algorithms. IETF protocols continue to evolve. Hardware-security modules, browsers, cloud services and network products determine which combinations can operate in production. The target should show an architecture that can adopt approved changes without rewriting every customer environment. This capability is commonly described as cryptographic agility [16,17].
Customer-specific work can constrain reuse. Contracts may assign deliverables, prohibit use of data or restrict publication of methods. Security-sensitive customers may require isolated environments and limit remote support. The acquisition model should separate reusable platform assets from customer-owned or restricted material.
9 Test product claims against standards and validation evidence
Terms such as quantum-safe, quantum-resistant and compliant can hide different evidence. A product may implement a standard algorithm in a library. A cryptographic module may have undergone algorithm testing or formal module validation. A complete system may still have vulnerable protocols, certificates, update mechanisms or dependencies. The target should state exactly what has been tested, by whom, against which version and within which boundary.
NIST's Cryptographic Algorithm Validation Program and Cryptographic Module Validation Program provide defined forms of validation [18,19]. Validation status should be checked on official lists. A target awaiting validation should identify the submitted module, laboratory, scope, open issues and expected decision. Customer statements should avoid implying approval that has not been granted.
Performance also matters. Post-quantum keys, signatures and messages can affect bandwidth, memory, latency, hardware and certificate infrastructure. Tests should represent the customer's protocols, devices, networks and traffic. Embedded and operational environments can have long lifecycles and constrained resources. Cloud test results do not establish performance on every edge device.
The acquirer should maintain a claims matrix linking each commercial statement to a standard, test, validation, customer acceptance or limitation. Unsupported claims can create mis-selling, warranty, regulatory and reputational exposure.
10 Examine customer concentration and procurement quality
Early post-quantum vendors may depend on a few government, defence, financial-services or technology customers. Concentration can provide strong references and demanding validation. It can also create renewal, budget, security-clearance and change-of-control risk. Revenue analysis should show customer, legal entity, contract, programme, product, geography, gross contribution, receivables and dependency.
Government awards require close reading. A framework place does not guarantee work. An indefinite-delivery vehicle may contain a ceiling rather than committed revenue. A research grant is not customer revenue. A prototype contract may end before production. The diligence team should identify funded task orders, appropriations, options, acceptance and termination rights.
Commercial customers may depend on board-approved cyber programmes, vendor roadmaps and broader infrastructure refresh. A migration project can be delayed when a cloud provider, device manufacturer or core-software vendor has not released compatible products. The target's contract should allocate those dependencies and change risk.
Change of control can require customer consent, security review, supplier onboarding or foreign-investment analysis. The buyer should identify customers and programmes that could be lost or restricted after acquisition and include that exposure in transaction conditions and valuation.
11 Assess alliances suppliers and ecosystem position
Post-quantum migration crosses many product boundaries. A target may rely on cloud platforms, hardware-security modules, certificate authorities, identity vendors, network equipment, browsers, operating systems, systems integrators and specialist laboratories. Alliances can expand distribution and capacity. They can also expose the target to channel conflict and weak bargaining power.
The diligence team should classify each relationship as referral, reseller, implementation partner, technology integration, subcontractor or strategic dependency. It should inspect executed agreements, exclusivity, territory, certification, revenue share, lead ownership, service responsibility, support, data access, intellectual property and termination.
Partner-sourced pipeline should be reconciled to registered opportunities and contracts. A memorandum of understanding should not be valued as distribution. Certification badges should be verified. Joint demonstrations should be separated from customer deployment. The target should identify which partner products are required for its solution and which can be substituted.
The strongest ecosystem position is evidenced by repeatable integration, accepted reference architectures, trained partners, joint customer wins and clear support boundaries. The buyer should test whether the acquisition strengthens that position or causes partners to treat the target as a competitor.
12 Quantify professional liability and security risk
Inventory and migration work can affect confidentiality, availability, authentication and software trust. A missed dependency can leave an exposure. A failed cutover can interrupt a critical service. An implementation flaw can create a new vulnerability. Advice may influence regulated or national-security systems. These risks require a specific liability review.
The data room should include customer warranties, indemnities, liability caps, service credits, professional-services obligations, security schedules, incident terms, insurance, claims and near misses. The buyer should identify commitments that exceed insurance or the target's control. Broad warranties that a system is quantum-safe can be difficult to support when standards, products and threat models evolve.
The target's own security should meet the sensitivity of its work. Diligence should inspect secure development, access control, code signing, secrets management, repositories, privileged administration, endpoint protection, supplier access, vulnerability management, incident response and recovery. Customer cryptographic inventories can reveal high-value architecture and deserve strong protection.
Risk allocation should follow the service boundary. The target can warrant defined methods, personnel and agreed deliverables. Customers and product vendors retain responsibilities for their systems, decisions and supplied information. The buyer should price unresolved exposures and require remediation or specific indemnity where evidence supports it.
13 Protect talent knowledge and technical authority
Scarce expertise can be the principal asset. The buyer should identify who can design architectures, approve claims, solve failures, maintain tooling, satisfy customers and train others. Organisation charts and job titles provide limited evidence. Project records, code history, design decisions, customer reliance and peer review reveal actual authority.
Key-person analysis should map each critical capability to at least two people, documentation and a succession route. Founder dependence is material when one person owns customer relationships, technical direction and final approval. Contractors can create continuity and intellectual-property risk. Security clearances and nationality restrictions may limit transfer between projects or countries.
Retention should address role, decision authority, compensation, research time, customer continuity and integration design. A large buyer can lose specialist staff through slow approvals or a purely sales-led operating model. The post-close plan should preserve technical review and secure development while integrating finance, legal, sales and support controls.
Knowledge transfer should be observable. Paired project leadership, reviewed documentation, repeat delivery and incident exercises provide stronger evidence than a training schedule. Earn-outs should avoid incentives to accept low-quality work or defer necessary investment.
14 Build a valuation model around evidence states
Valuation should reflect the target's current evidence state. A capability-stage target has specialists, prototypes and early customer access. A validated-tooling target has repeatable inventory or testing assets and accepted pilots. A contracted-migration target has funded programmes, implementation capacity and observable contribution. A scaled-platform target has diversified customers, partner delivery, recurring software or assurance and stable unit economics.
A wholly hypothetical probability-weighted illustration assigns enterprise values of USD 55 million, USD 150 million, USD 360 million and USD 700 million to those four states. The associated probabilities are 25%, 35%, 25% and 15%. The weighted values are USD 13.75 million, USD 52.50 million, USD 90.00 million and USD 105.00 million, producing USD 261.25 million in total. The assumptions demonstrate the method and do not value a named company.
The buyer should cross-check against revenue quality, contribution, cash conversion, product ownership, customer concentration and required investment. A software multiple should not be applied to labour-intensive migration revenue. A services multiple can understate reusable tooling and recurring assurance. Sum-of-the-parts analysis can separate these components.
Downside cases should include procurement delay, slower conversion from assessment, hiring constraints, partner dependence, failed validation, security incident and standards change. Value should fall when evidence requires future investment or customer action that the target does not control.
15 Structure consideration around migration evidence
Transaction structure can bridge uncertainty between strategic market timing and vendor-specific evidence. Upfront consideration should reflect owned assets, retained capability, contracted work and verified economics at closing. Deferred consideration can follow production acceptance, qualified recurring revenue, gross contribution, collections and retention of critical personnel.
An earn-out should use measures the seller can influence and the buyer can verify. Bookings can reward contracts that are poorly priced or beyond capacity. Revenue can reward low-margin subcontracting. EBITDA can be affected by buyer allocations. A balanced mechanism may combine accepted migration milestones, recurring software or managed-service revenue, customer retention and contribution before agreed central charges.
Holdbacks or escrow can address specific indemnities, intellectual-property defects, customer consents or validation claims. Reverse conditions may protect the seller if the buyer changes the agreed operating model. Governance during the earn-out should define investment, hiring, pricing, project acceptance and reporting.
The buyer should avoid paying twice for the same expectation. A high strategic premium and a full achievement-based earn-out can duplicate value. The valuation bridge should show which evidence is paid at closing and which future outcome releases additional consideration.
16 Plan integration before signing
Integration should preserve customer trust and technical credibility. The first hundred days should secure people, repositories, customer delivery, partner relationships, incident response and financial control. It should also identify which functions remain separate because of security, accreditation or customer obligations.
The buyer should map all live projects, milestones, access permissions, dependencies, responsible specialists, customer communications and cash commitments. Critical releases and migrations should have named continuity plans. Commercial teams should avoid announcing expanded capability before technical and contractual review.
Tool integration requires care. Moving code, telemetry or customer inventories into the buyer's environment can require consent and security approval. Identity changes can interrupt access. Replacing ticketing or development systems during a critical migration can reduce evidence quality. The integration plan should sequence changes around customer milestones.
Operating metrics should remain visible after close. The buyer should track inventory accuracy, conversion between stages, accepted migrations, specialist utilisation, contribution, incidents, renewals, collections and customer concentration. Integration success is demonstrated when the combined business delivers more accepted work with controlled risk and improved cash generation.
17 Use a ninety-day diligence programme
Days one to thirty should establish the evidence perimeter. The team maps products, services, customers, contracts, revenue, people, tools, intellectual property, dependencies, validations, liabilities and security controls. It selects representative customer files and defines technical tests. Finance reconciles revenue, backlog, receivables and staff cost.
Days thirty-one to sixty should test the operating claims. Technical reviewers run controlled inventory and interoperability tests. Commercial reviewers interview authorised customer and partner references. Operations reconciles signed work to named capacity. Legal reviewers analyse contracts, intellectual property, open-source obligations, data and change-of-control terms. Security reviewers inspect the target's own controls.
Days sixty-one to ninety should convert findings into transaction decisions. The team builds central and downside cases, identifies remediation, prices retained risk, defines conditions, drafts consideration mechanics and finalises the integration plan. The investment committee receives an evidence map that links every material assumption to a source and owner.
The programme can be compressed or extended according to transaction size and access. The sequence matters. Technical promise, commercial demand, delivery capacity and cash economics should be tested together. A finding in one workstream should update the others.
18 Establish post-close value creation gates
The first gate protects the existing business. Critical people remain, customer commitments are met, access is controlled and cash reporting is reconciled. The second gate improves evidence quality through a maintained cryptographic inventory, standard project architecture, resource planning and contribution reporting. The third gate increases throughput through reusable tooling, trained partners and repeatable testing.
The fourth gate builds recurring economics. Suitable functions can move into software subscription, managed inventory, certificate lifecycle, continuous discovery, assurance or support. The product must provide continuing customer value and should not be described as recurring merely because a project renews. The fifth gate expands distribution through qualified alliances and adjacent customers.
Capital should follow the gates. Research and product investment can precede revenue when the board understands the technical objective and customer path. Hiring should follow qualified backlog and a realistic onboarding period. Acquisition of adjacent capability should wait until the first target's delivery and integration controls are stable.
Value creation should remain connected to collected cash. The board can track contracts, acceptance, invoice, collection, direct cost, contribution and reinvestment by cohort. This discipline prevents a standards-driven market narrative from concealing weak execution.
Conclusion
Post-quantum migration has an official standards base and visible public-sector timelines. The work is extensive because cryptography is embedded in software, hardware, identity, communications, suppliers and operating processes. These conditions support a long implementation market. They also create room for vendors to overstate the commercial meaning of policy announcements, pilots and technical demonstrations.
An acquisition should be underwritten from customer evidence. The target should identify vulnerable cryptography accurately, convert inventories into prioritised plans, secure funded implementation scope, deliver production change safely, and retain enough specialist and partner capacity to meet the backlog. Revenue should be classified by work stage and cohort. Direct cost should include scarce technical effort. Product claims should link to standards, tests and validation boundaries.
The transaction structure should pay for current evidence and reserve further value for accepted migration, durable revenue, contribution and retained capability. Integration should protect technical authority, customer trust, secure environments and partner relationships. A board using this framework can assess whether it is acquiring a credible migration platform, a valuable specialist team, a project backlog or an early option. Each can have value. The price and capital plan should match the evidence.
Appendix A. Cryptographic inventory diligence fields
The inventory register should record the business service, application, owner, environment, data sensitivity, lifecycle, algorithm, key size, certificate, protocol, library, hardware module, supplier, source of detection, confidence, exposure, target state, dependency, remediation owner, budget, deadline, test requirement and acceptance status. Each record should link to source evidence and retain change history.
The buyer should inspect coverage across source code, binaries, runtime traffic, certificates, keys, devices, cloud services, operational technology and third-party products. It should record known blind spots and the manual work needed to close them. A maintained inventory has more value than a one-time scan.
Appendix B. Hypothetical financial model
The central case assumes USD 8.00 million of inventory and readiness revenue, USD 18.00 million of architecture and implementation revenue, USD 6.00 million of software and tooling revenue, and USD 4.00 million of managed assurance revenue. Direct cost totals USD 20.50 million and contribution totals USD 15.50 million before central overhead.
The pilot-heavy case assumes USD 12.00 million of revenue and a USD 1.00 million contribution loss. The scaled platform case assumes USD 82.00 million of revenue and USD 36.00 million of contribution. A real model should add sales capacity, research, product development, central engineering, tax, working capital, capital expenditure, financing and acquisition integration.
Appendix C. Customer evidence file
Each material customer file should include the legal entity, programme owner, applicable obligation, budget source, procurement route, contract, statement of work, work order, change control, acceptance criteria, project plan, dependency register, delivery team, technical evidence, invoice, collection, support commitment, renewal path and authorised reference record.
The file should distinguish customer-provided information, target analysis, accepted deliverables and management expectation. Sensitive inventories and architecture should remain in controlled rooms with role-based access and an audit trail.
Appendix D. Investment committee questions
The committee should ask whether customers have funded migration work, whether inventory outputs are complete enough to support decisions, whether production migrations have been accepted, whether contracted work fits named delivery capacity, whether contribution includes all specialist cost, whether intellectual property is owned, whether claims match validation evidence, and whether critical people will remain.
It should identify dependencies outside the target's control. These can include standards, cloud and hardware products, customer engineering, security approvals, protocol maturity and procurement. The transaction should allocate price, capital and timing according to those dependencies.
Appendix E. Transaction evidence hierarchy
The evidence hierarchy begins with policy and standards, which establish external direction. Customer strategy and budget establish organisation-level intent. Signed contracts establish committed scope subject to their terms. Production acceptance establishes delivery. Invoices and collections establish commercial conversion. Renewals, expansion and stable contribution establish repeatability.
Each level answers a different question. An acquisition premium should be linked to the levels the target has reached and can sustain. Future levels can be addressed through milestones, earn-outs and staged investment.
Proposed framework; each conclusion requires target and customer evidence.
Hypothetical management assumptions; percentages represent cohort progression, not market observations.
Management assumptions in USD millions; excludes central overhead tax financing and integration.
Management assumptions in USD millions; the chart is not a valuation conclusion.
Proposed sequence; timing should follow transaction and customer constraints.
| Signal | Current evidence | Transaction implication | Required target evidence |
|---|---|---|---|
| NIST principal standards | FIPS 203 204 and 205 final in 2024 | Product and migration work can reference final algorithms | Versioned implementation test and claim boundary |
| United States transition | Inventory duties and 2035 transition direction | Federal and supplier demand can become budgeted work | Funded order procurement route and customer acceptance |
| United Kingdom timeline | Discovery by 2028 priority migration by 2031 completion by 2035 | Near-term assessment demand can precede production migration | Cohort conversion and capacity plan |
| European Union roadmap | Transition start by end 2026 high-risk use cases by end 2030 | Multi-country opportunity with national implementation differences | Jurisdiction and customer-specific plan |
| Protocol development | Hybrid and post-quantum protocol standards continue to mature | Product compatibility and roadmap dependencies remain | Tested protocol support and upgrade architecture |
Official policy and standards evidence; target-specific commercial conclusions require separate verification.
| Stage | Evidence | Revenue treatment | Principal risk |
|---|---|---|---|
| Awareness | Meeting conference or request for information | Exclude from qualified pipeline | Interest has no budget |
| Funded discovery | Purchase order and accepted inventory scope | Project revenue | Customer may stop after assessment |
| Architecture | Approved target state and migration plan | Project revenue | Supplier and product dependencies |
| Production migration | Signed work order and change approvals | Backlog subject to delivery capacity | Acceptance and liability |
| Managed assurance | Subscription or managed-service contract | Recurring only for enforceable committed period | Service cost and renewal |
Proposed classification for transaction diligence.
| Dimension | Diligence test | Strong evidence | Warning signal |
|---|---|---|---|
| Coverage | Compare tools with known ground truth | Multiple discovery methods and reconciled assets | High counts without system ownership |
| Accuracy | Inspect false positives and false negatives | Documented precision limits and manual review | Unsupported completeness claim |
| Actionability | Trace finding to target state and owner | Prioritised maintained decision register | Static scan output |
| Integration | Review asset security and engineering interfaces | Versioned connectors and accepted workflows | Manual spreadsheet dependency |
| Continuity | Test refresh and change detection | Current inventory with change history | One-time assessment |
Proposed buyer test for a representative environment.
| Revenue or cost item | Revenue | Direct cost | Contribution |
|---|---|---|---|
| Inventory and readiness | 8.00 | 4.80 | 3.20 |
| Architecture and implementation | 18.00 | 12.20 | 5.80 |
| Software and tooling | 6.00 | 1.70 | 4.30 |
| Managed assurance | 4.00 | 1.80 | 2.20 |
| Total | 36.00 | 20.50 | 15.50 |
Management assumptions in USD millions; excludes central overhead tax financing and integration.
| Case | Revenue | Contribution | Principal condition |
|---|---|---|---|
| Pilot-heavy | 12.00 | -1.00 | Custom demonstrations and senior specialist intensity |
| Central | 36.00 | 15.50 | Funded migrations and controlled reuse |
| Scaled platform | 82.00 | 36.00 | Partner capacity recurring tooling and diversified customers |
Management assumptions in USD millions; these cases are not forecasts.
| Evidence state | Enterprise value | Probability | Weighted value |
|---|---|---|---|
| Capability | 55.00 | 25% | 13.75 |
| Validated tooling | 150.00 | 35% | 52.50 |
| Contracted migration | 360.00 | 25% | 90.00 |
| Scaled platform | 700.00 | 15% | 105.00 |
| Total | 100% | 261.25 |
Management assumptions in USD millions; the calculation is not a valuation conclusion.
| Gate | Required evidence | Transaction response | Post-close measure |
|---|---|---|---|
| Rights | Ownership open-source review and customer permissions | Condition or specific indemnity | Remediation closure |
| Demand | Funded contracts and authorised customer confirmation | Base consideration | Accepted backlog conversion |
| Capacity | Named resources and partner commitments | Hiring and retention plan | Delivery throughput and utilisation |
| Economics | Contribution and collection by cohort | Valuation and working-capital adjustment | Contribution and cash conversion |
| Scale | Reusable tooling renewal and expansion | Deferred consideration | Recurring revenue and customer retention |
Proposed transaction framework; legal and tax terms require qualified advice.
Sources
- National Institute of Standards and Technology. Post-Quantum Cryptography Project. 2026. Read the primary source
- National Institute of Standards and Technology. FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard. 2024. Read the primary source
- National Institute of Standards and Technology. FIPS 204 Module-Lattice-Based Digital Signature Standard. 2024. Read the primary source
- National Institute of Standards and Technology. FIPS 205 Stateless Hash-Based Digital Signature Standard. 2024. Read the primary source
- National Institute of Standards and Technology. NIST IR 8547 Transition to Post-Quantum Cryptography Standards. 2024. Read the primary source
- United Kingdom National Cyber Security Centre. Timelines for Migration to Post-Quantum Cryptography. 20 March 2025. Read the primary source
- European Commission. Post-Quantum Cryptography. 2026. Read the primary source
- NIS Cooperation Group. Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography. 2025. Read the primary source
- United States Office of Management and Budget. M-23-02 Migrating to Post-Quantum Cryptography. 18 November 2022. Read the primary source
- United States Executive Office of the President. Report on Post-Quantum Cryptography. July 2024. Read the primary source
- Cybersecurity and Infrastructure Security Agency. Strategy for Migrating to Automated Post-Quantum Cryptography Discovery and Inventory Tools. 15 August 2024. Read the primary source
- Internet Engineering Task Force. RFC 9794 Terminology for Post-Quantum Traditional Hybrid Schemes. 2025. Read the primary source
- Internet Engineering Task Force. RFC 9954 Hybrid Key Exchange in TLS 1.3. July 2026. Read the primary source
- Internet Engineering Task Force. RFC 9958 Post-Quantum Cryptography for Engineers. 2026. Read the primary source
- Internet Engineering Task Force. RFC 10024 Post-Quantum Traditional Hybrid Key Agreement Mechanisms for TLS 1.3. August 2026. Read the primary source
- National Cybersecurity Center of Excellence. Migration to Post-Quantum Cryptography. 2026. Read the primary source
- National Institute of Standards and Technology. Considerations for Achieving Crypto Agility. 2026. Read the primary source
- National Institute of Standards and Technology. Cryptographic Algorithm Validation Program. 2026. Read the primary source
- National Institute of Standards and Technology. Cryptographic Module Validation Program. 2026. Read the primary source
- National Security Agency. Post-Quantum Cybersecurity Resources. 2026. Read the primary source
- National Security Agency. Commercial National Security Algorithm Suite 2.0 Cybersecurity Advisory. 2022. Read the primary source
- Committee on National Security Systems. CNSS Policy 15 Use of Public Standards for Secure Information Sharing. 4 March 2025. Read the primary source
- Cybersecurity and Infrastructure Security Agency. Quantum Readiness Migration to Post-Quantum Cryptography. August 2023. Read the primary source
- National Cybersecurity Center of Excellence. NIST SP 1800-38B Migration to Post-Quantum Cryptography Quantum Readiness Cryptographic Discovery. 2023. Read the primary source
- European Commission. Recommendation on a Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography. 11 April 2024. Read the primary source
- European Union Agency for Cybersecurity. Post-Quantum Cryptography Integrations Study. 2022. Read the primary source
- European Union Agency for Cybersecurity. Cryptography Topic. 2026. Read the primary source
- Cloud Security Alliance. Quantum-Safe Security Working Group. 2026. Read the primary source
- Payment Card Industry Security Standards Council. Information Supplement Cryptographic Key Blocks. 2019. Read the primary source
- International Organization for Standardization. ISO IEC 27001 Information Security Management Systems. 2022. Read the primary source
- United Kingdom National Cyber Security Centre. Supply Chain Security Guidance. 2026. Read the primary source
- United Kingdom National Cyber Security Centre. Principles for Secure System Development. 2026. Read the primary source
