Does WorkOS Work in China? Data Residency, PIPL Cross-Border Transfer & ICP
With WorkOS the mainland-China question is not speed but data residency and cross-border transfer. WorkOS's own Data Processing Addendum names the United States as where personal data is stored and accessed, with no mainland-China region — so the enterprise directory and identity records it holds for your China users (employee names, emails, group and role attributes, sign-in identities and audit events) leave the mainland under PIPL, while the China-facing app that embeds the login still owes an ICP filing. A compliance-first look at the residency, cross-border and ICP exposure — and the lawful in-country path.
Does WorkOS work in China?
WorkOS is an identity API your app embeds, so the China question isn't whether an endpoint is fast — it's where the enterprise directory and identity records it stores for your China users come to rest. WorkOS's own Data Processing Addendum answers that: the United States.
By its DPA, WorkOS and its subprocessors transfer personal data “across international borders … to the United States,” and its Exhibit B names the one country that data is “stored in or accessed from” as the “United States of America” — with no mainland-China region. So the employee names, emails and group and role attributes a China customer syncs, the sign-in identities, and the audit trail behind them sit offshore. Holding them there is a cross-border transfer under PIPL (notice, a separate consent, and one transfer mechanism, Articles 38–40), it may trigger China's data-export security assessment, and for a critical information infrastructure operator the Cybersecurity Law's Article 39 (formerly Article 37) adds an in-country storage duty the US region can't meet — while the China-facing app that fronts the login still owes an ICP filing.
This is a risk map, not a verdict — what you owe turns on what you collect, your volumes, your role as handler and who your users are, and it's worth settling with counsel. 21YunBox maps the exposure, localizes the China identity data onto a China-resident footing, and delivers the China-facing app in-country on ICP-filed infrastructure — never any form of circumvention. Our China team can map your exposure with you →
What WorkOS's own documentation says about China
| Fact | Primary source |
|---|---|
| WorkOS's own Data Processing Addendum names the United States as where personal data is stored and accessed. Its Exhibit B answers the question of what countries personal data transferred out of the EEA, Switzerland and the UK is “stored in or accessed from” with “United States of America,” and Section 6(a) authorizes WorkOS and its subprocessors to transfer personal data “across international borders, including from the European Economic Area, Switzerland, and/or the United Kingdom to the United States.” No mainland-China location appears anywhere in the document, and WorkOS publishes no in-country data-residency region. | WorkOS Data Processing Addendum, Section 6(a) and Exhibit B (workos.com), retrieved 2026-10-09 |
| WorkOS holds directory, authentication and audit data — all personal information. Directory Sync (SCIM) pulls an enterprise customer's employee directory — names, work emails, group and role attributes — into WorkOS; SSO and AuthKit broker and hold sign-in identities; and audit logs record authentication events. Held in a US-hosted WorkOS, these records for your China users are a cross-border transfer of personal information under PIPL (Articles 38–40: notice, a separate consent, and one transfer mechanism). | WorkOS product documentation — SSO, Directory Sync, AuthKit, Audit Logs (workos.com/docs), retrieved 2026-10-09; PIPL Articles 38–40 |
| Sending China directory and identity data to an offshore WorkOS is a PIPL cross-border transfer, and may require a data-export security assessment. Moving personal information collected from people in mainland China to a WorkOS account hosted in the United States triggers PIPL Articles 38–40 — notice, a separate consent, and one transfer mechanism (a CAC security assessment, the CAC standard contract, or certification) — and above the relevant volume or sensitivity thresholds China's data-export security assessment (数据出境安全评估) may apply before anything leaves. | Personal Information Protection Law of the PRC, Articles 38–40 (cac.gov.cn), retrieved 2026-10-09 |
| CIIO and large-volume handlers owe in-country storage, and the China-facing login still needs an ICP filing. Where the handler is a critical information infrastructure operator or moves personal information at volume, personal information generated in China must be stored in the mainland (Cybersecurity Law Article 39 (formerly Article 37); PIPL Article 40) — which a US-hosted identity layer cannot satisfy. And the app that fronts the WorkOS login, served to mainland users, must carry an ICP filing (State Council Order No. 292; MIIT Order No. 33) bound to a mainland hosting resource WorkOS does not provide. | Cybersecurity Law Article 39 (formerly Article 37); PIPL Article 40; State Council Order No. 292; MIIT Order No. 33, retrieved 2026-10-09 |
Sources verified by the 21YunBox compliance team on 2026-10-09.
For an application that signs in enterprise customers from mainland China, the instinct with WorkOS is to ask whether its API reaches the mainland. That is the wrong test. WorkOS is an identity layer other products embed — single sign-on, Directory Sync, hosted user management, audit logs — and the China decision does not turn on how quickly an endpoint answers. It turns on where the directory and identity records WorkOS keeps about your China users come to rest, and on whether you had a lawful basis to move them there. WorkOS settles the first half of that in its own legal documentation, and the answer is the United States.
WorkOS in China at a glance
| What decides it | In WorkOS's own terms — and China's law |
|---|---|
| What it is — and why reachability isn't the axis | WorkOS is an enterprise-readiness identity API — SSO (SAML/OIDC), Directory Sync (SCIM), AuthKit user management, audit logs — that apps embed to onboard enterprise customers. It is integrated, not browsed, so whether an endpoint resolves from the mainland is a delivery matter. What decides the China question is where the identity data it stores lives, and whether that data could lawfully leave China. |
| Where the identity data lives | WorkOS's own Data Processing Addendum names the single country its personal data is “stored in or accessed from” as the “United States of America,” and authorizes transfer “to the United States.” There is no mainland-China region in its DPA, and no data-residency region in its docs to select. |
| What that data is | Directory Sync pulls an enterprise customer's employee directory — names, work emails, group and role attributes — into WorkOS; SSO and AuthKit broker and hold sign-in identities; audit logs record authentication events. Every one of these is personal information under China's law. |
| Collecting China identity data into it | Holding your China users' directory and identity records in a US-hosted WorkOS is a cross-border transfer (数据出境) under PIPL (Articles 38–40): notice, a separate consent, and one transfer mechanism. Above volume or sensitivity thresholds a data-export security assessment may apply, and for a critical information infrastructure operator the Cybersecurity Law's Article 39 (formerly Article 37) sets an in-country storage duty a US region cannot meet. |
| Serving the public | The China-facing app that fronts the WorkOS login is a public service in the mainland, so it needs an ICP filing bound to a mainland hosting resource — and compliant in-country delivery. WorkOS names no mainland region, so there is nothing of its own to file against. |
| The lawful path | Keep the China directory and identity data on a China-resident footing, send WorkOS only what may lawfully leave, keep WorkOS for your other markets, and deliver the China-facing app in-country on ICP-filed infrastructure. 21YunBox maps, localizes and delivers; it never uses or suggests circumvention. |
The identity records WorkOS holds are personal information — and they sit in the US
WorkOS’s business is to hold the identity of your users. When you wire up single sign-on it brokers the authentication; when you turn on Directory Sync it pulls your enterprise customer’s employee directory — names, work emails, group and role attributes — into WorkOS; and its audit logs record who signed in and when. Each of those is personal information.
WorkOS’s own Data Processing Addendum is explicit about where that information lands. It authorizes WorkOS and its subprocessors to transfer personal data “across international borders, including from the European Economic Area, Switzerland, and/or the United Kingdom to the United States,” and its Exhibit B names the one country that personal data is “stored in or accessed from” as the “United States of America.” No mainland-China location appears anywhere in the document, and WorkOS publishes no in-country data-residency region to choose. So the directory a China customer syncs, the sign-in identities behind it, and the audit trail that records their use all come to rest in the United States — offshore from the mainland.
Holding China directory and identity data offshore is a cross-border transfer
Under China’s Personal Information Protection Law, moving the personal information of people in mainland China into a WorkOS account hosted in the United States is a cross-border transfer (数据出境), and the obligation sits with the handler — your application, not WorkOS the processor. PIPL Articles 38–40 require notice, a separate consent distinct from any general agreement to sign up, and one transfer mechanism: a CAC security assessment, the CAC standard contract, or certification.
A directory sync can move an entire workforce’s records in one pass, so scale matters here. Above the relevant volume or sensitivity thresholds, the transfer may also require China’s data-export security assessment (数据出境安全评估) before anything leaves. And if your organization is a critical information infrastructure operator, the Cybersecurity Law’s Article 39 (formerly Article 37 — renumbered by the 2025 amendment that took effect on January 1, 2026, with its substance unchanged) requires personal information generated in China to be stored in China — an in-country storage duty a US-hosted identity layer simply cannot satisfy. Which of these bind your specific case turns on what you collect, your data volumes, and your role under Chinese law, and it is a risk to confirm with counsel.
Consent to process identities is its own PIPL duty
Residency is only one half. Directory Sync and SSO work by handling identifiable people — their names, their accounts, their authentication events — and under PIPL that processing needs its own lawful basis before the cross-border question is even reached: informed consent and a clear notice of what identity data is gathered and why. The transfer to a US-hosted WorkOS then needs a further, separate consent on top of that.
WorkOS gives you controls that can help — scoping which directory attributes are synced, and access and deletion APIs — and those can genuinely narrow what leaves the country. But they do not discharge the notice-and-consent duties, which remain yours as the handler. Whether a given identifier counts as sensitive, and what your consent flow must say, are questions to settle with counsel against what you actually collect.
Pointing WorkOS at another region doesn’t resolve a China duty
The obvious move is to choose a different hosting region and keep the data in place — but WorkOS’s own DPA names only the United States as the country where personal data is stored and accessed, and its documentation publishes no mainland-China region to point it at. There is nowhere in-country to send it.
Keeping China-collected directory and identity data on a China footing therefore means a different shape: a consented, China-resident store or identity bridge for the China entity’s users, with only what may lawfully leave passed on to WorkOS. That split — what must stay, what may go — is a legal judgment before it is a technical one, and it is where the real work sits. One operational note belongs here too: an authentication surface served from offshore sits squarely in the sign-in path, so if it loads slowly or fails from inside China it can stop a user signing in at all. The answer to that is never a network workaround — 21YunBox neither uses nor suggests circumvention of any kind — it is lawful, in-country delivery of the China-facing surface, which also carries its own ICP-filing duty.
This is a risk map, not a verdict: whether you owe separate consent, a transfer mechanism, in-country storage, an ICP filing, or some combination depends on your data volumes, your role as handler, and who your users are — worth settling with counsel before you rely on it.
The lawful path — map, localize, deliver
There is a compliant way to run WorkOS for a China-facing product, and it has three moves.
First, map: our China team works through your PIPL exposure on both fronts — the processing of identities and their transfer offshore — marking which directory fields, authentication records and audit events collected in China must stay in the country, what may lawfully leave, where a data-export security assessment or an Article 39 storage duty bites, and what your consent and notice have to cover. The legal conclusions are yours to confirm with counsel; we build the technical picture that feeds them.
Then localize: we stand up and integrate a China-resident footing for the China identity data — a consented, in-country store or an identity bridge for the China entity’s users — so the directory and sign-in your product depends on keep working while that data stops leaving the mainland by default, and you keep WorkOS for the markets where it already serves you.
Then deliver: the China-facing app that fronts the WorkOS login is itself a public service in the mainland, so it carries an ICP filing (备案) duty and needs compliant, in-country delivery. 21YunBox delivers it in-country — the 21YunBox Optimizer — set in front of what you already run, with no rebuild and no re-platform. The outcome is an identity layer that runs legally and compliantly for your users in China. We never hand you a route around China’s data-export rules or around any network restriction — no one lawfully can — because the whole design is the opposite: keep in the mainland what must stay, deliver the rest in-country, and never move personal information across the border by stealth.
Related reading:
- Cross-border data transfers under PIPL
- China’s data-export security assessment
- China’s Cybersecurity Law (data localization, Article 39)
- How to get an ICP filing for China
