One Unrevoked Key, 37.5 Million People: What the Coupang data breach reveals about data access

The Coupang breach is one of the clearest recent examples of a problem every CISO already worries about: trusted credentials can outlive their purpose, and when they do, organisations often cannot see what those credentials can reach until it is too late.

The enforcement decision and public reporting indicate that the incident involved poor management of authentication signing keys and weak access controls. A former engineer's credential allegedly remained valid after departure and was later used to access customer data over an extended period. The breach affected tens of millions of people and persisted for months before it was fully understood.

The most important lesson is not simply “rotate keys more often.” Key rotation matters, but it is only one part of the control story. The harder question is the one security teams often cannot answer quickly:

If this credential, service account, application, or machine identity is misused, what sensitive data can it reach, how much of it, and would we notice abnormal access before it becomes a breach?

That is where the Coupang incident becomes more than an IAM failure. It becomes a data access intelligence failure. And because the regulator's findings did not stop at access - they extended to notification, data destruction and the preservation of evidence - it is also a test of whether the organisation could describe its own data estate after the fact.

Those are the same question asked at two different moments. Before an incident, it sounds like blast radius. After one, it sounds like evidence. An organisation that cannot answer it in the first form will struggle to answer it in the second, under a statutory clock, in front of a regulator.

1. What happened, in plain technical terms

The reported control failure centres on an authentication signing key which an ex-employee retained after he was no longer with the organisation.

In modern applications, a user does not re-enter a password on every request. After login, the application may issue a signed token. That token carries claims that downstream systems use to determine whether the request should be trusted. The signing key is the private cryptographic secret used to create the token signature. If that key remains valid and accessible to the wrong person, an attacker may be able to generate tokens that appear legitimate to systems that validate the signature.

That does not mean every control is automatically bypassed. Well-designed systems should still validate the subject, claims, expiration, audience, scope, authorisation policy, object ownership, and business context before returning data. The risk is that a retained or compromised signing key can pass the first trust check. If downstream authorisation is weak, overly broad, or poorly monitored, that trusted path can become a large-scale data exposure.

In Coupang's case, unauthorised access began in mid-2025 and continued for approximately six months. Two intrusion windows circulated publicly in the months after disclosure; the figure above is the one the regulator adopted following investigation, and it was revised upward from the shorter window initially reported. The activity was tied to access from overseas servers and involved customer information such as names, email addresses, phone numbers, delivery addresses, order-related data and - in a detail worth pausing on - apartment entry codes.

Payment data and passwords were not included. The exposed information was nonetheless highly sensitive: contact data, delivery addresses and building access codes are exactly the combination that enables fraud, extortion and targeted social engineering.

The lesson for CISOs is simple. Valid credentials are dangerous precisely because they look normal at the authentication layer. The detection problem shifts from “did someone break in?” to “is this trusted access still appropriate?”

2. Why this stayed hidden for so long

The breach persisted for months. That does not necessarily mean every traditional control was absent or silent. A more likely explanation is that the available controls did not correlate the right signals quickly enough.

The relevant signals were likely spread across different planes:

• Identity state: Was the human owner, custodian, or related identity still active?
• Credential lifecycle: Was the signing key still valid, rotated, owned, and justified?
• Application activity: Were tokens being generated or used in unusual ways?
• Source context: Were requests coming from unusual infrastructure or geography?
• Data sensitivity: Were the accessed systems holding high-volume customer PII?
• Consumption pattern: Was the volume, frequency, or scope of data access abnormal?

Individually, each signal can look explainable. The credential may appear valid. The application path may appear authorised. The database read may appear to come from a normal service account. The customer data store may be a legitimate production system.

Together, however, those signals form a toxic combination:

A departed or stale identity relationship + a still-valid credential + access to high-sensitivity customer data + sustained abnormal data consumption.

That combination is what siloed controls often miss. IAM can tell you who can access a system. PAM can help manage privileged access. Logs can show activity. But unless those signals are connected to the sensitivity and scale of the data being accessed, security teams may not know which activity deserves urgent attention.

3. The gaps that were exposed, and the best practices that were ignored

Five control gaps sit in the access half of this incident. Some fall squarely in IAM, PAM, secrets management and application security. Others fall in data access governance. The distinction matters, because Data Access Intelligence should not be positioned as a replacement for key management or secure application design. It is the layer that exposes where sensitive data is concentrated, who or what can reach it, and whether access behaviour is abnormal.

