Question 1

What is PasskeyBridge?

Accepted Answer

PasskeyBridge is an Identity Threat Response as a Service (ITRaaS) platform. It receives carrier and identity signals (SIM-swap, number porting, fraud alerts) and executes your configured response playbook in real-time with zero PII storage. It is built on a patent-pending three-pillar architecture: Pillar I (Network Attestation), Pillar II (Legal Identity Verification via a self-hosted W3C VC engine), and Pillar III (Biometric Binding via WebAuthn/FIDO2).

Question 2

Who is PasskeyBridge for?

Accepted Answer

Any platform that authenticates users with phone numbers or needs identity verification. Fintech companies, neobanks, crypto exchanges, healthcare platforms, defense contractors, critical infrastructure operators, and any team that wants automated threat response without building it from scratch. Our target verticals include financial services (terminal binding, SEC Reg S-ID compliance), military and defense (device attestation), and critical infrastructure (SCADA authentication).

Question 3

Is PasskeyBridge a replacement for my auth provider?

Accepted Answer

No. PasskeyBridge sits alongside your existing auth stack (Okta, Auth0, Clerk, Firebase, etc.). We handle the threat-response layer: what happens after a threat signal is detected. That layer sits after authentication and bridges the gap between detection and containment. We integrate natively with Okta via OIN, SCIM v2, and event hooks.

Question 4

What does 'patent-pending' mean for PasskeyBridge?

Accepted Answer

PasskeyBridge holds a portfolio of sixteen patent filings: four non-provisional utility applications—19/553,357 (core three-pillar orchestration), 19/561,964 (Autonomous Inter-Agent Trust Negotiation), 19/564,338 (NTN Kinematic Trust Anchoring), and 19/567,418 (Recursive Entropy Chaining)—plus nine provisional CIP applications covering Graduated Agentic Trust Scoring (NF-05), Hybrid PQC Attestation (NF-06), Quantum-Seeded Entropy (NF-07), Spatially-Bound Identity Attestation (NF-08), BLAST Tunnel Protocol (64/006,808), Parametric Revocation Cascade (64/006,812), Provenance Guard (64/006,816), Identity Settlement Tokens (64/006,819), and Purpose-Bound PII Vault (64/014,323), a standalone provisional for Predictive Cybersecurity Threat Prosecution (PBIP, 63/999,157), and two additional non-provisional CIPs: Relativistic Space-Time Authentication (PBSTA, 19/570,722) and Topological Virtual Authenticator (PBANCHOR, 19/576,127). You're licensing genuinely novel identity infrastructure.

Question 5

What is the 'identity trust layer' architecture?

Accepted Answer

PasskeyBridge is designed as an identity trust layer: it sits between your platform and the user without becoming a data silo. We don't store user data, passwords, or PII. We orchestrate trust signals from carriers, issue and verify W3C Verifiable Credentials via our self-hosted engine, bind biometrics via WebAuthn, run AI threat analysis asynchronously, and protect everything with hybrid post-quantum cryptography seeded by quantum entropy. All with zero PII at rest.

Question 6

What is Pillar I: Network Attestation?

Accepted Answer

Pillar I is the signal-based threat response layer. It ingests carrier signals (SIM-swap alerts, number porting notifications, fraud indicators) from providers like Vonage, Twilio, Sinch, or custom webhooks. When a threat signal is detected, your configured playbook executes automatically: webhook callbacks, email alerts, Slack notifications, account suspension. Pillar I is included in all plans.

Question 7

What is Pillar II: Legal Identity Verification?

Accepted Answer

Pillar II provides W3C Verifiable Credential issuance and verification via PasskeyBridge's self-hosted VC engine. The engine supports JWT-VC format, OpenID4VP presentation exchange with batch VP Token verification (up to 20 tokens per request), W3C StatusList2021 credential status management with ETag-based auto-refresh, DID resolution (did:web:passkeybridge.io), and per-tenant P-256 ECDSA (ES256) signing keys with 24-hour rotation grace periods. Credentials can carry hybrid PQC signatures (ML-DSA-65 + classical ES256) on Enterprise plans. The verified identity is bound to the user's account via a SHA-256 hash: no PII is stored.

