Identity threat response

Identity threat detection and response, in the same request

PasskeyBridge ingests carrier and breach signals, scores them against your playbook, and revokes, freezes, or steps up in the same request—backed by post-quantum signatures you can verify yourself.

Start free Read the whitepaper

Grounded inNIST FIPS 204W3C VC 2.0FIDO2 / WebAuthnGSMA Open Gateway

Threat response in action

Response to three attack types

Three illustrated attack patterns and the response sequence, from signal ingestion to remediation. A live event records its decision time as decision_ms. The steps on this page are the sequence.

Step 1Threat detected

Attacker

Attacker initiates SIM port-out request at carrier store with social-engineered credentials.

PasskeyBridge

Vonage Number Insight webhook fires. PasskeyBridge ingest validates HMAC-SHA256 signature.

Step 2Analyzing

Attacker

Carrier begins porting process. Attacker's device receives OTP.

PasskeyBridge

The event is scored. The SIM signal does not match the passkey bound to the account.

Step 3Responding

Attacker

Attacker attempts account login with intercepted OTP.

PasskeyBridge

Cascade engine triggers. Cross-reference confirms SIM signal does not match bound passkey device.

Step 4Resolved

Attacker

PasskeyBridge

All active sessions revoked. Passkey re-enrollment ceremony initiated on verified device. Audit log written.

✓Sessions revoked. Passkey re-enrollment triggered.Response steps

Signal sources

Signals PasskeyBridge ingests

Carrier state, breach exposure, agent behavior, and device binding—ingested continuously, scored on every request.

Carrier

Live carrier state

SIM swap and porting from the carrier lookup you configure, checked when your service calls. A recycled number arrives as a number_recycle signal a tenant posts.

Vonage Number InsightHMAC-SHA256sim_swapport_out

Breach

Breach-sourced credentials

Leaked credentials matched against HIBP with k-anonymity—only a hash prefix ever leaves your tenant, never a password.

HIBP k-anonymitycredential_leakzero PII

Agents

Behavioral trust scoring

A trust score per delegated agent, recomputed from its recorded activity; behavioral signals such as a velocity spike lower it, and a score below the narrowing threshold removes scopes automatically.

trust scoreA2A coefficientscope narrowing

Device

Bound passkey device

Every decision cross-references the requesting device against the passkey bound to the account—WebAuthn, phishing-resistant, revocable.

FIDO2 / WebAuthnpasskey bindingrevocable

Cryptographic foundations

Cryptography you can verify

Every primitive is a ratified NIST standard or a provably secure construction. PasskeyBridge uses no proprietary ciphers.

ML-DSA-65 / ML-DSA-87

NIST FIPS 204 lattice-based digital signatures. Hybrid classical + post-quantum scheme with runtime algorithm branching per tenant.

ML-DSA-65 is default (3,309-byte signatures). ML-DSA-87 (Security Level 5, 4,627-byte signatures) available as Enterprise add-on.

Dilithium-based lattice construction (mldsa-wasm)
Hybrid co-signing: classical ES256 (P-256), or ES384 (P-384) on the ML-DSA-87 / CNSA 2.0 tier
Per-tenant pqc_level configuration
CNSA 2.0 aligned signature suite

✓3.3 KB / 4.5 KB signatures · FIPS 204

BLAST Protocol

Bi-Lateral Authenticated Secure Tunnels. X25519 ECDH key exchange with perfect forward secrecy and ephemeral session keys.

Every tunnel negotiation produces a unique shared secret. Keying material is zeroized after session teardown.

X25519 ephemeral key pairs
HKDF-SHA256 key derivation
AES-256-GCM tunnel encryption
Automatic session expiry + teardown

✓AES-256-GCM · PFS

QRNG Entropy

Hardware quantum random number generation from Outshift and QCi sources, with deterministic DRBG expansion and local CSPRNG fallback.

Entropy pool is continuously replenished. Each request draws from the highest-available source in the hierarchy.

Outshift QRNG primary source
QCi uQRNG secondary source
ANU Quantum tertiary source
Local CSPRNG guaranteed availability

✓Hardware entropy · 4-tier fallback

Cached Trust Proofs

Time-bounded, PQC-signed proof tokens that enable offline identity verification without network connectivity.

Proofs carry a trust level, expiry, and optional ML-DSA signature. Revalidated automatically when connectivity resumes.

Encrypted proof payload (AES-256-GCM)
Time-bounded with automatic expiry
Optional ML-DSA post-quantum signature
Network-aware trust level assignment

✓Offline verification · PQC-signed

Compliance posture

Standards alignment you can audit.

Every cryptographic implementation, data-handling policy, and credential lifecycle maps to a ratified standard.

Standard

Status

Coverage

SOC 2 Type II

Readiness

Readiness only: evidence collected and under review; no report issued. No audit firm engaged yet and no audit scheduled; we are evaluating audit firms. Controls in production: append-only audit logging, key rotation policies, tenant isolation via PostgreSQL RLS, time-bounded credential lifecycles.

ISO 27001

Readiness

Readiness only: controls designed against ISO 27001 criteria; not audited to the standard and no certificate issued. No audit firm engaged yet and no audit scheduled. Controls covered: access control, cryptographic key management, incident response procedures.

NIST FIPS 203

Aligned

The BLAST handshake mixes X25519 with ML-KEM-768 when the client sends an encapsulation key. Clients that omit it stay on X25519. This is the mechanism, not a claim that production traffic uses ML-KEM, and not a certification.

NIST FIPS 204

Partial

Signatures use the ML-DSA-65 and ML-DSA-87 algorithms from FIPS 204, via mldsa-wasm, a WebAssembly build of mldsa-native. ML-DSA-65 is the default; ML-DSA-87 is an Enterprise add-on. Key seeds are derived with HMAC-SHA-256 from a server-held master key, not generated from a fresh random seed as FIPS 204 key generation specifies.

W3C VC 2.0

Full Parity

JWT-VC issuance, SD-JWT-VC selective disclosure, OID4VCI ceremonies, OpenID4VP presentation exchange, StatusList2021 revocation.

CNSA 2.0

Aligned

ML-DSA-87, the signature parameter set CNSA 2.0 specifies, is available per tenant as an Enterprise add-on; the default is ML-DSA-65. BLAST can mix in ML-KEM-768; CNSA 2.0 specifies ML-KEM-1024, which this handshake does not use. Designed against the suite; no claim of certification or compliance.

eIDAS 2.0

Aligned

Cross-border credential interoperability. Verifiable credential format compatibility with EU Digital Identity Wallet architecture.

FIDO2 / WebAuthn

Implemented

Passkey registration and authentication with on-device user verification, required at every ceremony on the dashboard and in the hosted relying party for tenants. A playbook's freeze_credentials action invalidates cached passkey proofs so the next authentication attests afresh.

Use cases