KSAT–Xoople Links Customer Requirements to Shared Service Upgrades

Kongsberg Satellite Services (KSAT) is using its partnership with Xoople to develop capabilities intended for the standard KSATlite service. The 5 October 2026 announcement connects one constellation customer's requirements to future improvements available across a shared ground-service product. For other operators, the useful question is when those improvements become part of an offering they can use. KSAT's announcement.

Xoople selected KSATlite to support its constellation's deployment and operation. The agreement was signed in Madrid by KSAT Chief Commercial Officer Arild Jose Jensen and Xoople Chief Executive Fabrizio Pirondini. KSAT says it is adding ground stations and jointly developing faster delivery from the station to the cloud, alongside new service endpoints through which operators can further automate their operations. Those capabilities are intended to become part of the standard service.

The shared product already has an automation base

KSATlite provides ground access as a service: satellite operators use the supplier's network and software interfaces to arrange contacts and receive data. Its existing product description includes automated scheduling, machine-to-machine interfaces and a customer portal for managing operations. The Xoople work therefore extends an established service architecture. KSATlite product description.

There is also a documented customer history behind that model. In June, Japan's iQPS announced an extended partnership with KSAT and adopted KSATlite for its planned constellation expansion. That agreement concerned using the shared service as the fleet grew. The Xoople announcement adds a more explicit relationship between a customer's requirements and capabilities intended for other users. iQPS's 3 June announcement.

The distinction matters when an operator specifies an integration. A requirement can be met through work particular to its mission, or through a feature incorporated into the supplier's common product. The latter makes the product's release and support arrangements relevant to the operator's own development plan. The Xoople disclosure provides a concrete example of that route into the shared offering.

General availability is a separate delivery question

Faster station-to-cloud transfer and additional automation endpoints address different parts of the service. One concerns the movement of received data; the other concerns how an operator's software interacts with the ground provider. Their value to a prospective customer depends on the documented behaviour of the released capabilities and their fit with that customer's systems.

The practical procurement consequence is to distinguish a promised common feature from an integration that still needs to be commissioned. Availability, supported interfaces and the specified station-to-cloud delivery conditions belong in that comparison. A customer's influence on development is useful evidence of responsiveness; suitability for another mission still has to be established against its own requirements.

The next evidence is in the service definition

This may be an incremental extension of KSATlite around a demanding customer. The broader relevance comes from the stated intention to make the capabilities standard. Updated interface documentation and a release offered to other operators would turn that intention into something a procurement team can assess directly.

For the cloud-delivery work, measurements tied to a defined transfer path would establish the improvement achieved. For automation, documented endpoint availability and integration requirements would establish what another mission can adopt. Those are the milestones that connect Xoople's requirements to a usable shared product.