Coupang data breach shows cloud identity risk outlasting controls

At a glance

What this is: Coupang’s breach shows how long-running unauthorized access in cloud environments can expose customer data when identity controls lag behind access reality.

Why it matters: IAM, NHI, and cloud security teams need to treat effective access, offboarding, and session governance as live controls, not administrative afterthoughts.

By the numbers:

• 80% of recent cloud incidents were linked to identity-related issues, such as excessive permissions, misconfigurations, and poorly governed identities.
• Only 44% of companies ensure that all access rights are revoked within 24 hours of an employee’s departure.
• Around 59% of companies report experiencing a data breach related to poorly managed offboarding processes.

👉 Read Unosecur’s analysis of the Coupang data breach and cloud identity risk

Context

Cloud identity risk is what happens when access, not the network edge, becomes the main control plane. In this case, Coupang’s disclosure points to unauthorized access that persisted over months, which is exactly the kind of gap that IAM, cloud governance, and offboarding processes are meant to prevent but often do not.

The article does not identify the attack method, which matters because the governance lesson is broader than any one exploit path. When human and machine access is granted, inherited, and left active for too long, the organisation can have legitimate-looking sessions that are no longer legitimate in practice.

For IAM and NHI programmes, the core problem is not simply breached data. It is the inability to continuously verify whether access still matches the business relationship, the role, or the operational need that originally justified it.

Key questions

Q: What breaks when cloud access is not revoked quickly enough?

A: The breach window stays open after the business relationship has ended. In cloud environments that means accounts, sessions, keys, or delegated permissions can keep exposing sensitive data even when they no longer have a valid purpose. The result is not just delayed cleanup. It is extended unauthorized access that may look legitimate in telemetry until the damage is done.

Q: Why do cloud breaches so often come back to identity and access management?

A: Cloud platforms rely on identity for nearly every privileged action, so weak governance turns access itself into the attack path. When permissions are excessive, stale, or poorly monitored, an attacker does not need to break the platform. They only need to use the access the environment already trusts.

Q: How do organisations know whether offboarding is actually working?

A: They measure revocation speed, session termination, key invalidation, and third-party access removal after a departure or role change. If access still exists hours or days later, offboarding is administrative, not operational. Strong programmes verify that live access disappears, not just that a ticket was closed.

Q: Who is accountable when unauthorized access persists in a cloud environment?

A: Accountability sits with the team that owns identity lifecycle, access governance, and the systems that issue or retain privileges. In practice that usually means IAM, cloud security, and the business owner of the access path must share responsibility for revocation, review, and monitoring.

Technical breakdown

Why identity-first cloud access creates hidden exposure

Modern cloud environments route access through identities, roles, tokens, and delegated permissions rather than fixed network trust. That design improves flexibility, but it also means a compromised or stale identity can look normal while still carrying broad access. If logging, entitlement review, and session validation are weak, unauthorized access can persist without obvious infrastructure alarms. The exposure is often not a dramatic system takeover, but the slow use of valid access to reach customer data or administrative surfaces.

Practical implication: security teams need to evaluate effective access, not just configured access, across cloud identities and sessions.

Offboarding failures and lingering privilege windows

Offboarding is the point where access should end, but many programmes still treat it as an HR workflow instead of an identity control. If accounts, keys, or tokens remain active after role change or departure, the access window can stretch far beyond the business relationship that created it. In cloud systems, that window can include API access, console access, and service integrations, which makes revocation timing as important as initial provisioning.

Practical implication: revoke human and non-human access through the same lifecycle control standard, with short, measurable revocation SLAs.

Why cloud breach detection misses identity misuse

Identity misuse is difficult to spot because the attacker is often using valid credentials or authorized paths. That shifts detection away from malware signatures and toward behavioural anomalies, unusual session duration, access to sensitive datasets outside normal patterns, and privilege use that does not match the expected job function. In practice, teams need correlation between identity events, data access, and cloud telemetry to see when authorised access becomes unauthorised behaviour.

Practical implication: correlate identity logs with data-access telemetry so unauthorized use of valid access can be detected earlier.

Threat narrative

Attacker objective: The objective was sustained access to large-scale customer information for extraction or misuse without triggering immediate containment.

1. Entry occurred through unauthorized access to customer information in a cloud environment, with the initial path undisclosed in the public record.
2. Escalation appears to have relied on access that remained active for months, allowing the actor to continue using legitimate-looking privileges against customer records.
3. Impact was the exposure of 33.7 million customer accounts, including names, phone numbers, email addresses, physical addresses, and order-related information.

Breaches seen in the wild

• Zacks Investment Research breach — Zacks breach exposed 12M customer records including credentials.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

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

NHI Mgmt Group analysis

Cloud identity governance fails when organisations assume access can be reviewed after the fact. Coupang’s disclosure shows the more dangerous pattern: unauthorized access can persist long enough to move through normal business data paths before anyone notices. That is not a perimeter failure. It is a governance failure in how cloud access is granted, observed, and revoked.

