Chegg breach shows why granular identity hygiene still fails

At a glance

What this is: This is an analysis of the Chegg breach and how retained AWS root credentials, missing MFA, and weak data controls enabled large-scale exfiltration.

Why it matters: It matters because the same failure pattern still appears in NHI governance, privileged access, and cloud IAM programmes that rely on long-lived credentials and weak visibility.

By the numbers:

• Chegg Inc. faced a significant cybersecurity breach in April 2018, resulting in the exposure of sensitive data belonging to over 40 million users.

👉 Read Unosecur’s analysis of the Chegg breach and AWS root credential abuse

Context

Granular identity hygiene means knowing exactly who or what has access, for how long, and through which credential. In the Chegg case, the problem was not just data exposure but the persistence of privileged AWS root access after a contractor relationship had ended, combined with no MFA and weak data protection.

For IAM and PAM teams, this is a familiar failure mode: standing privilege outlives the business need, and the control stack assumes the account is already trustworthy. The result is a cloud breach path that looks simple in hindsight but is usually the product of poor lifecycle governance, weak monitoring, and overextended root-level access.

Key questions

Q: What fails when AWS root credentials are shared or retained after someone leaves?

A: Shared or retained root credentials break the basic assumption that privileged access is tied to an active, accountable operator. Once that credential survives offboarding, the environment loses its most sensitive control boundary. The result is broad access without lifecycle closure, which can turn a routine contractor exit into a full cloud compromise.

Q: Why do cloud breaches get worse when MFA is missing on privileged accounts?

A: MFA removes the easiest path from stolen or retained credentials to live access. Without it, a password or root secret becomes enough to reach sensitive cloud resources, especially when the account has wide permissions. That increases the chance that a single identity lapse can become data theft, rather than a contained login issue.

Q: How can security teams know whether S3 access is crossing into exfiltration?

A: Look for unexpected bucket enumeration, spikes in object retrieval, and access patterns that do not match normal business activity. Those signals matter more than raw request volume because attackers often hide inside legitimate cloud traffic. If logging is in place but no one is tuning alerts to retrieval behaviour, exfiltration will still look routine.

Q: Who is accountable when a contractor still has privileged cloud access after departure?

A: Accountability sits with the team that owns identity lifecycle governance, not just the person who left. Offboarding must remove access, verify revocation, and confirm that break-glass paths are controlled. Frameworks such as OWASP Non-Human Identity Top 10 and NIST CSF both support that ownership model across privileged access, secrets, and cloud operations.

Technical breakdown

How retained AWS root credentials became the entry point

AWS root credentials are the highest-privilege account in an environment, so retaining them after a contractor leaves creates an immediate trust problem. In this case, the former contractor could still authenticate because access was not removed and MFA was not enforced. That combination turns a single credential into full-account reach, especially when the root account is used for administrative tasks instead of being locked down and replaced by scoped IAM roles. The breach illustrates that root access is not just privileged, it is structurally difficult to govern once it becomes shared or persistent.

Practical implication: remove root from operational use and enforce a lifecycle offboarding control for every privileged cloud identity.

Why weak hashing and unencrypted data magnified the blast radius

Identity failures often become breach amplifiers because they open the path to poorly protected data. Chegg’s exposure included employee and user information stored without encryption and passwords protected with weak hashing, which made the stolen data far more usable after exfiltration. In cloud environments, access control and data protection must be treated as linked layers, not separate programmes. If a privileged credential is compromised or retained, the value of the breach depends heavily on whether the data itself is hardened against theft and reuse.

Practical implication: pair identity controls with encryption-at-rest, strong password hashing, and data access monitoring.

How S3 API activity exposes exfiltration when monitoring is thin

Large numbers of S3 API calls are often the behavioural clue that a breach is in progress. Here, the incident involved bucket access and data retrieval that should have triggered anomaly detection if cloud logging and alerting had been tuned to the environment. Identity threat detection is effective when it watches for unexpected bucket listings, unusual download volume, and tampering with security controls. Without that telemetry, exfiltration looks like normal cloud activity until the damage is already done.

Practical implication: tune cloud monitoring for unusual S3 enumeration, retrieval spikes, and security-control tampering.

Threat narrative

Attacker objective: The objective was to use retained privileged access to extract large volumes of sensitive data from Chegg’s cloud environment without early detection.

1. Entry occurred through a former contractor who still had access to AWS root credentials after the relationship should have ended.
2. Escalation came from the use of root-level privileges with no MFA, allowing broad access to S3-stored user and employee data.
3. Impact was data exfiltration from cloud storage, exposing personal information for millions of users and creating regulatory and remediation pressure.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standing root access is a lifecycle failure, not just a permissions mistake. The Chegg breach worked because a former contractor retained AWS root credentials after the business relationship had changed. That is a joiner-mover-leaver failure in cloud identity form, and it shows how privileged access becomes dangerous when offboarding does not fully close the account.

