On October 6, 2026, UK fashion retailer ASOS disclosed that an attacker had gained access to customer data. The way in was not a zero-day or a sophisticated malware chain. According to the company’s own notification, the attacker impersonated a trusted contact to trick an ASOS employee into handing over their login credentials, then used those credentials to reach information held on third-party platforms the retailer uses to communicate with customers. The exposed data included names, contact details, home addresses, phone numbers, and — notably — customers’ website search histories. Payment card data and account passwords were reported as unaffected.
Sources: Infosecurity Magazine, The Guardian, and TechCrunch.
If you lead security or platform engineering, the technique should feel uncomfortably familiar, because it is the most common breach pattern there is: someone steals a legitimate credential, and that credential already has access to everything the attacker needs. No exploit required. The login worked exactly as designed.
This post walks through what happened, explains why credential theft keeps turning into full-blown breaches, and lays out the control that breaks the chain — not by stopping every phish (you cannot), but by making a stolen login far less useful. The reassuring part is that this is a solved problem in principle. The gap is almost always in deployment, and it is a gap you can close methodically.
What Actually Happened
Let us separate the two stages, because the lesson lives in the second one.
Stage one: the credential was stolen through social engineering. The attacker posed as a trusted contact and persuaded an employee to give up their login. This is phishing in its purest form. It did not matter how strong the password was. The employee handed it over believing they were talking to someone legitimate.
Stage two: the stolen login had standing access to systems holding customer data. This is the stage that turned a successful phish into a reportable breach. The credential was not limited to the one thing the employee needed at that moment. It carried durable access to third-party platforms containing customer records — so the attacker, now holding a valid login, simply walked in and read the data.
Hold those two stages apart in your mind, because they call for completely different defenses. Stage one is about awareness, phishing-resistant authentication, and the hard reality that humans can be fooled. Stage two is about what a credential is allowed to reach, and for how long. You will spend enormous effort on stage one and still occasionally lose a credential. That is why stage two is where the breach is actually won or lost.
A note on the exposed data: search history may sound minor next to card numbers, but it is exactly the raw material for convincing, personalized phishing against the retailer’s customers. A message that references what someone was actually shopping for is far more believable. The downstream harm from this breach is a wave of better-targeted social engineering — the same technique that started it, now aimed at customers.
Why Credential Theft Keeps Becoming a Breach
If stolen credentials are the number-one way in, why do we keep letting them unlock so much? Three reasons, and all three are fixable.
1. “Temporary” access becomes permanent. An employee is granted access to a system for a project, a migration, or a one-off task. The task ends. The access does not. Multiply this across years and dozens of systems and you get accounts carrying far more standing access than anyone intends — a quiet accumulation nobody is tracking. When one of those accounts is phished, the attacker inherits all of it.
2. Access is granted broadly because scoping it is tedious. Giving someone (or some integration) durable, generous access is fast. Giving them narrow, time-boxed access the manual way is slow and annoying. So teams default to broad grants, and the breadth sits there as latent risk until a credential leaks.
3. Third-party and integration access is the worst-governed of all. The ASOS data lived on third-party platforms. External platforms, vendors, and integrations routinely get standing credentials into systems holding sensitive data, precisely because wiring up tighter access by hand is painful. If any one of those credentials is compromised, the blast radius is whatever that integration can touch — which is often a great deal.
Every one of these is the same underlying issue wearing a different hat: access that exists when nobody is actively using it. A credential that only worked during the few minutes an employee genuinely needed it would have given this attacker almost nothing. A credential that works 24/7, forever, is a standing invitation.
The Problem, Named Precisely
Standing access is the real exposure. Stealing a credential is stage one, and you cannot fully prevent it. The breach happens in stage two — when the stolen credential turns out to hold durable, broad access to sensitive systems. The fix is to ensure credentials only grant access in the moment it is needed, scoped to the task, and automatically revoked afterward.
This reframes the whole defense. You are not trying to build a wall no phish can ever cross — that wall does not exist. You are trying to ensure that when a credential inevitably gets stolen, there is nothing standing behind it for the attacker to use.
How Cloudanix Helps: Just-in-Time Access Everywhere It Matters
Cloudanix provides Just-in-Time (JIT) access across every surface where standing access tends to accumulate — cloud consoles, databases, servers, Kubernetes, SaaS applications, CI/CD pipelines, and AI agents. The lifecycle is the same everywhere and it is deliberately simple:
request → approve → time-boxed grant → auto-revoke.
Here is how that would have changed the ASOS story.
No standing access means a stolen login unlocks little
With JIT, an employee does not hold durable access to a sensitive third-party platform. They request access when they need it; it is granted for a bounded window; it revokes automatically. If their login is phished at 2 a.m. while they are not working, the credential grants access to nothing that is currently elevated — because nothing is. The attacker holds a valid login that, right now, opens no sensitive doors.
Compare that to the actual incident, where the stolen login carried live, standing access to customer-data systems. JIT does not make the phishing fail. It makes the phishing not matter nearly as much — which is the only durable position, given that some phishing will always succeed.
Third-party and vendor access, finally governed
This is the part the ASOS breach makes vivid. JIT applies to third-party and non-human access the same way it applies to employees. A vendor or integration does not get a permanent key to your data platforms; it requests scoped, time-boxed access and gives it back. One of our FinTech customers, Finfinity, used exactly this model to reach 100% reduction in privileged access exposure and effectively zero standing third-party risk across its environment — external partners could be granted access confidently because every grant was temporary, audited, and automatically revoked.
Multi-level approvals that match the sensitivity
Not every access should be gated the same way. JIT lets you auto-approve low-risk, read-only requests so day-to-day work is not slowed, require a single approver for staging, and demand a quorum for production or sensitive-data access. On-call engineers can be auto-approved during a declared incident so nothing blocks a real emergency. The friction lands exactly where the risk is, and nowhere else.
Identity-stamped audit in your own storage
Every request, approval, session, and revocation is recorded with the real human identity behind it — not just a role name — and written to your own storage. When you have to notify regulators or reconstruct an incident, you can state precisely who had access to what and when it ended. This is the opposite of the position most breached companies find themselves in, scrambling to reconstruct access that was never cleanly recorded.
Correlation with your posture graph
Because JIT runs alongside Cloudanix CSPM and CIEM, an identity that CSPM flags as over-privileged can feed directly into tightening its JIT policy. The exposure analysis and the access control are one system, so “this account can reach too much” leads directly to “so let’s stop it holding that reach when it is not using it.”
Being Honest: What JIT Does and Does Not Stop
We would rather you deploy this understanding exactly what it covers.
What JIT genuinely prevents: stage two. It removes the standing access that turns a stolen credential into a breach. A phished login with no currently-active grants is close to useless. This is the single highest-leverage change you can make against the most common breach pattern in existence.
What JIT does not do: it does not stop the phish itself. Social engineering targets humans, and humans can be convinced. You still need phishing-resistant authentication (hardware keys, passkeys), consistent MFA — the ASOS reporting and related coverage pointed to inconsistent MFA as a contributing factor across similar incidents — and ongoing awareness work. JIT is the layer that assumes those will occasionally fail and ensures the failure is contained.
Where this sits relative to your other controls: think of authentication as the lock on the front door and JIT as the rule that the house is empty of anything valuable unless someone is actively using it. You want both. The lock reduces how often someone gets in; JIT reduces what they can do when they do.
Being precise about this boundary is intentional. We are not promising to make you unphishable. We are promising that when a credential is stolen — and some will be — the attacker finds standing access reduced to almost nothing.
A Practical Path Forward
-
Find your standing access. Inventory which employees, vendors, integrations, and service accounts hold durable access to systems containing customer or sensitive data. The third-party and integration list is usually the scariest and the most ignored.
-
Start with the sensitive-data systems. Move access to your customer-data platforms, databases, and production consoles onto JIT first. These are where a stolen credential does the most damage.
-
Govern third parties explicitly. Replace any permanent vendor or partner credentials with scoped, time-boxed JIT grants. This is where the ASOS-style breach lives.
-
Keep developers happy. Auto-approve low-risk and incident-driven access so JIT is invisible until someone needs access they do not have. Adoption fails when security adds drag; it succeeds when it does not.
-
Point audit at your own storage and test it. Make sure you can answer “who accessed this and when” before you ever need to answer it for a regulator.
Each step shrinks the blast radius of the next stolen credential, and none of them depends on your phishing defenses being perfect.
The Takeaway
The ASOS breach is the oldest story in security told with 2026 details: a legitimate credential, stolen through a convincing lie, that happened to open doors it should not have been holding open. You will never make your people impossible to fool. What you can do — and what breaks the chain — is make sure that a stolen login finds nothing standing behind it.
Access that exists only in the moment it is used, scoped to the task and revoked automatically, turns the most common breach pattern in the world into a non-event. That is a position you can reach methodically, system by system, without slowing your teams down. You do not have to fear the next phish. You have to make sure it inherits nothing.
If you want to see where standing access is accumulating in your environment — especially among third parties — book a session and we will map it with you, then show you how JIT takes it off the table.
People Also Read
- Eliminating Standing Cloud Access for SOC 2 and ISO 27001
- Why IAM in the Cloud Needs Attention
- PAM for Cloud Infrastructure: Why Traditional PAM Falls Short
- A Big List of Popular Data Breaches and What Your CloudOps Team Can Learn
- What is IAM Just-In-Time (JIT) Access?
- Cloudanix: Just-in-Time Access
- Cloudanix: Contextual Severity
