INDUSTRY FACT FILE · SPACE, SATELLITE & GEOSPATIAL SERVICES

Five New Case Studies in Space, Satellite and Geospatial Security

Original 2026 case studies, each written as a blog post, showing how current threats play out at satcom providers, ground station operators, earth observation platforms, satellite makers and location vendors, and how Codec Networks services break the attack chain.

In this document 1.  About these case studies 2.  Case Study 1: The Update That Silenced the Terminals 3.  Case Study 2: The Ground Station Nobody Owned 4.  Case Study 3: The API That Gave Away the Map 5.  Case Study 4: The Component With a Second Owner 6.  Case Study 5: The Location Trail Anyone Could Follow

These five case studies were written for this document set and have not been published elsewhere. Each is a composite scenario combining control failures widely observed in space, satellite and geospatial organisations with the obligations that apply in India as of October 2026—in particular the Indian Space Policy 2023 and IN-SPACe's authorisation norms, the Telecommunications Act 2023 and the Telecom Cyber Security Rules 2024, CERT-In's Directions and audit guidelines, the Geospatial Data Guidelines, the IT Act and the DPDP Act. Attack techniques are described only at the level needed to explain the controls; no operational detail is given, and any radio frequency or link testing is described only as authorised testing in controlled environments, under the applicable licences and permissions.

Important disclosure The organisations described are fictional and the scenarios are illustrative. They are not accounts of real incidents, and they are not Codec Networks client engagements or claims of achieved outcomes. Their value lies in showing how connected weaknesses form an attack chain, which controls break it, and which services test those controls.

Case study	Organisation type	Core threat	Regulatory lens	Primary bundles
1. The Update That Silenced the Terminals	Satcom service provider	Management network breach and malicious terminal update	Telecom rules; CERT-In; licence; IT Act	B3, B7, B8
2. The Ground Station Nobody Owned	Ground station and teleport operator	Vendor tunnel abuse and ransomware	CERT-In; IN-SPACe terms; contracts	B1, B3, B9
3. The API That Gave Away the Map	Earth observation platform	Broken object-level authorisation in an ordering API	CERT-In; DPDP; Geospatial Guidelines; contracts	B2, B6, B1
4. The Component With a Second Owner	Small satellite manufacturer	Compromised supplier software in a subsystem	Contracts; CERT-In; export terms	B9, B2, B5
5. The Location Trail Anyone Could Follow	Location and telematics vendor	Unauthenticated legacy API exposing location histories	DPDP; CERT-In; client contracts	B2, B6, B7

The satellites were fine. Every terminal that talked to them was not.

At a glance
Organisation	A licensed satcom provider (“Satcomco A”) serving bank branches, mines, telecom towers and remote government offices through several thousand VSAT terminals managed from one network operations centre
Threat	Attackers used a weak, shared vendor VPN account to reach the network management system and pushed a destructive update to terminals
Why it is new	The management plane controls every terminal, so one breach can reach every customer
Codec Networks services	Management plane and access review, managed SOC, incident response (Bundles B3, B7, B8)

The scenario

Satcomco A managed its terminals from a network management system that also pushed firmware and configuration updates. Its hub vendor kept a VPN account for support; the account was shared among the vendor's engineers, had a password that had not changed in years and was not protected with MFA. The management network and the update server sat on the same segment as other operations systems.

Attackers obtained the vendor password from an earlier breach elsewhere, logged in late at night and explored the management network for several days. They then used the update server to push a file that overwrote terminal memory, and terminals across the network rebooted and failed to return to service.

By morning bank branches, mine sites and government offices served by Satcomco A were offline. Field teams found that many terminals had to be reflashed on site or replaced. Satcomco A isolated the management network, engaged forensic investigators, reported to CERT-In and through its telecom incident reporting channel, and informed customers. Restoring every site took weeks.

Figure 8: Illustrative attack path for Case Study 1 and the controls that break it.

