TSMC Data Breach: 46,000 Employee Records Allegedly Leaked Through a Cloud Vendor

On November 12, Taiwan Semiconductor Manufacturing Company furnished a Form 6-K to the U.S. Securities and Exchange Commission, signed by Senior Vice President and CFO Wendell Huang, with a statement of roughly 130 words. Two sentences carry the weight. Some current and former employee data “was made available on an external website without authorization,” and the company has “found no evidence that TSMC’s systems have been compromised.” What links them is the finding that the leaked information “has been verified to match data stored in the system services of a cloud service provider.”

Taiwan’s Central News Agency reported that sellers on underground forums were offering what they described as 46,000 TSMC employee records, 6.9 gigabytes in total, for three bitcoin (about NT$7.4 million, or roughly US$220,000 in international coverage). They threatened to publish everything if no buyer appeared within a week. Many readers came away with “TSMC hacked.” The filing says something narrower and less comfortable: the chipmaker’s own walls appear to have held while its employees’ personal lives leaked out through infrastructure it rents.

What TSMC confirmed in its SEC filing, and what the sellers only claim

The confirmed facts are few. TSMC acknowledged the exposure and tied the data to a cloud provider’s stored records. It stated that the material is unrelated to company operations or customer data, and said it has been informing affected personnel and providing support. It has engaged the cloud vendor, investigating authorities and a third-party cybersecurity firm to establish what happened. It has not named the provider, identified the service involved, confirmed a victim count or described an intrusion method. As of November 13, every colorful detail in circulation comes from the sellers and the press that covered them. None of it comes from TSMC or a regulator.

Those details are still worth cataloguing, as long as their provenance stays attached. CNA and Taiwan News reported the listings on DarkForums and BreachForums, the latter a marketplace that has been seized and resurrected more than once. Wccftech and Crypto Briefing described a proof file, “tsmc.txt,” containing 499 records laid out in 19 fields per person. Across outlets, the reported fields are names, job titles, national identification numbers, home addresses, phone numbers, email addresses, bank account details and emergency contact information. TSMC has verified that the exposed data matches what its cloud vendor holds. It has verified nothing about how the sellers obtained it.

That gap has received too little attention. A data-provenance match shows where the information lived, not where the intrusion happened. The same records could have come from the vendor’s production tenant, from a subprocessor further down the chain, or from an exported copy sitting in a staging area, and the match would look identical in all three cases. “No evidence of compromise” also describes the current state of an investigation, and TSMC’s own wording (“currently, we have found no evidence”) is careful on exactly that point.

For scale, TSMC and its subsidiaries employed more than 90,000 people worldwide at the end of 2025, according to its annual report. A claimed 46,000 records covering current and former staff would be a substantial slice of that population. The inclusion of former employees raises a retention question that comes up again below.

How 6.9 GB of HR data leaves a SaaS tenant without tripping an alarm

TSMC has disclosed no attack vector. What follows is the hypothesis space responders work through in incidents of this shape, grounded in documented precedents and not in guesses about this particular vendor.

Enterprise HR and payroll platforms are multi-tenant systems. Human access is federated through an identity provider using SAML 2.0 or OpenID Connect. Machine access runs on OAuth 2.0 tokens issued to integrations that sync employee records to payroll processors, banking gateways and identity governance tools. The data itself is normalized, with core identity and compensation tables and dependents and emergency contacts in child tables keyed to an employee identifier. A sample showing 19 unified fields per person, spanning payroll and emergency contacts, points to a joined reporting view or an account with query rights across several relational domains. That is an export, not a scrape of a directory page.

Stolen credentials and hijacked sessions

The first plausible path is stolen human credentials or session tokens, belonging either to a customer-side administrator or to the vendor’s own support staff. Infostealer malware on personal or contractor machines harvests credentials wholesale. Adversary-in-the-middle phishing proxies capture session cookies after multi-factor authentication has already succeeded, so the second factor protects nothing.

