Compliance & Privacy · 2026-03-18

The CISO's Guide to Zero-PII Identity Verification in a Post-GDPR World

By J. W. Bouckaert

The regulatory pressure that changed the question

The question used to be: "How do we protect the PII we collect?" That question is now obsolete.

GDPR Article 25—Data Protection by Design and by Default—imposes an obligation that most identity vendors have addressed superficially. They encrypt PII at rest. They restrict access with role-based controls. They log who accessed what and when. They call this "data protection by design."

It is not. It is data protection after collection. The data still exists. It still constitutes a liability. It still requires a Data Protection Impact Assessment (DPIA) under GDPR Article 35. It still triggers breach notification obligations under Article 33 (72-hour notification to supervisory authorities) and Article 34 (notification to affected data subjects). It still falls within the scope of CCPA Section 1798.100, which grants consumers the right to know what personal information is collected, and Section 1798.105, which grants the right to request deletion.

The only architecture that genuinely satisfies "data protection by design" is one that never collects the data in the first place. Not one that collects it and then protects it. One that performs the same identity verification functions—authentication, threat detection, audit trail maintenance, regulatory compliance—without ever holding personally identifiable information.

This is the operational architecture PasskeyBridge has deployed in production.

PII in an identity system

Before discussing elimination, it is necessary to define what constitutes PII within the specific context of an identity verification platform. The scope is broader than most CISOs assume.

Direct identifiers. Phone numbers, email addresses, government-issued ID numbers, biometric templates, device serial numbers. These are unambiguously PII under GDPR Recital 26 and CCPA Section 1798.140(v). Any system that stores these in plaintext or reversibly encrypted form holds PII.

Indirect identifiers. IP addresses (confirmed as personal data by the CJEU in Breyer v. Bundesrepublik Deutschland, Case C-582/14, 2016), user agent strings with sufficient entropy to enable fingerprinting, location coordinates, and behavioral patterns that could identify an individual when combined with other data. GDPR's definition of personal data explicitly includes information that can be used to identify a natural person "indirectly" (Article 4(1)).

Credential metadata. Passkey credential IDs, WebAuthn attestation objects, verifiable credential subject fields, carrier-signal identifiers. Depending on jurisdiction and context, these may constitute personal data if they can be linked back to an identifiable individual.

The regulatory test that matters is whether the data could identify someone, directly or indirectly, by any party with access to reasonably available means, whether or not it currently does. This is the "means reasonably likely to be used" test established in GDPR Recital 26. Under this test, most identity platforms store far more PII than their privacy policies acknowledge.

The keyed-hash architecture

PasskeyBridge's zero-PII architecture rests on a single cryptographic primitive applied to low-entropy personal identifiers: every such identifier that enters the system is immediately hashed with keyed HMAC-SHA-256, under a server-held secret (a "pepper"), before any storage, processing, or logging occurs.

The distinction between a keyed hash and a plain hash is the entire point, and it is worth being precise about, because the naive version of this claim is a well-known trap:

Why a plain SHA-256 is not sufficient for these identifiers. Cryptographic pre-image resistance (there is no known attack that reverses SHA-256 in fewer than ~2^256 operations) protects a hash only when the input is unpredictable. Personal identifiers are not unpredictable: the global E.164 phone-number space is on the order of a few billion values, and email addresses are drawn from breach corpora and dictionaries. An attacker who obtains a column of unkeyed sha256(phone) digests does not attempt a pre-image attack at all—they simply hash every phone number once, build a lookup table, and read every value back. The 2^256 figure is irrelevant when the input space is 2^33. For this class of data, the statement "we SHA-256 our phone numbers, therefore they are irreversible" is false.

What keying changes. HMAC-SHA-256 mixes a high-entropy server-held secret into the digest. Because that pepper is not in the database and never leaves the server, an attacker holding a leaked digest column cannot precompute anything: the table they would need to build depends on a secret they do not have. A leaked keyed digest therefore discloses only equality—the same identifier produces the same digest—and nothing about the identifier itself. Reversal is restored to infeasible precisely because the effective input space is now (identifier × secret), not (identifier).

Collision resistance. It remains computationally infeasible to find two different inputs that produce the same digest, so each identifier maps to a unique value with overwhelming probability, preserving the platform's ability to correlate signals without ambiguity.

Determinism (and a deliberate design choice). The same input always produces the same digest under a given pepper. The pepper is a single server-held secret rather than a per-tenant salt, which means the same identifier hashes identically across tenants. That is intentional: it is exactly what the k-anonymous cross-tenant threat-sharing feature relies on to recognize an indicator independently reported by multiple tenants. It also means pepper custody and rotation are first-order security controls, treated as such in the platform's key-management evidence.

