Suntory breach exposes identity data in Microsoft 365 files

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Unosecur's blog post: Suntory’s cloud breach exposed personal data for about 100,000 people and shows how collaboration suites become repositories for identity data.

Why it matters: Identity and access teams need to treat collaboration storage as part of the identity surface because partner records, applicant data and contact lists can be exposed through valid cloud sessions.

👉 Read Unosecur's analysis of the Suntory cloud breach and identity data exposure

Context

SaaS collaboration environments often become shadow repositories for identity data because people export lists, contacts and registrant records there to get work done. The result is a governance problem: the information that defines who can be contacted, hired, delivered to or supported sits outside the systems that normally own identity lifecycle decisions.

Suntory’s case shows the risk is not limited to corporate employees. Partner staff, applicants, suppliers and customers can all be pulled into the same tenant exposure, which means identity governance has to extend beyond directory records and into file-sharing and collaboration stores.

Key questions

Q: How should teams govern identity data stored in collaboration suites?

A: Treat the identity estate inside collaboration suites as governed data, not loose content: apply least privilege to shared drives, groups and guest roles, classify files that contain IAM records, and review ownership for service accounts, API keys and recovery contacts stored in messages or documents. Centralise access reviews, retention rules and audit logging so identity data does not outlive its business need.

Q: Why can SaaS breaches bypass network and endpoint controls?

A: SaaS breaches can bypass network and endpoint controls because the attacker operates inside the provider's identity layer rather than through malware or a blocked port. Compromised SSO sessions, OAuth grants, API tokens and abused admin roles can let them read or export data while identity telemetry and conditional access checks become the main detection points.

Q: How do external accounts expand collaboration-suite exposure?

A: External accounts widen collaboration-suite exposure by creating additional trusted identities, such as guests, federated users and contractor accounts, that can inherit shared folder access, chat history and file links. Each outside identity should have a named owner, a time-bound purpose, scoped permissions and periodic removal so access does not persist after the business need ends.

Q: What should teams do first after cloud file exposure?

A: First preserve logs and state needed for investigation, including audit trails, access logs, sharing events, authentication records and file version history. Then contain the exposure by revoking affected tokens, disabling risky shares, resetting credentials and recording who had access, because cloud file incidents are usually resolved through identity and permission changes rather than endpoint cleanup.

Technical breakdown

Why collaboration suites become identity-data stores

File-sharing and collaboration platforms absorb identity data because they are convenient export destinations for rosters, applicant lists, supplier contacts and delivery records. Those copies are often governed by file permissions rather than by the identity system of record, so ownership, retention and exposure controls drift apart. Once identity data moves into shared storage, the security question changes from who belongs in the directory to who can reach the file, who can copy it, and which external parties were included in the dataset. See the Identity Data Quality and Identity Fabric Guide.

Practical implication: Treat collaboration storage as an identity-data repository and classify exported lists by access path as well as by content.

Why valid cloud sessions bypass network and endpoint assumptions

When an attacker uses a legitimate SaaS session, the platform sees authenticated access rather than obvious perimeter intrusion. That means network controls may see only ordinary cloud traffic, while endpoint tools may not observe the actual file access path inside the service. In these cases, identity evidence such as sign-in logs, consent logs, audit trails and token activity carries more value than perimeter telemetry because the security event happens inside the cloud control plane. See the Identity Visibility and Intelligence Platforms (IVIP) Guide.

Practical implication: Correlate SaaS audit, sign-in and consent logs so identity-led investigations can explain legitimate-looking cloud access.

How third-party identities widen the blast radius

Partner employees, suppliers, applicants and customers can all be present in the same collaboration tenant, even when they are not managed like internal users. That creates a mixed identity estate where guest accounts, delegated access and external sharing can extend exposure beyond the payroll boundary. The security issue is not only whether access was granted, but whether the organisation still understands which outside identities remain connected to sensitive files and what they can still reach. See the Multi-Cloud Identity Guide.

Practical implication: Extend access reviews to guest accounts, external sharing and application grants, not just internal directory users.

Threat narrative

Attacker objective: The attacker appears to have wanted access to identity-rich files inside the cloud tenant, most likely for data theft and downstream misuse.

1. Entry occurred through a legitimate cloud service session rather than a visible network intrusion, which is why the route into the tenant remains unconfirmed.
2. Credential or access-path abuse likely involved one of the standard cloud entry mechanisms the notice leaves open, such as a stolen credential, an OAuth grant, a guest account or a misconfiguration.
3. The attacker then downloaded files from the collaboration tenant and extracted lists containing personal data for multiple stakeholder groups.
4. Impact was exposure of roughly 100,000 people’s data and a notification and containment process that had to follow quickly after discovery.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

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