The canonical case is the 2024 Snowflake campaign. Mandiant’s investigation traced every incident to compromised customer credentials, mostly lifted by infostealers such as VIDAR, REDLINE and LUMMA from non-Snowflake systems, sometimes years before use. The affected accounts lacked MFA and network allowlists, and Mandiant and Snowflake notified roughly 165 potentially exposed organizations. Snowflake’s platform itself was never breached. The attackers exported customer data, extorted victims directly and sold the rest on criminal forums, which is the business model visible in the TSMC listing.

Over-privileged OAuth integration tokens

The second path is programmatic. In August 2025, the actor Google Threat Intelligence tracks as UNC6395 used OAuth tokens stolen from Salesloft’s Drift application to impersonate a trusted integration against customer Salesforce instances. Between August 8 and 18 it systematically exported large volumes of data, then combed the haul for AWS keys, passwords and Snowflake tokens. FINRA put the blast radius at more than 700 organizations. The attackers deleted query jobs to cover their tracks, but the audit logs survived, and the core Salesforce platform had no vulnerability at all. Even Workday, the HR software vendor, told customers the campaign had reached routinely shared business contact data in its own third-party CRM.

The same logic applies to HR. If an integration holds broad read scopes across employee tables and its client secret or refresh token leaks, an attacker can paginate through tens of thousands of records from any hosting provider on earth, at a request rate that looks like a nightly sync.

Misconfigured storage and export pipelines

The third path is duller and common. HR systems generate scheduled flat files for bank payroll clearing and benefits reconciliation, and those files land in object storage. Permissive bucket policies, long-lived pre-signed URLs or a tenant-isolation flaw in a reporting microservice can hand an outsider the finished archive without touching an application login at all.

In all three scenarios the traffic never crosses TSMC’s network. It is vendor-side API or storage activity, authenticated with valid tokens and indistinguishable from administration at the network layer. Unless the customer streams the vendor’s audit logs into its own SIEM, the only witnesses to the exfiltration are logs the customer does not hold.

What the file size suggests

One piece of arithmetic sharpens the picture. At 6.9 gigabytes for a claimed 46,000 people, the archive averages roughly 150 kilobytes per person. Nineteen fields of plain text, even with Chinese-language names and addresses in UTF-8, would run one to two kilobytes per row. The gap suggests the archive carries more than the flat sample shows: scanned identity or banking documents, base64-encoded attachments (which inflate payloads by about a third), verbose JSON or XML wrappers, or overlapping exports of the same population.

This is inference from the sellers’ own numbers and not a confirmed finding, but it matters for severity. Document scans turn a phishing-enabling dataset into a ready-made kit for passing identity verification checks.

What leaked employee data is worth to fraudsters and spies

For the individuals, the reported field combination is close to a worst case. A national ID number paired with a home address, mobile number and bank account details supports fraudulent credit applications, account-takeover pretexts against banks and telecoms, and SIM-swap attempts.

Bank details plus job title enable a well-documented fraud called payroll diversion. A caller impersonating the employee persuades HR or the payroll helpdesk to redirect direct deposit, or logs into HR self-service with phished credentials and changes it directly. Emergency contacts extend the attack to people who never worked for TSMC. A caller who knows an engineer’s spouse’s name and phone number can build a hospital-emergency pretext that no security-awareness training has prepared that family to resist.

For organizations, the dataset is a targeting map. Job titles attached to personal emails and mobile numbers let any buyer identify process integration engineers, lithography specialists and advanced packaging staff, and approach them outside corporate defenses. The sellers here look like financially motivated brokers, complete with a fixed bitcoin price and a countdown. Once data is sold or dumped, though, it stops belonging to its first customer.

Hsinchu does not treat that as an abstract concern. In July, Taiwan’s courts finalized a ten-year prison sentence for former TSMC engineer Chen Li-ming in the 2-nanometer trade-secret case, and Tokyo Electron’s Taiwan subsidiary was fined NT$150 million in the same prosecution. Prosecutors framed the case under the National Security Act as well as the Trade Secrets Act. Taiwanese authorities have spent years warning about mainland efforts to poach chip talent, and a roster of who works on what, reachable on personal channels, has obvious value to anyone running those efforts.

