PasskeyBridge —

Compliance & Privacy · 2026-04-12

Data Residency for Identity Signals: Navigating Schrems III and Cross-Border Carrier Lookups

By J. W. Bouckaert

Data Residency for Identity Signals: Navigating Schrems III and Cross-Border Carrier Lookups

Carrier lookups are data transfers

An identity check that asks a carrier or a carrier data provider about a phone number sends that number to the provider. Under the GDPR a phone number is personal data. If the provider processes it outside the European Economic Area, the lookup is a transfer of personal data under Chapter V and needs a legal basis, whatever comes back in the response.

Many identity teams do not think of a lookup this way, because the request is small and the answer is a few fields about line type, porting or SIM changes. This article covers the legal history behind EU-US transfers, the current challenge to the EU-US Data Privacy Framework that people call "Schrems III", what technical measures can and cannot do for a lookup, and how PasskeyBridge handles phone numbers.

From Safe Harbor to the Data Privacy Framework

Schrems I (2015)

On 6 October 2015 the Court of Justice of the European Union (CJEU) invalidated the Safe Harbor framework in Schrems (C-362/14), finding that US law allowed public authorities general access to the content of communications.

Schrems II (2020)

On 16 July 2020, in Data Protection Commissioner v Facebook Ireland and Schrems (C-311/18), the CJEU invalidated the EU-US Privacy Shield. It held that Standard Contractual Clauses (SCCs) remain valid, but that the exporter must check whether the law of the destination country lets the importer meet them, and add supplementary measures where it does not.

The Data Privacy Framework (2023)

After the US issued Executive Order 14086 in October 2022, which added limits on signals intelligence and created a Data Protection Review Court, the European Commission adopted an adequacy decision for the EU-US Data Privacy Framework (DPF) on 10 July 2023. US companies that certify under the DPF can receive EU personal data without SCCs.

The challenge called "Schrems III"

"Schrems III" is not a ruling. The term refers to an expected CJEU challenge to the DPF. The first direct challenge, Latombe v Commission (T-553/23), was dismissed by the EU General Court on 3 September 2025. Mr Latombe appealed to the Court of Justice on 31 October 2025 (C-703/25 P), and the appeal is pending.

US surveillance law is also changing. The Reforming Intelligence and Securing America Act of April 2024 extended Section 702 of the Foreign Intelligence Surveillance Act to April 2026. After a short extension, the statutory authority lapsed on 12 June 2026, but certifications approved by the Foreign Intelligence Surveillance Court in March 2026 allow collection under them to continue until March 2027. Any CJEU review of the DPF will look at the US law in force at the time.

Parties that receive the number

A lookup can pass through several parties:

  • The identity verification provider that receives the request.
  • A carrier data provider such as Twilio, Vonage or Sinch, which may answer from its own data or ask the carrier.
  • The carrier or a carrier API aggregator.

Each party that processes the number outside the EEA, or that is subject to the law of a non-EEA country, is part of the transfer analysis. The exporter needs to know who they are, where they process data and which transfer mechanism covers each one.

Limits of technical measures

The European Data Protection Board's Recommendations 01/2020 on supplementary measures give use cases in which technical measures can make a transfer acceptable, and cases in which they cannot.

  • Use case 2, pseudonymised data. A transfer can be acceptable if the data is pseudonymised so that it cannot be attributed to a person without additional information that stays with the exporter in the EEA.
  • Use case 5, split or multi-party processing. Data can be split between independent processors so that no single party can identify a person.
  • Use cases 6 and 7, access in the clear. When the importer needs the data in the clear to provide the service, the EDPB found no technical measure that prevents access by public authorities.

A carrier lookup is a use case 6 situation: the provider needs the actual number to look it up. Hashing the number before sending it does not work, because the provider cannot look up a hash. For the lookup itself, the exporter relies on the transfer mechanism (the DPF or SCCs) and a transfer impact assessment rather than on pseudonymisation.

Pseudonymisation still matters for everything stored after the lookup. Under GDPR Recital 26, pseudonymised data remains personal data for anyone who can re-identify it. In EDPS v SRB (C-413/23 P, 4 September 2025), the CJEU held that pseudonymised data may not be personal data for a recipient that has no reasonable means of re-identifying the people concerned.

Phone numbers at PasskeyBridge

PasskeyBridge's database and edge functions run on Supabase in the US (us-east-1), so tenant data is processed in the US. Its Security page lists the subprocessors and their regions. For phone numbers:

  • Hosted lookups. When a tenant uses PasskeyBridge's own Twilio or Vonage accounts, PasskeyBridge sends the number to that provider for the lookup. The number is held in memory for that one call and is stored only as a keyed HMAC-SHA-256 digest under a server-held pepper.
  • Tenant accounts. A tenant can register its own Vonage application or Sinch project. Lookups then run under the tenant's account, and the tenant's agreement with that provider governs the provider's processing.
  • Bring your own lookup. A tenant can query its own provider and send PasskeyBridge only the result and a digest it computed. No phone number reaches PasskeyBridge in that case.
  • Storage. Identifiers are stored as keyed digests. Because PasskeyBridge holds the pepper, these digests are pseudonymised personal data for PasskeyBridge, and they are protected under the same Data Processing Addendum.

PasskeyBridge acts as a processor under the GDPR and PIPEDA. Its Data Processing Addendum, incorporated into the Terms of Service, covers transfer mechanisms and subprocessors.

A checklist for identity teams

  1. List every party that receives a phone number during a check, including providers your provider uses.
  2. Record where each party processes data and which transfer mechanism covers it.
  3. Prefer providers that can process EU numbers in the EEA, or use a lookup path under your own carrier account.
  4. Store only keyed digests after the lookup, and keep the key away from the stored data.
  5. Write a transfer impact assessment for each non-EEA transfer, and review it when the DPF appeal is decided or US surveillance law changes.
  6. Note other regimes that apply to you. India's Digital Personal Data Protection Act 2023, for example, allows transfers except to countries the government restricts by notification, and China's Personal Information Protection Law generally requires a security assessment, a standard contract or certification before personal information leaves the country.

---

See the zero-PII architecture and the subprocessor list on the Security page.

Start free · Test the API