INDUSTRY FACT FILE · SAAS & ENTERPRISE SOFTWARE

Five New Case Studies in SaaS Security

Original 2026 case studies, each written as a blog post, showing how current threats play out for SaaS vendors and how Codec Networks services break the attack chain.

In this document 1.  About these case studies 2.  Case Study 1: The Tenant ID in the URL 3.  Case Study 2: The Integration Token That Opened Every CRM 4.  Case Study 3: The Support Session That Copied Customer Data 5.  Case Study 4: The Customers Who Never Turned On MFA 6.  Case Study 5: The Library Nobody Knew Was There

These five case studies were written for this document set and have not been published elsewhere. Each is a composite scenario combining attack techniques and control failures widely observed among SaaS and enterprise software vendors with the obligations that apply in India as of October 2026—in particular CERT-In's Directions and SBOM guidelines, the DPDP framework and customer requirements.

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	Vendor type	Core threat	Regulatory lens	Primary bundles
1. The Tenant ID in the URL	HRMS and payroll SaaS	Tenant isolation flaw	CERT-In; DPDP; customer contracts	B1, B2, B7
2. The Integration Token That Opened Every CRM	CRM platform and integration partner	OAuth token theft via a third-party integration	CERT-In; DPDP; customer contracts	B9, B2, B7
3. The Support Session That Copied Customer Data	Collaboration SaaS	Stolen support-console sessions	CERT-In; DPDP; customer contracts	B3, B7, B8
4. The Customers Who Never Turned On MFA	Data and analytics SaaS	Credential stuffing against tenants without MFA	CERT-In; DPDP; shared responsibility	B2, B7, B10
5. The Library Nobody Knew Was There	Enterprise software vendor	Vulnerable transitive dependency	CERT-In SBOM guidelines; customer contracts	B2, B5, B8

The customer only changed one number in the request.

At a glance
Organisation	An HRMS vendor (“Vendor A”) serving several hundred companies
Threat	A reporting API that trusted a client-supplied tenant ID
Why it is new	Isolation flaws expose many customers through one bug
Codec Networks services	Tenant isolation testing, code review, monitoring (Bundles B1, B2, B7)

The scenario

Vendor A's reporting feature passed the tenant ID as a request parameter. The API used it directly instead of the tenant bound to the user's session.

A customer's HR administrator, troubleshooting a report, changed the ID and received another company's payroll data.

The administrator reported it. Vendor A had to determine how long the flaw had existed and whether anyone had exploited it.

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

What went wrong

• The server trusted the client's tenant ID.
• No cross-tenant tests in CI.
• No alerts on cross-tenant access patterns.
• Reports were not in PT scope.

The impact

Vendor A notified affected customers, faced audits and churn, and assessed CERT-In and contractual reporting duties.

The regulatory lens

• CERT-In Directions: incidents reported within six hours.
• DPDP Act and Rules: customers as data fiduciaries must ensure safeguards and, once provisions commence, intimate breaches.
• Customer contracts: confidentiality, security and notification obligations.

How Codec Networks would help

Need	Codec Networks response	Bundle
Test isolation	Cross-tenant testing across every endpoint	B1
Fix the pattern	Code review and CI authorisation tests	B2
Watch for abuse	Cross-tenant anomaly alerts	B7

Key lessons Bind tenants on the server. Never trust client IDs. Automate isolation tests. Alert on cross-tenant access.

The attackers never touched the CRM vendor. They breached its partner.

At a glance
Organisation	A CRM vendor (“Vendor B”) with a marketplace of connected apps
Threat	A breached integration vendor's stored OAuth tokens used to export customer CRM data
Why it is new	Integrations hold long-lived access to many tenants
Codec Networks services	Integration assessment, OAuth review, export monitoring (Bundles B9, B2, B7)

The scenario

A popular sales-assistant integration stored OAuth tokens for thousands of Vendor B customers.

Attackers breached the integration vendor and used the tokens to export contacts, deals and support cases—some containing passwords and API keys pasted into notes.

Vendor B revoked the integration's tokens, but data had already left many tenants.

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

What went wrong

• Integration scopes were broader than needed.
• Tokens were long-lived.
• Bulk exports by integrations were not monitored.
• Integration vendors were not assessed.

The impact

Many customers had to notify their own stakeholders and rotate exposed secrets; Vendor B tightened its marketplace rules.

The regulatory lens

• CERT-In Directions: incidents reported within six hours.
• DPDP Act and Rules: safeguards and breach intimation by customers once provisions commence.
• Customer contracts and marketplace terms: security and notification obligations of partners.

How Codec Networks would help

