When a rideshare launch scrapes a payload fairing or a Ku-band antenna refuses to deploy, insurance is the backstop that keeps a satellite startup alive. Yet in 2026, the fastest-growing constellation builders are discovering that a signed policy isn’t the same as being covered. The problem is rarely the premium. It is the exclusion-rich fine print lurking in otherwise standard satellite insurance 101 documents. For startups, the difference between a smooth indemnity payment and a total write-off often comes down to how well they spot mission-killing exclusions before signing.
This isn’t an argument for skipping insurance. Rather, it is a call to read beyond the coverage summary and scrutinize the schedule of exclusions, warranty conditions, and endorsement riders that underwriters add to protect themselves from the messy realities of modern small satellites. Here are the most common, and most dangerous, coverage gaps hiding in current-launch-era satellite policies — and how to negotiate around them.
The Exclusion That Defines Your Mission
Most new-space operators assume that an “all risks” satellite policy covers any physical loss or damage during launch, orbit raising, and initial in-orbit testing. That assumption is the first gap. An all-risks policy in the satellite world is usually broad only for the launch phase. Once the satellite separates and begins its journey to final orbit, the policy transitions into a set of highly conditional coverages tied to performance milestones. If your spacecraft misses a critical milestone due to an excluded cause, the insurer may deny the entire claim — even for damage that later appears unrelated.
Startups should treat the policy as a map of prohibited behavior, not just a safety net. The exclusions below are the ones that have quietly ended missions over the past few years, and they are especially common in policies written for microsatellites and ESPA-class payloads.
Collision Avoidance Maneuvers: The Propulsion Catch
Orbital debris is a growing threat, and any satellite launched after 2025 will likely have a collision avoidance protocol. Insurers know this. They also know that active debris avoidance burns fuel, reduces station-keeping margin, and can introduce unexpected attitude control stress. As a result, many policies include an exclusion that voids coverage for any damage resulting from a collision avoidance maneuver that wasn’t pre-approved by the insurer in writing.
The problem for startups is operational: you may have only hours to react to a conjunction alert. Waiting for a written approval from an underwriter in a different time zone is not practical. Yet if you execute the maneuver and something goes wrong — for example, a reaction wheel desaturates and the thruster misaligns — the insurer can argue that the maneuver itself was the proximate cause of the anomaly and the exclusion applies.
What to look for: read the exclusions section for the exact wording around “evasive actions” or “orbital avoidance operations.” Some policies allow for prior notification within 24 hours after the maneuver, while others demand pre-approval. Push for the post-facto notification option. A simple change in the reporting requirement can mean the difference between a covered anomaly and an uninsured collision-avoidance failure.
Software-Defined Payload Failures: The Quiet Denial
Software-defined radios, reconfigurable beamforming antennas, and AI-driven star trackers are now standard on most startup missions. These components are also a favorite target for insurers seeking to limit their exposure. The emerging standard exclusion is blunt: “No coverage shall be provided for any loss or damage attributable to the malfunction, misconfiguration, or unintended behavior of onboard software, including firmware updates, uploaded commands, or autonomous decision-making routines.”
That language is mission-killing for a constellation whose whole value proposition relies on in-flight reconfiguration. If your satellite runs into a jammed phase shifter caused by a software command sequence, the underwriter can deny the claim by pointing to the software exclusion — even if the physical hardware burned out as a direct result of that software command.
Startups should not accept this exclusion wholesale. Ask your broker to carve out coverage for “physical damage caused by a software command” while still excluding purely logical or cyber-event losses. Some specialty insurers offer software-caused-and-causing endorsements that cover the hardware consequences of a coding error, provided the code was uploaded before the loss and can be forensically verified.
The Ground Segment Dependency Trap
Satellite insurance is often sold as if the spacecraft exists in a vacuum. But any satellite’s health depends on the ground segment. This is where a particularly insidious exclusion appears: the policy may exclude coverage for satellite anomalies that occur while the satellite is not in direct line of sight with a ground station, or anomalies that are not detected until after a data outage. The theory is that the underwriter cannot verify the exact time and cause of the failure without continuous telemetry.
Startups with sparse ground networks or networks built on shared partner stations are especially vulnerable. Imagine a battery overdischarge event that happens during an eclipse while the satellite is over the Pacific and no ground station is available. When telemetry is reacquired and the discharge is discovered, the insurer may deny the claim because the start of the loss could not be substantiated with continuous data. The exclusion is often called the “loss verification” exception.
Before signing, review the policy’s definition of “first knowledge of loss.” Insist on language that recognizes packet-gap telemetry and allows for post-event reconstruction using onboard engineering models. If your ground architecture relies on third-party stations, list those stations in the policy schedule — otherwise the insurer may argue that a station’s downtime is an excluded concurrent cause.
Launch Window Delays and Assembly Integration
Insurance is meant to cover sudden and accidental losses. But a launch delay caused by a range scheduling conflict is not an accident; it’s a business risk. Most startup satellite insurance policies include an exclusion for “any delay, postponement, or rescheduling of the launch, regardless of the underlying cause, except as covered by a separate launch delay policy.” If your satellite’s battery capacity degrades while waiting in a cleanroom for weeks longer than planned, the resulting loss of mission life will not be covered under your launch policy. It falls under non-operative degradation, which is explicitly excluded in standard wording.
What can you do? Purchase separate launch delay coverage or negotiate a “pre-launch battery degradation” endorsement if your satellite uses lithium-ion cells. For startups with electric propulsion, the extra time in the payload integration facility also means additional power cycling, and the policy should acknowledge that as a covered risk if the launch provider is solely responsible for the delay.
How To Negotiate a Broker-Friendly Exclusion Schedule
Don’t simply accept the first draft policy sent by the broker. Ask for a review session that goes line by line through the exclusions. Most brokers will accommodate this if you frame it as a risk mitigation exercise. A few practical strategies:
- Create a mission risk matrix: List every anomaly that could plausibly occur in the first 90 days, then map each one to policy exclusions. You’ll discover gaps faster than any executive summary.
- Use a technical rider: Add a rider that defines “covered anomaly” broadly enough to include software-induced hardware failures and ground-link loss events.
- Negotiate a “predominant cause” clause: This states that if a loss has multiple causes, insurance responds if the predominant cause is not excluded. Without this clause, any contributing excluded cause can void the claim.
- Cap the exclusion bucket: Ask for a sub-limit that provides some coverage even for excluded causes, usually 10% of the policy limit, so a mission can recover partial value even if the worst happens.
The satellite insurance market has become more sophisticated, but the standard policy forms have not kept pace with the architecture of modern small satellites. Startups that rely on generic templates will inherit generic exclusions.
A Practical Review Process Before Signing
Gather your engineering lead, your outside counsel, and your broker for a single face-to-face or video review. Provide them with a list of your satellite’s unusual features: autonomous collision avoidance, star tracker software updates, reconfigurable payload, or a ground network with limited contact time. Then work backward from each exclusion to see whether that feature is inadvertently caught in the language.
One specific trap is the “orbital debris mitigation plan” warranty. Most policies require that you comply with your own debris mitigation plan as filed with the FCC or a national agency. If you later deviate from that plan, even with the approval of a regulator, the insurer can void coverage. Make sure your policy says “non-compliance with the debris mitigation plan shall not void coverage unless it directly contributes to the loss.” That nuance is worth the cost of a lawyer for half a day.
Conclusion
Satellite insurance should be a strategic tool, not an afterthought. The exclusions that sink startups are not the obvious ones about war or nuclear contamination — they are the everyday clauses about software, collision avoidance, ground connectivity, and launch delays. By reading those sections closely, negotiating for a predominant cause clause, and building the policy around your actual mission architecture, you can close the costly gaps before they become operational risks. The goal is not to get the cheapest policy, but to get one that pays when your satellite hits an unexpected moment of truth. When that moment arrives, a fully covered anomaly is just a line item in the annual report — and an uncovered one is the end of your company.