Question 8

What is Pillar III: Biometric Binding?

Accepted Answer

Pillar III provides device-level biometric binding via the WebAuthn/FIDO2 standard. Users register a passkey using their device's biometric sensor (Face ID, Touch ID, Windows Hello). The credential is bound to the device's Secure Enclave or TPM, creating a cryptographic link between the user's physical presence and their digital identity. Combined with Pillars I and II, this creates a three-factor deterministic trust chain: something the network knows, something a government issued, and something the body proves.

Question 9

Do I need all three pillars?

Accepted Answer

No. Pillar I (Network Attestation) is included in every plan and works standalone. Pillars II and III are optional per-seat annual licenses that you can add when your security requirements demand it. Many customers start with Pillar I for immediate threat response and add Pillar II or III as their compliance needs grow.

Question 10

How does signal ingestion work?

Accepted Answer

You point your carrier webhook (Vonage, Twilio, Sinch, or custom) at your unique PasskeyBridge ingest URL: POST /v1/shield-ingest. We verify every payload with HMAC-SHA256 (if a signing secret is configured), extract and keyed-HMAC-SHA-256 hash any PII (phone numbers) under a server-held pepper, match the signal against your active playbooks, execute the ordered action chain, and return the result inside the request. Every step is logged immutably to your event audit trail.

Question 11

What signal sources do you support?

Accepted Answer

PasskeyBridge is provider-agnostic by design. We support Vonage Number Insight V2, Twilio Verify + Lookup, Sinch Verification, and any custom webhook that sends JSON payloads. You can register multiple signal sources per tenant, each with its own signing secret for payload verification. If your carrier sends JSON over HTTPS, PasskeyBridge can ingest it.

Question 12

What signal types can I detect?

Accepted Answer

Common signal types include: sim_swap (SIM card changes), port_out (number porting to another carrier), credential_leak (compromised credentials detected), device_change (device fingerprint mismatch), velocity_anomaly (abnormal usage patterns), and account_takeover (suspicious login behavior). You can also define custom signal types: PasskeyBridge matches them against your playbooks by the event_type field in the payload.

Question 13

How do I authenticate ingest requests?

Accepted Answer

Production requests use API key authentication via the x-pb-api-key header. API keys are SHA-256 hashed before storage and the raw key is shown only once at generation time. Keys are scoped to specific capabilities (ingest, events, metrics, vc_issue, vc_verify, vc_revoke, spatial, scim, okta_hooks, dpop, supply_chain, passkey_rp, passkey_rp_import, receipts) so you can follow least-privilege principles. For testing from the dashboard, JWT authentication with the x-pb-test-mode: true header is supported.

Question 14

What is a playbook?

Accepted Answer

A playbook is an ordered chain of actions that execute when a matching threat signal is detected. Each playbook is bound to a signal_type (e.g., 'sim_swap') and executes its actions sequentially. If a playbook has three actions—webhook_callback, slack_webhook, email_alert—they execute in that order. Each action has its own latency tracking and error handling. Playbooks are versioned, so you can iterate on your threat response strategy without losing history.

Question 15

What action types are supported?

Accepted Answer

PasskeyBridge supports four action types: (1) webhook_callback—POSTs the event payload to your endpoint with HMAC-SHA256 signature, with exponential backoff retry (up to 4 attempts); (2) email_alert—sends a threat alert email to a specified address; (3) slack_webhook—sends a rich Slack notification with signal details, risk score, and phone hash via Incoming Webhook URL; (4) log_event—records the event with a configurable severity level. Each action includes latency tracking and error capture in the audit trail.

Question 16

How does webhook callback signing work?

Accepted Answer

