Launch Vehicle Liability for Rideshare Customers
Rideshare customers often discover their payloads aren't covered by launch provider insurance.
A smallsat operator signs a launch services agreement, books a slot on a rideshare mission, and then treats the launch provider's insurance as if it protects the whole venture. That assumption is wrong, and the gap between what the policy actually covers and what the operator thinks it covers is the subject of this piece. Rideshare missions now routinely carry dozens of payloads, sometimes more than a hundred, from customers spread across many countries, and that density of hardware packed into a single fairing is why the scope of the launch provider's insurance matters so much. The launch provider's third-party liability policy exists to protect people and property on the ground, in the air, and in other orbits, not the payload riding inside the rocket. Mapping exactly where that policy's obligations end and the customer's own uninsured exposure begins is the work this article sets out to do.
The U.S. legal framework that sets the liability floor for every commercial launch
Every commercial launch operates under a statutory scheme built by the Commercial Space Launch Act, and that scheme was written with one goal: protect the public from the fallout of a launch failure, not protect the people who paid to put a payload on the rocket. The CSLA sets up a two-tier system. In the first tier, the launch operator has to buy liability insurance up to a "maximum probable loss" figure that the FAA calculates for third-party claims arising from the launch. In the second tier, the federal government steps in to cover damages above that amount, up to a ceiling tied to 51 U.S.C. § 50915 and adjusted for inflation over time.
The law caps how much insurance is required rather than guaranteeing that every mission carries the maximum. Required third-party liability coverage is $500 million at most, and coverage for government property is a lower ceiling still. These are legal limits, not purchase defaults, and the FAA sets the actual required amount mission by mission. For Starship-Super Heavy flights out of Starbase, the FAA's license conditions call for a large liability figure tied to the flight itself and a much smaller figure tied to pre-flight ground operations, which shows how much the required coverage swings depending on the activity being insured and the specific license at issue.
The framework has a hole in it that matters enormously for payload customers: federal indemnification only applies to FAA-licensed activity, meaning licensed launches and reentries. Once a satellite separates and starts operating on orbit, activities like repositioning a spacecraft fall outside FAA licensing, and the indemnification backstop simply does not reach them. The statute was never built to follow a payload once it leaves the rocket.
How the launch provider's policy names the customer
Federal licensing rules require the launch operator to add a long list of parties as additional insureds on its third-party liability policy: its own contractors and subcontractors, the satellite customer and that customer's contractors and subcontractors, and the U.S. government along with its participating agencies. On paper, being named as an additional insured sounds like real protection, and in one specific sense, it is. It means that if the rocket causes harm, say, debris strikes a building or a piece of ground equipment is damaged, the payload customer is shielded from being personally sued over damage the rocket itself caused to someone else.
What additional insured status does not do is protect the payload itself. The coverage only reaches third-party bodily injury, death, and property damage, the kind of harm that falls on people and property outside the launch, not the customer's own hardware riding in the fairing. If the launch fails and destroys the satellite, the additional insured clause has nothing to say about the loss, since that loss falls on the customer alone and never touches a third party. It is the customer's own asset, and the policy was never built to reach inward toward the payload; it was built to reach outward, toward everyone standing outside the launch.
This is a different kind of coverage than what "additional insured" status typically means in a construction contract or a general commercial liability policy, where the term can sometimes stretch to cover a broader set of the insured party's own interests. In the launch context, the scope is narrower and more specific by design, carved out to match what the CSLA's public-protection purpose requires and nothing more.
The cross-waiver mechanism
If the statutory insurance framework defines what gets covered, the cross-waiver clause in the launch services agreement defines what does not, and it is the single most consequential provision most rideshare customers underestimate before they sign. A cross-waiver works by having every party involved in the launch agree not to sue each other over their own property losses, regardless of who caused them. The launch operator, its contractors and subcontractors at every tier, the U.S. government, and the customer (along with the customer's own contractors and subcontractors) all agree to absorb their own losses and release everyone else from liability for those losses. Published rideshare agreements make the customer alone responsible for loss or damage to its own payload, from static fire testing through on-orbit operation, and the customer has to waive subrogation against the launch provider and its related parties.
Subrogation is the mechanism that lets an insurer, after paying out a claim, step into its policyholder's shoes and go after whoever actually caused the loss. Waiving subrogation means that even if the customer buys its own insurance and that insurer pays out after a launch failure, the insurer cannot turn around and sue the launch operator to recover what it paid. So the recovery path a customer might expect to have is closed off.
The consequence runs deeper than a missed insurance recovery. Even in a scenario where the launch operator's own negligence destroys the payload, the cross-waiver blocks the customer from bringing a tort claim over it. This is the deliberate architecture of how rideshare missions get priced and insured, built so that each party bears its own risk rather than pushing it onto everyone else through litigation. The same structure runs in both directions: the customer is also on the hook for any third-party harm its own payload causes once it's on orbit, so if the satellite causes damage after separation, that liability sits with the customer alone, not the launch provider.
The four exposures a rideshare customer owns outright after the cross-waiver takes effect
Once the statutory floor and the cross-waiver are both on the table, the rideshare customer's actual exposure sorts into four distinct categories, and each one deserves its own answer before launch day rather than a single blanket assumption that "insurance has it covered."
The first category is loss of or damage to the payload itself during launch or separation. If the rocket fails before the satellite separates cleanly, that loss belongs entirely to the customer; the launch provider's third-party liability policy was never built to respond to it, and the cross-waiver forecloses any claim against the operator over it.
The second category comes from the mission's own density: on a rideshare flight carrying dozens or more than a hundred satellites, another customer's hardware can fail in a way that damages or interferes with a neighboring payload, whether through a deployment malfunction, debris generation, or some other failure mode. The cross-waiver structure limits what recourse exists against the launch provider in that scenario, and recourse against the other customer directly is limited as well, since each party has generally agreed to bear its own losses.
The third category begins the moment the satellite reaches orbit, because on-orbit activity sits outside FAA licensing and the CSLA's indemnification regime stops applying there. From that point forward, commercial in-orbit insurance is the only mechanism available to address an anomaly, a failed deployment, or a satellite that never comes alive, and buying that coverage is not a legal requirement for smallsat operators, only a commercial choice.
The fourth category is third-party liability caused by the customer's own payload once it's operating on orbit, whether through generated debris, a collision, or interference that leads to physical damage elsewhere. The launch provider's agreement explicitly assigns this liability back to the customer, and it does not expire at deployment; it persists for as long as the satellite is operational.
Why smallsat operators routinely self-insure payload loss
Because in-orbit insurance is not a legal requirement, a large share of smallsat operators choose to go without it and self-insure instead, particularly for cubesats and short-lived imaging missions where the premium cost can outweigh the asset's value. This is a standard, defensible market practice, not a sign of carelessness. Operators flying inexpensive, short-duration missions often conclude, reasonably, that the cost of a policy isn't worth it against an asset that was cheap to build and was never expected to last more than a year or two in orbit.
That calculus changes sharply as the value of the asset climbs. A single geostationary communications satellite, launch included, can run well into the hundreds of millions of dollars, a level of exposure that sits far beyond what most companies' balance sheets can absorb in a single write-off and well beyond what most project financiers will tolerate going uninsured. Launch insurance, where it's purchased, typically costs a few percent of the satellite's insured value, a real expense but a modest one set against the alternative of a total, uninsured loss on an asset worth hundreds of millions.
The rational choice to self-insure also depends on what happens after separation, not just what the satellite cost to build. A cubesat with a short operational life flying in a low, well-characterized, low-debris orbit carries a materially different on-orbit liability profile than a satellite meant to operate for years in a congested orbital regime, where the odds of a collision or interference event causing third-party harm rise accordingly. Self-insurance that makes sense for the first case can be a poor fit for the second, even if the hardware cost looks similar on paper.
Insurance requirements in enterprise and government contracts
A rideshare customer's insurance obligations do not end once the launch services agreement is signed. Enterprise anchor customers and government agencies that buy data or capacity from a satellite operator routinely set their own insurance minimums in the contracts downstream of the launch, and the launch provider's policy was never designed to satisfy them. The exposure most likely to trigger this requirement is the same one the launch provider explicitly hands back to the customer: third-party liability arising from the customer's own satellite. A government payload integration agreement or a commercial data-purchase contract will often name that liability directly and require the operator to prove it carries coverage for it.
If operators hold their own FAA authorizations for their space activities, separate from the launch license itself, they carry an independent regulatory insurance obligation tied to that authorization, one that exists regardless of what the launch operator's policy covers. Assuming the launch provider's coverage satisfies a downstream contract's insurance clause is a mistake with consequences beyond an uncovered loss: a customer that has not independently sourced the coverage a government or enterprise contract requires can be in technical breach of that contract from the day it's signed, whether or not anything ever goes wrong in orbit. That turns a coverage gap into a commercial problem that can block a deal entirely, not just a balance-sheet risk sitting quietly in the background.
Reading a launch services agreement for coverage gaps
The launch services agreement is where the statutory framework and the cross-waiver turn into specific, enforceable language, and reading it carefully, with the exposure map above in mind, turns an abstract risk into concrete questions to bring to counsel and a broker. Three sections of the agreement deserve close attention before signing. The indemnification and cross-waiver provision spells out precisely what the customer is agreeing to absorb and release. The insurance requirements section specifies what the customer has to procure on its own, and at what limits, rather than what the launch provider is assumed to supply. The definitions of "payload" and "payload-related equipment" determine what hardware falls under the customer's exclusive responsibility once the cross-waiver takes effect.
Customers flying through an aggregator face an extra layer of diligence. The cross-waiver and insurance terms in an aggregator's contract generally mirror the upstream launch services agreement between the aggregator and the launch operator, because federal rules require that waiver structure to flow down through every contractual tier. A customer working through an aggregator should ask to see that upstream agreement directly, or at minimum get clear confirmation of exactly which clauses flow down into its own contract, since visibility into the terms actually governing the mission can otherwise be limited.
On-orbit liability is the area most likely to go unaddressed in the agreement. If the contract is silent on what happens after separation, that silence should never be read as a form of protection. The CSLA's structural gap around on-orbit activity and the cross-waiver's broad release combine to leave that risk with the customer by default, whether the agreement says so explicitly or simply never raises the question.
The coverage lines that address what the launch provider's policy leaves open
Each of the four exposures mapped above has a corresponding insurance product built to address it, and no single policy covers all four at once. Assembling coverage for a rideshare mission means treating it as a program with distinct pieces, not a single purchase.
Launch insurance is the product built for the first exposure, loss or damage to the payload from ignition through separation. It is typically written to respond across that specific window, and it can sometimes extend through on-orbit checkout, so it works as the primary tool against failure during the launch phase itself. In-orbit insurance picks up where launch insurance leaves off, covering the satellite against loss or anomaly once it's separated and operating; it is not legally required for smallsats, but it becomes the only mechanism standing between the operator and a total loss once the CSLA's indemnification regime no longer applies. Third-party liability coverage for on-orbit operations addresses the exposure the launch provider's agreement explicitly hands back to the customer, claims arising from the satellite causing harm once it's in orbit, and it is the coverage line most often absent from smallsat operators' programs, largely because it sits outside the launch phase that gets the most attention during contract negotiation. Technology errors and omissions coverage matters for satellites delivering a commercial service, remote sensing, data relay, or communications, since a software or system failure that interrupts that service or causes a customer's data loss can trigger a claim that neither launch insurance nor general liability was ever built to answer.
Put together, these four lines map directly onto the four exposures the cross-waiver leaves with the customer. None of them come bundled with the launch services agreement, and none of them are optional in the sense of being unnecessary; they are optional only in the legal sense that no statute compels most operators to buy them. Deciding which ones to carry, and at what limits, is the real work that follows from understanding exactly where the launch provider's coverage stops.