It is worth naming the five precisely, because the regulator cited six violations spanning the full incident lifecycle and only two of them sit in this half of the story. The other four are dealt with in Section 6.

Gap 1: Weak signing-key and credential lifecycle governance

The most obvious gap was key lifecycle management. Authentication signing keys should have explicit ownership, restricted access, rotation schedules, revocation triggers, and periodic audits. If an employee leaves, changes role, or no longer has a business need, related credentials and secrets must be reviewed and revoked or rotated.

This is primarily an IAM, PAM and secrets-management discipline problem. But data context changes the priority. A stale credential with access to a low-sensitivity test environment is not the same risk as a stale credential that can reach tens of millions of customer records. Without data context, organisations treat credential cleanup as generic hygiene. With data context, they can prioritise revocation by blast radius.

Gap 2: No clear view of what sensitive data the credential could reach

The core question is not just “who had access?” It is “what sensitive data sat behind that access?”

Coupang had customer names, contact details, delivery addresses and order-related data exposed - including, notably, records belonging to people who were not Coupang customers at all, but whose shipping details passed through the platform. A CISO would want to know which systems contained that data, which identities and services had access to it, which access was actually used, and which credentials created the largest blast radius.

If those answers require a manual investigation after the breach, the control has already failed.

Gap 3: Over-scoped service or application access

Trusted application or authentication paths could reach highly sensitive customer data at scale. That indicates concentration of privilege: one compromised or misused credential could create a disproportionately large blast radius.

Security teams need to identify service accounts, applications, roles and credentials with unusually broad access to sensitive data, and to challenge whether that access is still necessary.

If this one credential is compromised, how much sensitive data becomes reachable?

Most organisations cannot answer that continuously.

Gap 4: Lack of sensitive-data access monitoring

A login event alone is not enough. A successful token validation alone is not enough. Even a service account read event may not be enough unless it is connected to the data being accessed.

The missing control is continuous monitoring of sensitive-data access patterns: volume, frequency, scope, source, identity, object and sensitivity. A sustained pull of high-sensitivity customer data should create a different alert than a normal application read, even if both use valid credentials.

This is the data-layer behaviour that matters. The attacker's activity may have appeared normal to authentication systems, but it was being expressed at the data layer through repeated access to sensitive customer information.

Gap 5: Incomplete blast-radius and regulator-response readiness

When a breach occurs, regulators ask direct questions: what data was accessed, who could access it, when did access occur, how many individuals were affected, and why was the activity not detected earlier?

If answering those questions requires stitching together IAM exports, database grants, application logs, data inventories, ticketing records and manual interviews, the organisation is already behind. A data-aware access governance programme does not make incident response automatic, but it gives security and privacy teams a much stronger starting point: a current map of sensitive data, access paths, entitlements, actual usage and risk concentration.

4. Key takeaways

Most commentary on the Coupang breach will file it under IAM failure, insider risk, or key-management failure. Those labels are not wrong, but they are incomplete.

From the Veeam and Securiti point of view, the decision exposes a deeper operating problem:

Security teams cannot govern access effectively if they do not know what sensitive data sits behind each credential, service, application and identity - and they cannot answer a regulator if they cannot reconstruct what the estate held on the day it happened.

IAM and PAM enforce access to systems. They do not always know how much sensitive data sits behind those systems, whether access is proportional to business need, or whether actual consumption patterns are abnormal.

Data Access Intelligence and Governance, as part of the Veeam and Securiti DataAI Command Platform, is best framed as the data-context layer for access governance. Its role is to correlate sensitive-data discovery, identity and entitlement context, activity telemetry and policy signals across supported environments. That context helps security teams detect toxic combinations that individual tools may miss.

The strongest claim is not that any single product would have automatically prevented Coupang in every architecture. The stronger and more credible claim is this:

Data Access Intelligence addresses the class of failures the incident illustrates: stale or excessive access, weak visibility into who or what can reach sensitive data, and delayed detection of abnormal sensitive-data consumption. The same data context then carries the phases that follow - evidence, recovery and notification. 

5. What Data Access Intelligence would have surfaced

Step 1: Know where the sensitive data concentrates

