May 2026: Continuity Cannot Depend on One Operator
Reviewed and revised:
The recent restrictions around commercial satellite imagery did not create a new problem.
They exposed an old one.
For years, Earth observation programs have treated supplier diversity as a procurement preference. Nice to have. Useful for price tension. Helpful when one constellation misses a collection window.
That is too small.
Supplier diversity is now an operational continuity requirement.
When a single operator, region, jurisdiction, licence model, distribution rule, or policy decision can interrupt access to imagery, the issue is no longer vendor management. It is infrastructure design.
The lesson from the latest US operator restrictions
The important point is not whether one provider made the right decision in one conflict zone.
The important point is that commercial access can change quickly when imagery becomes operationally sensitive.
Planet’s restrictions showed how access to fresh imagery can be delayed or withheld when national security concerns override normal commercial distribution. Vantor’s enhanced access controls showed the same broader pattern. BlackSky sits in the same strategic category for buyers that depend heavily on US-operated commercial imagery.
That does not make US operators unreliable.
It means US operators are not infrastructure by themselves.
They are inputs into infrastructure.
If a program depends on one operator, one country, one licensing pathway, or one commercial archive, then it has built a single point of failure into its operating model.
This is not a sensor problem
Most EO failure is not caused by a lack of satellites.
It is caused by brittle access.
A collection plan can fail because of weather, off-nadir constraints, revisit timing, regional restrictions, tasking priority, export controls, licensing terms, distribution rules, archive access delays, or customer eligibility.
Those risks do not disappear because the supplier is large.
They become more dangerous when the supplier is large enough that the customer stops designing for failure.
A serious EO program should assume disruption. Not as an exception. As a normal operating condition.
One vendor is not a continuity strategy
A single-vendor model is simple until it breaks.
When it breaks, the buyer usually discovers the same gaps:
- no secondary tasking pathway
- no equivalent archive source
- no licensing fallback
- no automated vendor substitution
- no normalized metadata across providers
- no entitlement model that survives provider change
- no common delivery state across operators
- no clean way to compare latency, quality, cost, and tasking confidence
At that point, the team is not switching vendors.
It is rebuilding the workflow under pressure.
That is exactly what infrastructure is meant to prevent.
Multi-region matters as much as multi-vendor
Vendor diversity is not enough if every fallback sits under the same jurisdictional, regulatory, or distribution risk.
A resilient EO architecture needs multi-region access.
That means the operating layer should be able to route demand across different operators, different regions, different data types, and different commercial models. It should know which providers can serve the area, which ones can legally distribute the data, which ones can meet latency, and which ones have archive depth.
The customer should not be manually discovering this during an incident.
The system should already know.
Failover needs to be designed before the outage
Failover is not a contact list.
It is not a spreadsheet of alternative suppliers.
It is not someone emailing three account managers and hoping one replies quickly.
Real failover requires pre-integrated supplier pathways, normalized ordering, comparable metadata, entitlement-aware dissemination, and delivery states that are consistent across providers.
When a primary source is constrained, the workflow should not stop. It should evaluate alternatives:
- Can another optical provider meet the requirement?
- Is SAR more appropriate because of weather or conflict conditions?
- Is archive sufficient?
- Is lower resolution acceptable for the mission?
- Is a non-US operator required?
- Does licensing permit internal use, partner sharing, or public release?
- Can the result be delivered into the same downstream system without manual rework?
That is the difference between supplier optionality and operational continuity.
Why EODI is the core layer
EODI exists because EO programs should not be hardwired to one operator.
The infrastructure layer should sit above individual vendors and manage the operational contract: discovery, tasking, archive access, licensing, normalization, fulfilment, entitlements, audit trails, and dissemination.
Operators remain critical.
But the customer should not have to rebuild their workflow every time the best operator changes.
A mature EO program needs the ability to move between providers without changing the customer experience, the downstream pipeline, or the governance model.
That requires common infrastructure.
Not another portal.
Not another catalogue.
Not another supplier-specific workflow.
What continuity should look like
The minimum standard is clear.
An EO system should be able to:
- identify viable providers across regions
- compare tasking and archive options
- route requests based on latency, cost, licence, sensor type, and access constraints
- substitute vendors when restrictions, weather, capacity, or priority block the preferred path
- normalize metadata and delivery outputs
- preserve permissions, usage rights, and audit records across providers
- keep downstream systems stable even when upstream suppliers change
That is the operating layer.
That is what continuity means in Earth observation.
The recent news did not prove that one supplier is bad. It proved that no single supplier should be treated as the system.
EO programs that bank on one region or one operator are not buying resilience. They are buying exposure.
EODI is the multi-region, multi-vendor failover structure that turns EO access from a supplier dependency into dependable infrastructure.