INDUSTRY FACT FILE · AGRICULTURE & AGRITECH

Five New Case Studies in Agriculture and Agritech Security

Original 2026 case studies, each written as a blog post, showing how current threats play out at cooperatives, farm IoT providers, marketplaces, agri-credit platforms and seed companies, and how Codec Networks services break the attack chain.

In this document 1.  About these case studies 2.  Case Study 1: The Harvest Week Lockout 3.  Case Study 2: The Sensor Hub With a Default Password 4.  Case Study 3: The Mandi App That Paid Twice 5.  Case Study 4: The Field Agent Who Wasn't 6.  Case Study 5: The Farmer List That Went Public

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 agriculture and agritech organisations with the obligations that apply in India as of October 2026—in particular CERT-In's Directions and audit guidelines, RBI's digital lending rules, the WDRA framework, AgriStack and scheme integration terms, the Seeds Act, 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 testing of devices, drones and payment systems is described only as authorised testing in agreed windows and controlled conditions.

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 Harvest Week Lockout	Grain cooperative	Phishing-led ransomware at harvest	CERT-In; lenders; members; IT Act	B7, B8, B10
2. The Sensor Hub With a Default Password	Precision farming and farm IoT provider	Default device credentials and a shared cloud broker	CERT-In; client contracts; IT Act; DPDP	B1, B3, B11
3. The Mandi App That Paid Twice	Agritech marketplace	Forged and replayed payment callbacks	Payment partner terms; CERT-In; DPDP	B2, B1, B7
4. The Field Agent Who Wasn't	Agri-credit platform	Phished agent account and forged loan files	RBI lending rules; CERT-In; DPDP	B3, B2, B8
5. The Farmer List That Went Public	Seed company	Vendor's public cloud bucket exposing farmer data	DPDP; CERT-In; vendor contract; IT Act	B6, B3, B9

The crop was ready. The systems that bought it were not.

At a glance
Organisation	A multi-state grain cooperative (“Agroco A”) that buys, grades, dries, stores and pays for members' crops at twelve procurement centres linked to a central ERP and payment system
Threat	A phished staff login gave attackers remote access during harvest week, and ransomware spread from the office network to procurement, grading and payment servers
Why it is new	Harvest concentrates a year's trade into a few weeks, when attackers know downtime hurts most
Codec Networks services	Managed SOC, incident response, crisis exercises (Bundles B7, B8, B10)

The scenario

Agroco A ran its procurement centres on a central ERP that recorded weights from weighbridges, grades from moisture meters and payments to members' bank accounts. Staff used webmail and a remote access gateway without MFA. Office PCs, weighbridge terminals and dryer control PCs shared one network, and backups were kept on a share reachable from it. Monitoring was limited to antivirus alerts that nobody reviewed at weekends.

In the first week of harvest an accounts officer entered her password on a fake webmail page. Attackers logged into the remote access gateway, explored the network for four days and then, on a Saturday night, encrypted the ERP, payment and grading servers, the backup share and several weighbridge terminals, leaving a ransom note.

On Sunday morning trucks queued at every centre. Staff could not record weights or grades, and payments due to thousands of members stopped. Agroco A switched to paper slips at some centres, closed others, engaged incident responders, reported to CERT-In and informed its bank and members. Restoring the ERP from an older offline copy and re-entering paper records took nine days.

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

What went wrong

• No MFA on webmail and remote access.
• A flat network joining office, weighbridge and dryer systems.
• Backups reachable from the systems they protected.
• No monitoring at weekends in peak season.

The impact

Members waited more than a week for payments, some sold to private traders at lower prices, perishables were held in poor conditions, and Agroco A bore recovery costs and lost member trust; it then introduced MFA, segmentation, offline backups, a manual procurement playbook and 24x7 monitoring through each harvest.

The regulatory lens

• CERT-In Directions: the ransomware incident reported within six hours of noticing it; logs preserved for the investigation.
• Lenders and members: working capital lenders and members expected timely information on payments, stock and records, and the cooperative's bylaws shaped governance of the response.
• IT Act and DPDP: the intrusion is an offence under the IT Act; member identity and bank data on encrypted servers required assessment for exposure under the DPDP Act once provisions commence.

How Codec Networks would help

Need	Codec Networks response	Bundle
Watch the season	24x7 SOC with heightened monitoring of remote access, email and servers during harvest	B7
Contain and recover	Ransomware response, forensics, recovery planning and reporting support	B8
Rehearse the bad week	Harvest-week ransomware tabletop and manual procurement playbook	B10

Key lessons Put MFA on every remote door. Separate office, weighbridge and plant networks. Keep backups out of reach and tested. Plan to buy and pay manually for a week.

Every gateway shipped the same way. That was the problem.

