Chegg breach shows why granular identity hygiene still fails

At a glance

What this is: This is a breach analysis of how Chegg’s AWS root credential handling allowed a former contractor to exfiltrate sensitive user data at scale.

Why it matters: It matters because IAM teams still have to treat privileged cloud identities, MFA enforcement, and offboarding as breach-prevention controls, not administrative hygiene.

By the numbers:

• More than 40 million users were affected by the breach, according to Unosecur.

👉 Read Unosecur's analysis of the Chegg AWS root credential breach

Context

Chegg’s breach is a cloud identity failure, not just a data exposure story. A former contractor retained AWS root access after the relationship should have ended, and that privileged account was used to reach S3-stored records.

The governance gap sits in lifecycle control, credential scope, and monitoring. When root access remains live without MFA and without tight logging, offboarding is not complete and privileged access is still operationally dangerous.

For IAM and NHI practitioners, the lesson is straightforward: standing administrative access in cloud environments can outlive both role changes and business relationships. That creates a breach window that normal access review rhythms often miss.

Key questions

Q: What breaks when a former contractor still has AWS root access?

A: The entire offboarding model breaks, because the access relationship outlives the business relationship. A retained root credential can bypass normal delegated controls, especially if MFA is missing. In practice, the failure is not just access retention, but the persistence of highest-level privilege after responsibility has already moved on.

Q: Why does missing MFA on a cloud root account create such a high risk?

A: Missing MFA weakens the last line of defense on the most privileged account in the environment. If credentials are compromised, an attacker can log in with far less friction and potentially change security controls, create new access paths, or conceal activity. The risk is amplified because root access usually bypasses normal least privilege boundaries.

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: What should IAM teams do when every cloud account can become privileged?

A: They should treat privilege as a design attribute of the cloud estate, not a role label. That means identifying which accounts, services, and keys can reach production systems, then reducing rights until each identity only has the access needed for its workload. The goal is narrow, explicit scope.

Technical breakdown

How AWS root credential abuse created the initial entry path

AWS root credentials sit above ordinary role-based controls because they can bypass many delegated permission boundaries. In this case, a former contractor retained root access, which meant the account could still act with the highest level of authority over cloud resources. Without MFA, the credential was not just powerful, it was easier to reuse after the relationship should have ended. The key governance failure is that root access was treated like a static administrative entitlement rather than a lifecycle-bound exception. Practical implication: root accounts need stricter issuance, monitoring, and revocation discipline than standard IAM roles.

Practical implication: treat root access as a break-glass identity with hard offboarding and MFA enforcement, not a routine administrator account.

Why S3 access made exfiltration fast once the credential was live

Amazon S3 is often used as a broad storage layer for user and employee data, so a privileged identity with read access can move from authentication to bulk retrieval quickly. The article says large numbers of S3 API calls were made during the incident, which is a classic sign that cloud storage access was being used for extraction rather than normal administration. If encryption and access controls are weak, the data path becomes simple: authenticate, list, retrieve, and copy. Practical implication: storage permissions and anomaly detection must be tuned to distinguish routine administration from data harvesting.

Practical implication: monitor S3 enumeration and retrieval patterns as potential exfiltration signals, not just normal platform activity.

How weak password hashing and missing encryption amplified the breach impact

The breach was not limited to access abuse. The article also points to weak password hashing and the absence of encryption for employee and user information, which increased the value and usability of the stolen records. That means the identity control failure and the data protection failure reinforced each other. Once data is stored in a way that remains readable or easily reused, a single credential lapse becomes a broader confidentiality event. Practical implication: identity governance and data protection must be designed together, because one cannot compensate for the other after compromise.

Practical implication: pair privileged access controls with encryption and strong hashing so credential abuse does not become immediate data exposure.

Threat narrative

Attacker objective: The objective was to extract large volumes of sensitive Chegg user and employee data from cloud storage before the access lapse was detected.

1. Entry occurred when a former contractor retained AWS root credentials after access should have been removed, and MFA was not enforced on the account.
2. Credential abuse followed through authenticated access to AWS and repeated S3 API calls that supported bulk retrieval of stored records.
3. Impact came from exfiltration of a database containing sensitive user information for millions of users, amplified by weak hashing and missing encryption.

Breaches seen in the wild

• Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.
• AI LLM hijack breach: attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Root access offboarding failed as a lifecycle control, not as a password problem: The former contractor’s access should have been ended when the business relationship changed, but the account remained usable. That is a governance failure in entitlement removal and exception handling, not a simple credential weakness. The implication is that cloud root accounts need a stricter joiner-mover-leaver model than ordinary administrative users.

