INDUSTRY FACT FILE · DRONES, ROBOTICS & AUTONOMOUS SYSTEMS

Five New Case Studies in Drone, Robotics and Autonomy Security

Original 2026 case studies, each written as a blog post, showing how current threats play out at drone makers, survey operators, delivery fleets, warehouse robotics firms and fleet software providers, and how Codec Networks services break the attack chain.

In this document 1.  About these case studies 2.  Case Study 1: The Update That Flew Itself 3.  Case Study 2: The Bucket Full of Rooftops 4.  Case Study 3: The Delivery Route That Drifted 5.  Case Study 4: The Warehouse That Stopped Picking 6.  Case Study 5: The Fleet Console Anyone Could Open

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 drone, robotics and autonomous systems organisations with the obligations that apply in India as of October 2026—in particular the Drone Rules 2021, the Certification Scheme for Unmanned Aircraft Systems, DGCA's GNSS interference guidance, CERT-In's Directions and audit 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 navigation resilience testing is described only as authorised testing in controlled environments, coordinated with the customer and any required regulatory 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 Flew Itself	Agricultural drone maker	Tampered over-the-air firmware update	CERT-In; Drone Rules; IT Act; DPDP	B2, B3, B8
2. The Bucket Full of Rooftops	Survey and inspection operator	Exposed imagery in public cloud storage	DPDP; CERT-In; client contracts	B3, B6, B9
3. The Delivery Route That Drifted	Drone delivery operator	GNSS interference and untested fail-safes	Drone Rules; DGCA GNSS guidance; CERT-In	B1, B11, B10
4. The Warehouse That Stopped Picking	Warehouse robotics firm	Phished vendor access and ransomware	CERT-In; IEC 62443; client contracts	B3, B7, B9
5. The Fleet Console Anyone Could Open	Fleet management software provider	Broken API authorisation across tenants	CERT-In; DPDP; client contracts	B2, B1, B7

Every drone checked the signature. The attacker had the key.

At a glance
Organisation	An Indian maker of agricultural spraying drones (“Droneco A”) with type-certified models, a PLI-supported plant and several hundred drones in service with operators and self-help groups
Threat	Attackers reached a build server through exposed remote desktop access, found the firmware signing key in a file and released a signed, tampered update
Why it is new	Over-the-air updates turn one server breach into a fleet-wide incident
Codec Networks services	Firmware and update pipeline review, key management, incident response (Bundles B2, B3, B8)

The scenario

Droneco A pushed firmware updates to its fleet over the air from a build server in its engineering office. The drones verified a signature before installing updates, but the private signing key sat in a file on the same server so that releases could be automated. Remote desktop access to the server was open to the internet for engineers working from the field.

Attackers guessed a weak password on the remote desktop service, explored the server for a week and found the signing key. They modified a release candidate so that drones under-reported spray volumes to the cloud and ignored some remote commands, then signed and published it through the normal channel.

Within two days operators complained that drones were behaving oddly and spray records did not match tank levels; two drones would not respond to a land command and had to be recovered manually. Droneco A halted updates, told operators to ground affected drones, engaged forensic investigators, reported to CERT-In and informed customers, scheme partners and its certification contacts. It took weeks to rebuild the pipeline, rotate keys and reflash the fleet.

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

What went wrong

• A signing key stored in a file on an internet-reachable build server.
• Remote desktop exposed with weak passwords and no MFA.
• No staged roll-out or telemetry checks before full release.
• No monitoring of build and signing activity.

The impact

Operators lost spraying days in peak season, two drones needed manual recovery, Droneco A faced customer claims and questions from scheme partners, and the company rebuilt its release process around hardware-held keys, dual approval and staged roll-outs.

The regulatory lens

• CERT-In Directions: the compromise reported within six hours of noticing it; logs preserved for the investigation.
• Drone Rules and type certification: changes to certified behaviour and safety occurrences raised questions with certification contacts and DGCA processes.
• IT Act and DPDP Act: the intrusion is an offence; operator and farmer personal data in the cloud handled with reasonable safeguards.

How Codec Networks would help

Need	Codec Networks response	Bundle
Secure the pipeline	Firmware, secure boot and OTA pipeline review with staged roll-out design	B2
Protect the keys	HSM-backed signing with dual approval, remote access and identity review	B3
Contain and recover	Forensic investigation, firmware comparison, reporting support and recovery plan	B8

Key lessons Keep signing keys in hardware. Never expose build servers to the internet. Release to a few before releasing to all. Watch who signs what, and when.

The flights were flawless. The file sharing was not.