What went wrong

• A shared vendor VPN account without MFA or rotation.
• No segmentation between the update server and other systems.
• Terminals that accepted any update the server sent.
• No monitoring of management logins at night.

The impact

Customers lost connectivity for days to weeks, Satcomco A bore the cost of field visits and replacement terminals, faced SLA claims and questions from its licensor, and rebuilt its management plane around named, MFA-protected access, segmentation, signed updates and staged roll-outs.

The regulatory lens

• CERT-In Directions: the compromise reported within six hours of noticing it; logs preserved for the investigation.
• Telecom Cyber Security Rules 2024: the security incident reported within six hours with further details within 24 hours, with the CTSO coordinating the response.
• Licence conditions and IT Act: licence security conditions and customer contracts shaped the response; the intrusion is an offence under the IT Act.

How Codec Networks would help

Need	Codec Networks response	Bundle
Lock the management plane	Management VPN and NMS review, MFA, named vendor access and segmentation design	B3
Watch the plane	24x7 monitoring of management logins, update activity and terminal health	B7
Contain and recover	Forensic investigation, terminal recovery plan and reporting support	B8

Key lessons Treat the management plane as the crown jewel. Give every vendor engineer a named account. Make terminals check what they install. Update a few before updating all.

Every vendor had a way in. Nobody was watching any of them.

At a glance
Organisation	A teleport and ground-station-as-a-service operator (“Groundco B”) running antennas, TT&C and downlink services for several domestic and foreign satellite operators
Threat	An infected vendor laptop used an always-on remote access tunnel to reach a flat ground network, and ransomware encrypted the scheduling and baseband servers
Why it is new	Shared ground infrastructure concentrates many customers behind the same vendors and networks
Codec Networks services	Ground network VAPT, vendor access and segmentation review, supplier assurance (Bundles B1, B3, B9)

The scenario

Groundco B had grown quickly by adding antennas from different vendors, each of which kept its own permanent remote access tunnel for maintenance. Antenna control units, baseband servers, the pass scheduling system and office PCs shared one flat network, and backups of the scheduling database were stored on a share reachable from it.

A field engineer at one vendor connected an infected laptop to the vendor's support network. Attackers used the tunnel into Groundco B, moved across the flat network and, two weeks later, encrypted the scheduling servers, baseband servers and backup share during a weekend.

Groundco B could not schedule or process passes for more than a day. Several satellite operators missed downlinks of imagery and telemetry and switched to other stations at short notice. Groundco B rebuilt systems from older images, reported to CERT-In, informed its customers and reviewed its obligations under its IN-SPACe authorisation and customer contracts.

Figure 9: Illustrative attack path for Case Study 2 and the controls that break it.

What went wrong

• Always-on vendor tunnels with no brokering or monitoring.
• A flat network joining antennas, servers and office PCs.
• Backups reachable from the systems they protected.
• No inventory of who could reach which antenna.

The impact

Customers lost a day of passes and data, one foreign operator moved its contract to a competitor, Groundco B paid for recovery and service credits, and it rebuilt its network with segmentation per customer and antenna, brokered vendor access and offline backups.

The regulatory lens

• CERT-In Directions: ransomware reported within six hours of noticing it; logs preserved.
• IN-SPACe authorisation: the incident raised questions under the terms of authorisation for ground systems serving authorised operators.
• Customer contracts: SLA, security and notification clauses with domestic and foreign operators decided penalties and remediation duties.

How Codec Networks would help

Need	Codec Networks response	Bundle
Find the open doors	Ground network VAPT covering antennas, baseband, scheduling and exposure	B1
Close and broker access	Vendor access brokering, MFA, segmentation and backup redesign	B3
Assure the vendors	Security assessment of antenna and baseband vendors and their support practices	B9

Key lessons Know every way into the station. Separate antennas, customers and office. Broker and record every vendor session. Keep backups out of reach.

Every customer had a login. Not every request checked whose order it asked for.