When your playbook triggers a webhook_callback action, PasskeyBridge signs the outbound payload with your tenant's callback_signing_secret using HMAC-SHA256. The signature is included in the x-pb-signature header. Your server should verify this signature before processing the payload to ensure it came from PasskeyBridge and hasn't been tampered with. You can rotate your signing secret at any time from the dashboard.

Question 17

What happens if a webhook callback fails?

Accepted Answer

PasskeyBridge uses exponential backoff retry with up to 4 attempts (delays of 1s, 2s, 4s, 8s). HTTP 2xx responses are treated as success. HTTP 429 and 5xx responses trigger retries. HTTP 4xx responses (except 429) are treated as permanent failures and are not retried. Every delivery attempt—including failures—is logged to the webhook delivery log with status code, response body, latency, and error message. You can inspect these in the dashboard's Webhooks tab.

Question 18

Do you offer pre-built playbook templates?

Accepted Answer

Yes. PasskeyBridge includes 5 pre-built playbook templates covering common threat scenarios: SIM-Swap Account Lock (universal), Number Port Fraud Alert (fintech), Booking Identity Verify (travel & hospitality), High-Risk Login Review (SaaS & marketplace), and Agent Delegation Audit (enterprise). When creating a new playbook, select a template to pre-fill the name, trigger signal, and response actions—then customize as needed.

Question 19

Does PasskeyBridge have its own VC engine?

Accepted Answer

Yes. PasskeyBridge operates a self-hosted W3C Verifiable Credential engine comprising five edge functions: shield-vc-issue (credential issuance), shield-vc-verify (cryptographic verification), shield-vc-present (OpenID4VP presentation exchange), shield-vc-status (W3C StatusList2021 revocation management), and shield-did-resolve (DID document resolution for did:web:passkeybridge.io). Per-tenant signing keys are managed via shield_tenant_keys with rotation support.

Question 20

What VC formats and standards are supported?

Accepted Answer

The engine issues JWT-VC format credentials (W3C VC Data Model 2.0), supports OpenID4VP presentation exchange for verifier flows, resolves DID documents for issuer verification, and implements a three-state credential lifecycle (active → suspended → revoked). Enterprise tenants with PQC enabled get hybrid signatures (ML-DSA-65 + classical) on all issued credentials.

Question 21

What are trusted issuer registries?

Accepted Answer

Each VC provider configuration includes a list of trusted issuer DIDs (Decentralized Identifiers). When a credential is verified, PasskeyBridge checks that the issuer is in your trusted list. If the issuer isn't trusted, the verification is rejected—even if the credential itself is cryptographically valid. This prevents acceptance of credentials from unknown or untrusted issuers.

Question 22

What credential types can I issue and accept?

Accepted Answer

You configure the supported_credential_types array per provider. Common types include VerifiableId (government ID), VerifiablePassport, VerifiableEmployeeCredential, VerifiableDiploma, and any W3C Verifiable Credential type. The self-hosted engine can issue credentials with custom claims and verify inbound credentials against your trusted issuer registry.

Question 23

How does zero-PII work with Verifiable Credentials?

Accepted Answer

When a Verifiable Credential is verified, PasskeyBridge extracts the credential subject and replaces all PII fields with '[redacted]' before logging. Only field names, types, and non-PII metadata (DID, credential type) are stored. The subject's DID is SHA-256 hashed for correlation. The actual credential content exists only in-memory during the verification request and is never persisted.

Question 24

Is there a client-side SDK for credential management?

Accepted Answer

Yes. The PBWallet SDK (available at /sdk) is a TypeScript library that provides IndexedDB-backed credential storage, OpenID4VP Presentation Exchange 2.0 matching, and full lifecycle management (issuance, verification, revocation, suspension). Initialize with your tenant API key and endpoint, then call wallet.requestCredential(), wallet.presentCredentials(), or wallet.revokeCredential(). The SDK handles BLAST tunnel negotiation, PQC signature embedding, and automatic cross-reference binding.