Two caveats. First, identifiers supplied to the API already pre-hashed by an integrator (for example a client-computed phone_hash) carry only the resistance of however they were computed—the platform cannot key a value it never receives in the clear, so a client-supplied plain SHA-256 remains enumerable. Second, keyed digests are version-stamped; any legacy unkeyed rows are treated as enumerable and age out rather than being re-hashed in place, because the platform does not retain the plaintext needed to upgrade them.

Fixed output length. Every digest is exactly 256 bits (64 hexadecimal characters), regardless of input length, so an observer examining stored data cannot distinguish the type of identifier that was hashed.

Hashed identifiers

Every identifier flowing through the PasskeyBridge platform is hashed at the point of ingestion:

The plaintext value never reaches the database. It never reaches the application logs. It never reaches the audit trail. The hashing occurs in the edge function that receives the ingest request, before the data is passed to any downstream service.

The GDPR position on hashing

The regulatory position on whether hashed data constitutes personal data turns on the details of the hashing, but it is increasingly well-established.

GDPR Recital 26 states that data is personal data if the controller or "another person" could use "reasonably likely" means to re-identify the individual. This is exactly why keying matters: an unkeyed SHA-256 of a low-entropy identifier does meet the "reasonably likely" threshold, because anyone can build a lookup table by hashing the small input space—so it remains personal data. A keyed HMAC-SHA-256 digest under a secret pepper defeats that precompute and materially raises the re-identification bar. The European Data Protection Board (EDPB) distinguishes between pseudonymization (reversible by someone holding additional information—still personal data under GDPR Article 4(5)) and anonymization (irreversible by anyone, outside GDPR scope). Because PasskeyBridge holds the pepper, the conservative classification is that these keyed digests are strongly pseudonymized and continue to be treated as personal data—not that they are fully anonymized.

The critical distinction: pseudonymization retains a link (a key, a lookup table, a decryption capability) that enables re-identification. PasskeyBridge retains such a link: the server-held pepper. There is no plaintext lookup table and no stored reversible ciphertext of the identifier, but anyone who holds the pepper can re-hash a candidate identifier and test equality. That is why these digests stay classified as pseudonymized personal data rather than anonymized data, and remain in GDPR scope.

This is the conservative classification. The practical implication is that data-subject rights, breach-notification analysis, and transfer rules still apply to the keyed digests—even though a database dump without the pepper is not enumerable. PasskeyBridge treats hashed identifiers as personal data within GDPR scope.

Threat detection without knowing who is being threatened

The most common objection from CISOs encountering zero-PII architecture for the first time: "How do you detect threats against a specific user if you do not know who the user is?"

The answer is that threat detection operates on patterns, not identities. A SIM-swap attack has a specific signal pattern—a carrier API returns a porting event timestamp within a configurable window of the current authentication attempt. Detecting this pattern requires comparing two values: the carrier signal hash associated with the current request and the carrier signal hash associated with the credential being used. If the hashes diverge, the signal has changed. If the signal changed within the threat window, the playbook fires.

At no point in this detection chain does the system need to know the user's phone number, name, email address, or any other identifier. It needs to know that this hash no longer matches that hash. The threat is detected against a hash-identified entity, and the response—credential revocation, session termination, step-up challenge—is executed against the same hash-identified entity.

Carrier signal ingest

When a carrier event arrives (SIM-swap alert, number port notification, fraud flag), the PasskeyBridge signal ingest pipeline processes it as follows:

1. Hash the phone number at the edge function boundary. The plaintext phone number provided by the carrier API is keyed-hashed with HMAC-SHA-256 under a server-held pepper immediately. The keyed digest is stored; the plaintext is discarded from memory.
2. Correlate the hash against existing records. The system queries shield_events and shield_cross_references using the phone_hash to find matching identity bindings.
3. Evaluate playbook triggers. If the event type matches an active playbook's trigger (for example, a playbook set to fire on SIM-swap events), that playbook fires.
4. Execute response actions. Credential revocation, session termination, webhook notification, alert escalation—all executed against hash-identified entities.
5. Log the event. The audit trail records the event type, the phone_hash, the playbook that fired, the actions executed, and the outcome. Zero PII.

The entire detection-to-response cycle completes inside the request that carried the signal. The carrier's plaintext phone number exists in memory for the duration of the keyed-hash computation—microseconds—and is then garbage collected. It is never written to disk, never logged, never transmitted to any downstream service.

Behavioral threat detection

For agentic identity delegation, behavioral anomaly detection operates on the same hash-anchored model. Agent activity is logged with the agent's agent_identifier_hash in place of its plaintext identifier. Behavioral baselines—request frequency, scope usage patterns, temporal distribution—are computed against the hash. Anomaly detection compares current behavior against the hash-anchored baseline. Scope narrowing and revocation are executed against the hash.