Before access can be governed, sensitive data has to be discovered and classified.

In supported repositories, Data Access Intelligence can help identify structured and unstructured data assets and classify sensitive data such as customer identifiers, delivery-address fields, contact details and order-history attributes. That inventory gives security, privacy and data teams a defensible starting point for determining which systems require tighter access review, monitoring, masking or segmentation.

For Coupang-shaped environments, this matters because customer data does not live in one clean database. It exists in production systems, delivery-address lists, logs, exports, analytics environments, backups and derivative datasets. IAM cannot govern what the organisation has not inventoried.

Step 2: Quantify who and what can reach it

Once sensitive data is mapped, the next question is access.

Data Access Intelligence can help map entitlements across supported users, roles, groups, service accounts, applications and connected access paths. The objective is not to produce another access list. It is to rank access by sensitivity and blast radius.

In a Coupang-shaped environment, the key finding would be concentration of privilege: a small number of application or service identities with effective access to large volumes of customer PII. The platform cannot know that a former employee kept an offline copy of a key unless that signal exists in connected systems. But it can show that compromising a highly privileged service path would expose a large portion of the customer data estate.

That is the finding security teams need before an incident, not after one.

Step 3: Flag stale, unused or excessive access

Where entitlement data and activity telemetry are available, Data Access Intelligence can compare granted access against observed usage and recommend least-privilege remediation.

Access risk is not binary. Some access is unused. Some is excessive. Some is rarely used but high impact. Some is normal for a service but abnormal for a location, time or volume. A risk-proportionate programme prioritises the credentials and service accounts that combine broad entitlement with sensitive-data reach.

For a departing employee, this context matters especially. Offboarding should not be a flat checklist. Credentials tied to high-blast-radius data should be revoked, rotated and verified with higher urgency than low-risk access.

Step 4: Detect toxic combinations, not isolated events

Individually, the signals may not trigger the right alarm. The credential is valid. The application path is authorised. The customer data store is a known system. The service account has access. The data request succeeds.

Together, those signals tell a different story:

A stale or suspicious credential path is repeatedly accessing high-sensitivity customer data at unusual volume, from unusual infrastructure, through a privileged application path.

That is what a data command graph is designed to surface. By connecting identities, credentials, entitlements, data stores, sensitivity labels and activity, security teams can detect combinations more meaningful than any single alert.

It is also how teams reduce false positives. Instead of alerting on every sensitive dataset, every service account, or every unusual access event, they can focus on the narrower set of conditions that actually indicate business risk.

Step 5: Baseline sensitive-data consumption

Security teams need to know what normal data access looks like.

Where logs include identity, token or subject claims, source context, requested objects, response volume and data sensitivity, Data Access Intelligence can help establish baselines for how much sensitive data each identity, service and application normally reads.

Would this guarantee detection within hours in every architecture? No. If malicious reads ride through legitimate application paths and logs lack the right subject, object or response context, detection will be harder.

But it addresses the six-month problem directly, by making sustained, high-volume access against sensitive datasets measurable rather than invisible.

Step 6: Prioritise remediation based on data value

Not every access issue deserves the same urgency.

A data-aware governance model ranks remediation by data sensitivity and blast radius. A stale service account touching regulated PII should be treated differently from a stale account with access to low-sensitivity internal content. A credential associated with a high-volume customer data store should receive faster review, tighter controls and more frequent recertification.

This is where DSPM context makes IAM and PAM decisions risk-proportionate. Without data context, access reviews are access-list-proportionate. With data context, they become business-risk-proportionate.

Step 7: Accelerate investigation and regulator response

When regulators ask who could access what, many organisations begin a slow reconstruction across IAM systems, database grants, application logs and data inventories.

If entitlements, activity and sensitive-data classification are already correlated for the affected systems, the organisation can answer faster and with stronger evidence. The realistic claim is acceleration and defensibility, not instant completeness.

That matters because breach impact is not limited to the incident itself. It also includes regulatory scrutiny, customer notification, executive accountability, litigation risk and reputational damage.

Steps 1 to 7 describe the front half of the incident. The phases that follow the intrusion have their own owners, and they are judged against a different set of questions.

6. The same question, asked at every phase of the incident

