Key Takeaways
- WooCommerce 11.0, released on 4 August 2026, lets a customer attach their past guest orders to a user account after confirming their email address. The merchant-facing switch is called "Customer email confirmation".
- The authentication is stronger than the one-line release note suggests. Pull request #65971, merged on 26 June 2026, replaced a 6-digit code with "an authenticated GET carrying an unguessable, single-use, email-bound key" — the person clicking must already be signed in as the target user.
- The weak link is not the gate. It is the key. Past orders are matched on the billing email typed into a guest-checkout form, an address the store never verified belonged to anyone in particular.
- EDPB Guidelines 01/2022 endorse authenticating someone through "other existing means of communication known as to belong to the data subject, such as the e-mail address" (Example 13). A guest checkout is precisely where that knowledge is missing.
- You are the controller, not WooCommerce. Article 5(2) puts the burden on you to demonstrate the decision was made deliberately — which means a considered setting, an updated Article 30 record, and a privacy notice that matches.
Introduction
A customer emails you eighteen months after a one-off purchase: "I've made an account now — where are my old orders?" Until this month the honest answer on WooCommerce was a manual database edit or a third-party plugin. Since 4 August 2026 it is a setting. WooCommerce 11.0 lets shoppers find previous guest orders and connect them to a user account after confirming their email address, closing a gap merchants have been asking about since 2021.
It is a genuinely useful feature, and the engineering behind it is more careful than most people will notice. It also quietly hands you a new decision as data controller: under what conditions your store will hand over a stranger's purchase history. This article works through what actually shipped, what the EDPB says about verifying identity by email, and what to check before you leave the switch on.
This article is informational content, not legal advice. For organisation-specific guidance, consult a qualified legal professional.
What WooCommerce 11.0 Actually Changed
The release notes are terse. WooCommerce's own developer blog, dated 4 August 2026, says only: "WooCommerce has allowed post-checkout account creation since 9.5. In WooCommerce 11.0, customers can now find previous orders and connect them to their user account with email validation."
One sentence, two meaningfully different capabilities. Post-checkout account creation, which has existed since 9.5, turns a guest into a registered user going forward. What 11.0 adds is retrospective: orders placed before the account existed can now be pulled into it.
How the verification actually works
The mechanism is not what the phrase "email validation" usually implies. WooCommerce shipped one design and then replaced it before release. Pull request #65822 built a 6-digit one-time passcode entered in My Account. Pull request #65971 — titled "Follow up: Replace email-verification OTP with a login-gated link" and merged into trunk on 26 June 2026 against the 11.0.0 milestone — swapped it out.
What ships is described in that PR as "an authenticated GET carrying an unguessable, single-use, email-bound key", modelled on WordPress core's own email-change confirmation links. The important clause is the condition: opening the link "verifies the address directly — but only when the request is authenticated as the link's target user, so an email-client/scanner prefetch (always logged out) can never complete it or spend the key." A logged-out visitor gets the login prompt and returns to the link after signing in.
Give the WooCommerce team credit here. That design defeats the failure mode that breaks most confirmation links in the wild — corporate mail scanners and link-preview bots that fetch every URL in an inbox and burn single-use tokens before a human sees them. Two things are required, not one: control of the account and control of the inbox.
Where the setting lives
In your admin, under WooCommerce → Settings → Accounts & Privacy, the option reads: "Customer email confirmation — Allow customers to confirm their account email and link matching past guest orders to the account."
The same screen holds "Enable guest checkout", the three account-creation options, the account-erasure toggles, and the Personal Data Retention periods for inactive accounts and for pending, failed, cancelled and completed orders. That co-location is convenient, and it is also a hint: everything on that page is a controller decision, and this new one arrived among settings you probably configured years ago and have not looked at since.
Is Email Confirmation Enough to Verify Identity Under GDPR?
For a registered account holder, yes — and the EDPB says so directly. What the WooCommerce feature raises is a different question: not whether the person is who they say they are, but whether the orders being handed to them were ever theirs. Those are two separate obligations, and the GDPR treats them separately.
What the EDPB actually endorses
The relevant text is EDPB Guidelines 01/2022 on data subject rights – right of access, adopted in Version 2.0 on 28 March 2023. It is unusually practical about online accounts.
Paragraph 73 states that to let individuals reach data in their accounts, including "an account on social networks or online shops", controllers "are most likely to request the logging through the login and password of the user, which in such cases should be sufficient to authenticate a data subject." It goes further: "it is disproportionate to require a copy of an identity document in the event where the data subject making a request is already authenticated by the controller."
Paragraph 75 endorses exactly the pattern WooCommerce built — "a quick and effective security measure to identify a data subject based on the authentication it has previously carried out, e.g. via e-mail or text message containing confirmation links, security questions or confirmation codes." Paragraph 74 adds the flip side, warning that demanding ID copies "creates a risk for the security of personal data" and should generally be considered inappropriate.
So the honest verdict on WooCommerce's gate is that it sits comfortably inside guidance the EDPB has already blessed. Anyone claiming this feature is a reckless privacy hole has not read the pull request.
The gap is identification, not authentication
Paragraph 58 draws the distinction the whole feature turns on: to minimise "the risk of unauthorised disclosure of personal data, the controller must be able to find out which data refer to the data subject (identification) and confirm the identity of that person (authentication)."
WooCommerce 11.0 authenticates well. It identifies on an unverified string.
The matching key is the billing email address typed into a guest-checkout form. Nobody ever confirmed that address belonged to the person typing it — that is what makes guest checkout guest checkout. Read Example 13 of the same guidelines closely and the condition is explicit: a controller may authenticate through "other existing means of communication known as to belong to the data subject, such as the e-mail address or a phone number" (emphasis added). At guest checkout, the store never acquired that knowledge. It has an address that received an order confirmation, which is not the same claim.
Our read: the gate is sound and the key is assumed. That is a narrow risk rather than a broad one, and it is yours to size, because the person answering for a wrong disclosure is you.
Where Guest-Order Matching Goes Wrong
Four scenarios put the wrong order history behind the right login. None requires an attacker.
| Scenario | What the store sees | What actually happened |
|---|---|---|
| Gift or proxy order | One billing email, several orders | A shopper used a relative's address so the confirmation reached them |
| Mistyped address | A valid, deliverable mailbox | One character wrong at checkout; a real stranger owns it |
| Shared mailbox | A household or business address | Several people order through info@ or a family account |
| Recycled address | A long-dormant address, now active | A departed employee's work address was reassigned |
The last two are the ones worth losing sleep over, because they are ordinary rather than exceptional. Small businesses order through shared inboxes constantly. Staff leave and their addresses get handed on.
What gets disclosed is not trivial either: line items, delivery address, phone number, order value. For most stores that is mundane. For a pharmacy, an adult retailer, or anyone shipping to a customer who has since left an abusive household, a browsable archive of past deliveries is a different order of risk. Article 32(2) asks you to weigh precisely this — "the risks that are presented by processing, in particular from ... unauthorised disclosure of, or access to personal data".
There is a fair counter-argument, and it deserves stating: the order confirmation already went to that mailbox at purchase time, so linking discloses nothing the address did not receive once. That is true, and it materially shrinks the risk. It does not eliminate it. A confirmation email arriving in 2024 and being ignored is a different exposure from a permanent, searchable order archive available in 2026 — and paragraph 70 of the EDPB guidelines asks controllers to weigh "any damage that could result from improper disclosure", not merely whether a copy once existed somewhere.
This is not hypothetical in the WooCommerce ecosystem
Bulk email-matching of orders has misfired here before. A one-star review of "Guest Order Assigner", a third-party plugin with 200+ active installs that solved this problem before core did, reports: "It took all of our customers addresses and replaced them with one users info...removed all the orders from their account and added 2 random orders to each account."
A thread on the WordPress.org WooCommerce support forum titled "Users who checkout as guest, then create account, see other guest orders" describes the symptom directly: "If a user makes a purchase as a guest, then creates an account after submitting their order, previous guest checkout orders from other users appear under the 'orders' tab within their account." A WooCommerce support engineer replied that he could not reproduce it on a clean test install but, working on the merchant's live site, "I tested the process on your website and was able to replicate the issue you described."
Be precise about what that evidence does and does not show. It is a third-party plugin and a site-specific report that could not be reproduced on a clean install — not a defect in WooCommerce 11.0, and it would be unfair to present it as one. What it shows is that the failure mode is real in the wild rather than theoretical, which is the reason to test on your own store rather than assume.
The platform precedent points the same way. Shopify tightened the equivalent pattern on 21 March 2024, adding login requirements to its Order Status Page "to enhance the security of merchant and customer information". Shopify framed that as general security rather than a GDPR obligation, so do not read it as a regulatory ruling — but two major platforms independently concluding that lightweight order lookup needs an authentication step is a signal worth noting. The pressure does not run only one way: WooCommerce 11.1 moves in the opposite direction with an EU withdrawal form at /my-account/withdraw-order/ that its release notes say needs "no auth required", which raises its own set of GDPR questions about unverified requests.
What to Do Before You Leave the Setting On
- Decide the toggle on purpose, and write down why. Leaving a default in place is a decision under Article 5(2), which makes you "responsible for, and be able to demonstrate compliance with" the principles. A one-paragraph note in your privacy decisions log is enough; silence is not.
- Match the setting to what you sell. For general retail, leave it on — the customer-service benefit is real and the residual risk is small. For pharmacy, adult, medical or otherwise sensitive goods, our recommendation is to switch it off and handle these requests through your normal subject-access route, where a human sizes the risk. The trade-off is honest: you take on manual work in exchange for a person checking before a purchase history is disclosed.
- Add the disclosure route to your Article 30 record. This is a new way personal data leaves your store, and it belongs in your record of processing activities alongside the processing it enables.
- Check the retention interaction. Linking a guest order to an account can extend how long that data stays identifiable, which Article 5(1)(e) limits to "no longer than is necessary". Review the Personal Data Retention periods on the same settings screen so a linked order does not quietly outlive the schedule you set for it.
- Update the privacy notice. If customers can now claim historical orders, say so, and say what verification you require.
- Test it on your own store. Place two guest orders with the same address, register, link them, and look at what the account actually exposes. Then confirm your erasure tooling still reaches those orders once linked.
- Route the edge cases to a human. When a customer disputes an order in their history, treat it as a potential wrong-disclosure incident, not a support ticket about a UI bug.
Common Mistakes
Treating it as a WooCommerce problem. The single worst framing. WooCommerce supplies the mechanism; you decide whether it runs and on what data. Under Article 5(2) the accountability sits with the store, and "the platform shipped it that way" has never been a defence.
Demanding ID to fix it. The instinct after reading a piece like this is to add an identity check. Resist it for authenticated users: paragraph 73 calls requiring an ID copy disproportionate where the data subject is already authenticated, and paragraph 74 warns that collecting ID copies creates security risk of its own. Over-verification is a compliance failure in the other direction — the same tension we cover in our guide to automating subject access requests.
Assuming an upgrade left your settings alone. Check the state of the toggle rather than assuming, particularly across a major version. Five minutes on the Accounts & Privacy screen is cheaper than finding out from a customer.
Forgetting this sits inside a bigger question. Whether shoppers must register at all is itself under regulatory scrutiny — the EDPB's Recommendations 2/2025 make guest checkout the GDPR default. A feature that rewards account creation with restored order history is a nudge toward registration, and it is worth checking that nudge is not doing work your lawful basis cannot support.
Skipping the notice update. New disclosure route, unchanged privacy notice, is a transparency gap that costs nothing to close and is awkward to explain later.
How PrivacyForge Helps
The hard part of a change like this is not the setting. It is noticing that a platform update created a new way personal data leaves your business, and having somewhere to record what you decided.
PrivacyForge's data mapping keeps your Article 30 record as a live document rather than a spreadsheet that was accurate in March, so a new disclosure route gets captured when it appears. The DSAR workflow gives order-history requests a tracked path with statutory deadlines and a verification step, which is where the disputed cases from step 7 should land. Retention policies let you hold order data to the schedule you actually set, including once a guest order has been linked to an account. And compliance scoring surfaces the gap between what your privacy notice says and what your store now does.
None of that decides the toggle for you. It means that when someone asks why it is set the way it is, the answer exists in writing.
Frequently Asked Questions
Does WooCommerce 11.0 let anyone with my email address see my order history?
No. The confirmation link only works when the browser opening it is already signed in as the account the link was issued to, so inbox access alone is not enough. Pull request #65971 built it that way deliberately, so that logged-out mail scanners and link-preview bots cannot spend the single-use key.
How does WooCommerce decide which past orders belong to an account?
It matches on the billing email address recorded on the guest order. That is the feature's real limitation: the address was typed into a checkout form and never verified as belonging to the person who typed it, so gift orders, mistyped addresses and shared mailboxes can all associate an order with the wrong account holder.
Is email verification enough to satisfy GDPR identity checks?
For someone already logged into an account, yes. EDPB Guidelines 01/2022 state that login credentials "should be sufficient to authenticate a data subject" for account data, and paragraph 74 warns that demanding an identity document creates security risk and is generally inappropriate. Article 12(6) permits extra information only where you have reasonable doubts.
Should I switch the guest order linking setting off?
For general retail, no — the customer-service benefit outweighs a small residual risk. Switch it off if you sell pharmacy, medical, adult or otherwise sensitive goods, where a browsable delivery history carries real-world consequences, and route those requests through your normal subject access process instead.
What do I need to document if I leave it enabled?
Record the decision and its reasoning, add the disclosure route to your Article 30 record of processing activities, check that linking does not extend retention beyond your schedule, and update your privacy notice to describe how customers can claim past orders. Article 5(2) requires you to demonstrate compliance, not merely achieve it.
Conclusion
WooCommerce 11.0 shipped a well-built authentication gate on top of an identifier nobody verified. That is not a scandal, and the engineering deserves more credit than the one-sentence release note gave it. It is a decision that has moved onto your desk without an announcement.
Open Accounts & Privacy, look at what "Customer email confirmation" is set to, and decide it rather than inherit it. For most stores the answer is to leave it on and write down why. For stores where a delivery history is sensitive, the answer is to turn it off and let a person handle those requests. Either way, put the reasoning somewhere you can find it — because the one question you will eventually be asked is not whether the setting was on, but whether you meant it to be.
Sources
- WooCommerce 11.0 Release Notes
- WooCommerce documentation: Accounts and Privacy settings
- Pull request #65971: Replace email-verification OTP with a login-gated link
- WooCommerce issue #29138: link past guest orders to a new account
- EDPB Guidelines 01/2022 on data subject rights – Right of access (Version 2.0)
- GDPR Article 5 – Principles relating to processing of personal data
- GDPR Article 12 – Transparent information, communication and modalities
- GDPR Article 32 – Security of processing
- GDPR Recital 64 – Identity verification
- Shopify: New login requirements for the Order Status Page
- WooCommerce support: Users who checkout as guest, then create account, see other guest orders