The agent's actual identity—its provider, its model version, its deployment context—is never stored. The system knows that hash X exhibits behavioral patterns consistent with its own baseline. When those patterns diverge, trust is reduced. As trust crosses each threshold, scopes are narrowed, first to read-only and then to verify-only. When trust falls below the delegate's revocation floor, the delegate is revoked.

Audit trails that satisfy regulators without storing PII

SOC 2 Type 2 requires demonstrable evidence that access controls are operating effectively over a sustained audit period (commonly between 3 and 12 months). ISO 27001 requires an information security management system (ISMS) with documented controls and evidence of their operation. Both frameworks assume that audit logs contain sufficient detail to reconstruct security events for forensic analysis.

The traditional approach stores PII in audit logs: "User john.doe@company.com accessed resource X at timestamp T from IP address Y." This creates a secondary PII repository that requires its own access controls, retention policies, breach notification procedures, and DSAR (Data Subject Access Request) response capabilities.

PasskeyBridge's audit trail records the same forensic detail without any PII:

{
  "action": "credential_revoked",
  "actor_type": "system",
  "actor_id": "playbook-sim-swap-response",
  "resource_type": "passkey_credential",
  "resource_id": "cred_7f8a...",
  "tenant_id": "tenant_abc...",
  "result": "success",
  "metadata": {
    "trigger": "sim_swap_detected",
    "phone_hash": "a1b2c3d4...",
    "signal_source": "vonage"
  }
}

This log entry is forensically complete. An auditor can reconstruct the chain of events: a SIM-swap signal arrived, the system identified the affected credential via phone_hash correlation, and the playbook executed credential revocation. The auditor can verify that the control operated correctly—that the detection triggered the prescribed response.

What the auditor cannot do is identify the affected individual from the log. The phone_hash is a 64-character hexadecimal string. PasskeyBridge does not keep the phone number after the keyed hash is computed, and without the server-held pepper nobody can test the digest against candidate numbers. Because PasskeyBridge holds that pepper, the digest is still pseudonymized personal data, so the log is handled under the same rules as other personal data while holding no plaintext identifier.

Hash-chained integrity

A database trigger links each new audit row into a hash chain, so a row that is altered or removed later breaks the chain and the change can be detected. Checkpoints of the chain are signed with ML-DSA-65 (NIST FIPS 204), a post-quantum signature scheme, so the record of integrity stays verifiable after large quantum computers exist.

The audit trail holds no plaintext identifiers and is tamper-evident. A regulator examining the log can check the hash chain and the checkpoint signatures without access to any plaintext personal data.

Cross-border data transfers

GDPR Chapter V (Articles 44-49) imposes significant restrictions on transferring personal data to countries outside the European Economic Area (EEA) that lack an adequate level of data protection. The Schrems II decision (Case C-311/18, 2020) invalidated the Privacy Shield, then the main mechanism for EU-US data transfers, and made Standard Contractual Clauses (SCCs) depend on transfer impact assessments and, where needed, supplementary measures. In July 2023 the European Commission adopted an adequacy decision for the EU-U.S. Data Privacy Framework, which covers transfers to US organizations certified under it. Transfers to other US recipients still rely on SCCs.

For identity platforms that store PII, this creates a genuine architectural constraint. Carrier signal data originating from a European mobile network operator, processed through a US-hosted identity platform, constitutes a cross-border transfer of personal data. The platform must implement SCCs, conduct transfer impact assessments, and potentially implement supplementary technical measures.

For PasskeyBridge, the transfer content is a keyed digest rather than a phone number or email address. Because the controller holds the pepper, those digests remain pseudonymized personal data and GDPR Chapter V still applies. What the architecture does eliminate is a plaintext-identifier store sitting in a second jurisdiction. SCCs, transfer impact assessments, and supplementary measures are evaluated against keyed digests. There is no database of phone numbers to assess.

That follows directly from the architectural decision to never store PII; no legal workaround is involved. The compliance benefit is a side effect of the security architecture.

The verifiable credential layer: Zero-PII legal identity

PasskeyBridge's native W3C Verifiable Credential engine extends the zero-PII architecture to legal identity verification. When a verifiable credential is issued (a KYC attestation, an age verification, an employment credential) it names its subject by the DID the issuer supplies, and PasskeyBridge stores only a keyed HMAC-SHA-256 digest of that DID under a server-held pepper. Issuers should use a subject DID that carries no personal data, such as one derived from a random account identifier and never from an email address or phone number.

The credential asserts: "The subject has been verified to meet condition Y by issuer Z at time T." The relying party can verify the credential's authenticity (via the issuer's DID and the credential's digital signature), verify its revocation status (via StatusList2021), and confirm that the presenter holds the credential (via a key-binding proof when the credential is holder-bound). PasskeyBridge's records hold only keyed digests of the subject, never the subject identifier itself.

