Legitimate access, not exploits, drove two major identity breaches

At a glance

What this is: This is an identity-breach analysis showing that lawful or trusted access can become the attack path when monitoring, verification, and usage baselines are weak.

Why it matters: It matters because IAM, PAM, and NHI programmes must treat external accounts, partner access, and trusted contacts as governed identities, not assumed-safe exceptions.

By the numbers:

• The Danish incident affected about 8.8 million people, living and dead, from a register holding roughly 11 million records.

Context

The core security problem is not unauthorized entry in the classic sense, but legitimate access that was neither constrained by behavior nor questioned when it changed shape. In both cases, the attacker used an identity path that already existed, which is why this belongs in the identity governance discussion rather than only in breach response.

For identity teams, the lesson is that third-party access inherits the sensitivity of the data or action it can reach, not the size or trust status of the account holder. A lawful account, an employee login, or a partner platform all become part of the same control surface once they can query records, send notifications, or access customer data.

That is why access reviews, authentication strength, and usage monitoring have to be connected. If the programme only checks who was granted access and not how that access behaves, it will miss exactly the kind of misuse seen here.

Key questions

Q: What breaks when third-party access is treated like ordinary employee access?

A: The control model breaks because vendor access usually carries broader blast radius, weaker lifecycle discipline, and more indirect authentication paths than employee access. Third-party relationships often include API keys, service accounts, delegated tokens, and non-interactive sign-ins that are easy to forget and hard to monitor. That creates a persistent exposure surface attackers can replay after a supplier breach.

Q: Why do impersonation attacks succeed even when passwords are strong?

A: Because the attacker is targeting the process around the password, not just the password itself. If reset, recovery, or credential handoff can be satisfied by a convincing call or message, then the login remains transferable and therefore exploitable.

Q: How do security teams spot malicious activity after a legitimate login?

A: They correlate identity events across applications and look for behavioural deviation. Sudden file spikes, unusual locations, new device enrolments, broad OAuth grants, and access to data outside normal working patterns are stronger indicators than login success alone. Cross-application correlation is essential because single-system logs rarely reveal the full chain.

Q: Should organisations prioritise authentication hardening before more perimeter controls?

A: Yes, when the threat model includes rapid exploitation and post-compromise movement. Perimeter controls matter, but identity assurance decides whether an attacker who gets in can continue. Authentication hardening should be prioritised where compromise would otherwise unlock privileged access.

Technical breakdown

Why legitimate access becomes the attack path

These incidents show a control failure that happens after authentication succeeds. The attacker does not need to break the login mechanism if the identity already has standing access to a sensitive system. In identity terms, the weak point is not initial authentication alone but the absence of continuous scrutiny over what a valid account can do, especially when the account belongs to a third party or a trusted intermediary. Once query rights, messaging rights, or customer-data reach are granted, the account becomes part of the attack surface. See the NHI Lifecycle Management Guide.

Practical implication: Map every external identity to the data and functions it can actually reach, then monitor that reach as a privileged condition.

Behavioral baselines for third-party identities

A password, token, or employee login is only one signal. The more useful signal is whether the account behaves like the role it claims to be. A small partner account making millions of searches, or an employee account suddenly contacting customer-facing platforms, is an anomaly that identity governance should treat as a control event. Behavioral baselines are especially important where lawful access exists, because abuse may never look like a failed login or an exploit. Read Top 10 NHI Issues.

Practical implication: Set per-account usage thresholds and alert on volume, timing, and destination changes that do not fit the approved access pattern.

Why phishing-resistant authentication matters for impersonation-led access

In the ASOS case, the reported entry method was impersonation of a trusted contact to obtain credentials. That is a classic failure mode for knowledge-based or transferable secrets, because the human process around the login becomes the weakest link. Phishing-resistant authentication changes the trust model by binding the credential to the legitimate site and device, reducing the chance that a social-engineering prompt can hand over usable access. This does not solve every insider or partner risk, but it does close a common path into third-party platforms. See the IAM and Identity Provider Buyer's Guide.

Practical implication: Require phishing-resistant MFA wherever an account can reach customer data or messaging infrastructure.

Threat narrative

Attacker objective: The objective was to extract or reach personal and customer data through accounts that the target systems already trusted.

1. Entry occurred through legitimate access rather than a software exploit: the Danish case used lawful register access, and the ASOS case used credentials obtained by impersonation.
2. Credential or account access was then abused to reach high-value systems, including the Danish population register and third-party customer-data platforms used by ASOS.
3. The impact was mass exposure of personal data and, in the ASOS case, unauthorized contact with customers through the app and connected platforms.