At a glance
Organisation	A drone survey and inspection firm (“Surveyco B”) that maps substations and transmission corridors for a power utility and residential areas for a municipal body
Threat	A contractor made a shared cloud folder public to send large files quickly, exposing substation layouts and imagery of residents
Why it is new	Imagery is often protected less carefully than the drones that capture it
Codec Networks services	Cloud storage review, DPDP programme, contractor assurance (Bundles B3, B6, B9)

The scenario

Surveyco B processed imagery in a cloud workspace and shared deliverables with clients and freelance analysts through folders. Data was not classified, sharing links never expired, and the contract with the utility said little about handling beyond confidentiality.

Under deadline pressure, a freelance analyst changed a project folder to public access so that a colleague could download it without an account. The folder held high-resolution orthomosaics of substations, equipment labels and access roads, and drone imagery of residential streets in which faces and vehicle number plates were visible.

Weeks later a security researcher found the folder and wrote to the utility. The utility suspended Surveyco B's contract, asked for a full review and informed its own security team; the municipal body asked how residents' imagery had been handled. Surveyco B closed the folder, reported to CERT-In and engaged advisers on its DPDP position.

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

What went wrong

• No data classification for sensitive sites or people.
• Sharing links that never expired and could be made public.
• Freelancers with broad access and no security terms.
• No blurring or minimisation of people in imagery.

The impact

Surveyco B lost its largest contract for six months, faced reputational damage with public-sector clients and rebuilt its data handling with classification, expiring links, contractor terms and automated blurring.

The regulatory lens

• DPDP Act: imagery of identifiable residents is personal data, requiring reasonable safeguards and, once provisions commence, breach intimation.
• CERT-In Directions: the data exposure assessed and reported within six hours of noticing it where it met the reporting criteria.
• Client contracts: the utility's confidentiality and security terms, and its own critical infrastructure concerns, decided the commercial consequences.

How Codec Networks would help

Need	Codec Networks response	Bundle
Lock down storage	Cloud storage and sharing configuration review, access control and expiry	B3
Protect people in the data	DPDP programme with classification, blurring and retention rules	B6
Hold contractors to account	Freelancer and subcontractor security terms and assessments	B9

Key lessons Classify imagery before you share it. Make every link expire. Blur what you do not need. Contractors need rules too.

The drones knew where they were. Until they did not.

At a glance
Organisation	A drone delivery operator (“Deliveryco C”) running scheduled medical sample and parcel flights between clinics and hubs on the edge of an industrial area
Threat	Drones on one route reported position jumps from interference whose source was unknown; fail-safes had never been tested and behaved inconsistently
Why it is new	GNSS interference is now reported around Indian airports, and delivery drones depend on accurate position
Codec Networks services	Link and ground station testing, authorised navigation resilience testing, exercises (Bundles B1, B11, B10)

The scenario

Deliveryco C's drones relied mainly on satellite positioning, with inertial sensors used only for short gaps. Its fail-safe settings had been inherited from the manufacturer and never verified for the routes it flew, and pilots had no procedure for reporting suspected interference.

On several days, drones on one route began reporting sudden position jumps. The source was never confirmed and may have been unintentional. Two drones triggered fail-safes inconsistently: one returned to an earlier waypoint, and the other landed in an open plot away from its pad, where staff recovered it without injury.

Deliveryco C paused the route, preserved flight logs, informed its client hospitals and reported the interference through the appropriate channels. A review found that the drones had no integrity alerts, the remote operations team could not see when position quality degraded, and no one had tested how the fleet behaved when navigation became unreliable.

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

What went wrong

• Heavy dependence on a single navigation source.
• Fail-safes never verified for the routes flown.
• No integrity alerts for the remote operations team.
• No interference reporting procedure or playbook.

The impact

Deliveryco C suspended a revenue route for weeks, faced questions from hospital clients and its insurer, and introduced sensor cross-checks, integrity alerts, verified fail-safes and an interference reporting playbook before resuming flights.

The regulatory lens

• Drone Rules and permissions: operations, safety occurrences and records handled under the operator's permissions and DGCA procedures.
• DGCA GNSS guidance: the 2023 circular's expectations on mitigation, contingency procedures and reporting informed the review and playbook.
• CERT-In Directions: the team assessed whether any cyber compromise of systems was involved; none was found, and logs were preserved.

How Codec Networks would help

Need	Codec Networks response	Bundle
Test the control path	Link, ground station and remote operations centre security testing	B1
Verify the fail-safes	Authorised navigation resilience testing in a controlled environment, coordinated with the customer and any required regulatory permissions	B11
Rehearse the response	Interference and lost-navigation tabletop with operations, clients and leadership	B10