Standing privileged cloud access creates an identity blast radius that standard access review cadences cannot contain: Root credentials can be used long after the original need has expired, which means the review process is already behind the risk. In practical terms, the problem is not merely overprivilege, it is persistent, high-impact privilege with weak expiry discipline. Practitioners should treat this as a breach class where time-in-account matters as much as permission scope.

Granular identity hygiene is inseparable from data protection: This breach shows that strong IAM alone does not save readable data, and encryption alone does not save overexposed credentials. The two controls have to fail together before the incident becomes large. That is why identity governance for cloud workloads must be measured against both access lifetime and the residual value of the data behind it.

Weak monitoring converts an access lapse into a delayed detection event: The article’s emphasis on large S3 API activity shows that exfiltration produces behavioural signals before full impact is realised. When logging and alerting are thin, the environment cannot distinguish legitimate administrative retrieval from theft. Practitioners should interpret cloud monitoring as part of identity enforcement, not as a separate detective layer.

AWS root credentials are a governance exception that should never become operationally normal: The Chegg case demonstrates that once a highest-privilege identity is shared, inherited, or left in place, the programme has already lost control of the account lifecycle. The practitioner conclusion is to eliminate persistent root usage paths and manage them as tightly bounded exceptions under explicit ownership.

From our research library:

• 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
• Read next: Identity Security Posture Management (ISPM) Guide

What this signals

Granular identity hygiene is only real when privileged cloud accounts have an expiry condition: If a contractor, admin, or vendor can keep superuser access after the work ends, the programme is already operating with standing breach potential. The control question is not whether access exists, but whether its lifespan is governed.

Monitoring must be identity-aware at the storage layer: Large volumes of bucket enumeration and object retrieval are not just cloud activity, they are identity signals. When those events are tied to unusual accounts or off-hours access, they become early-warning evidence of misuse rather than routine noise.

For practitioners

• Enforce root-account offboarding controls Inventory every cloud root or equivalent superuser account, assign named ownership, and require removal or replacement when staff or contractors leave a role. Build this into joiner-mover-leaver checks so the account cannot survive the relationship change.
• Require MFA on all privileged cloud identities Make multi-factor authentication mandatory for any administrative identity that can reach storage, billing, or security settings. Do not allow shared or password-only access paths for accounts that can expose large data sets.
• Reduce the blast radius of storage permissions Separate read, list, and admin permissions for object storage, and remove broad access from identities that do not need it. Review who can enumerate buckets, not just who can read files.
• Alert on high-volume S3 retrieval patterns Tune cloud monitoring to flag unexpected bucket listings, repeated object retrievals, and access patterns that deviate from normal administrative work. Use those signals as early indicators of exfiltration.
• Encrypt sensitive records and harden password storage Store user and employee data with encryption at rest and use strong password hashing algorithms with unique salts. That reduces the value of any data extracted through compromised cloud access.

Key takeaways

• Chegg’s breach shows how retained cloud root access can turn a lifecycle failure into a large-scale data exposure event.
• The incident affected more than 40 million users, which demonstrates how quickly a single privileged identity can create enterprise-scale impact.
• MFA enforcement, access revocation, and storage-level monitoring are the controls most directly tied to limiting this kind of breach.

Key terms

• Root Account Governance: The discipline of treating cloud root or equivalent superuser access as a tightly controlled exception with explicit ownership, MFA, and offboarding rules. In practice, it means the account is managed as a lifecycle-bound privilege, not a normal administrative login.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Offboarding Latency: Offboarding latency is the delay between removing an identity's access entitlement and the actual disappearance of that access from systems. For NHIs and privileged access paths, long latency creates residual exposure, especially when multiple platforms or extra components must be cleaned up separately.
• S3 Enumeration Pattern: A repeated sequence of bucket listing and object retrieval activity that can indicate data harvesting rather than ordinary administration. In cloud monitoring, the pattern matters because it often appears before full-scale exfiltration is complete.

What's in the full article

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

• The specific AWS access path Chegg allowed to remain active and how that created the breach window.
• The FTC remediation requirements tied to MFA, threat monitoring, encryption, and data access rights.
• The article's operational guidance on detecting bucket enumeration and exfiltration activity in cloud logs.
• The vendor's incident narrative on how monitoring and response could have reduced dwell time.

👉 The full Unosecur post covers the access path, FTC remediation, and cloud monitoring details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.