Question 25

What is W3C StatusList2021 and how does PasskeyBridge implement it?

Accepted Answer

W3C StatusList2021 is the standard for verifiable credential revocation using compressed bitstring encoding. PasskeyBridge implements this via shield-vc-status, supporting three states: active, suspended (reversible), and revoked (permanent). Public GET requests return the StatusList2021 bitstring for any issuer DID, enabling external verifiers to check credential status without contacting PasskeyBridge directly. StatusList responses include HTTP ETags derived from the bitstring content, enabling conditional caching: relying parties only download a fresh list when the underlying state has changed.

Question 26

What is batch VP Token verification?

Accepted Answer

Batch VP Token verification allows you to submit up to 20 OpenID4VP Verifiable Presentation tokens in a single API call to shield-vc-present. Each token is independently verified against its presentation definition, and the response returns per-token results. This replaces sequential round trips with a single request, which is particularly useful for onboarding flows, compliance audits, and multi-party attestation chains. The 20-token limit is enforced at both the client SDK and edge function layers. Pro plan required.

Question 27

How does StatusList2021 auto-refresh work?

Accepted Answer

Each StatusList response carries an ETag derived from a SHA-256 hash of the bitstring content (not timestamps). When a relying party polls for status updates and the bitstring has not changed, the server returns 304 Not Modified with zero body. Relying parties cache the StatusList locally and only download a fresh copy when a credential has been revoked or suspended. In steady-state operation, the caching ratio approaches 100%.

Question 28

Does the SDK store credentials on the server?

Accepted Answer

No. The PBWallet SDK stores credentials locally in IndexedDB (with an in-memory fallback). Credentials are only transmitted to the server during issuance (to receive the signed JWT-VC) and presentation (to verify against your trusted issuer registry). The SDK never persists plaintext PII: all subject identifiers are SHA-256 hashed before any server communication.

Question 29

How does WebAuthn passkey registration work?

Accepted Answer

From the dashboard, users click 'Register Passkey' which triggers the browser's WebAuthn API. PasskeyBridge generates registration options (challenge, relying party info), the browser prompts for biometric verification (Face ID, Touch ID, Windows Hello), and the resulting credential is cryptographically verified on our server. The public key is stored; the private key never leaves the user's device Secure Enclave or TPM.

Question 30

What devices support passkey authentication?

Accepted Answer

Any device with a FIDO2-compatible authenticator: iPhones with Face ID or Touch ID, Macs with Touch ID, Windows PCs with Windows Hello (camera, fingerprint, or PIN), Android devices with fingerprint or face unlock, and hardware security keys (YubiKey, etc.). PasskeyBridge supports both platform authenticators (built into the device) and roaming authenticators (USB/NFC keys).

Question 31

Can users register multiple passkeys?

Accepted Answer

Yes. Users can register passkeys on multiple devices—for example, a Face ID passkey on their iPhone and a Windows Hello passkey on their laptop. Each credential is independently stored and can be individually revoked. We recommend registering at least two passkeys for redundancy.

Question 32

What is 'biometric binding' in the context of the three-pillar model?

Accepted Answer

Biometric binding is the cryptographic link between a user's physical biometric (face, fingerprint) and their digital identity. When combined with Pillar I (network attestation) and Pillar II (legal identity), it creates a deterministic trust chain: the carrier attests the phone number, the verifiable credential attests the legal identity, and the biometric attests physical presence. All three are linked via SHA-256 hashes without storing PII.

Question 33

What are agent delegates?

Accepted Answer

Agent delegates are authorized digital agents (AI assistants, automation bots, service accounts) that can act on behalf of your organization with scoped, time-bound permissions. You create a delegate with specific scopes (e.g., 'read_events', 'trigger_playbook') and an optional expiration. The agent receives a one-time token (shown once, never again) that it uses to authenticate. Delegates can be revoked instantly from the dashboard.