Need	Codec Networks response	Bundle
Assess partners	Integration vendor security assessments	B9
Narrow access	OAuth scope and token-lifetime review	B2
Spot exports	Monitoring of bulk exports by integrations	B7

Key lessons Grant integrations minimal scopes. Shorten token lifetimes. Monitor integration exports. Assess marketplace partners.

The attacker logged in as support. Support could see everything.

At a glance
Organisation	A collaboration vendor (“Vendor C”) whose support team can impersonate customer admins
Threat	Info-stealer malware stealing a support engineer's session tokens
Why it is new	Support tools concentrate access to many tenants
Codec Networks services	Support-tool review, identity hardening, incident response (Bundles B3, B7, B8)

The scenario

A support engineer's personal laptop, also used for work, was infected with info-stealer malware.

The malware captured session cookies for Vendor C's support console, which allowed impersonation of customer administrators.

The attacker browsed several customer tenants and downloaded files before unusual activity was spotted.

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

What went wrong

• Support access was standing, not just-in-time.
• Sessions were not bound to managed devices.
• Customers could not see support actions.
• Support logins were not monitored for anomalies.

The impact

Vendor C notified affected customers, rebuilt its support access model and faced customer audits.

The regulatory lens

• CERT-In Directions: incidents reported within six hours.
• DPDP Act and Rules: safeguards and breach intimation by customers once provisions commence.
• Customer contracts: access, audit and notification obligations.

How Codec Networks would help

Need	Codec Networks response	Bundle
Limit support	Just-in-time, approved support access review	B3
Watch support	SOC monitoring of support sessions	B7
Respond	Investigation and customer coordination	B8

Key lessons Make support access just-in-time. Bind sessions to managed devices. Show customers support actions. Monitor support logins.

The platform offered MFA. Most customers never switched it on.

At a glance
Organisation	A data platform vendor (“Vendor D”) hosting customer data warehouses
Threat	Passwords from info-stealer logs used against customer accounts without MFA
Why it is new	Shared responsibility fails when secure defaults are optional
Codec Networks services	Identity testing, SOC monitoring, customer awareness (Bundles B2, B7, B10)

The scenario

Attackers bought credential logs harvested by info-stealer malware from employees of Vendor D's customers.

Several customer accounts had no MFA. Credential stuffing succeeded, and data was exported and held for ransom.

Customers and the public questioned whether Vendor D should have enforced MFA.

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

What went wrong

• MFA was optional for customer admins.
• Credential stuffing was not detected.
• Customers lacked a security posture view.
• Shared-responsibility guidance was unclear.

The impact

Vendor D faced reputational damage and moved to MFA by default; affected customers faced breach reporting.

The regulatory lens

• CERT-In Directions: incidents reported within six hours.
• DPDP Act and Rules: reasonable security safeguards; breach intimation once provisions commence.
• Customer contracts: shared-responsibility terms.

How Codec Networks would help

Need	Codec Networks response	Bundle
Secure defaults	Identity and MFA configuration testing	B2
Spot stuffing	SOC detection of credential stuffing	B7
Guide customers	Customer awareness and posture guidance	B10

Key lessons Enforce MFA by default. Detect credential stuffing. Give customers a posture view. Spell out shared responsibility.

The vulnerable library was three levels deep. Nobody had listed it.

At a glance
Organisation	An enterprise software vendor (“Vendor E”) selling on-premise and cloud editions
Threat	A critical vulnerability in an untracked open-source dependency
Why it is new	Without an SBOM, exposure assessment takes days
Codec Networks services	SCA and SBOM programme, vulnerability process, incident response (Bundles B2, B5, B8)

The scenario

A critical vulnerability was published in an open-source library used indirectly by Vendor E's product.

Vendor E had no SBOM and could not tell which product versions included the library.

Attackers exploited unpatched customer installations before Vendor E issued a fix. Customers demanded an SBOM and a timeline.

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

What went wrong

• No SBOM for releases.
• Transitive dependencies were not scanned.
• No patch SLAs or advisory process.
• Customer installations were not tracked by version.

The impact

Vendor E faced customer incidents, emergency patching costs and lost trust in its security process.

The regulatory lens

• CERT-In SBOM guidelines (2024): recommended SBOM practices.
• CERT-In Directions: incidents reported within six hours.
• Customer contracts: vulnerability notification and patch obligations; EU CRA obligations for in-scope products sold in the EU.

How Codec Networks would help

Need	Codec Networks response	Bundle
Know your components	SCA scanning and SBOM per release	B2
Formalise the process	Vulnerability disclosure and patch SLAs	B5
Respond	Incident support and customer advisories	B8

Key lessons Produce an SBOM for every release. Scan transitive dependencies. Set patch SLAs. Publish clear advisories.

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