Breaches seen in the wild

• Vercel Context.ai OAuth Supply Chain Breach: Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

Third-party access is privileged access: Once an external account can query, retrieve, or send data on behalf of an organisation, its legal status does not reduce its security criticality. The Danish case shows that a small company can hold enormous effective reach, while the ASOS case shows that a trusted platform can become a customer-data pathway. Identity programmes that classify these accounts as ordinary vendor access are under-governed by design. The practitioner implication is to treat external identities as privileged assets with ownership, monitoring, and recertification.

Behavior is the missing identity control plane: Authentication answers who logged in, but not whether the session still matches the approved purpose. Roughly 14 million lookups from a small business account, or an employee login used to touch third-party customer systems, should be treated as identity anomalies, not billing oddities or isolated misuse. This is where per-account baselines and alerting move from nice-to-have to essential. The practitioner implication is to govern usage patterns with the same seriousness as entitlement assignment.

Trusted-contact impersonation is a governance failure, not just a phishing story: The ASOS incident shows that social engineering succeeds when the organisation has no strong requirement that reset, recovery, and privilege changes be verified through resistant authentication paths. Passwords alone remain transferable, and transferability is exactly what the attacker exploited. Identity provider selection matters here because the control objective is not convenience, but binding high-risk access to a verifiable source. The practitioner implication is to remove any account recovery path that can be satisfied by a convincing impersonation.

Access outlives accountability when offboarding is not operationalised: The Danish case points to a familiar NHI pattern, where partner access remains valid after the original trust context has changed. That assumption was designed for stable commercial relationships and regular review cycles. It fails when a partner account can persist, be reused, or be passed around without immediate revalidation. The implication is not merely to add a review, but to rethink whether partner access can exist without lifecycle ownership and revocation evidence.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

Identity governance for third parties has to move from approval to verification: The next maturity step is not broader exception handling, but tighter proof that an external account still deserves the access it has. Organisations should expect more attacks that stay inside valid credentials and therefore evade controls built only for unauthorised logins.

Partner access needs the same control weight as internal administration: When a vendor or trusted contact can touch customer data, the security model should assume privileged exposure, not shared convenience. That means lifecycle ownership, behavioral alerts, and recovery-path controls become core identity programme requirements rather than adjunct controls.

Access baselines are becoming the practical boundary of trust: As lawful access is abused more often, the organisations that can prove who should do what, how often, and through which channel will absorb less risk. The operational question is no longer whether an account was valid, but whether its behaviour remained within the bounds of that validity.

For practitioners

• Inventory every third-party identity with data reach List partner accounts, vendor accounts, and SaaS service identities that can search records, send notifications, or access customer data, and assign a named owner to each.
• Require phishing-resistant MFA for high-risk external access Use FIDO2 security keys or passkeys for any account that can reach sensitive records or customer communications, including recovery and reset paths.
• Set behavioral baselines on sensitive accounts Alert on unusual query volume, unusual message volume, new destinations, and access outside normal time windows for any account with privileged reach.
• Recertify partner access on a defined schedule Reconfirm why each external account still needs access, then remove credentials that have no recent justified use or no current business owner.

Key takeaways

• The central failure in both incidents was not a broken exploit chain but valid access that was never constrained by behavior.
• The Danish case affected about 8.8 million people, showing how much damage a single trusted account can create when access is overbroad.
• Strong authentication and access recertification both matter, but external identities also need usage baselines and owner-level accountability.

Related NHI Mgmt Group resources: NHI Lifecycle Management Guide · IAM and Identity Provider Buyer's Guide · Vercel Context.ai OAuth Supply Chain Breach · Top 10 NHI Issues

Key terms

• Third-Party Identity: An identity issued to a partner, vendor, contractor, or external service that can access internal systems. These identities often sit outside normal employee governance and can become persistent trust paths if they are not reviewed, expired, and revoked on schedule.
• Behavior Baseline: A record of normal activity for a non-human identity, including typical consumers, resources, and actions over time. Baselines help security teams detect when an identity is being used in an unusual way and provide the context needed to enforce least privilege safely in dynamic environments.
• Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
• Access Recertification: Access recertification is the periodic review of user or account permissions to confirm that access is still justified. It is useful, but it is not enough on its own because it reacts after entitlements already exist, which is why lifecycle governance must reduce the volume of exceptions before review time.

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.