Question 34

What is Graduated Agentic Trust Scoring (NF-05)?

Accepted Answer

NF-05 is a patent-pending trust engine that continuously evaluates agent behavior and assigns a trust score from 0.000 to 1.000. Based on the score, agent scopes are dynamically narrowed: ≥0.7 retains full access, ≥0.4 drops to read-only, ≥0.2 restricts to verify-only, and <0.2 triggers automatic revocation. The engine detects behavioral signals including action velocity anomalies, error bursts, IP rotation, and inactivity-burst patterns.

Question 35

How does dynamic scope narrowing work?

Accepted Answer

When the trust engine detects anomalous behavior, it narrows the agent's active scopes while preserving the original scopes for potential restoration. If trust recovers above the full-access threshold (≥0.7), scopes are automatically restored without admin intervention. Hard signals (SIM-swap, SS7 intercept, device compromise) bypass the graduated system entirely and trigger immediate revocation.

Question 36

Does the AI influence trust decisions?

Accepted Answer

Yes, but with a hard cap. AI behavioral analysis contributes a maximum of 30% influence weight to trust score changes. The remaining 70%+ comes from deterministic signal evaluation. This ensures that AI hallucinations or adversarial prompt attacks cannot single-handedly revoke an agent's access. The AI can only escalate, never approve.

Question 37

Why do I need agent delegates?

Accepted Answer

As AI agents become prevalent in enterprise workflows, they need authorized access to your systems. Without proper delegation, agents either have no access (limiting automation) or use shared credentials (creating security risks). PasskeyBridge agent delegates provide scoped, audited, revocable access with continuous trust evaluation—the same security model you'd want for human team members, but designed for AI agents.

Question 38

What is the A2A Horizontal Trust Protocol?

Accepted Answer

The A2A (Agent-to-Agent) Horizontal Trust Protocol (Patent 19/561,964) enables autonomous agents to negotiate trust and transaction limits directly with each other via recursive attestation of their human root-of-trust. Unlike vertical trust models (agent-to-platform), A2A establishes peer-level trust corridors with scoped transaction limits, expiration windows, and automatic invalidation on carrier compromise signals.

Question 39

How does A2A trust negotiation work?

Accepted Answer

A2A follows a five-phase pipeline: (1) Initiate -- one agent proposes a trust corridor with requested scopes and transaction limits; (2) Attest -- the responder validates the initiator's root-of-trust via cached proof or live carrier attestation; (3) Negotiate -- both agents compute a Combined Trust Coefficient (CTC) synthesizing behavioral data, network jitter, and NF-08 fingerprint bonuses; (4) Renew -- active corridors can extend with a 10% score-drift guard preventing gradual trust inflation; (5) Invalidate -- hard carrier signals (SIM-swap, SS7 intercept) cascade through all active negotiations for the affected user hash.

Question 40

What is the Combined Trust Coefficient?

Accepted Answer

The CTC is a weighted composite score (0.000-1.000) that synthesizes both agents' individual trust scores, behavioral clustering data, network jitter measurements, and an optional +0.05 bonus for active NF-08 spatial bindings. It enforces four trust states: Full (CTC >= 0.7), Limited (>= 0.4), Verify-Only (>= 0.2), and Auto-Revoked (< 0.2). The CTC determines the maximum transaction value and rate limits for the negotiated corridor.

Question 41

How are A2A handshakes cryptographically protected?

Accepted Answer

Every A2A handshake proof carries dual-layer hybrid signatures: HMAC-SHA-256 (classical) plus ML-DSA-65 (post-quantum). Nonces are quantum-seeded via the Seed and Stretch entropy architecture, with replay protection enforcing single-use consumption and 300-second clock drift tolerance. All nonce hashes are persisted to shield_a2a_nonces for forensic auditability.

Question 42

What happens when a carrier signal invalidates an A2A negotiation?

Accepted Answer

