Security · 2026-03-30

The Missing Link in Identity Assurance: Cross-Referencing SIM Signals with Verifiable Credentials

By J. W. Bouckaert

The gap between "who passed KYC" and "who is holding the phone"

Identity verification platforms solve two problems independently. The first is legal identity: can this person prove they are who they claim to be? This is the domain of Know Your Customer (KYC) processes, document verification, and—increasingly—W3C Verifiable Credentials (VCs) that encode the result of that verification as a portable, cryptographically signed assertion.

The second problem is device possession: is this person currently in control of the phone number or device associated with their account? This is the domain of carrier-signal attestation—SIM swap detection, number portability checks, and real-time GSMA Open Gateway signals that confirm the SIM in the device has not been recently reassigned.

Both signals are valuable. Neither is sufficient alone.

A Verifiable Credential proves that a person passed KYC at some point in the past. It does not prove they still control the device registered to their account. A carrier signal confirms the SIM is stable right now. It does not prove the person holding the device is the person who passed KYC. The gap between these two signals is where account takeover, synthetic identity fraud, and SIM-swap-enabled credential theft occur.

Cross-referencing closes this gap. It creates a deterministic binding between the carrier-signal attestation and the VC subject—without storing or transmitting any personally identifiable information.

Deterministic cross-references

A deterministic cross-reference is a cryptographic binding that maps a carrier-signal identifier (the SIM attestation hash) to a Verifiable Credential subject identifier (the VC subject hash), producing a composite entity profile hash that represents the verified pairing.

The operation is conceptually simple:

1. The carrier signal identifier (e.g., a SIM attestation event ID) is SHA-256 hashed
2. The VC subject identifier (e.g., a credentialSubject.id from a W3C VC) is SHA-256 hashed
3. Both hashes are combined with the carrier name and credential type into a composite string
4. The composite string is SHA-256 hashed to produce the entity profile hash

The resulting entity profile hash is a deterministic, non-reversible fingerprint of the binding. Given the same SIM signal and VC subject, the same entity profile hash will always be produced. Given the hash alone, neither the carrier signal identifier nor the VC subject identifier can be recovered.

This is the zero-PII architecture applied to cross-referencing: the system proves the binding exists without knowing—or storing—who the person is.

Temporal proximity

Not all cross-references are equal. A SIM attestation performed within the same session as a VC verification carries stronger assurance than one performed 24 hours later. The time gap between the two events determines the match strength.

An exact match (≤ 5 minutes) indicates that the SIM attestation and VC verification occurred within the same user session. This is the strongest possible binding: the person who proved their legal identity via KYC is demonstrably the same person whose SIM was attested in the same authentication ceremony.

A fuzzy match (> 24 hours) is still useful for establishing an initial binding, but it should trigger a re-attestation flow within a reasonable period. The cross-reference remains valid, but downstream systems should weight it accordingly when making authorization decisions.

The architecture: From signal to binding

The cross-reference lifecycle has five operations: establish, verify, bind passkey, revoke, and list. Each operation is designed to maintain zero-PII compliance while providing the cryptographic guarantees that enterprise identity systems require.

Establishing a cross-reference

The establish operation requires four inputs:

1. SIM signal identifier: The raw carrier attestation identifier (hashed on ingestion)
2. VC subject identifier: The credential subject identifier from the Verifiable Credential (hashed on ingestion)
3. Carrier metadata: The carrier name and signal type (e.g., T-Mobile, sim_swap_check)
4. Credential metadata: The credential type and issuer (e.g., IdentityCredential, did:web:issuer.example.com)

On ingestion, both the SIM signal identifier and VC subject identifier are immediately SHA-256 hashed. The raw identifiers never reach persistent storage. The privacy here is architectural rather than application-layer: the hashing occurs before the database insert, and the raw values exist only in ephemeral request memory.

The system then computes the entity profile hash from the composite of both hashes plus the carrier and credential type metadata. This composite hash becomes the lookup key for all subsequent operations.

Duplicate detection

Before inserting a new cross-reference, the system checks for an existing active binding with the same SIM hash and VC hash within the same tenant. If a match exists, the establish operation returns a 409 Conflict with the existing cross-reference ID. This prevents duplicate bindings and ensures each SIM-to-VC pairing is unique within a tenant's namespace.

Hybrid post-quantum signatures

For tenants with post-quantum cryptography enabled, the cross-reference is signed with a hybrid signature that combines a classical HMAC-SHA-256 layer with a NIST FIPS 204 ML-DSA-65 (Dilithium) signature. The signature payload includes the entity profile hash, both constituent hashes, and the match score.

This dual-signature approach provides forward security: if either the classical or post-quantum algorithm is compromised in the future, the other signature remains valid. The signature bundle is stored as a JSON structure containing both signatures, the key fingerprint, and a quantum-seeded nonce.

Verification: Proving the binding without revealing the identity

The verify operation accepts either an entity profile hash (for systems that already have it) or the raw SIM and VC identifiers (which are hashed server-side before lookup). The operation returns:

• Whether a valid, active cross-reference exists
• The match score and method
• The carrier and credential type metadata
• Whether a passkey has been bound to the cross-reference
• The PQC verification status (if hybrid signatures are present)

