PasskeyBridge —

Engineering · 2026-02-28

Building a Zero-PII Audit Trail

By PasskeyBridge

Building a Zero-PII Audit Trail

The constraint

PasskeyBridge processes identity threat signals, verifiable credential presentations and passkey attestations, all of which contain personally identifiable information. We need to log everything for audit compliance, but we refuse to store PII.

This constraint spans all three pillars of our platform. For a full overview, see Introducing PasskeyBridge.

Pillar I: signal scrubbing

When a carrier signal arrives at our ingest endpoint, the first operation is PII extraction and hashing. Before the payload touches any persistent storage:

  1. Phone numbers are extracted and replaced with keyed HMAC-SHA-256 digests, computed under a server-held pepper after E.164 normalization. Keying is the point: a plain SHA-256 of a phone number is reversible by enumerating the small phone-number keyspace, so an unkeyed digest is not by itself a privacy control. The pepper removes that capability.
  2. Other low-entropy identifiers (email, IP, subject) are normalized and keyed-hashed the same way.
  3. The original payload is never written to disk.

This same architecture is what makes Reg S-ID compliance possible without storing phone numbers.

Pillar II: credential proof isolation

Verifiable credential verification happens entirely in-memory. When a user presents a credential via OpenID4VP:

  1. The presentation is verified against the trusted issuer's public key.
  2. Only the verification result (pass or fail), credential type and issuer identifier are logged.
  3. The actual credential claims (name, DOB, address) are never persisted.
  4. The VC provider's API key is stored with AES-256 encryption at rest.

Pillar III: passkey attestation privacy

WebAuthn passkey registration stores the minimum required data:

  1. The credential public key, required for authentication.
  2. The AAGUID, the authenticator model identifier, which is not user-identifying.
  3. A monotonic counter for replay detection.
  4. No biometric data ever leaves the user's device, that's the WebAuthn guarantee.

The append-only event log

Our shield_audit_log table is append-only by design:

  • No UPDATE or DELETE operations are permitted via RLS policies.
  • Every row captures actor context, resource diffs and action results.
  • Actor IP addresses are stored as inet types and excluded from client-side queries via column-level security.
  • Timestamps are server-generated and immutable.

This gives us a tamper-evident audit trail that satisfies SOC 2 Type II and ISO 27001 requirements without storing a single piece of PII across any of our three pillars. For the compliance angle, read Reg S-ID Compliance Without Storing a Single Phone Number.

Sources

  • W3C WebAuthn Level 3 specification (Authenticator Data and AAGUID semantics).
  • OpenID for Verifiable Presentations (OpenID4VP) draft specification.
  • AICPA Trust Services Criteria (TSP Section 100), Privacy category.
  • NIST FIPS 180-4, SHA-256 hashing.

Start free · Test the API