At a glance
Organisation	A precision farming company (“Farmco B”) that sells soil moisture sensors, field gateways and remote irrigation control to FPOs, plantations and large growers across several states
Threat	Field gateways shipped with one default password and an open administration port, and their cloud message broker accepted any authenticated device on any topic
Why it is new	One weakness in a device model or broker reaches every farm on the platform
Codec Networks services	IoT and network testing, cloud and broker review, IoT security programme (Bundles B1, B3, B11)

The scenario

Farmco B's gateways collected readings from sensors in the field and sent them over mobile networks to a cloud message broker, which fed dashboards and an irrigation scheduling service that could switch pumps and valves. To simplify installation, every gateway shipped with the same administrator password and a remote administration port open. On the broker, any device holding the shared platform credential could publish to any farm's topics.

Someone scanning mobile network address ranges found a gateway's administration port, logged in with the default password and extracted the platform credential. Using it, they published false soil moisture readings and irrigation commands to topics belonging to farms in several districts.

Over two days some fields were over-watered while others received no water, and growers complained of stressed crops. Farmco B's support team noticed pumps running at unusual hours, paused remote control across the platform, rotated the shared credential and engaged investigators. It reported to CERT-In and wrote to clients.

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

What went wrong

• One default password on every gateway.
• An open administration port reachable from mobile networks.
• A broker that let any device publish to any farm.
• No limits or alerts on irrigation commands.

The impact

Several growers suffered crop stress and claimed compensation, FPO clients paused renewals, and Farmco B spent weeks visiting farms to re-provision gateways; it introduced unique device credentials, closed ports, per-farm broker authorisation, signed firmware, command limits and anomaly monitoring.

The regulatory lens

• CERT-In Directions: the compromise reported within six hours of noticing it; broker and device logs preserved.
• Client contracts: service levels, liability and security clauses with FPOs and growers decided compensation and remediation duties.
• IT Act and DPDP: unauthorised access is an offence under the IT Act; grower contact and farm location data on the platform required assessment for exposure.

How Codec Networks would help

Need	Codec Networks response	Bundle
Test the devices	Gateway, sensor and firmware testing with authorised field and bench work	B1
Fix the broker and cloud	Per-device identity, topic authorisation, secrets and cloud configuration review	B3
Build an IoT programme	Secure provisioning, signed updates, command limits and device monitoring	B11

Key lessons Give every device its own credentials. Close what installers do not need. Authorise every topic per farm. Limit and watch every command.

The gateway never said the trade was paid. The app believed it anyway.

At a glance
Organisation	A B2B agritech marketplace (“Tradeco C”) that connects FPOs and farmers with processors and traders, collecting buyer payments through a payment gateway and releasing payouts to sellers
Threat	The settlement service trusted payment callbacks without verifying their signature or checking status with the gateway, so a trader could forge and replay confirmations
Why it is new	Payment logic flaws pay out real money and often go unnoticed until reconciliation
Codec Networks services	Payment integration and API testing, platform VAPT, monitoring (Bundles B2, B1, B7)

The scenario

When a buyer paid for a trade, Tradeco C's payment gateway sent a callback to its settlement service, which marked the trade as paid and queued the seller's payout. The service did not verify the callback's signature, did not confirm the payment with the gateway's server, and processed the same callback more than once if it arrived again. Earlier tests had focused on the mobile apps, not the settlement service.

A trader registered as both buyer and, through an associate, seller. He studied the callbacks his own small payments produced, then sent forged and replayed callbacks for large trades that were never paid. The settlement service released payouts to the associate's account for crop lots that existed only on paper.

Reconciliation at the end of the following week found a gap of several crore rupees between payouts and gateway settlements. Tradeco C froze payouts, traced the accounts, informed its payment partner and bank, filed a police complaint, reported to CERT-In and engaged investigators.

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

What went wrong

• Callbacks accepted without signature or status checks.
• No replay protection or idempotent settlement.
• Payouts released before reconciliation.
• Testing that skipped the settlement service.

The impact

Tradeco C recovered part of the money through its bank, absorbed the rest, faced a review by its payment partner and delayed payouts to genuine sellers for a week; it introduced callback verification, server-side status checks, idempotent settlement, reconciliation before payout and payout anomaly monitoring.

The regulatory lens

• Payment partner terms: the gateway and bank agreements required timely notification, cooperation and remediation of integration flaws.
• CERT-In Directions: the incident assessed against reporting criteria and reported within six hours of noticing it.
• DPDP Act and IT Act: seller and buyer data in the investigation handled under the DPDP Act once provisions commence; the fraud is an offence under the IT Act and other laws.

How Codec Networks would help

Need	Codec Networks response	Bundle
Test the money path	Payment integration testing of callbacks, settlement, refunds and payouts	B2
Test the platform	Full platform VAPT of apps, APIs and admin functions	B1
Watch payouts	Monitoring of payout patterns, account changes and callback anomalies	B7

Key lessons Verify every callback on the server. Process each payment once. Reconcile before paying out. Test the settlement service, not just the app.

The loan files looked perfect. The agent who submitted them was asleep at home.

