End-of-life plans in a satellite-service supplier assessment

A satellite-service customer may never operate a spacecraft, yet the supplier's end-of-life decisions can affect its product, continuity and credibility. A service can depend on an asset approaching retirement, a replacement still being commissioned or a disposal plan whose assumptions have changed. These are commercial dependencies as well as space-sustainability questions.

The assessment should begin with evidence appropriate to the supplier's role. A reseller cannot necessarily provide the same records as a spacecraft operator. A hosting company may control some lifecycle decisions while relying on others. The customer's task is to establish what has been planned, who is accountable and what evidence will show that the plan remains credible.

Establish which baseline the claim refers to

A statement that a mission follows recognised sustainability requirements is incomplete without a named document, version and explanation of applicability. ESA's published document register separates its policy, technical standards and verification guidance. At the time of this review, it lists the space-debris mitigation requirements as issue 1, revision 1, dated 23 October 2025. A supplier citing an earlier edition should explain why that is the relevant baseline for its mission.

That does not mean every company must adopt the newest document in a public register immediately. It means the customer should be able to understand the relationship between the cited requirement and the actual project. A logo, membership or broad statement of support is a different kind of evidence from an identified requirement assessed against a particular spacecraft.

UNOOSA's background account of the long-term sustainability guidelines records their adoption by COPUOS in June 2019 and describes voluntary implementation. That international framework should not be confused with a specific supplier's contract conditions or other applicable requirements. The customer needs each claim to retain its actual scope.

A plan and a report answer different questions

The ESA standard's documentation requirements distinguish a mitigation plan describing intended compliance from a report describing implementation and verification. Its scope is ESA programmes and projects. The documentation table also provides for updates around relevant anomalies, mission changes or extensions and the end of a mission. This gives a useful model for evaluating evidence over time, without treating the standard as a universal rule for all suppliers.

A plan can show that an organisation identified the issue and assigned work. A report can show what evidence has been produced and assessed. Neither should be described as proof that a future disposal has already succeeded. The language used in a supplier comparison should preserve those stages.

This matters particularly for a young company with limited flight history. Its evidence may be primarily design assessment and verification work. That can still support a serious commercial discussion if the company states the limits and identifies what remains to be demonstrated. Inflating a planned capability into an achieved outcome makes the evidence less useful to a customer deciding how much dependency to accept.

Connect the spacecraft role to the service contract

Start by identifying the organisations behind the service. The customer may contract with a data company that purchases capacity from another provider, whose spacecraft is operated by a third organisation. The customer needs an accountable route for lifecycle questions even when it has no direct relationship with the operator.

The route should explain who maintains the relevant assessment, who decides whether the mission continues and who informs the customer when a decision changes the service. It need not expose detailed operational information. A commercial summary can identify the decision, evidence status and likely service effect without reproducing the operator's full technical record.

For hosted customers, the boundary is especially important. Ending an experiment, ending a hosting agreement and ending the spacecraft's mission are not necessarily the same event. BDI's hosted-payload integration guide addresses the initial allocation of responsibility; the lifecycle assessment should carry that responsibility through to the customer's exit.

A supplier should also distinguish its own commitment from a dependency on a future third-party service. A capability under development may improve the eventual plan, but it should not be presented as a purchased and available solution unless the supporting evidence establishes that status.

Review what has changed since the assessment

A document's age is relevant because the mission can change. The better question is which assumptions remain valid, rather than whether the report has a recently refreshed cover date. A new assessment should identify substantive changes and their effect on the conclusion.

An extension of the revenue-producing service is a clear review point. The business may benefit from more time in operation, but the lifecycle assessment needs to address the changed plan. A customer's renewal decision should therefore ask whether the extended service period has been considered in the relevant evidence and by the responsible decision-maker.

An unexpected event can also change the information available. The customer should know how the supplier reports a material revision to its lifecycle position and when that revision could affect service availability. Repeating the original plan without explaining new circumstances provides little help to a downstream business.

The comparison should preserve unresolved items. A condition awaiting verification can be tracked and discussed. Removing it from the summary because it is inconvenient makes the supplier appear more certain while leaving the customer's exposure unchanged.

Keep retirement and replacement on separate lines

Consider an illustrative analytics company renewing a subscription to satellite data. The supplier expects an existing mission to stop serving customers during the renewal period and intends to replace it with a new spacecraft. The new launch is announced, but the replacement data product has not completed customer acceptance.

The analytics company needs two evidence chains: the planned withdrawal of the current service and readiness of its replacement. A launch announcement alone cannot bridge them. The renewal should identify what happens if the replacement is later, provides a different product or becomes available only in stages.

BDI's guide to launch schedules and service-delivery risk explains why launch and usable service are distinct milestones. The retirement decision should be compared with the latter, because that is when the downstream company can actually transfer its dependency.

A transition period may allow parallel evaluation, but the customer should establish which costs and responsibilities it retains. Reprocessing historical work, changing ingestion software or explaining a changed dataset to end users can require effort even when the supplier offers the replacement at the same subscription price.

Retain evidence after the service ends

Closing the commercial service should not make its history disappear. The customer may need to explain which product version supported an earlier report, when access ended and which lifecycle statements were current during the contract. A durable handover should preserve the records needed for those questions.

The supplier's closing account should distinguish completed actions from remaining activities outside the customer's service period. If disposal remains a future event, describe it as such and identify the source of any later confirmation. Ending invoices is not evidence that all spacecraft lifecycle activity has concluded.

A useful supplier review consequently avoids a single sustainability score with an unexplained basis. It identifies the applicable baseline, responsible organisations, evidence status, changed assumptions and customer transition. That record supports a more precise decision about whether to start, renew or reduce a dependency on the service while keeping planned and achieved outcomes visibly separate.