This model satisfies the regulatory requirement for identity verification—the platform can prove that verification occurred, that it was performed by a legitimate issuer, and that the verified entity matches the presenting entity—without any party in the chain storing PII.

Implementation guidance for CISOs

Step 1: Audit your current PII surface

Before migrating to a zero-PII architecture, quantify your current exposure. Map every data store, log repository, analytics pipeline, and third-party integration that contains or processes PII. For each, document:

• What PII is stored (direct identifiers, indirect identifiers, credential metadata)
• Why it is stored (functional requirement, regulatory obligation, historical practice)
• What retention period applies (regulatory mandate, contractual obligation, default)
• What breach notification obligations are triggered if this data is compromised

Many stores of PII serve functions that a keyed one-way hash (HMAC) could perform just as well, such as matching, deduplication and correlation. The plaintext often persists because no one asked whether it was necessary.

Step 2: Identify hash-compatible functions

For each PII-bearing function identified in Step 1, evaluate whether the function can operate on hashes instead of plaintext:

• Identity matching: Yes, with a keyed hash. HMAC-SHA-256 under a secret key held only by the server (a pepper) produces identical outputs for identical inputs, so digest-to-digest comparison matches identities without storing plaintext. An unkeyed hash is not sufficient for low-entropy identifiers such as email addresses or phone numbers, because an attacker can recover them by hashing every candidate value.
• Threat detection: Yes. Anomaly detection operates on patterns alone. A divergence between two hashes signals the same threat as a divergence between two plaintext values.
• Audit logging: Yes. Hash-identified entities provide the same forensic reconstruction capability as plaintext-identified entities, without the PII liability.
• Analytics and reporting: Yes, with constraints. Aggregate metrics (event counts, response times, threat distributions) operate on hash-grouped data. Per-user analytics require the caller to maintain their own hash-to-identity mapping.
• Regulatory reporting: Context-dependent. Some regulations require the ability to identify specific individuals in response to law enforcement requests. In these cases, the caller (your organization) maintains the hash-to-identity mapping, and it stays with you.

Step 3: Evaluate vendor architecture

When evaluating identity vendors against zero-PII criteria, ask these specific questions:

1. Where does hashing occur? If the vendor hashes data after it arrives at their API, the plaintext traversed their infrastructure. If hashing occurs client-side or at the edge, the plaintext never reached the vendor.
2. Is there a lookup table? If the vendor maintains any mapping between hashes and plaintext values, the data is pseudonymized and remains within GDPR scope.
3. What appears in logs? Request vendor audit log samples. If any log entry contains a plaintext identifier, phone number, email address, or IP address, the vendor stores PII regardless of their marketing claims.
4. What do subprocessors receive? If the vendor passes plaintext identifiers to carrier APIs, analytics providers, or monitoring services, PII is dispersed across the vendor's subprocessor chain.
5. What survives a breach? If the vendor's database is exfiltrated, what does the attacker obtain? Hashes with no lookup table, or plaintext PII?

Step 4: Plan the migration

Zero-PII migration is architectural. You cannot partially hash an identity system. Either the phone number is hashed before storage, or it is not. Either the audit trail is PII-free, or it contains PII.

The migration path for most organizations:

1. Deploy hash-at-ingestion for new data flows first. All new identity events are hashed at the boundary. Existing data remains in its current state.
2. Backfill existing hashes. For each existing PII record, compute the keyed HMAC-SHA-256 digest under a server-held pepper and store it alongside the plaintext. Verify hash-to-hash matching produces identical results to plaintext matching.
3. Cut over detection and response. Switch threat detection, playbook execution, and audit logging to use hash-based correlation exclusively.
4. Purge plaintext. Once all functions operate on hashes, delete the plaintext PII. Your GDPR exposure structurally changes at this step.
5. Update DPIAs and privacy documentation. Reflect the architectural change in your Data Protection Impact Assessments, privacy policies, and data processing agreements.

Nothing to steal

The zero-PII architecture provides a security benefit that transcends compliance. In a traditional identity platform, a breach exposes millions of records containing phone numbers, email addresses, biometric templates, and credential metadata. The remediation cost—breach notification, credit monitoring, regulatory fines, litigation—is proportional to the volume and sensitivity of exposed PII.

In a zero-PII architecture, a breach of the database exposes keyed HMAC-SHA-256 digests. Without the server-held pepper (which lives outside the database), those strings are not enumerable. The pepper is still additional information the controller holds, so the dump is treated as a personal-data incident and analysed under the existing breach process—the blast radius is hashes alone, and limiting it to that is what the architecture is for.

The practical advantage is a smaller breach: a stolen database holds digests that cannot be enumerated without the pepper, so there are no plaintext phone numbers or email addresses to notify about, monitor or litigate over.

Start free · Test the API