At a glance
Organisation	An earth observation data platform (“Imageco C”) that sells archive imagery, tasking and analytics to government departments, infrastructure companies and insurers through a web portal and API
Threat	The order API trusted an order number supplied by the client, so one customer could view other customers' orders, tasked areas and imagery links
Why it is new	Data platforms concentrate many clients' sensitive interests behind one API
Codec Networks services	API and multi-tenant testing, data handling review, platform VAPT (Bundles B2, B6, B1)

The scenario

Imageco C's portal and API let customers place tasking requests, track orders and download imagery. Each request carried an order number, and the server checked that the user was logged in but not that the order belonged to the user's organisation. Earlier penetration tests had focused on the login page and the web portal rather than the API.

An analyst at an insurer noticed that changing the order number returned another client's order, including the areas of interest a government department had tasked, high-resolution imagery download links and contact names and phone numbers. The links worked without further authentication.

The insurer reported the flaw. Imageco C fixed it within a day, reviewed logs to see whether it had been abused, assessed the exposure against CERT-In's reporting criteria and notified affected clients. The government department suspended new orders and asked for an independent security assessment and a review of how sensitive areas and attributes were handled.

Figure 10: Illustrative attack path for Case Study 3 and the controls that break it.

What went wrong

• Authorisation based on an identifier supplied by the client.
• Download links that never expired or rechecked access.
• Testing that did not cover the API or tenant isolation.
• No monitoring for enumeration of order numbers.

The impact

Imageco C avoided known abuse but lost new government orders for months, faced client audits and DPDP questions about contact data, and introduced server-side authorisation checks, expiring links, tenant isolation tests in every release and API monitoring.

The regulatory lens

• CERT-In Directions: the exposure assessed and reported within six hours of noticing a reportable incident.
• DPDP Act: client contacts' names and phone numbers are personal data requiring reasonable safeguards and, once provisions commence, breach intimation.
• Geospatial Data Guidelines and contracts: handling of sensitive attributes and client-restricted areas, and confidentiality clauses, shaped the client's demands.

How Codec Networks would help

Need	Codec Networks response	Bundle
Fix the logic	API and multi-tenant security testing with fix verification in each release	B2
Handle data properly	Data handling review covering links, retention, sensitive attributes and contact data	B6
Test the platform	Full platform VAPT of portal, API, storage and cloud	B1

Key lessons Check authorisation on the server, every time. Make every download link expire. Test the API, not just the portal. Watch for enumeration.

The subsystem passed every functional test. One test bench noticed it was talking to someone else.

At a glance
Organisation	A small satellite manufacturer (“Satco D”) building earth observation satellites for a domestic operator and a foreign customer, integrating subsystems from several suppliers
Threat	A supplier's build server was breached, and a library in its subsystem software gained a hidden remote function that surfaced during integration testing
Why it is new	Supplier software is delivered as finished images that makers rarely verify
Codec Networks services	Supplier assurance, software integrity review, governance (Bundles B9, B2, B5)

The scenario

Satco D received onboard software for a communications subsystem as a finished image from a supplier. It did not hold an SBOM for the software, did not verify images against hashes from a separate channel and relied on functional tests. Its integration test benches were, however, on an isolated network whose traffic was monitored.

During integration, the bench monitoring flagged the subsystem trying to open an unexpected connection. Investigation found a modified library that could accept remote instructions. The supplier, when told, discovered that its own build server had been breached months earlier.

Satco D halted integration, informed its customers, asked every supplier to re-verify and re-deliver images with integrity evidence, and reviewed the incident against its contracts and CERT-In's reporting criteria. Delivery of both satellites slipped by several weeks while images were rebuilt and retested.

Figure 11: Illustrative attack path for Case Study 4 and the controls that break it.

What went wrong

• No SBOM or integrity verification for supplier images.
• Supplier contracts without security or notification clauses.
• No assessment of critical suppliers' build security.
• Reliance on functional tests alone.