TSMC’s 2023 LockBit incident and the Kinmax precedent

TSMC has been here before, in structure if not in data type. At the end of June 2023, LockBit listed the company on its leak site with a $70 million demand and an August 6 deadline. TSMC traced the intrusion to Kinmax Technology, an IT hardware supplier, and said its operations and customer data were untouched. That is the same perimeter-holds, vendor-fails posture as this week. The three years between the two incidents chart a shift in the industry: the third party that leaks your data used to be the integrator who configured your servers, and now it is the cloud service that stores your people.

Taiwan’s Personal Data Protection Act: why TSMC cannot outsource liability

The statute that governs this incident is Taiwan’s Personal Data Protection Act (PDPA), and it is unforgiving on exactly the point TSMC’s statement emphasizes. Article 4 deems anyone commissioned to collect, process or use personal data to be acting on behalf of the commissioning agency. Renting the processing does not rent out the liability.

The security-maintenance duty, long housed in Article 27 and renumbered to Article 20-1 in the amendments promulgated on November 11, 2025, requires measures against theft, alteration, damage, loss and leakage. Article 12 requires notifying affected individuals once a leak is known, which is what TSMC’s notification campaign is doing.

The 2025 amendments add mandatory reporting to a new single regulator, the Personal Data Protection Commission, along with duties to take immediate countermeasures and preserve incident records for inspection. The Executive Yuan sets the effective date. Through 2026 the commission was still operating via its preparatory office while implementing regulations were drafted, so the transition itself is part of the compliance picture any Taiwanese breach now lands in.

Fines and executive liability

The penalty schedule has teeth that were absent a few years ago. Under Article 48, security-measure failures draw fines of NT$20,000 to NT$2 million, escalating to NT$150,000 to NT$15 million where the violation is material or goes unrectified. Article 50 allows the regulator to fine the responsible representative or manager the same amount as the company, unless that person proves they exercised due care to prevent the violation. Executives at companies that treat vendor questionnaires as their security program should read that article twice.

Civil exposure and class actions

Civil exposure is where the arithmetic gets interesting. Article 28 lets victims claim NT$500 to NT$20,000 per person per incident even when they cannot prove a quantifiable loss. Aggregate statutory compensation is capped at NT$200 million for a single incident unless the interests at stake exceed that figure. Article 29 shifts the burden of proof: a company is liable unless it can show the injury did not result from its willful act or negligence, and because of Article 4, pointing at the vendor does not automatically make that showing.

If the seller’s 46,000 figure holds, 46,000 claims at the NT$20,000 maximum would total NT$920 million. The cap, roughly US$6 million, binds well before the multiplication does, though victims who can prove actual damages pursue them separately.

Article 34 makes collective action practical. A foundation with at least NT$10 million in registered assets, or a charity with 100 or more members, can sue in its own name on written delegations from 20 or more victims. It must list data protection in its charter and have stood for three years, and court fees are waived on claim value above NT$600,000. Claims run two years from knowledge of the damage and five from the incident. None of this requires anyone to prove TSMC itself was hacked.

The SEC disclosure track

The SEC filing runs on a parallel track. As a foreign private issuer, TSMC discloses material events by furnishing Form 6-K, the same channel it used two days earlier for its board resolutions. The SEC’s 2023 cybersecurity rules direct foreign issuers to furnish material incidents on that form when they publicize them at home. A statement filed within hours of the first CNA report is what a functioning disclosure process looks like. Whether the eventual findings get the same promptness is the thing to watch.

An awkward week in Hsinchu: the board meeting, AI bets and other Taiwan breaches

The leak landed two days after one of the more consequential board meetings in TSMC’s recent history. On November 10, directors approved third-quarter financials showing consolidated revenue of NT$1,494.24 billion (US$46.72 billion) and net income of NT$763.06 billion, with diluted earnings per share of NT$29.43. They approved capital appropriations of approximately US$40.93 billion for advanced technology and packaging capacity, fab construction and 2027 R&D investment.