Hard carrier signals (SIM-swap, port-out, SS7 intercept) trigger cascading invalidation across all active A2A negotiations for the affected agent delegate. The invalidation records the triggering signal ID and reason, transitions the negotiation to 'invalidated' status, and narrows the affected delegate's scopes via the graduated trust engine. This is automatic and immediate -- no human intervention required.

Question 43

What observability capabilities does PasskeyBridge provide?

Accepted Answer

Enterprise tenants get structured metrics (Prometheus and JSON export), anomaly detection with configurable alert rules, and multi-channel alerting (Slack, PagerDuty, OpsGenie, webhook). The shield-metrics edge function computes real-time statistics across signals, events, playbooks, agents, VCs, cached proofs, and A2A negotiations. All metric payloads contain aggregated counts and scores only -- zero PII.

Question 44

How do alert rules work?

Accepted Answer

Alert rules are tenant-scoped, configurable triggers that fire when a metric crosses a threshold. Each rule specifies: metric name (e.g., high_risk_event_count, avg_response_ms, failed_webhook_rate), comparison operator (gt, lt, gte, lte, eq), threshold value, severity (info, warning, critical), cooldown period (minutes between re-fires), and channel configuration. Rules are managed via the shield-alerting edge function and the dashboard's Observability tab.

Question 45

What is Human-in-the-Loop (HITL) review?

Accepted Answer

HITL review is the workflow for security analysts to review, correct, and annotate AI intelligence assessments. When the Intelligence Layer flags an event, analysts can approve, reject, or correct the AI's risk score, intelligence type, and threat actor label. Corrections are persisted to the intelligence record with reviewer ID, timestamp, and notes. This feedback loop improves the AI's accuracy over time while maintaining human oversight of all automated decisions.

Question 46

What is behavioral clustering?

Accepted Answer

Behavioral clustering groups recent events by signal type, risk score ranges, carrier patterns, and temporal distribution to identify coordinated attack campaigns. The shield-intelligence-worker uses clustering data to enrich AI assessments with contextual threat intelligence. Clusters are computed from the tenant's recent event history and include metrics like dominant signal types, risk score distribution, and event velocity.

Question 47

Can I integrate PasskeyBridge metrics with my existing monitoring stack?

Accepted Answer

Yes. The shield-metrics endpoint exports data in both Prometheus text format and JSON. The Prometheus exposition accepts an API key carrying the metrics or events scope, so a Prometheus scraper or Datadog agent can read it directly; the JSON actions are read from the dashboard session instead. The JSON format is compatible with any monitoring system that accepts structured data via HTTP.

Question 48

What are mTLS agent certificates?

Accepted Answer

Enterprise tenants can pin X.509 certificates to agent delegates for mutual TLS (mTLS) authentication. Each certificate record stores the SHA-256 fingerprint, subject CN, issuer CN, validity window (not_before/not_after), and active/revoked status. Certificates are managed via the Agents tab in the dashboard and enforced at the edge function layer for high-assurance agent authentication.

Question 49

How does automated key rotation work?

Accepted Answer

Rotation policies define automatic key and credential rotation schedules per resource type (api_key, tenant_signing_key, agent_certificate, blast_session_key, entropy_seed, vc_signing_key). Each policy specifies rotation interval (hours), grace period (hours for dual-key overlap), and auto-rotate toggle. The system tracks last rotation, schedules next rotation, and executes rotation with zero-downtime key overlap during the grace period.

Question 50

What resource types support automated rotation?

Accepted Answer

Six resource types: API keys, tenant signing keys, agent certificates, BLAST session keys, entropy seeds, and VC signing keys. Each can have independent rotation intervals (e.g., API keys every 720 hours, entropy seeds every 24 hours). Rotation policies are tenant-scoped and managed via the Settings tab.

Question 51

What is Spatially-Bound Identity Attestation?

Accepted Answer

