INDUSTRY FACT FILE · DIGITAL IDENTITY, TRUST & ESIGN

Five New Case Studies in Digital Identity, Trust and eSign Security

Original 2026 case studies, each written as a blog post, showing how current threats play out at agent networks, lenders, KYC platforms, eSign integrators and certifying authorities, and how Codec Networks services break the attack chain.

In this document 1.  About these case studies 2.  Case Study 1: The Fingerprints That Were Never There 3.  Case Study 2: The Vault That Had a Back Door 4.  Case Study 3: The Applicant Who Was a Video Feed 5.  Case Study 4: The Document That Changed After Consent 6.  Case Study 5: The Certifying Authority's Long Weekend

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 identity, KYC, signing and financial services organisations with the obligations that apply in India as of October 2026—in particular the Aadhaar Act and Regulations, UIDAI's checklists and Circular 14 of 2025, the IT Act and CCA eSign guidelines, RBI's KYC Directions, CERT-In's Directions and the DPDP Act. Attack techniques are described only at the level needed to explain the controls; no operational detail is given.

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 Fingerprints That Were Never There	Bank agent network (sub-AUA)	Cloned fingerprints at assisted outlets	Aadhaar Act; UIDAI; RBI; CERT-In	B1, B7, B8
2. The Vault That Had a Back Door	Digital lender (KUA)	Aadhaar data copied outside the vault	Aadhaar Act; Circular 14; CERT-In; DPDP	B3, B6, B4
3. The Applicant Who Was a Video Feed	Video-KYC platform	Deepfakes injected into video-KYC	RBI KYC Directions; IT Rules; CERT-In	B2, B11, B7
4. The Document That Changed After Consent	Lending app (ASP)	Document swapped between consent and signing	IT Act; CCA eSign; ESP terms; DPDP	B1, B2, B4
5. The Certifying Authority's Long Weekend	Certifying authority and ESP	Registration authority account takeover	IT Act; CCA; CERT-In	B3, B7, B8

Every withdrawal passed authentication. None of the account holders had been at the outlet.

At a glance
Organisation	A business correspondent network (“Agentco A”) running assisted cash withdrawals and deposits as a sub-AUA under a bank's AUA
Threat	Silicone copies of fingerprints, taken from documents in public records, beat older devices without liveness at a few outlets
Why it is new	Fraud moves to wherever devices and agent controls lag behind the rest of the ecosystem
Codec Networks services	Device and agent app testing, authentication anomaly monitoring, fraud forensics (Bundles B1, B7, B8)

The scenario

Agentco A ran thousands of outlets across several states. Most used current registered devices, but a few hundred still ran older models and software that had never been updated, and the agent app accepted any device that connected. Agent onboarding was quick and refresher audits rare.

Fraudsters obtained copies of residents' fingerprints from documents uploaded to public records portals, made silicone replicas and, working with a handful of agents, carried out small cash withdrawals in villagers' names. Each transaction authenticated successfully, so nothing looked wrong at the bank's end.

Complaints rose sharply in two districts. The bank's fraud team traced the transactions to a small set of outlets and devices, suspended them and asked Agentco A to investigate. Forensics confirmed the pattern, and the bank had to examine every disputed transaction, refund affected customers and explain its controls to its regulator and to UIDAI.

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

What went wrong

• Older devices without current liveness software still in service.
• An agent app that did not check device certification or software version.
• No anomaly monitoring by agent, device and location.
• Light agent vetting and infrequent audits.

The impact

The bank refunded customers, suspended dozens of agents and devices, replaced older devices across the network and introduced face authentication for higher-value transactions; Agentco A faced contract penalties and a full review of its outlets.

The regulatory lens

• Aadhaar Act and UIDAI: the parent AUA answers for authentication through its sub-AUAs and devices, with suspension and penalties possible for contraventions.
• RBI: customer protection, business correspondent oversight and fraud reporting obligations apply to the bank.
• CERT-In Directions: the incident reported within six hours of noticing it; logs needed for the investigation.

How Codec Networks would help

Need	Codec Networks response	Bundle
Fix the front line	Registered device and agent app testing, device certification and version checks	B1
Spot the pattern	SOC anomaly monitoring of authentications by agent, device and location	B7
Trace the fraud	Forensic investigation, disputed-transaction analysis and reporting support	B8

Key lessons Retire devices that cannot run current liveness. Let the app refuse uncertified devices. Monitor patterns, not just failures. Vet and audit agents continuously.

The vault passed every audit. The data lake next to it held the same numbers in plain text.

