How does this integrate with our existing IdP (Okta, Entra ID, Auth0)?+
ScrambleID for humans federates with your IdP via OIDC. It doesn't replace it. Your IdP keeps owning the principal model, group membership, and SSO entitlements. ScrambleID adds the cross-surface signature your IdP can't deliver: the same identity primitive that signs the web event signs the voice event, the workstation event, and the recovery event. Existing federation between your IdP and your downstream apps stays in place.
How does this co-exist with passkeys we already deployed?+
Passkeys close primary auth on the web surface. ScrambleID extends past that. The primary-auth event can be a passkey if you've already standardized on one. The signature on the recovery event, the voice event, the workstation event, and the peer-verification event is ScrambleID's. Customers running deployed passkeys keep them and add cross-surface coverage on top. New deployments can use ScrambleID end-to-end.
What does cross-surface recovery actually look like?+
User loses every web-surface device. Recovery starts: a signed challenge goes to the user's registered phone (voice surface). The user answers, and the contact-center system verifies the signed event before any agent picks up. A second signed challenge goes to a designated peer at the organization (people surface) for in-person or video peer-verification. Two signed events, neither involving the helpdesk and neither falling back to KBA. New device gets enrolled, old keys revoked, account restored. The entire recovery is cryptographic, not narrative.
What does 'native MFA-by-design' mean specifically?+
Multi-factor authentication is part of the primitive, not bolted on at the protocol layer. Every signed event is a cryptographic key plus a second factor (biometric, PIN, or hardware token) verified locally on the device. The signature only generates if both factors verify. There's no separate TOTP enrollment, no separate push notification flow, no separate SMS gateway. The MFA is the auth, not a layer above it.
How broad is the surface coverage?+
Workforce web auth (passwordless across One Tap, QR, code, biometric, PIN). Voice and contact center (caller verification before the agent picks up, deployed across NICE, Twilio, Google CCAI). Frontline (per-user identity at shared workstations and POS without requiring a personal device). People (peer verification with selective attribute disclosure). Four surfaces. One primitive. Consumer-facing passwordless (One Tap on mobile, QR on desktop, biometric on workstation, a code path with no phone) is that same primitive deployed for D2C, not a separate surface.
What does deployment actually look like?+
Pilot: integrate the signing SDK on one surface (typically workforce web), federate against your IdP, sign the first recovery event in days. Production: extend across the surfaces you want covered, federate recovery flows into your helpdesk and contact-center stacks, route the signed event log to your SIEM. Pilot in days. Production in weeks. No PKI re-architecture. No enclave provisioning.
Does this work for B2B, D2C, and consumer-facing customer auth?+
Yes. ScrambleID for humans is one primitive across all three. Workforce uses it for internal IAM (web surface plus the recovery, voice, frontline, and people surfaces). B2B uses it for vendor and partner staff authenticating into your tenant (same primitive, federated trust roots between organizations). D2C and consumer-facing customer auth use it as the consumer passwordless layer (One Tap mobile, QR desktop, biometric workstation, no-phone fallback). The primitive doesn't change as the audience does.
What happens if the user loses every device?+
The recovery flow runs across the surfaces they still have access to. Cross-surface signed recovery: the user's registered phone is challenged (voice surface) and verified by signed event, not by KBA. A designated peer at the organization is challenged (people surface) and verifies in person or via video with the selective-disclosure peer-verification primitive. Both events sign cryptographically. New device enrolled. Old keys revoked. The helpdesk never has to vouch for an unknown caller.
How does this interact with deepfakes on voice or video?+
Voice biometrics fail against deepfakes that public-cloud APIs can produce. Real-time video deepfakes fail visual identity confirmation. ScrambleID doesn't authenticate the waveform or the face; it authenticates the device-bound signed event. The caller's phone signs a cryptographic challenge. The peer's phone signs a verification event. A deepfake of the voice or the face doesn't produce a signature. Deepfake-resistance comes from the cryptographic primitive, not from voice or video forensics.
What's the per-authentication latency budget?+
Signing and verification fit inside the existing auth-event latency budget. Local device signing is sub-100ms on modern phones and workstations. Server-side verification is sub-10ms. The full signed event lands in your IdP's existing auth-event timing window without adding visible delay to the user.