Key lessons Never trust one navigation source alone. Test fail-safes before you need them. Show operators when position degrades. Test only with authorisation and control.

The robots were fine. The server that told them what to do was not.

At a glance
Organisation	A warehouse automation firm (“Robotco D”) that runs a fleet of autonomous mobile robots and sorters for a large third-party logistics customer under a robots-as-a-service contract
Threat	A support engineer was phished and the team's shared, always-on remote access account was used to deploy ransomware on the fleet management server
Why it is new	Robots-as-a-service puts vendor access at the heart of customer operations
Codec Networks services	Vendor access and segmentation review, managed SOC, supplier assurance (Bundles B3, B7, B9)

The scenario

Robotco D's support team maintained the robot fleet through a single shared remote access account with a permanent tunnel into the customer's warehouse network. The fleet management server, which assigned tasks to robots and exchanged orders with the warehouse management system, sat on the same flat network as warehouse PCs, and its backups were stored on a share reachable from it.

An engineer entered credentials on a fake login page during the peak season. Attackers used the shared account at night, moved to the fleet management server and encrypted it and the backup share.

At the start of the morning shift the robots stopped receiving tasks. The customer switched to manual picking, but orders backed up for four days while Robotco D rebuilt the server from older images. The customer invoked SLA penalties and demanded a security review; Robotco D and the customer reported the incident to CERT-In.

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

What went wrong

• A shared, always-on remote access account without MFA.
• A flat network joining robots, fleet servers and warehouse PCs.
• Backups reachable from the server they protected.
• No monitoring of remote sessions at night.

The impact

The customer lost four days of automated throughput in peak season and claimed SLA penalties, and Robotco D rebuilt its support model around named, MFA-protected, time-bound access, segmentation and offline backups.

The regulatory lens

• CERT-In Directions: ransomware reported within six hours of noticing it; logs preserved.
• IEC 62443 and CERT-In audits: zones, conduits and remote access controls for automation systems became part of the customer's OT audit scope.
• Client contracts: SLA, security and notification clauses decided penalties and remediation duties.

How Codec Networks would help

Need	Codec Networks response	Bundle
Fix the access path	Vendor remote access review, PAM, MFA and network segmentation design	B3
Watch the sessions	24x7 monitoring of remote sessions, fleet servers and OT alerts	B7
Assure the vendor	Supplier assessment of the robotics provider against the customer's requirements	B9

Key lessons Name every support account. Separate robots from the office network. Keep backups out of reach. Watch remote sessions around the clock.

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

At a glance
Organisation	A fleet management software firm (“Fleetco E”) whose cloud platform plans missions, stores imagery links and manages pilots for dozens of drone operators
Threat	The mission API trusted an organisation ID sent by the client app, so one customer could view and edit another customer's missions
Why it is new	Multi-tenant platforms concentrate risk: one flaw affects every customer
Codec Networks services	API and multi-tenant testing, platform VAPT, SOC monitoring (Bundles B2, B1, B7)

The scenario

Fleetco E's web and mobile apps sent an organisation ID with each request to its mission API. The server checked that the user was logged in but not that the user belonged to that organisation. Penetration tests had focused on the login page and had not tested tenant isolation in depth.

An engineer at a customer noticed that changing the ID in a request returned another operator's missions, including flight plans over industrial sites, links to imagery and pilot names and phone numbers. Edits to mission waypoints were also accepted.

The customer's partner reported the flaw to Fleetco E, which fixed it within a day, reviewed logs to see whether it had been abused, reported to CERT-In and notified affected customers. Several enterprise clients asked for independent evidence of the platform's security before renewing.

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

What went wrong

• Authorisation based on an ID supplied by the client.
• Testing that did not cover tenant isolation.
• No monitoring for cross-tenant requests.
• No published vulnerability disclosure process.

The impact

Fleetco E avoided known abuse but faced customer audits, delayed renewals and DPDP questions about pilot data, and introduced server-side authorisation checks, tenant isolation tests in every release, API monitoring and a disclosure policy.

The regulatory lens

• CERT-In Directions: the vulnerability and any unauthorised access assessed and reported within six hours of noticing a reportable incident.
• DPDP Act: pilot names and contact details are personal data requiring reasonable safeguards and, once provisions commence, breach intimation.
• Client contracts: security, audit and notification clauses shaped customer demands for evidence.

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
Test the platform	Full platform VAPT of web, mobile, cloud and mission control paths	B1
Watch the API	Monitoring for cross-tenant requests and unusual mission edits	B7

Key lessons Check authorisation on the server, every time. Test tenant isolation in every release. Monitor for requests that cross tenants. Make it easy to report flaws.

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