They also authorized up to US$500 million to buy Anthropic common shares at its per-share IPO price, up to US$500 million for preferred stock in OpenAI Group PBC, and up to US$500 million more to establish an investment company for the semiconductor industry and its surrounding ecosystem. Announced U.S. commitments have reached roughly US$265 billion after the additional US$100 billion expansion unveiled in July.

Against those numbers, a US$220,000 extortion demand is a rounding error, and no wafer output or customer design was implicated. The costs that matter sit elsewhere: incident response and forensic fees, notification and support for tens of thousands of people, the litigation and regulatory exposure described above, and the harder-to-price erosion of employee trust at a company whose engineers are already targets of espionage prosecutions.

It was a rough week for Taiwanese cybersecurity generally. Travel site EzTravel disclosed on Monday that attackers had exposed data on more than 690,000 customers, and Bank SinoPac said on Wednesday that its online banking system had been exploited for unauthorized transfers worth NT$41.76 million. TSMC’s incident is the most famous of the three and not obviously the worst.

The juxtaposition with the board’s AI investments is less ironic than it looks. Capital intensity at the leading edge buys no immunity at the identity layer, and the same company can be world-class at one and merely average at the other.

How to protect employee data at SaaS vendors: controls that survive the vendor boundary

This incident should push companies toward controls that keep working once the data sits outside their network. The usual vendor checklist falls short here.

Phishing-resistant authentication and short-lived tokens

Start with authentication. Use phishing-resistant FIDO2/WebAuthn for every administrative and HR-privileged account on both sides of the relationship, because adversary-in-the-middle attacks reduce SMS and push-based MFA to a speed bump. Session lifetime matters as much as login strength. Support for Continuous Access Evaluation and the OpenID Shared Signals Framework lets an enterprise identity provider kill active SaaS sessions within seconds of detecting anomalous behavior, instead of waiting for a token to expire.

Integration tokens deserve the same scrutiny as human ones. Give them narrow scopes instead of tenant-wide reads and short lifetimes, and bind them to the sender through mutual TLS (RFC 8705) or DPoP (RFC 9449), so a stolen token replayed from unfamiliar infrastructure simply fails. The Drift campaign adds a further requirement: inventory the vendor’s own integrations and subprocessors. Your provider’s chat widget or CRM connector is part of your attack surface whether or not it appears in your risk register.

Encryption that holds up against application-layer compromise

Encryption deserves a candid assessment. Provider-managed encryption at rest, and even customer-managed keys, protect against disk theft and rogue infrastructure access. They do nothing against an authenticated application session, because the application decrypts transparently for anyone the access layer trusts.

Holding your own keys outside the provider, or tokenizing specific columns such as national IDs and bank account numbers before they reach the vendor’s database, does change the outcome of an application-layer compromise. The price is real: ciphertext breaks native search, sorting and payroll computation on those fields. The technique fits a handful of high-sensitivity columns and not the whole schema.

Audit-log monitoring, contracts and data retention

Stream the vendor tenant’s audit logs into your own SIEM and write detections for bulk pagination, abnormal report exports and off-hours queries against sensitive tables. The UNC6395 actors deleted query jobs but could not delete the logs, and those logs were where victims found the truth. Contractually, demand notification timelines measured in hours, subprocessor transparency and audit rights you actually exercise.

Then apply minimization, with some skepticism toward inherited defaults. Does the HR platform need emergency contacts’ home addresses? Why were former employees’ full records, bank details included, still sitting in an active system years after departure? Article 11 of the PDPA already requires erasure when the collection purpose ends. Retention schedules are a security control as much as a compliance artifact.

What to watch next in the TSMC investigation

TSMC’s response so far is procedurally what good looks like: same-day disclosure, employee notification, and a joint investigation with the vendor, authorities and an outside firm. The judgment that matters will come later. Does the postmortem name the failure mode honestly, and do the unnamed vendor’s other customers get told in time to check their own tenants?