NF-08 (patent-pending, 63/998,671) binds identity to a specific physical device at a specific moment in time. It creates 'Atomic Fingerprints': composite hashes of EMI spectral energy, on-die thermal sensor variance, accelerometer motion vectors, and network jitter (RTT variance), all captured within a ≤100ms temporal window. This deterministic spatial attestation proves that the operator was physically present at the enrolled device when an action was initiated.

Question 52

What sensor channels does the client SDK capture?

Accepted Answer

The sensor-capture SDK (sensor-capture.ts) captures four channels: (1) Network jitter—RTT variance sampled via Resource Timing API, navigator.connection, and OS scheduler delta; (2) Accelerometer—60Hz motion vectors via the Generic Sensor API with graceful degradation for unsupported browsers; (3) Magnetometer—ambient magnetic field sampled via the Generic Sensor API, used as an EMI proxy; (4) Thermal state—a coarse thermal bucket derived from navigator/UA heuristics. Native EMI-spectral and on-die thermal sensing require a firmware bridge and are on the native-SDK roadmap. All raw data is SHA-256 hashed on-device before transmission. Identical jitter hashes across distinct captures trigger a replay anomaly (+0.4 anomaly score).

Question 53

What verticals does NF-08 target?

Accepted Answer

Three primary verticals: (1) Military and defense—binding operator identity to ruggedized terminals and tactical radios, preventing credential relay and ghost-operator attacks; (2) Financial services—binding trader identity to Bloomberg terminals and trading workstations for SEC Rule 15c3-5 and MiFID II compliance; (3) Critical infrastructure—binding operator identity to SCADA HMI consoles for NERC CIP, NRC 10 CFR 73, and EPA SDWA compliance.

Question 54

How does the ≤100ms temporal window work?

Accepted Answer

The Spatial Binding Controller (shield-spatial-bind edge function) enforces that the elapsed time between the sensor capture timestamp and the server receipt timestamp must be ≤100ms. If the window is exceeded, the binding is rejected with an NF08_TEMPORAL_WINDOW_EXCEEDED error. This prevents replay attacks where captured sensor data is forwarded from a different location.

Question 55

How is NF-08 different from TPM or Secure Enclave attestation?

Accepted Answer

TPM and Secure Enclave bind cryptographic keys to a chip, but they attest the device, not the device-at-a-moment-in-time. A stolen device with valid keys passes attestation. Atomic Fingerprints bind to the physical state of the device at capture time (EMI emissions, thermal variance), making credential relay detectable. It is also distinct from behavioral biometrics (BioCatch, TypingDNA), which are probabilistic and trainable by adversaries.

Question 56

What is Quantum-Ready PQC?

Accepted Answer

PasskeyBridge deploys real ML-DSA-65 lattice-based signatures (NIST FIPS 204) via the PQClean reference implementation compiled to WebAssembly. Every hybrid signature pairs a genuine ~3,309-byte ML-DSA-65 lattice signature with a classical HMAC-SHA-256 authentication tag. The post-quantum lattice layer provides forward security against 'harvest now, decrypt later' adversaries even as classical assumptions weaken. PQC is available on the Enterprise plan.

Question 57

What NIST standards does PasskeyBridge follow for PQC?

Accepted Answer

Our implementation deploys NIST FIPS 204 (ML-DSA-65) in production today via mldsa-wasm (PQClean compiled to WebAssembly). Key pairs are derived deterministically from a master key using domain-separated HMAC-SHA-256 seed derivation. We also align with NIST SP 800-227 for hybrid migration planning and NIST SP 800-90A for QRNG-seeded DRBG entropy. There is no simulation layer—these are real lattice-based signatures.

Question 58

What is the quantum entropy system?

Accepted Answer