The impact

Satco D lost several weeks on two programmes and paid for re-verification, but caught the problem before launch thanks to its isolated, monitored test bench; it then introduced supplier assessments, SBOMs, hash verification and contract clauses across its supply chain.

The regulatory lens

• Customer and supplier contracts: delivery, security and notification clauses decided delays, costs and the evidence customers demanded.
• CERT-In Directions: the supplier compromise assessed against reporting criteria and reported within six hours where required.
• Export and partner terms: the foreign customer's security requirements and applicable export controls shaped what could be shared during the investigation.

How Codec Networks would help

Need	Codec Networks response	Bundle
Assure suppliers	Security assessment of critical suppliers' build and delivery processes	B9
Verify the software	SBOM programme, integrity verification and secure SDLC review	B2
Govern the chain	Supplier security policy, contract clauses and governance aligned with ISO 27001	B5

Key lessons Verify every image you integrate. Ask suppliers for SBOMs. Keep test benches isolated and watched. Write notification into every contract.

The new API was locked down. The old one was still answering.

At a glance
Organisation	A location platform (“Locco E”) that provides vehicle and field staff tracking, a mobile SDK and location APIs to logistics firms, utilities and service companies
Threat	An old API version without authentication remained online, and a researcher downloaded months of precise movement histories of drivers and field staff
Why it is new	Location data reveals where people live and travel, and old APIs are easy to forget
Codec Networks services	API and SDK testing, DPDP programme, API monitoring (Bundles B2, B6, B7)

The scenario

Locco E's mobile SDK sent precise positions every few seconds to its analytics API, and clients viewed routes and histories in a dashboard. When it launched a new, authenticated API version, it left the old version running for a few clients who had not migrated. The old version accepted requests without authentication, and data was kept indefinitely.

A security researcher found the old endpoint, confirmed that it returned movement histories for any device identifier, and downloaded a sample showing home locations and daily routes of drivers and field staff for several clients.

The researcher reported the issue. Locco E shut the endpoint, reviewed logs, assessed the exposure against CERT-In's reporting criteria, informed clients and engaged advisers on its DPDP position. Two clients paused contracts pending an independent assessment.

Figure 12: Illustrative attack path for Case Study 5 and the controls that break it.

What went wrong

• A legacy API left online without authentication.
• No API inventory or retirement process.
• Indefinite retention of precise location histories.
• No monitoring for bulk queries.

The impact

Locco E faced client pauses, DPDP questions and reputational damage, and introduced an API inventory and retirement process, authentication on every version, reduced precision and short retention for histories, and monitoring for bulk access.

The regulatory lens

• DPDP Act: precise location histories of identifiable drivers and staff are personal data requiring purpose limits, retention limits, safeguards and, once provisions commence, breach intimation.
• CERT-In Directions: the exposure assessed and reported within six hours of noticing a reportable incident.
• Client contracts: data processing, security and notification clauses decided clients' rights to audit and pause services.

How Codec Networks would help

Need	Codec Networks response	Bundle
Find every API	API inventory, testing of all versions and SDK review	B2
Minimise the data	DPDP programme with precision, retention and purpose rules for location data	B6
Watch the API	Monitoring for unauthenticated and bulk access to location data	B7

Key lessons Retire old APIs on purpose. Authenticate every version. Keep location history short. Watch for bulk queries.

Contact Codec Networks Pvt. Ltd. New Delhi: 507, 5th Floor, New Delhi House, Barakhamba Road, Connaught Place, New Delhi – 110001 Gurugram: 707, 7th Floor, Silverton Tower, Golf Course Extension Road, Sector 50, Gurugram – 122018, Haryana Landline: 011 430 496 96 | 011 437 522 99   Mobile: +91 99716 76124 | +91 88007 88220 | +91 88003 31124 Email: mktg@codecnetworks.com   Web: www.codecnetworks.com