At a glance
Organisation	A digital lending NBFC (“Lendco B”) that uses Aadhaar e-KYC as a KUA and stores Aadhaar numbers in a certified Aadhaar Data Vault
Threat	Full Aadhaar numbers and e-KYC data copied into logs, reports and an analytics bucket that was left publicly readable
Why it is new	Vault controls fail when other systems quietly keep their own copies
Codec Networks services	Vault and cloud review, data discovery and privacy programme, UIDAI audit (Bundles B3, B6, B4)

The scenario

Lendco B had built its Aadhaar Data Vault carefully, with keys in an HSM and reference keys in its loan system. But debug logging in the loan origination service wrote full e-KYC responses, monthly collection reports exported Aadhaar numbers for agencies, and a data science team copied both into a cloud analytics bucket.

During a migration, the bucket's access policy was changed to allow public reads for a dashboard test and never reverted. For several weeks anyone with the address could list and download files containing Aadhaar numbers, names, addresses and photographs.

A security researcher reported the exposure. Lendco B closed the bucket, engaged forensics to determine what had been accessed, reported to CERT-In, informed UIDAI and its lending partners, and began a search for every other copy of Aadhaar data in its estate. Its last annual audit had tested the vault but not the systems around it.

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

What went wrong

• Full e-KYC responses written to debug logs.
• Reports and analytics holding Aadhaar numbers outside the vault.
• A public cloud bucket left open after a test.
• An audit scope limited to the vault itself.

The impact

Lendco B faced scrutiny from UIDAI and its partners, customer complaints and weeks of clean-up, and rebuilt logging, reporting and analytics so that only tokens left the vault.

The regulatory lens

• Aadhaar Act and UIDAI Circular 14 of 2025: Aadhaar numbers and e-KYC data only in the vault; contraventions can lead to suspension and civil penalties.
• CERT-In Directions: data exposure reported within six hours of noticing it.
• DPDP Act and Rules: reasonable security safeguards and breach intimation for personal data once provisions commence.

How Codec Networks would help

Need	Codec Networks response	Bundle
Lock the vault's doors	Vault, HSM, tokenisation and cloud configuration review	B3
Find every copy	Data discovery across logs, reports, backups and cloud; masking design	B6
Audit the whole estate	Role-specific UIDAI IS audit scoped beyond the vault	B4

Key lessons The vault should be the only copy. Mask Aadhaar numbers in logs and reports. Scan cloud storage for identity data. Scope audits to every system that touches e-KYC.

The face blinked, turned and smiled on cue. It had never been in front of a camera.

At a glance
Organisation	A video-KYC and identity verification platform (“Verico C”) serving several banks and fintech lenders
Threat	Synthetic faces fed through virtual cameras and emulators matched stolen identity documents and opened mule accounts
Why it is new	Fraudsters now attack the camera feed, not just the face in front of it
Codec Networks services	App and SDK security testing, deepfake and injection testing, fraud monitoring (Bundles B2, B11, B7)

The scenario

Verico C's mobile SDK ran liveness and face matching on video captured during a V-CIP call with a bank official. Its models were tested against printed photographs and screen replays, but the SDK did not check whether the camera feed came from a real device camera or a virtual one.

A fraud group used stolen identity documents and generated matching faces, then injected the synthetic video through a virtual camera on emulated phones. The faces responded to prompts convincingly, and busy agents approved the calls. Dozens of accounts were opened in a few weeks.

The accounts were used to receive and move fraud proceeds. One bank client's monitoring flagged the mule pattern and froze the accounts, then asked Verico C to explain how they had passed KYC. A review found the injection technique, and every bank client asked for evidence of a fix.

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

What went wrong

• No detection of virtual cameras, emulators or injected streams.
• Liveness tested only against presentation attacks.
• Agent workload that left little time for scrutiny.
• No post-onboarding monitoring shared with clients.

The impact

Verico C's bank clients paused new onboarding through the platform, conducted their own reviews and reported the fraud; Verico C rebuilt its SDK with injection and device integrity checks and lost one client.

The regulatory lens

• RBI KYC Directions: regulated entities remain responsible for V-CIP, including liveness, spoof detection and face matching, and oversee their technology vendors.
• IT Rules amendment (2026): synthetic content provisions frame how deepfakes are treated on intermediary platforms.
• CERT-In Directions: the incident reported within six hours of noticing it.

How Codec Networks would help

Need	Codec Networks response	Bundle
Harden the SDK	Mobile app and SDK testing, emulator and virtual-camera detection review	B2
Test with deepfakes	Deepfake and injection testing of liveness and face-match models	B11
Watch after onboarding	SOC and fraud monitoring for mule patterns across new accounts	B7