At a glance
Organisation	An agri-credit platform (“Creditco D”) that originates crop and equipment loans for a bank and an NBFC partner through field agents' tablets and a farmer app
Threat	A field agent's password was phished, and attackers used the account to submit loan files with forged land and crop documents, disbursed to mule accounts
Why it is new	Lending partners hold the platform to bank-grade controls, and fraud spreads fast through agent networks
Codec Networks services	Access and device review, loan app and API testing, fraud investigation (Bundles B3, B2, B8)

The scenario

Creditco D's field agents visited farmers, captured KYC and uploaded land records, crop details and photos through a tablet app, which submitted files to the lenders' systems through an API. Agent accounts used passwords only, could log in from any device and could upload documents as images. Approval rules checked completeness but not the source of land and crop data.

An agent received a message, apparently from Creditco D's support team, asking him to re-verify his login. Attackers captured his password and, over three nights, used the account from a new device to submit dozens of loan files with forged land documents and photos, each naming a bank account controlled by a mule network.

The NBFC partner disbursed several loans before its analysts noticed files submitted at night by one agent from an unfamiliar device. It halted disbursals through Creditco D and demanded an audit. Creditco D disabled the account, engaged investigators, reported to CERT-In and the police and worked with the lenders on recovery.

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

What went wrong

• Password-only agent accounts without device binding.
• Uploaded documents accepted without source checks.
• No velocity or time-of-day rules on loan files.
• Agents untrained in spotting fake support messages.

The impact

The lenders recovered part of the disbursed amount, paused the partnership for two months and required an independent audit, and Creditco D introduced MFA and device binding, source-verified land and crop data, anomaly rules and agent awareness training.

The regulatory lens

• RBI digital lending rules: the regulated lenders remained responsible for their lending service provider's conduct and controls, and required audit evidence before resuming.
• CERT-In Directions: the account compromise reported within six hours of noticing it; logs preserved.
• DPDP Act: farmer KYC, land and crop data handled by agents and attackers required assessment and, once provisions commence, breach intimation where applicable.

How Codec Networks would help

Need	Codec Networks response	Bundle
Lock down agent access	MFA, device binding, device management and access review	B3
Test the loan path	Agent app, farmer app and lender API testing, including upload and data source checks	B2
Investigate the fraud	Forensic investigation, timeline and lender-ready report	B8

Key lessons Bind agent accounts to devices. Verify data at source, not from uploads. Flag night-time bursts of files. Train agents to spot fake support.

The company never uploaded the file. Its loyalty app vendor did.

At a glance
Organisation	A seed company (“Seedco E”) that runs a dealer and farmer loyalty app through a marketing technology vendor, rewarding farmers who scan QR codes on seed packs
Threat	The vendor stored app exports in a publicly readable cloud bucket holding names, phone numbers, villages, crops and landholdings of lakhs of farmers
Why it is new	Farmer data often lives with vendors that the data fiduciary rarely checks
Codec Networks services	DPDP programme, cloud review, vendor assurance (Bundles B6, B3, B9)

The scenario

Seedco E's loyalty app asked farmers to register with their name, phone number, village, crops and landholding, scan codes on seed packs and claim rewards through dealers. A marketing technology vendor ran the app and, for convenience, exported registration data each week to a cloud storage bucket so that Seedco E's sales team could download it. The bucket was set to public read.

A security researcher scanning for open buckets found the files, which held records of several lakh farmers and thousands of dealers going back three years. The researcher reported the exposure to Seedco E through its website, and a news site asked for comment the same week.

Seedco E asked the vendor to close the bucket, engaged investigators to establish who had accessed the files, reported to CERT-In and prepared notices. Dealers complained that competitors could now see their customers, and farmers began receiving spam calls.

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

What went wrong

• A public bucket created by a vendor.
• No vendor assessment or data handling clause.
• More data collected and kept than the scheme needed.
• No monitoring for public exposure of data stores.

The impact

Seedco E faced DPDP questions, dealer anger and press coverage, paid for investigation and notification, and rebuilt the programme around data minimisation, retention limits, private-by-default storage, vendor security clauses and assessments, and exposure monitoring.

The regulatory lens

• DPDP Act: Seedco E, as data fiduciary, remains responsible for its processor's safeguards; breach intimation to the Board and affected farmers applies once provisions commence.
• CERT-In Directions: the data exposure assessed and reported within six hours of noticing a reportable incident.
• Vendor contract and IT Act: data processing, security and notification clauses with the vendor shaped remediation and cost recovery; reasonable security practices under the IT Act.

How Codec Networks would help

Need	Codec Networks response	Bundle
Govern farmer data	DPDP gap assessment, data map, minimisation and retention rules	B6
Close the cloud	Cloud storage and configuration review, exposure monitoring	B3
Assure the vendors	Security and data handling assessment of marketing and app vendors, contract clauses	B9

Key lessons Know which vendors hold farmer data. Make storage private by default. Collect only what the scheme needs. Write security into every vendor contract.

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