The verify operation never returns the SIM signal hash or VC subject hash. The caller learns that a binding exists and how strong it is, but cannot extract the constituent identifiers from the response. This is a deliberate privacy boundary: downstream systems can make authorization decisions based on the binding's existence and strength without learning the underlying identifiers.

Expiry and automatic deactivation

Every cross-reference has an expiration timestamp. When a verify request encounters an expired cross-reference, the system automatically deactivates it and returns verified: false with the reason Cross-reference has expired. This ensures that stale bindings do not persist as valid assertions—a requirement for SOC 2 Type II credential lifecycle compliance.

PQC integrity verification

When a cross-reference carries a hybrid PQC signature, the verify operation performs full integrity verification. The signature payload is reconstructed from the stored data, and both the classical and post-quantum signatures are verified against the original signing key. Both signatures must pass for the cross-reference to be considered PQC-verified.

If the signature bundle is malformed or either signature fails verification, pqc_verified returns false. This does not invalidate the cross-reference itself—it indicates that the cryptographic integrity guarantee cannot be confirmed, which is a signal that downstream systems should factor into their trust decisions.

Binding to a biometric passkey

The cross-reference becomes its most powerful when bound to a device-specific biometric passkey. The bind operation links a passkey credential ID to an existing cross-reference, creating a three-layer identity assertion:

1. Carrier layer: The SIM in the device has not been swapped or ported (carrier signal attestation)
2. Legal identity layer: The person has passed KYC and holds a valid Verifiable Credential (VC subject hash)
3. Biometric layer: The person is physically present and has authenticated via device biometrics (passkey ceremony)

This three-layer binding addresses the limitation we explored in Passkeys Are Not Enough: a passkey alone proves device possession and biometric presence, but it cannot detect a SIM swap that occurred moments before the authentication ceremony. By binding the passkey to a cross-reference that includes a carrier signal attestation, the system can verify all three layers in a single lookup.

Revocation: Immediate, auditable, irreversible

Cross-references can be revoked through a single API call. Revocation sets the is_active flag to false and records the revocation timestamp. The operation is:

• Immediate: The cross-reference is deactivated in the same database transaction as the revocation request
• Auditable: Every revocation is recorded in the immutable audit log with the actor ID, timestamp, and request context
• Irreversible: A revoked cross-reference cannot be reactivated; a new establish operation is required to create a fresh binding

Revocation triggers include:

• Manual revocation by a tenant administrator
• SIM swap detection on the bound carrier signal
• VC revocation via W3C StatusList2021
• Behavioral trust score decay below the tenant's configured threshold
• Passkey credential compromise or device loss

The multi-provider correlation advantage

Cross-references become significantly harder to fool when the carrier signal layer uses multi-provider correlation rather than a single carrier API. A cross-reference established with a SIM attestation from a single provider (e.g., Twilio Lookup alone) carries the risk of that provider's blind spots becoming the system's blind spots.

When the carrier signal is the product of a fused, multi-provider correlation—where multiple carrier APIs independently confirm the SIM status—the cross-reference inherits that higher confidence level. The match score reflects the attestation strength: a multi-provider corroborated signal paired with a fresh VC verification within the same session produces the maximum confidence binding.

Enterprise tenant isolation

Cross-references are tenant-scoped. Every cross-reference record includes a tenant_id, and all queries are filtered by tenant at the database layer through Row-Level Security (RLS). A cross-reference established by Tenant A is invisible to Tenant B—not because the application filters it, but because the database engine enforces the boundary.

This is the same database-layer isolation pattern required for SOC 2 Type II compliance: the isolation cannot be bypassed by a missing WHERE clause or a misconfigured API endpoint.

Consequences for identity assurance

The cross-reference model introduces a primitive that the identity industry has lacked: a cryptographic proof that two independent identity signals—one from the telecom layer and one from the legal identity layer—refer to the same entity, without revealing who that entity is.

This has direct implications for:

• Account recovery: Before re-issuing credentials, verify that the person requesting recovery still controls the original SIM and holds a valid VC. The cross-reference confirms both without requiring the user to re-submit personal documents.

• Step-up authentication: When a high-value transaction requires elevated assurance, verify the cross-reference rather than prompting for additional personal information. The binding already encodes the KYC-to-device relationship.

• Regulatory compliance: Regulations like eIDAS 2.0 increasingly require multi-factor identity assurance that spans both the digital credential and the physical device. Cross-references provide this assurance natively, with a zero-PII architecture that satisfies GDPR Article 25 data protection by design requirements.

• Fraud detection: A cross-reference that suddenly fails verification—because the SIM hash changed but the VC hash did not—is a strong indicator of a SIM swap attack targeting a verified identity. The system can trigger automated response playbooks without needing to know who the user is.

A higher standard

Most identity platforms treat KYC verification and device attestation as separate concerns. They answer "did this person pass KYC?" and "is this SIM stable?" independently, and leave the correlation to the application layer—where it is frequently omitted, improperly implemented, or performed with reversible identifiers that create a privacy liability.

Deterministic cross-referencing makes the binding a first-class cryptographic primitive. The SIM signal and VC subject are hashed, combined, signed, and stored as an entity profile hash that proves the relationship without exposing the identifiers. The binding is time-scored, PQC-signed, passkey-bindable, and revocable within a single API call.

This is the missing architectural layer between "identity verified" and "identity assured", not a feature.

Start free · Test the API