Key lessons Test against injection, not just photographs. Check device and camera integrity. Give agents time and tools to doubt. Monitor accounts after they open.

The borrowers really did sign. They signed something they had never seen.

At a glance
Organisation	A consumer lending app (“Loanco D”) that integrates Aadhaar e-KYC-based eSign through an eSign service provider
Threat	The app showed borrowers a summary page, and a flaw let a different document be submitted for signing after OTP consent
Why it is new	A valid signature is only as trustworthy as the application that requests it
Codec Networks services	ASP security assessment, document-binding and API testing, signing audit readiness (Bundles B1, B2, B4)

The scenario

Loanco D's app showed borrowers a one-page summary of their loan, then sent them to the ESP for OTP-based eSign. The document hash was computed on Loanco D's server, and the app never displayed the full agreement that was actually signed. The integration had not been assessed since an early version.

A developer error in a later release let the server pick up whichever agreement template was current at signing time, rather than the one prepared when the borrower started. When a template with higher charges went live mid-week, some borrowers in the middle of their applications signed it without seeing it.

Borrowers complained when repayments did not match what they had been shown. Loanco D, the ESP and the lending partner had to establish what each borrower had seen and signed, and the logs could not show it reliably. The ESP suspended new signing requests from the app until the issue was fixed.

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

What went wrong

• No document binding between what was shown and what was signed.
• A summary page instead of the full document.
• No security assessment of later releases.
• Logs that could not prove what each signer saw.

The impact

Loanco D honoured the original terms for affected borrowers, faced complaints and partner scrutiny and rebuilt its signing flow with full-document display, hash binding and tamper-evident logs.

The regulatory lens

• IT Act and CCA eSign guidelines: a legally valid electronic signature depends on the signer's informed act; ESP terms set ASP obligations.
• Lending partner and regulator expectations: borrowers must receive and agree to the actual terms of their loan.
• DPDP Act: consent records and personal data handled with reasonable safeguards.

How Codec Networks would help

Need	Codec Networks response	Bundle
Assess the ASP	Application security assessment before go-live and after significant releases	B1
Bind the document	Document-binding, consent and ESP API tests in every release cycle	B2
Prove it later	Log integrity and evidence review for signing disputes and audits	B4

Key lessons Show the signer the document being signed. Bind the hash to what was displayed. Retest the flow after every release. Keep logs that can settle a dispute.

No key was stolen. The attackers simply asked for certificates and approved the requests themselves.

At a glance
Organisation	A licensed certifying authority (“Trustco E”) that issues digital signature certificates through registration officers and also operates as an eSign service provider
Threat	A phished registration officer's VPN password, with no MFA, let attackers approve certificate requests in other people's names
Why it is new	Attackers target the people and processes around a CA, not just its keys
Codec Networks services	Privileged access and RA control review, issuance monitoring, incident response (Bundles B3, B7, B8)

The scenario

Trustco E's registration officers verified applicants and approved certificate requests through an RA portal reached over the company VPN. Remote working had become normal, the VPN used passwords alone and any single officer could approve a request.

Before a long weekend, an officer entered credentials on a convincing fake login page. Attackers used them to reach the RA portal, submitted requests for organisational certificates in the names of several companies with forged documents and approved them from the officer's account.

The certificates were used to sign filings on a government portal. Trustco E's new issuance monitoring flagged approvals at unusual hours from an unfamiliar location. The certificates were revoked within hours, the account was disabled, CERT-In was informed and an investigation traced every certificate the officer's account had approved.

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

What went wrong

• VPN access without MFA for registration officers.
• Single-person approval of certificate requests.
• Weak document checks for organisational certificates.
• Monitoring that had only just been introduced.

The impact

Trustco E revoked the rogue certificates, notified the affected companies and the portal operator, faced close scrutiny from the CCA and rebuilt RA access with MFA, PAM and dual control.

The regulatory lens

• IT Act and CCA: CAs are licensed by the CCA and must verify applicants and protect issuance; failures can affect licence standing.
• CERT-In Directions: the incident reported within six hours of noticing it; logs needed for the investigation.
• Relying portals: filings signed with rogue certificates had to be identified and handled with the portal operator.

How Codec Networks would help

Need	Codec Networks response	Bundle
Guard the approvers	MFA, PAM and dual control for RA and CA operators	B3
Watch the issuance	SOC monitoring of approvals by volume, time and location	B7
Contain and trace	Incident response, revocation support and forensic tracing of every approval	B8

Key lessons Protect RA access as you protect keys. Require two people for every approval. Monitor issuance around the clock. Rehearse mass revocation before you need it.

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