Everything above concerns the front half of an incident: what sensitive data exists, who or what can reach it, and whether that access is behaving normally. That is where the Coupang failure started. It is not where the consequences were decided.

Of the six violations the regulator cited, only two concern the securing of authentication methods and the control of access. The remaining four sit after the intrusion - delayed breach notification, undermining the independence of the privacy officer, failure to destruct personal information, and failure to preserve evidence. Three of those are, at their core, questions about the state of the data estate and the organisation's ability to describe it after the fact.

That is the honest reason to widen the frame. Access intelligence shortens the window in which a valid credential can quietly read customer data. It does not, on its own, tell a regulator what the estate held on a given date, reconstruct an intrusion without contaminating production, or carry a notification programme for tens of millions of affected people. Those capabilities sit in different planes. The organisations that answer a regulator well are the ones that decided in advance which plane owns which phase.

The table below sets out that posture. The right-hand column is the more useful one. These are the questions to pose to any vendor, including us - each written so that a truthful answer has preconditions attached, because every one of these capabilities does.

Read down the middle column and a pattern appears that is easy to miss when these capabilities are discussed separately. The same classification decision serves four different phases. What sensitive data exists and where it sits determines which access is worth reviewing, which alert is worth escalating, which recovery point is worth trusting, and which individuals must be notified.

An organisation that gets that one decision right is not only better protected. It is better able to prove it.

7. What this means for security leaders

The Coupang breach is a warning about separated control planes.

The identity plane knew something about accounts and credentials. The application plane knew something about requests and tokens. The data plane knew where customer information lived. The monitoring plane held fragments of activity. But the organisation lacked a continuous, data-aware view of how those pieces combined into risk - and, afterwards, of what the estate had actually held.

For CISOs, the takeaway is not that one tool replaces IAM, PAM, secrets management, secure coding or incident response. It does not. The takeaway is that those controls are incomplete unless they are backed by best practice and informed by data context.

Security teams need to be able to answer, continuously:

• Where does sensitive data concentrate?
• Which users, services, applications and credentials can reach it?
• Which access paths have the largest blast radius?
• Which entitlements are stale, excessive or unused?
• Which identities are consuming sensitive data abnormally?
• Which toxic combinations should be prioritised before they become incidents?
• Could we prove what the estate held on the day of the breach?
• Could we identify and notify every affected individual inside the statutory window?

The first six are questions about exposure. The last two are questions about evidence. They are answered from the same inventory.

The remediation business case has changed

There is a financial dimension that deserves attention from anyone building a remediation case internally. The Coupang penalty was assessed against revenue - approximately 1.8 percent of a three-year average revenue base, for 37.5 million affected records. The comparable rate in the SK Telecom case, covering roughly 26.95 million records, was approximately 0.8 percent.

Read together, those two decisions suggest a regulator willing to assess breach penalties on revenue at roughly double the previous rate. That reframes the argument. Reducing the volume of sensitive data any single credential can reach is no longer only a risk-reduction measure. It is a reduction in a revenue-linked liability, and it can be modelled as one.

8. The takeaway

Coupang had security tooling. What it lacked was continuous, data-aware truth about who or what could touch customer data, whether that access still made sense, and - once the access had already happened - what the estate had contained and who had to be told.

A valid credential should never become an unlimited customer-data access path without visibility, monitoring and proportional controls. And an organisation should never discover the shape of its own data estate for the first time in a regulator's letter.

See how Data Access Intelligence and Governance maps sensitive data access, detects toxic combinations, and helps prioritise remediation in a live demo.

Sources

Analysis is based on the regulator's enforcement decision and public reporting. Sources consulted include:

• Personal Information Protection Commission (PIPC) - enforcement decision and press release, June 2026
• Korea Herald, “Coupang hit with record W624.7b privacy fine,” June 11, 2026
• Korea Economic Institute of America, “The Coupang Data Breach: A Timeline,” February 22, 2026
• Bloomberg, “Coupang Warns of 2026 Slowdown After Data Breach Hits Spending,” May 6, 2026
• Bloomberg, “Coupang's Losses Grow After Fallout From Data Breach Deepens,” August 4-5, 2026
• TechCrunch, “CEO of South Korean retail giant Coupang resigns after massive data breach”
• TechCrunch, “Korea's Coupang says data breach exposed nearly 34M customers' personal information,” December 1, 2025