PasskeyBridge uses a Quantum-Seeded Entropy Generation system (NF-07, patent-pending). 256-bit seeds from Outshift QRNG (Cisco quantum hardware) are stretched via AES-CTR-DRBG to power thousands of cryptographic operations. The system has a four-tier failover: Outshift QRNG (Cisco) → QCi uQRNG (Photonic) → ANU QRNG → OS CSPRNG fallback. Seeds rotate every 60 seconds or 1,000 requests (whichever comes first). All seed activity is logged to an auditable entropy pool with per-seed quality metrics.

Question 59

Do I need to change my integration for PQC?

Accepted Answer

No. PQC is entirely transparent to your integration. When enabled, hybrid signatures are automatically applied to cross-references, cached proofs, spatial bindings, and verifiable credentials. The pqc_signature field stores a JSON bundle containing both classical and PQC components. Your existing API calls, webhooks, and playbooks work exactly the same.

Question 60

Why is PQC Enterprise-only?

Accepted Answer

Hybrid PQC signatures add computational overhead and require enhanced infrastructure controls. The Enterprise plan includes dedicated instance support, extended retention, and the security guarantees needed for quantum-resilient operations. As PQC matures and costs decrease, we may extend availability to lower tiers.

Question 61

What is the difference between ML-DSA-65 and ML-DSA-87?

Accepted Answer

ML-DSA-65 (NIST Security Level 3) is the default post-quantum signature algorithm included with all Enterprise plans. ML-DSA-87 (NIST Security Level 5) is an optional Enterprise add-on ($149/mo) that provides the highest CNSA 2.0 security level—equivalent to AES-256 strength against quantum adversaries. ML-DSA-87 produces ~4,627-byte signatures (vs ~3,309-byte for ML-DSA-65). The upgrade is transparent to your integration: toggle it in Settings → Security → PQC Level, and all subsequent signatures use the stronger algorithm. Existing ML-DSA-65 signatures remain valid and verifiable.

Question 62

Does PasskeyBridge support SAML and OIDC SSO?

Accepted Answer

Yes. Enterprise tenants can configure SAML 2.0 and OIDC-based SSO providers via the dashboard's SSO configuration panel. Each SSO config includes provider type, entity ID, SSO URL, certificate, and optional domain hint. Multiple SSO providers can be active simultaneously per tenant. SSO is managed via the shield-sso edge function.

Question 63

What is SCIM provisioning?

Accepted Answer

PasskeyBridge implements SCIM v2 (RFC 7644) for automated user and group provisioning. When you connect your identity provider (Okta, Azure AD, OneLogin), user creation, updates, and deprovisioning are synchronized automatically. The shield-scim edge function handles GET/POST/PUT/PATCH/DELETE operations on /Users and /Groups resources.

Question 64

How does the Okta integration work?

Accepted Answer

PasskeyBridge integrates with Okta via three channels: (1) SCIM v2 for user provisioning, (2) Okta Event Hooks for real-time lifecycle events (user.lifecycle.create, user.lifecycle.suspend, user.lifecycle.deactivate), and (3) OIN (Okta Integration Network) for marketplace distribution. The shield-okta-hooks edge function consumes Okta's one-time verification challenge and processes lifecycle events into your threat pipeline.

Frequently Asked Questions

General

Three Pillars

Technical—Signal Ingestion

Technical—Playbooks & Actions

Technical—Verifiable Credentials (Pillar II)

Technical—Biometric Binding (Pillar III)

Agentic Identity & Trust Scoring

A2A Horizontal Trust Protocol

Observability, Alerting & HITL Review

mTLS Agent Certificates & Key Rotation

Spatial Binding & Atomic Fingerprints (NF-08)

Quantum Resilience (PQC)

Enterprise SSO & SCIM

Supply Chain Provenance

SDK Integrity Attestation

Breakglass Emergency Access

Cross-Tenant Threat Sharing

Insider Threat Analytics

SSF/CAEP & DPoP

Operational Resilience

Enterprise Features

AI Intelligence Layer

Social Recovery

Security & Privacy

Sign-in & Federated Auth

Developers & SDK

Pricing & Billing

Integration & Onboarding

Legal & IP