Collaboration suites have become identity-data repositories, not just workspaces. The Suntory exposure involved files that held names, email addresses, phone numbers and registration details, which means the tenant contained identity data well beyond ordinary documents. That creates a governance problem because lifecycle ownership of the data often sits with whoever exported it, not with the team that governs identities. Practitioners should treat exported lists and shared folders as part of the identity estate, not as peripheral storage.

Valid cloud authentication changes the shape of the incident. When an attacker acts through a legitimate SaaS session, the breach may leave little signal at the network edge and little context on the endpoint. The useful evidence shifts to identity logs, audit records and consent history, which is why collaboration-suite monitoring belongs inside identity operations rather than only in cloud operations. Identity visibility platforms help, but only if they are fed the right identity and access telemetry.

Third-party access without tenant-level governance expands the blast radius. Suntory’s exposure reached partner staff, supplier staff, applicants and customers, showing that external identities can sit inside the same data plane as employees. That is a reminder that partner access is not a side issue once files are shared into a tenant. Practitioners need one control view for internal and external identities, because the exposure boundary is defined by access paths, not payroll status.

Identity-data sprawl is the real failure mode. The breach did not require a special attack on the identity system itself; it required valuable personal data to accumulate in a collaboration platform where access controls and file sharing had become the de facto governance layer. That is why the named concept here is identity-data sprawl: personal and partner data moving into shared stores faster than identity teams can inventory and govern it. The practical consequence is that lifecycle and entitlement controls must extend to where the data lives, not only where identities are created.

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: Identity Data Quality and Identity Fabric Guide

What this signals

Identity-data sprawl is now a collaboration problem as much as an IAM problem. The next governance step is to locate where exported identity records accumulate in SaaS storage and decide which of those repositories belong in review cycles, retention rules and offboarding processes. That shift matters because the exposure boundary is no longer the directory alone.

The practical programme change is to treat partner access, guest access and app grants as a single review surface whenever collaboration data contains names, contact details or registration records. Review cycles that stop at internal users miss the identities most likely to widen the blast radius when a tenant is accessed.

For practitioners

• Map collaboration repositories to identity-data classes Inventory which shared drives, channels and tenant folders contain employee, partner, applicant and customer identity data, then assign an owner for each dataset.
• Correlate SaaS audit and sign-in logs Use cloud audit trails, sign-in history and consent records to reconstruct who accessed files, from where, and through which identity or app grant.
• Extend reviews to external and delegated access Include guest accounts, partner identities, app grants and tokens in recertification so access to collaboration data is reviewed as a single estate.
• Prepare a file-level notification workflow Build a response runbook that can identify affected files, classify the personal data in them and support regulator and individual notification within jurisdictional timelines.

Key takeaways

• The breach shows that collaboration suites can become long-lived stores for identity data, not just tools for messaging and document sharing.
• The evidence points to a SaaS access path that bypassed perimeter assumptions and exposed files holding personal data for about 100,000 people.
• The limiting control is not only tenant security but governance over exported identity data, external accounts and the access paths that reach shared files.

Related NHI Mgmt Group resources: Identity Data Quality and Identity Fabric Guide · Multi-Cloud Identity Guide · Data Breach Notification Checklist

Key terms

• Dedicated Tenant SaaS: A dedicated tenant SaaS model gives one customer isolated application and infrastructure resources within a provider-managed cloud service. In IAM, it is typically used when organisations need stronger data isolation, greater customisation, or tighter control for compliance reasons. The trade-off is usually higher cost and more operational complexity.
• Collaboration Suite: A collaboration suite is a set of cloud tools for email, chat, file sharing, calendars and online meetings. It usually combines shared storage, group workspaces and admin controls under one tenant, so security teams manage identities, sharing permissions, retention and audit logging across the same platform.
• Tenant Exposure: Tenant exposure is unwanted access to data, settings or identities in a cloud tenant, usually through misconfigured sharing, overly broad roles or compromised credentials. It describes the reach of one tenant's content or administration being exposed to another party, including guests, external users or attackers who gain valid access.
• Guest Account: A guest account is a directory identity issued to an outside user so they can collaborate inside an organisation’s environment. It usually inherits access to specific channels, documents, or apps. Because the identity is controlled by another tenant, its authentication posture and lifecycle cannot be assumed to match internal standards.

What's in the full article

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

• The full detection timeline and response sequence, including how Suntory moved from anomaly detection to preliminary regulator reporting.
• The specific file groups and personal-data categories exposed across employees, partners, applicants, suppliers and customers.
• The investigation details behind the access path, including what evidence remains unresolved and what Suntory has not yet confirmed.
• The identity monitoring and remediation workflow described for collaboration suites and SaaS environments.

👉 The full Unosecur post covers the response flow, exposed data groups and identity-governance implications in detail.

Deepen your knowledge

NHI governance, identity lifecycle management, and workload identity security 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.