Granular identity hygiene is the control gap that determines whether cloud access becomes cloud loss. Without MFA, role scoping, encryption, and monitoring, root access becomes a single point of compromise with no compensating friction. The breach demonstrates that privileged cloud accounts need the same governance discipline as any other high-risk identity, only with tighter lifecycle and session controls.

Identity blast radius is the real metric Chegg exposed. The issue was not only that access existed, but that one retained credential could traverse from administrative control to large-scale data exfiltration. This is the kind of breach that OWASP Non-Human Identity Top 10 and NIST CSF access governance both warn about in different language, and practitioners should treat the blast radius as the programme-level risk signal.

Shared administrative access breaks accountability before it breaks containment. When a contractor can still use a root credential, ownership, review, and revocation all fail at once. That failure mode is particularly relevant to cloud IAM, PAM, and NHI governance because the same pattern often appears in service accounts, API keys, and temporary vendor access that was never truly temporary.

Chegg’s exposure shows why access review alone is insufficient if the underlying credential never expires. A review cadence cannot correct a root credential that outlives the person who used it. The practitioner implication is to govern credential lifespan as aggressively as access scope, because persistence is what turns a stale credential into an incident path.

From our research:

• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, which shows how quickly one identity failure can cascade into repeated loss.
• For a broader breach pattern view, see 52 NHI Breaches Analysis, which tracks how identity mismanagement repeatedly translates into real incident paths.

What this signals

Identity blast radius: Chegg is a reminder that the biggest programme risk is not credential existence, but credential persistence after the business need has ended. With 72% of organisations reporting or suspecting an NHI breach in our research, the governance question is no longer visibility alone, but whether revocation actually closes the path.

Teams should expect the same failure mode to appear anywhere long-lived cloud privilege, vendor access, and service credentials are treated as operational defaults. The control conversation is shifting from access grant to access end-state, and programmes that cannot prove closure will continue to carry unnecessary breach exposure.

That shift has practical consequences for PAM, IAM, and cloud operations owners. If a credential can survive offboarding, the programme has not truly governed it, and the next incident will usually begin where the last review stopped.

For practitioners

• Retire root access from routine operations Reserve AWS root for break-glass scenarios only, remove it from day-to-day administration, and track every place the credential is stored or recoverable.
• Enforce lifecycle offboarding for privileged cloud identities Tie contractor exit workflows to explicit credential revocation, session termination, and account closure so no administrative identity survives the business relationship.
• Require MFA on every high-privilege cloud account Block any privileged authentication path that relies on password-only or shared-root access, including emergency accounts and inherited admin roles.
• Harden sensitive data against identity failure Use encryption at rest, strong password hashing, and limited S3 bucket access so a stolen credential cannot directly turn into readable records.
• Tune detection for abnormal cloud retrieval patterns Alert on unexpected bucket listings, unusual download volume, and security-control tampering so exfiltration is visible before the breach completes.

Key takeaways

• The Chegg breach shows how retained root access, not just weak security posture, can turn a contractor exit into a major cloud incident.
• The scale mattered because more than 40 million users were exposed, which shows how quickly identity failures can amplify into data-breach events.
• Root access retirement, enforced MFA, and lifecycle revocation are the controls most likely to prevent this exact failure pattern from recurring.

Key terms

• Root Credentials: The highest-privilege credentials in an AWS account, capable of overriding most other controls. They should be tightly protected, rarely used, and never shared for routine administration. When root credentials survive beyond their intended owner or purpose, they become a critical lifecycle and accountability failure.
• Identity Lifecycle Governance: The discipline of ensuring identities are created, changed, reviewed, and removed in step with business need. For cloud and NHI programmes, this means every credential, role, and token has an owner, a purpose, and a clear end state. If offboarding does not remove access, governance has failed.
• Identity Blast Radius: The amount of damage one identity can cause if it is misused or compromised. In cloud environments, blast radius is shaped by privilege scope, credential persistence, data sensitivity, and logging quality. The smaller the blast radius, the less one credential failure can affect the business.

What's in the full article

Unosecur's full article covers the operational detail this post intentionally leaves for the source:

• The article walks through the Chegg incident timeline and the specific AWS access misuse described in the breach narrative.
• It includes the FTC remediation context and the controls Chegg agreed to strengthen after the incident.
• It outlines Unosecur's detection approach for CloudTrail-style activity, S3 enumeration, and remediation workflows.
• It adds FAQ-style explanations of MFA, password hashing, Zero Trust, and JIT access in the context of the breach.

👉 Unosecur’s full post covers the breach timeline, FTC response, and cloud detection detail

Deepen your knowledge

NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or access governance in your organisation, it is worth exploring.