Introduction
The acquisition question is whether the target can continue protecting space missions, customer data and command pathways after ownership changes. Revenue growth and customer logos matter, but they do not answer that question. Space cybersecurity value sits in a connected system that includes engineering records, software releases, hardware roots of trust, cryptographic material, identity services, network controls, mission procedures, cleared personnel, customer approvals and recovery capability. A weakness in one part can limit the value of the whole system.
Space systems also have a distinctive lifecycle. Components can remain in orbit for years after launch, communications windows can be limited, replacement is expensive, and remote remediation may be constrained by power, bandwidth, processor capacity or safety rules. Ground systems combine mission technology with enterprise IT, cloud services, operational technology and supplier connections. CISA describes the ground segment as highly accessible and interconnected, while NASA guidance covers both the space vehicle and ground segment. The diligence perimeter therefore needs to extend from development and supply chain through launch, operations, incident response and decommissioning.
The paper uses two valuation disciplines. The first is an evidence discipline: every premium claim is tied to a configuration, operating environment, period, source record and customer consequence. The second is a cash discipline: evidence changes revenue confidence, margin, remediation cost, capital needs, contractual exposure and transaction protection. This approach avoids assigning a vague strategic premium to a collection of cyber features.
1 Define the acquired mission-assurance system
The transaction perimeter should begin with the services that customers buy and the mission outcomes those services support. A target may sell secure mission operations, satellite-command protection, ground-segment monitoring, cryptographic key management, threat intelligence, secure software development, identity services, incident response or a combined platform. Each service depends on different assets and evidence. The buyer should define the protected mission, authorised users, data flows, command paths, service levels, operational boundaries and failure consequences for each material revenue stream.
The perimeter should include all entities that contribute to delivery. These may include a software owner, a managed-service subsidiary, a cleared operations team, a cloud tenant, a hardware supplier, a ground-station partner and a parent company that holds customer contracts or licences. Shared assets require particular attention. A target can report attractive gross margin while relying on a parent company's identity platform, security operations centre, development pipeline or cryptographic infrastructure at below-market cost.
The acquisition model should identify which capabilities transfer at closing, which require consent, which remain under transition services and which must be rebuilt. It should also identify the assets that are valuable only in combination. A threat-detection engine may have limited standalone value when its training data, mission telemetry, deployment rights or expert analysts do not transfer. The transaction perimeter becomes the basis for the diligence request list, separation plan and valuation model.
2 Treat flight heritage as a bounded evidence claim
NASA describes technology readiness through nine levels and identifies technology as flight proven at TRL 9 after successful mission use. That classification is useful, but an acquisition requires a more granular question: what exactly flew, in which configuration, under what conditions, for how long, and with what accepted result? A successful mission involving one component does not establish that later releases, new interfaces or a different operating environment share the same evidence.
Flight heritage should be recorded at the level of configuration identity. The record should include hardware part and revision, software and firmware version, cryptographic module, build provenance, libraries, interfaces, deployment architecture, mission profile, orbit or environment, operational duration, anomalies, corrective actions and customer acceptance. When the acquired product is primarily ground software, the relevant heritage may include sustained mission use, command-window performance, availability, incident history and recovery rather than physical exposure to launch and orbit.
Heritage can decay when the configuration changes. NASA systems-engineering guidance recognises that heritage components can require renewed maturity assessment when architecture or environment changes. The buyer should therefore construct a delta record between the evidenced configuration and the product offered at signing. Major changes in processor, operating system, communications protocol, cryptography, hosting environment, autonomy or integration can reduce the relevance of earlier evidence until new testing or mission use closes the gap.
3 Build the heritage evidence ladder
The evidence ladder should distinguish claim, demonstration, qualified configuration, operational use and repeat accepted use. Marketing material sits at the bottom because it states the claim without proving its scope. Internal test results add evidence when the environment and acceptance criteria are controlled. Customer acceptance, mission logs and anomaly closure provide stronger evidence. Repeat use across missions, customers or environments supports a broader inference about reliability, provided the configuration lineage remains clear.
The buyer should seek primary records: configuration-control documents, signed test reports, mission logs, command histories, incident tickets, anomaly-review decisions, release records, customer acceptance, service-level reports and independent assurance. Reference calls can explain operating behaviour, but they should not replace records. A customer may be satisfied with an overall service while remaining unaware of control exceptions or supplier dependencies.
Each heritage claim should receive a scope statement and confidence rating. The scope statement identifies what the evidence supports. The confidence rating reflects record quality, independence, consistency and recency. Revenue should then be mapped to the supported scope. A contract that uses the exact evidenced configuration can receive greater forecast confidence than a new programme requiring a changed architecture, new cryptography and a different cloud environment.
4 Translate heritage into valuation
Flight heritage can affect valuation through several routes. It can improve bid eligibility, shorten customer assurance, reduce testing cost, support pricing, lower warranty exposure and improve the probability that contracted milestones convert into cash. It can also reduce the time and capital required to adapt a product for a new mission. These benefits should be reflected in specific forecast assumptions rather than an unallocated premium.
The revenue model should separate exact-configuration heritage, derivative heritage and unproven pipeline. Exact-configuration revenue uses a product and environment supported by accepted records. Derivative revenue depends on a bounded change with documented verification. Unproven pipeline depends on material new development, qualification or customer approval. Each class should have a stated conversion probability, delivery cost, schedule and evidence gate.
The cost model should capture sustaining engineering, vulnerability remediation, obsolescence, recertification, test environments, mission support and insurance. A heritage product can carry expensive legacy dependencies. Unsupported libraries, unavailable hardware, undocumented interfaces or irreplaceable personnel can convert past success into future fragility. The buyer should reward transferable and maintainable heritage rather than age alone.
5 Define zero trust as enforced operating capability
NIST SP 800-207 describes zero trust as a resource-focused architecture in which location or ownership does not create implicit trust. Authentication and authorisation occur before a session to a protected resource. For an acquisition, the important question is whether these principles are implemented across the target's relevant estate and whether the buyer can operate them after closing.
A credible capability begins with inventories of identities, devices, workloads, data, services and privileged paths. It includes policy decision and enforcement points, strong authentication, device or workload posture, least privilege, segmentation, protected telemetry and continuous assessment. Cloud-native services also require service identities, workload-to-workload policy and observation of distributed application behaviour. Mission systems add constrained devices, intermittent links, safety boundaries and commands whose failure can have irreversible consequences.
The buyer should avoid treating a product feature list as an enterprise capability. The target may sell zero-trust software while operating its own development or mission environment with broad administrator access, shared credentials or incomplete logging. The diligence record should separate controls embedded in the product, controls used to deliver managed services, and controls protecting the target's corporate and development systems.
6 Map the space attack surface
The threat map should follow the full satellite lifecycle described by current space-security guidance. Development risks include compromised source code, build systems, test equipment, design data and supplier components. Deployment risks include logistics, launch interfaces, initialisation and credential provisioning. Operational risks include enterprise IT, cloud services, ground stations, communications links, mission-control systems, spacecraft processors, payload software and customer interfaces. Decommissioning adds credential revocation, data disposition and residual control risk.
The ground segment deserves detailed testing because it combines accessible networks with mission authority. A compromised enterprise account can lead to a development repository, support portal or remote administration path. A compromised ground-system service can affect scheduling, telemetry, command approval or payload operations. Network segmentation therefore needs to be supported by identity, application and data controls rather than a diagram alone.
The threat map should also show third parties. Ground-station networks, cloud providers, component vendors, software maintainers, consultants and customers may receive access or data. Each connection should have a business purpose, owner, authentication method, privilege scope, logging, review cadence and termination process. Unknown or unmanaged connections become both cyber risk and integration work after closing.
7 Test identity and privileged access
Identity evidence should cover human users, service accounts, workloads, devices and machine credentials. The buyer should reconcile directories, access-control systems, privileged-access tools, cloud identities, code repositories, mission applications and support platforms. Dormant accounts, local administrators, shared credentials and unmanaged service accounts should be quantified and linked to systems and contracts.
Privileged access requires workflow evidence. The target should be able to demonstrate request, approval, time limitation, session control, logging, review and revocation. Emergency access should exist for defined conditions and should create an auditable record. Remote vendor support should be constrained by identity, device, time, destination and purpose. A policy that requires these steps has limited value when production logs show permanent standing privilege.
Separation and integration can disrupt identity control. The buyer should know which identity provider, hardware token, certificate authority and privileged-access platform survives closing. If the target depends on a seller service, the transition agreement should set service levels, incident obligations, data access, exit support and a funded migration plan. The valuation model should include duplicate licences, migration teams and the possibility of customer reapproval.
8 Test segmentation and command-path control
Segmentation should be evaluated through observed enforcement. The diligence team should identify trust zones, permitted flows, policy owners, exception processes and monitoring. Tests should confirm that unauthorised paths are blocked and that approved paths carry the expected identity, encryption and logging. The assessment should include enterprise-to-development, development-to-test, test-to-mission, support-to-production and partner connections.
Command paths need additional controls because they can affect mission state. The buyer should identify who can originate, approve, transmit, modify and replay commands. Strong evidence includes authenticated commands, dual authorisation for critical actions, separation of duties, command allowlists, sequence controls, protected telemetry, simulation, witnessed exercises and independent review. The architecture should prevent a corporate administrator from gaining mission authority through an indirect shared service.
Spacecraft limitations should be recorded. An older platform may not support contemporary algorithms, frequent credential rotation or fine-grained policy. The target should show compensating controls at gateways, ground systems and operating procedures. The buyer should value the resulting service based on tested risk reduction and customer acceptance, while funding the next-generation architecture separately.
9 Examine secure development and the software supply chain
The acquired value often depends on proprietary software and the target's ability to change it safely. Diligence should cover source control, branch protection, code review, build provenance, dependency management, secrets, test evidence, vulnerability handling, release approval and deployment. NIST's Secure Software Development Framework provides a useful baseline for organising these questions.
The software bill of materials should reconcile to shipped products and active services. A document produced for diligence is insufficient when it cannot be regenerated from the build. The buyer should identify unsupported packages, restrictive licences, known vulnerabilities, embedded credentials, export restrictions and components supplied under non-transferable terms. It should also identify which mission configurations cannot be patched without customer approval or operational risk.
Build and signing infrastructure is a control asset. The target should demonstrate who can produce a release, how build inputs are verified, how artefacts are signed, where signing keys are held and how customers verify updates. The buyer should plan the ownership change for repositories, pipelines, certificates and keys before closing. A broken signing chain can delay releases and weaken customer confidence even when the underlying code is sound.
10 Assess cryptographic agility and key management
Cryptographic capability should be inventoried across data at rest, data in transit, command authentication, software signing, identity, telemetry and customer integration. The inventory should identify algorithm, key length, protocol, library, hardware module, certificate authority, key owner, rotation, recovery, expiry and upgrade path. Long-lived assets require particular attention because algorithms and implementations can become obsolete before the asset is replaced.
NIST has finalised post-quantum standards for key establishment and digital signatures. Their existence does not mean every space product can migrate immediately. The target should show where migration is feasible, what performance or memory constraints apply, how hybrid approaches will be tested, and which customers or regulators must approve the change. The plan should distinguish corporate IT, ground systems, mission software and spacecraft.
Key management is also a transaction issue. The buyer should determine which keys transfer, which must be rotated, which belong to customers and which remain with the seller. It should confirm custody, backup, recovery, dual control, logging and destruction. The closing plan should prevent either party from retaining unauthorised access while preserving continuity. Costs for hardware modules, certificate reissuance, engineering and customer acceptance should enter the model.
11 Review monitoring, detection and response
Monitoring evidence should connect telemetry to action. The buyer should identify log sources, collection coverage, time synchronisation, retention, integrity, detection rules, alert ownership, escalation and incident records. High alert volume is not proof of effective detection. Useful evidence shows that material events are observed, triaged, investigated, contained and closed within defined service levels.
Space operations create specialised telemetry that may not fit enterprise tools. Mission anomalies, command patterns, link behaviour, configuration changes and ground-station events may require domain-specific rules and expert interpretation. The target should show how these signals reach the security and mission teams, how responsibility is allocated, and how safety decisions are made during an incident.
Incident records can be valuable diligence evidence when handled under privilege and confidentiality. They reveal control performance, response speed, root causes and repeat issues. The buyer should distinguish absence of recorded incidents from evidence of effective monitoring. It should also review contractual notification deadlines, regulator obligations, insurance conditions and customer approval for investigative access.
12 Prove recovery and mission continuity
Recovery capability should be demonstrated through exercises and operating records. The target should identify minimum viable mission service, recovery time, recovery point, alternate facilities, backup integrity, clean-room procedures, credential recovery and decision authority. The exercise should include loss of identity services, cloud regions, ground stations, supplier access and key personnel where these are material dependencies.
Backups are useful only when they can be restored into a trusted environment. The buyer should inspect restore tests, configuration baselines, key availability, dependency versions and reconciliation to production. Mission continuity may require a controlled fallback configuration that preserves safe operations while reducing features. The customer contract should define whether this reduced mode satisfies the service obligation.
Continuity also depends on people. The target may rely on a small group with clearance, mission knowledge or access to customer environments. Diligence should map critical roles, employment terms, location, succession, on-call coverage and transfer restrictions. Retention value should be tied to documented knowledge transfer and operating capability, not only continued employment.
13 Reconcile compliance and customer assurance
Space cybersecurity companies can face overlapping obligations from customer contracts, national security requirements, export controls, data protection, critical-infrastructure rules and sector standards. The buyer should build an obligation register by legal entity, product, customer, geography and system. Each obligation should identify the control owner, evidence, exception, reporting duty and change-of-control consequence.
Customer assurance often includes questionnaires, architecture reviews, penetration tests, security plans, facility requirements and named personnel. These materials should be reconciled to actual control operation. An answer given during a procurement process can become a contractual representation or renewal dependency. Differences between customer statements and current practice should be assessed for remediation, disclosure and liability.
Change of control may require consent or renewed accreditation. The buyer should identify contracts that permit termination, suspend access, restrict ownership or require a new security plan. The forecast should reflect timing and probability of customer approval. Consideration can be deferred until material approvals and retained revenue are evidenced.
14 Separate intellectual property from operating know-how
The intellectual-property review should cover source code, models, detection logic, cryptographic implementations, patents, trade secrets, documentation, data rights and customer-specific developments. Ownership should be traced through founders, employees, contractors, universities, government funding and acquired code. Open-source and third-party licences should be reconciled to actual use.
Operating know-how can be more valuable than registered rights. Mission analysts may understand false positives, telemetry patterns, customer procedures and integration workarounds that are not documented. The buyer should identify this knowledge, convert it into controlled documentation and design retention around transfer milestones. A broad retention bonus without a knowledge plan can preserve dependency rather than capability.
Data rights require separate analysis. Threat intelligence, mission telemetry and incident records may be owned by customers or limited to service delivery. The target may have permission to process data without a right to reuse it for product development or another customer. The valuation should recognise only the data rights that transfer and can lawfully support the forecast.
15 Build the evidence-linked revenue model
The revenue model should reconcile contracts, order forms, task orders, acceptance, invoices, collections and deferred revenue. It should identify programme ceilings, funded amounts, options, termination rights, milestone dependencies and pass-through costs. Government and prime-contractor revenue may require additional analysis of appropriations, security access, subcontract status and audit rights.
Each revenue line should be tagged by heritage evidence, control dependencies and transfer requirements. A recurring managed-service contract with accepted production performance and transferable staff can receive high confidence. A framework agreement dependent on a future spacecraft interface, customer accreditation and unbuilt features should receive lower confidence and explicit completion capital.
Forecast margin should include mission support, security operations, cloud, ground access, assurance, vulnerability response, insurance and customer-specific engineering. These costs can be hidden in research, central IT or founder labour. Normalisation should preserve the resources required to meet customer and control obligations.
16 Quantify remediation capital
Remediation should be organised by mission consequence, contractual exposure and value dependency. Critical actions may include closing unauthorised command paths, rotating keys, isolating build systems, protecting signing infrastructure, removing unsupported components and restoring monitoring coverage. Other actions may improve efficiency or future market access. The plan should identify owner, cost, duration, service impact, customer approval and evidence of completion.
The buyer should distinguish one-time remediation from recurring operating cost. New tooling can require licences, specialists, monitoring and governance. A secure-development reset can slow releases. Customer reapproval can delay revenue. These effects should enter cash flow and covenant planning rather than appear as a single purchase-price deduction.
Remediation estimates should carry ranges and dependencies. A code vulnerability may require a limited patch or an architecture change after deeper investigation. The model should include contingency for uncertain high-consequence items and use escrow or contingent consideration when the seller controls the evidence or action before closing.
17 Construct the valuation bridge
The starting value can use a revenue, EBITDA or discounted-cash-flow approach appropriate to the business. The evidence bridge then adjusts for revenue quality, control capability, remediation, customer concentration, transferability and strategic options. Each adjustment should connect to a forecast line, capital requirement, probability or contractual protection.
Heritage value should reflect supported revenue and reduced execution cost. Zero-trust value should reflect enforceable access, monitoring, recovery and customer assurance. Strategic value can include scarce clearances, approved integrations, mission data rights or access to specialised personnel. These benefits should be stated separately and should not duplicate cash flows already in the forecast.
The bridge should also record value that remains contingent. A product may become materially more valuable after completing an exact-configuration mission, deploying service identity across mission systems, passing customer accreditation or retaining a key programme. Contingent consideration can align payment with those outcomes when the metric is objective and the buyer can operate the business without suppressing the result.
18 Design transaction protections
Representations should address ownership, code provenance, security controls, incidents, vulnerabilities, customer statements, access, data rights, export controls and compliance. The disclosure process should identify known exceptions with sufficient detail for pricing and remediation. Generic cyber representations provide limited protection when the material issue is a specific command path, customer accreditation or unsupported component.
Conditions to closing can cover customer or government consent, key rotation, removal of seller access, transfer of repositories, delivery of configuration records and closure of critical vulnerabilities. Interim covenants should preserve security posture, staffing, incident notification and customer relationships. The buyer should control changes that could alter the evidence supporting value.
Escrow, specific indemnities, retention and contingent consideration should address different risks. Known quantified exposures may support a specific indemnity or price adjustment. Uncertain evidence-dependent value may support an earn-out or milestone. Retention should support knowledge transfer and operational continuity. The transaction structure should avoid paying twice for the same protection.
19 Plan Day One and the first 100 days
Day One priorities are access control, continuity, incident coordination and customer confidence. The buyer should establish authorised administrators, emergency contacts, logging, key-custody decisions, repository control, change approval and customer communications. Integration should avoid broad network connection until trust boundaries and dependencies are understood.
The first 30 days should validate identities, privileged paths, critical vulnerabilities, backup restoration, signing infrastructure and contractual deadlines. Days 31 to 60 should close material segmentation and service-identity gaps, launch cryptographic migration, reconcile customer assurance and fund the remediation backlog. Days 61 to 100 should complete priority control deployment, exercise incident and continuity procedures, confirm evidence ownership and refresh the valuation case.
Integration metrics should measure outcomes: privileged accounts reduced, mission paths covered, critical logs reconciled, builds reproducible, keys controlled, restores tested, exceptions closed and customers retained. Tool deployment alone is insufficient. The board should receive a concise evidence dashboard and decisions requiring capital or risk acceptance.
20 Establish board approval gates
The board should approve the transaction through linked gates. The perimeter gate confirms that material assets, people, rights and dependencies transfer. The heritage gate confirms the scope and quality of mission evidence. The control gate confirms enforced identity, segmentation, monitoring, cryptography and recovery. The commercial gate reconciles evidence to revenue, margin and cash. The transaction gate confirms that price and protection follow supported value.
Each gate should have an owner, evidence package and failure response. A failed gate can require remediation, lower price, deferred consideration, a condition to closing or termination. The decision record should identify management assumptions and ranges. It should also state which risks are accepted and why.
The board should revisit the acquisition case after closing. If heritage evidence, customer retention or remediation differs from the model, capital allocation and contingent payments should adjust. This discipline turns diligence into an operating control rather than an archive.
21 Hypothetical acquisition case
Assume a strategic buyer evaluates a space cybersecurity target that provides ground-segment monitoring, mission identity, secure deployment and incident-response services. The target reports USD 92 million of annual revenue, USD 18 million of EBITDA and a USD 420 million headline enterprise value. All amounts and probabilities in this case are hypothetical management assumptions created only to demonstrate the framework. They do not describe a real company or transaction.
The seller identifies USD 60 million of revenue as supported by flight heritage. The buyer's reconciliation finds USD 38 million tied to exact configurations with accepted mission records, USD 14 million tied to derivative configurations with bounded changes, and USD 8 million tied to programmes that use the heritage label without sufficient configuration evidence. Remaining revenue includes enterprise services, development work and early deployments.
Control testing finds strong corporate identity, endpoint management and central monitoring. Mission-system service identities are incomplete; several vendor paths retain standing privilege; cryptographic inventory is fragmented; two legacy ground components cannot support the preferred authentication method; and recovery exercises have not tested loss of the seller's identity tenant. The buyer estimates USD 26 million of one-time remediation and integration capital over 24 months, plus USD 6 million of additional annual operating cost at stabilisation.
The valuation bridge reduces value for unsupported revenue, recurring cost, remediation, customer concentration and transfer risk. It recognises strategic value for accepted mission integrations, specialised personnel and verified customer relationships. The resulting cash value at closing is USD 315 million. Up to USD 45 million is payable for exact-configuration acceptance, mission-system zero-trust deployment, customer retention and collected cash. The buyer also funds the remediation plan and retains termination rights if critical customer or government approvals fail.
22 Interpretation of the hypothetical results
The case shows why flight heritage and zero trust should not be reduced to binary labels. The target has real mission evidence and valuable controls, but the evidence does not cover every revenue stream or every deployed configuration. A broad premium would overpay for unsupported scope. A broad discount would ignore accepted integrations and scarce operating capability.
The bridge also distinguishes purchase price from capital requirement. The buyer pays for supported cash flow and strategic capability, then funds controls needed for continuity and growth. Contingent consideration preserves upside when the seller's claims become evidenced. It also gives the transaction team a clear metric set for post-close governance.
The approach remains sensitive to assumptions. A severe customer loss, failed accreditation or discovery of unauthorised access could reduce value further. Faster remediation, stronger exact-configuration evidence or transferable government approvals could increase value. The investment committee should therefore review central, adverse and severe cases and confirm liquidity under each.
23 Limits of the framework
This framework organises transaction decisions. It does not replace technical testing, legal advice, export-control review, security accreditation, accounting judgment, tax advice or customer consent. Space systems differ materially by mission, orbit, payload, customer, jurisdiction and architecture. A control appropriate for a cloud-native ground service may not be feasible on a legacy spacecraft.
Public guidance provides principles and control baselines. It does not verify the posture of a specific target. Buyers should obtain primary evidence, conduct authorised testing and use specialists with space, cyber, finance and transaction experience. Classified or export-controlled information requires approved handling and may limit the diligence team.
The hypothetical valuation is illustrative. It does not provide a market multiple, forecast or investment recommendation. Every amount is a management assumption used to show how evidence can affect price and structure.
24 Run a configuration delta review
The configuration delta review should begin with the last accepted mission baseline and end with the product expected to generate forecast revenue. The team should compare hardware, firmware, operating system, libraries, cryptographic modules, deployment environment, interfaces, data models, autonomy, command logic and customer-specific modifications. Each difference should be classified by mission consequence, verification status and customer approval requirement. A controlled delta record allows the buyer to preserve legitimate heritage while identifying the work needed before a broader claim can be used.
The review should include negative evidence. An anomaly, failed test or deferred defect does not automatically eliminate value. It can demonstrate that the target has a functioning detection, investigation and corrective-action process. The buyer should examine root-cause analysis, containment, regression testing, configuration updates and customer acceptance. Repeated unresolved anomalies, undocumented waivers or discrepancies between internal and customer records should reduce evidence confidence.
The delta review also supports purchase accounting and integration planning. A documented, transferable and maintainable platform can support identifiable technology value. Material dependence on undocumented know-how, customer-controlled environments or seller infrastructure can shorten useful life or increase replacement cost. The finance, technology and transaction teams should use one agreed configuration record rather than separate commercial and technical narratives.
25 Test control portability after ownership change
Cyber controls can appear mature inside the seller's environment and become fragile during separation. Identity, logging, ticketing, key management, code signing, cloud tenancy, threat intelligence and security operations may depend on shared services. The buyer should map every control to its owner, technology, data source, contract, administrator and exit route. A control receives full transaction credit only when it can transfer, remain under an enforceable transition service or be replaced within the funded plan.
Portability testing should include a simulated change of authority. The target should demonstrate how administrators are approved, how seller access is revoked, how customer credentials remain valid, how logs continue to flow, and how incident responsibility changes. The exercise should identify actions required before legal completion and actions that can follow under controlled transition. It should also confirm that a rushed cutover will not interrupt mission service or destroy evidence.
The buyer should price duplicate operating periods. Secure migration often requires old and new identity, monitoring or signing systems to run together while customers approve the new state. Dual running creates licence, engineering and assurance cost. The model should include those costs and the liquidity needed if customer acceptance takes longer than planned.
26 Link cyber evidence to customer economics
Customer value should be observed through renewal, expansion, pricing, accepted performance and cash collection. A sophisticated control environment can support those outcomes, but the relationship should be demonstrated. The buyer should compare control milestones with contract awards, assurance findings, service credits, renewals and customer contribution. It should avoid attributing every commercial result to cybersecurity when product capability, procurement, mission success and relationships also matter.
The most valuable evidence often appears at the boundary between technical assurance and customer operation. Examples include a reduced accreditation cycle, a successful mission recovery, a secure integration accepted by a prime contractor, or a command-path control required for a programme award. These events can support a price premium when the associated revenue, margin and transfer rights are documented.
Customer concentration changes the value of control evidence. A capability accepted by one large customer may be technically strong while remaining commercially dependent on that programme. The buyer should test portability to other customers, the cost of separate accreditation and the rights to reuse integration work. Strategic value should reflect the addressable opportunity after these constraints, not the size of the original programme alone.
27 Maintain an evidence room after closing
The transaction evidence room should become an operating evidence system. It should retain configuration baselines, release provenance, access reviews, key ceremonies, incident records, recovery tests, customer approvals, contract changes, remediation evidence and contingent-consideration calculations. Each record should have an owner, retention period, access rule and link to the relevant control or financial assumption.
This record supports several post-close needs. It allows the board to monitor whether the acquisition thesis is being delivered. It supports customer assurance and regulator engagement. It gives finance a basis for impairment, useful-life and contingent-consideration judgments. It also reduces dependence on individual recollection when personnel change.
The evidence system should show exceptions and stale records. A dashboard that reports only completed controls can hide unresolved risk. The board should see overdue actions, unsupported claims, customer dependencies, expiring certificates, untested recovery routes and milestones at risk. The same evidence should support decisions to invest, delay integration, renegotiate a customer commitment or withhold contingent payment.
Conclusion
Space cybersecurity M&A requires the buyer to value an operating evidence system. Flight heritage should be tied to exact configuration, environment, duration, records and customer acceptance. Zero-trust capability should be tied to enforced identity, policy, segmentation, telemetry, cryptography, recovery and secure development across the systems that create mission value.
The recommended process is direct: define the mission-assurance perimeter; build the heritage evidence ladder; test controls through observed operation; reconcile claims to contracts, cash and capital; and structure consideration around supported and contingent value. The same evidence should drive Day One access, the remediation roadmap and board monitoring.
This discipline produces a more defensible transaction. It rewards capability that can be demonstrated and transferred. It directs remediation toward mission consequences. It preserves upside when evidence matures. Most importantly, it gives directors a clear account of what they are buying, what must change after closing and which conditions support the price.
Proposed transaction evidence hierarchy; a broader claim requires broader configuration and operating evidence.
Proposed diligence map from development through customer delivery; arrows indicate principal trust and data paths.
Illustrative control coverage from zero to five; scores are management assumptions for the hypothetical case.
Illustrative sequencing; customer approval and mission windows determine final timing.
Illustrative USD millions; all amounts are management assumptions used only to demonstrate the framework.
| Domain | Principal question | Primary evidence | Valuation consequence |
|---|---|---|---|
| Product | What configuration is sold and supported? | Release, architecture and support records | Revenue confidence and sustaining cost |
| Mission operations | Which functions affect command, telemetry or safety? | Procedures, logs and witnessed exercises | Liability and service continuity |
| Development | Can software be changed and reproduced securely? | Repositories, pipelines and signed builds | Product value and remediation capital |
| Identity | Who and what can access each resource? | Directory, service identity and privilege records | Control coverage and separation cost |
| Cryptography | Which algorithms, keys and modules protect value? | Inventory, custody and migration plan | Obsolescence and customer approval |
| Customers | Which rights, approvals and revenues transfer? | Contracts, acceptance and collections | Forecast cash and transaction conditions |
Proposed minimum scope; the perimeter should be adapted to the target and customer obligations.
| Tier | Evidence | Revenue treatment | Transaction response |
|---|---|---|---|
| Exact configuration | Accepted mission record reconciled to current configuration | Highest confidence subject to contract quality | Include in base case |
| Bounded derivative | Documented changes with relevant qualification and customer path | Probability weighted | Fund remaining test and approval |
| Demonstrated | Controlled test or limited mission use without repeat evidence | Scenario value | Use milestone consideration |
| Claimed | Marketing, proposal or unsupported reference | Exclude from base case | Require evidence or remove claim |
| Obsolete heritage | Earlier success with unsupported or non-transferable configuration | Cost and liability review | Rebuild, isolate or discontinue |
Proposed classification for transaction valuation.
| Domain | Evidence of operating capability | Common transaction gap | Cash consequence |
|---|---|---|---|
| Human identity | Strong authentication, role and review records | Shared or dormant accounts | Migration and exception closure |
| Service identity | Workload credentials, policy and rotation | Static secrets and unknown services | Engineering and outage risk |
| Policy enforcement | Tested decision and enforcement points | Diagrams without observed blocking | Re-architecture cost |
| Privileged access | Approval, time limit, recording and revocation | Permanent vendor access | Tooling and separation cost |
| Telemetry | Covered sources, detections and response records | Missing mission logs | New collection and analysts |
| Recovery | Restored trusted service in an exercise | Untested backups | Continuity capital |
| Cryptography | Inventory, custody, agility and customer approval | Unknown algorithms and keys | Migration and reaccreditation |
Proposed evidence set based on resource-focused zero-trust principles.
| Exposure | Diligence question | Evidence | Transaction treatment |
|---|---|---|---|
| Change of control | Is consent or reaccreditation required? | Contract and authority record | Closing condition or deferred value |
| Security representation | Do customer statements match operation? | Questionnaire and control test | Disclosure, remediation or indemnity |
| Incident notification | Were events reported on time? | Incident and notification log | Liability reserve and covenant |
| Data rights | Can telemetry and threat data transfer and be reused? | Contract, consent and processing record | Exclude unsupported data value |
| Export control | Can code, hardware and support transfer? | Classification and licences | Structure access and conditions |
| Critical infrastructure | Do ownership or resilience rules apply? | Legal analysis and regulator record | Approval timetable and governance |
Proposed review; local counsel and security authorities determine applicable requirements.
| Item | Reported or headline | Evidence adjustment | Transaction case |
|---|---|---|---|
| Annual revenue | 92 | -8 unsupported heritage exposure | 84 supported or probability-weighted |
| EBITDA | 18 | -6 recurring control cost | 12 normalised |
| One-time remediation | 0 | -26 funded programme | -26 capital requirement |
| Headline enterprise value | 420 | -125 net evidence and risk adjustments | 315 cash at closing |
| Contingent consideration | 0 | +45 subject to objective milestones | Up to 45 after evidence |
Illustrative USD millions; all amounts are management assumptions and describe no existing company.
| Risk | Preferred mechanism | Release or claim evidence | Governance |
|---|---|---|---|
| Missing critical consent | Condition to closing | Written approval | Buyer control of waiver |
| Unsupported heritage | Contingent consideration | Accepted exact-configuration evidence | Independent verification |
| Known vulnerability | Price adjustment or specific indemnity | Closed finding and customer acceptance | Defined test and deadline |
| Customer retention | Earn-out tied to contribution and collections | Contract, invoice and cash | Accounting policy and audit right |
| Knowledge concentration | Retention tied to transfer milestones | Documentation and witnessed operation | Named owner and succession |
| Seller access | Closing covenant and technical cutover | Access reconciliation and key rotation | Day One control |
Proposed allocation by risk type.
| Period | Priority | Evidence of completion | Board decision |
|---|---|---|---|
| Day One | Identity, incident contacts, repository and key control | Reconciled access and custody | Accept opening risk |
| Days 1 to 30 | Validate privilege, logs, backups and critical findings | Tests and exception register | Fund urgent remediation |
| Days 31 to 60 | Deploy service identity and segmentation priorities | Observed enforcement | Approve customer migration |
| Days 61 to 100 | Exercise continuity and close priority gaps | Witnessed recovery and control evidence | Refresh value case |
| Ongoing | Crypto migration, customer assurance and metrics | Accepted milestones and collections | Release contingent value |
Proposed sequence; mission and customer constraints determine exact timing.
Sources
- National Institute of Standards and Technology, SP 800-207 Zero Trust Architecture, 2020. Read the primary source
- National Institute of Standards and Technology, SP 800-207A A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Location Environments, 2023. Read the primary source
- National Institute of Standards and Technology, SP 1800-35 Implementing a Zero Trust Architecture, 2025. Read the primary source
- National Institute of Standards and Technology, Cybersecurity Framework 2.0, 2024. Read the primary source
- National Institute of Standards and Technology, SP 800-53 Revision 5 Security and Privacy Controls for Information Systems and Organizations. Read the primary source
- National Institute of Standards and Technology, SP 800-218 Secure Software Development Framework Version 1.1, 2022. 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
- Cybersecurity and Infrastructure Security Agency, Recommendations to Space System Operators for Improving Cybersecurity, 2024. Read the primary source
- National Aeronautics and Space Administration, Space Security Best Practices Guide, 2023. Read the primary source
- National Aeronautics and Space Administration, Space Security Best Practices Guide, Software Engineering Handbook. Read the primary source
- National Aeronautics and Space Administration, NASA-STD-1006A Space System Protection Standard, 2022. Read the primary source
- National Aeronautics and Space Administration, Technology Readiness Levels, 2023. Read the primary source
- National Aeronautics and Space Administration, Systems Engineering Handbook Appendix, 2023. Read the primary source
- National Aeronautics and Space Administration, Software Technology Readiness Levels and Milestone Review Alignment. Read the primary source
- European Union Agency for Cybersecurity, ENISA Space Threat Landscape 2025. Read the primary source
- United Kingdom Space Agency, Cyber Security Toolkit, 2021. Read the primary source
- United Kingdom National Cyber Security Centre, Supply Chain Security Guidance. Read the primary source
- United Kingdom National Cyber Security Centre, Cyber Assessment Framework. Read the primary source
- United States Government Accountability Office, NASA Cybersecurity: Protection of Spacecraft and Systems, GAO-24-106624, 2024. Read the primary source
- United States Government Accountability Office, NASA Cybersecurity: Risk Management, GAO-25-108138, 2025. Read the primary source
- National Institute of Standards and Technology, NISTIR 8401 Satellite Ground Segment: Applying the Cybersecurity Framework to Satellite Command and Control. Read the primary source
- The White House, Space Policy Directive 5 Cybersecurity Principles for Space Systems, 2020. Read the primary source
- United States Department of Defense, Department of Defense Zero Trust Strategy, 2022. Read the primary source
- United States Securities and Exchange Commission, Cybersecurity Risk Management Strategy Governance and Incident Disclosure, 2023. Read the primary source
- European Union, Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union. Read the primary source
- European Union, Regulation (EU) 2024/2847 Cyber Resilience Act. Read the primary source
- IFRS Foundation, IFRS 3 Business Combinations. Read the primary source
- IFRS Foundation, IFRS 13 Fair Value Measurement. Read the primary source
- United States Department of the Treasury, Committee on Foreign Investment in the United States. Read the primary source
- United States Department of Justice and Federal Trade Commission, Merger Guidelines, 2023. Read the primary source
- European Commission, EU Merger Control. Read the primary source
- Consultative Committee for Space Data Systems, Security Working Group Publications. Read the primary source