Hidden effective access is the real breach surface in cloud environments. The article is a reminder that configured permissions and effective permissions are not the same thing, especially when roles, inherited access, and stale sessions remain active. IAM programmes that stop at provisioning miss the live-state problem. Practitioners should treat effective access as the control boundary that matters.

Vendor or employee status does not change the risk when lifecycle offboarding is weak. Whether the actor is internal, external, or somewhere in between, access that outlives the relationship becomes a standing exposure window. This is the same failure mode seen in many cloud incidents: accountability ends on paper, but access stays alive in systems. Security teams should model offboarding as a revocation control, not an HR completion step.

Identity visibility is the named concept this breach reinforces: access without continuous verification becomes operational debt. The longer cloud access remains unvalidated, the more it behaves like an unmanaged asset rather than a controlled entitlement. This is where NIST CSF and Zero Trust thinking intersect with NHI governance. Practitioners need a programme that can see who or what still has live access and whether that access still makes sense.

This incident validates continuous identity security as a cloud control requirement, not a specialised add-on. When the breach path is unknown but the access pattern is clear, the governing question becomes how quickly teams can detect, scope, and revoke access that no longer has a defensible reason to exist. The practitioners who win here are the ones who operationalise identity governance across both human and machine identities.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which helps explain why identity abuse can persist unnoticed in cloud environments.
• That visibility gap is why teams should pair lifecycle governance with the 52 NHI Breaches Analysis to understand how hidden access becomes real compromise.

What this signals

Hidden access is now a board-level cloud risk, not a back-office IAM issue. When only a fraction of organisations can see service accounts clearly, identity abuse is likely to outlast ordinary monitoring. Practitioners should expect cloud breach investigations to focus increasingly on effective access, stale privileges, and offboarding latency rather than just intrusion vectors.

Identity blast radius is the right concept for this class of incident: once access exists, the question is how far it can travel before it is revoked or detected. That means teams need tighter linkage between joiner-mover-leaver events, cloud telemetry, and data exposure paths.

Programmes that still separate human IAM, service-account governance, and cloud access review will struggle to contain incidents with this shape. The operating model now has to treat all three as one access fabric, with revocation, monitoring, and certification measured against live entitlement use.

For practitioners

• Tighten revocation SLAs for all departures Set a measurable SLA for revoking human, vendor, and service access after role change or exit. Track completion against active sessions, API keys, and console privileges so revocation closes the real access window, not just the HR record.
• Review effective access, not assigned roles Inventory cloud identities and compare assigned permissions with actual usage, inherited entitlements, and dormant sessions. Focus on high-value data paths and administrative functions where valid access can still produce unauthorized exposure.
• Correlate identity events with data access Join IAM, cloud audit, and data telemetry to spot unusual persistence, atypical dataset access, and privilege use that does not match the expected function. This is the fastest way to detect valid credential abuse before it becomes a large disclosure.
• Treat offboarding as a revocation control Use a single offboarding checklist for employees, contractors, and non-human accounts that includes key rotation, token invalidation, session termination, and third-party access removal. The control objective is to eliminate standing access quickly and verifiably.

Key takeaways

• Coupang’s breach shows that unauthorized cloud access can persist long enough to expose millions of records even when the attack path is undisclosed.
• The scale of the issue is structural: identity-related issues dominate cloud incidents, and delayed revocation keeps access alive far beyond the business need.
• Teams need to manage effective access, offboarding speed, and telemetry correlation as core breach controls, not as support functions.

Key terms

• Effective Access: Effective access is the real privilege a user, service account, or token can exercise in a live environment, not just what is written in an entitlement record. It includes inherited permissions, active sessions, delegated rights, and any access path that remains usable after provisioning changes.
• Offboarding Revocation: Offboarding revocation is the process of removing access at the point a relationship, role, or service need ends. In practice it means ending sessions, invalidating keys and tokens, removing third-party access, and confirming that no live privileges remain beyond the approved lifecycle.
• Identity Blast Radius: Identity blast radius is the amount of data, systems, or administrative capability reachable once an identity is abused. It depends on privilege scope, session duration, inheritance, and monitoring quality, which is why it can stay large even when the original compromise looks small.
• Continuous Identity Security: Continuous identity security is the practice of monitoring, validating, and adjusting access throughout the identity lifecycle instead of only at provisioning. It matters because cloud and machine identities can become risky long after they were created, approved, or reviewed.

What's in the full article

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

• The company’s own breakdown of the disclosure timeline, including when unauthorized access was identified and how long it may have persisted.
• The vendor’s discussion of cloud identity risk signals, including offboarding weaknesses, insider-risk considerations, and identity-first exposure patterns.
• The identity security platform framing used by Unosecur to explain how it maps human and non-human identities in cloud environments.
• The incident FAQ section that ties the breach to identity control failures and suggested operational responses.

👉 The full Unosecur post covers the disclosure timeline, identity-risk interpretation, and platform framing behind the incident.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.