Passwords are still the most common path into a breach. Passkeys help where they reach. ScrambleID for the web surface reaches everywhere else: cross-device sign-ins, shared terminals, users without mobile devices, and the voice, agent, and frontline surfaces web alone can't cover.
One Tap Login on a mobile site. QR scan from a phone to a desktop. A short code typed into a desktop client. A native biometric on a workstation. A PIN on any of them. Every modality produces the same signed authentication record. Same origin binding, same session binding, same cryptographic guarantees, regardless of how the user gets there.
One Tap Login
Mobile site . Mobile app
Single tap on a mobile site. Native biometric unlocks the key. Done.
QR Scan
Desktop site . Mobile app
Browser displays a signed QR. Phone scans. Browser session binds to the signature.
Code Entry
Desktop site . Desktop app
Browser shows a short code. User enters it in the desktop or mobile app. No phone required.
Native Biometric
Workstation . Desktop app
Windows Hello, Touch ID, Face ID. Platform authenticator unlocks the device-bound key.
PIN
Workstation . Mobile app
Numeric PIN as the unlock factor. For users without biometrics or high-assurance environments.
FIVE MODES . ONE SIGNATURE . EVERY DEVICE
A method is phishing-resistant if the user can't be tricked into producing a reusable proof an attacker can replay from another site or session. OTP, push, and SMS codes don't clear that bar. WebAuthn passkeys do. Signed QR with session binding does. Three places web auth still breaks today, and how cryptographic origin and session binding closes each.
THREAT . 01
Modern phishing kits proxy the legitimate site in real time. The user types their password into the proxy. The proxy forwards it. The site sends an OTP or push. The user approves. The proxy captures the session cookie. SMS, TOTP, and push approval all fall to this. Cryptographic origin binding (passkeys + ScrambleID's signed QR for the web surface) refuses to authenticate to the wrong origin.
THREAT . 02
Public data dumps put billions of email + password pairs in circulation. Stuffing tools try them at speed. Even password complexity rules don't help when the password reuses the one that already leaked. The fix isn't a stronger password. It's removing the password from the auth path entirely. No password to stuff means no credential stuffing.
THREAT . 03
When passkeys close the front door, attackers move to the recovery flow. Vish the help desk, claim the device is lost, get a reset link or temporary credential, register a new device. This is the largest post-passkey ATO surface today. The fix isn't a better password question. It's verifying the caller cryptographically (voice surface) and verifying the in-person identity (people surface) before any reset is granted.
A consumer signing in on a phone, a worker signing in at a shared workstation, and a recovery flow when the user has nothing left to authenticate with. Three contexts that look completely different on the surface and use the same cryptographic primitive underneath.
SCENARIO . 01
A user opens their bank's mobile site. They tap "Sign in with ScrambleID." The phone's biometric unlocks the device-bound key. The signature returns. They're in. No password to type, no code to enter, no app to switch to. The full auth event takes well under a second of perceived effort.
SCENARIO . 02
A worker walks up to a shared workstation, taps the ScrambleID button, and either scans the on-screen QR with their phone or completes Windows Hello / Touch ID locally. Either path produces a per-user signed authentication, attributable to the actual person who walked up, not to a shared station account. The next worker walks up and does the same. No shared password, no terminal handoff.
SCENARIO . 03
A user calls the help desk. Their phone is lost. Their laptop is locked. Their backup codes are at home. The help-desk agent does not reset the account on the strength of a sympathetic story. The system routes the call into ScrambleID's voice surface for caller authentication, then escalates to ScrambleID's people surface for in-person identity verification. Only after both pass is a new device registered. The recovery flow stops being the soft underbelly.
Two questions every CISO asks in the first thirty seconds. ScrambleID for the web surface answers both. The recovery flow uses the same cryptographic primitive as the front-door auth, routed through voice and people surfaces for caller and in-person verification. The deployment pattern federates into Okta, Entra ID, or Auth0 as an upstream authenticator. No rip-and-replace. No second control plane. Production timelines measured in weeks.
// Okta + ScrambleID web surface . upstream authenticator// federation: ops/idp/scrambleid-web.oidc authenticator ScrambleIDWeb {type: "OIDC",issuer: "https://auth.scrambleid.com",client_id: "acmebank-prod",scopes: ["openid", "profile"],signing_alg: "EdDSA"} policy PrimaryAuth {when "web sign-in" => ScrambleIDWebwhen "recovery" => ScrambleIDWeb + CrossSurface}
deployment hash . sha256: 7e2b c1f4 a8d9 0613 . pinned for the rollout window
PASSWORDS + MFA
Password + OTP or push. Both phishable via AiTM proxy.
PASSKEYS
Phishing-resistant on the device. No story for cross-device, shared terminal, or voice.
PUSH / TOTP
Better than nothing, but the auth path still has a phishable factor.
Cryptographic, multi-modal, cross-surface. ScrambleID for the web surface is the only row with all three.
Five primitives . one row holds the line
Swipe sideways to compare. ScrambleID is the highlighted column.
| Method | Phishing-resistant | Multi-modal | Works without a mobile device | Cross-surface | Recovery without help-desk weakness |
|---|---|---|---|---|---|
| Passwords + MFAPassword plus SMS OTP or push approval | NoAiTM proxies relay both factors in real time | NoSingle mode: type and approve | PartialSMS works, push doesn't | NoWeb only | NoHelp desk resets, vishable |
| TOTP authenticator appSix-digit codes from Google Authenticator, Authy, etc. | NoCodes are typeable into a proxy site | NoSingle mode: read and type a code | NoRequires the phone with the app | NoWeb only | NoHelp desk resets, vishable |
| Push notification approvalTap to approve a sign-in attempt | NoApprovals can be relayed; MFA fatigue is a real attack pattern | NoSingle mode: tap to approve | NoRequires the phone with the app | NoWeb only | NoHelp desk resets, vishable |
| Passkeys (FIDO2 / WebAuthn)Cryptographic credentials synced or device-bound | YesOrigin-bound, defeats AiTM proxies | NoDevice-native biometric or PIN, single modality | NoNo native cross-device fallback for shared terminals | NoWeb and app only; no voice, agent, frontline | PartialHelp desk recovery is the residual surface |
| Web surfaceCryptographic, multi-modal, cross-surface by design | YesOrigin and session bound on every modality | YesOne Tap, QR, code, biometric, PIN | YesDesktop app handles the no-phone case natively | YesSame primitive on voice, agent, frontline | YesCross-surface verification before any reset |
ScrambleID for the web surface fits a consumer-facing login flow, a B2B SaaS workforce, and an enterprise IAM control plane on the same primitive. The auth event looks the same to your engineers and to your auditors regardless of who's signing in. What differs is the deployment shape, the IdP integration pattern, and which AI workflows the rollout makes possible.
DEPLOYMENT . 01
Replace passwords on consumer-facing web apps. Banks, retailers, content platforms, B2C SaaS. One Tap on mobile, QR for cross-device, code entry for users without smartphones. Synced passkeys for users who have them. Recovery uses ScrambleID's omnichannel architecture, so help-desk ATO stops being the residual surface. Conversational interfaces and embedded AI assistants stop breaking on a password field.
DEPLOYMENT . 02
Federate into Okta, Entra ID, Ping, or Auth0 as an upstream authenticator. End users sign in to internal apps with the same primitive that runs your customer-facing login. No rip-and-replace. No second control plane. Drops in alongside the IdP your team already runs. The auth front door stops being the thing that breaks the AI's flow.
DEPLOYMENT . 03
Large-scale workforce, mixed device fleets (managed laptops, BYOD phones, shared kiosks, clean rooms), CISO and IAM-architect-led deployments. Same primitive across every mode and surface. Native MFA, defensible recovery, cross-surface attribution. The AI roadmap stops stalling in security review for want of a production-ready front door.
Edge cases
// what about users on a public or shared computer?
Cross-device QR is the canonical path. Browser displays a signed QR. The user's phone scans it. The authentication is bound to the browser session that initiated it. Public computers can't replay the proof.
// what about users without a mobile device?
Desktop client is the path. ScrambleID for Windows or macOS handles the auth via native biometric (Windows Hello, Touch ID) or PIN. Code entry covers users without biometrics. No phone required.
// does this work on tablets?
iPadOS and Android tablets fully supported. Same modalities as on a phone. One Tap Login on the tablet's browser, biometric on the device, PIN as fallback.
// what if someone tries to AiTM-relay the authentication?
Cryptographic origin binding refuses. The signature commits to the legitimate origin. A proxy site has a different origin. The signature won't validate when the relayed proof reaches the real site. Same defense passkeys provide, applied to every modality.
// what if a user loses every device they've registered?
Cross-surface recovery: the voice surface verifies the caller cryptographically, the people surface verifies in-person identity. Both signed. Only after both pass does a new device get registered and old keys get revoked.
// what does session security look like after authentication?
The session is bound to the device that produced the signature. Re-auth triggers on configurable events (privileged action, idle timeout, IP change). The auth doesn't expire just because time passed; it expires when something material changes.
ScrambleID for the web surface federates as an OIDC upstream authenticator. Your IdP delegates the primary auth event to ScrambleID, then receives a signed assertion back. No rip-and-replace. No second user directory. Federation setup is configuration, not code. Most pilots ship in weeks.
The mobile site renders a "Sign in with ScrambleID" button. The user taps once. The device's platform authenticator (Face ID, Touch ID, Android biometric) unlocks the device-bound private key. The key signs a fresh challenge over the legitimate origin. The signature returns to the browser. Total user effort: one tap. Behind the scenes, it's WebAuthn-grade cryptography with origin binding.
Five modalities: One Tap Login (mobile site, mobile app), QR scan (desktop with phone, mobile app), code entry (desktop, no phone needed), native biometric (workstation via Windows Hello / Touch ID, desktop app), and PIN (workstation, mobile app, desktop app). The user picks based on what they have available. The site can default to the strongest modality for the device class.
Yes. By design, not by bolt-on. Every authentication combines a cryptographic key (something the user has, bound to a specific device) with an unlock factor (biometric or PIN, something the user is or knows). Two factors, on every authentication, in every modality. No separate TOTP app to install, no SMS code to relay, no push to spam.
iPadOS and Android tablets are fully supported. All modalities work: One Tap Login in the tablet's browser, biometric unlock on the device, QR scan from a paired phone if both devices are in use, PIN as a fallback. Same primitive, same UX, same cryptographic guarantees as on a phone or desktop.
Desktop client handles the no-phone case. ScrambleID for Windows or macOS authenticates the user via native biometric (Windows Hello, Touch ID) or PIN. The site shows a short code instead of a QR; the user enters the code in their desktop client. No phone required at any step.
ScrambleID for the web surface supports WebAuthn-grade passkeys natively. Users with synced or device-bound passkeys keep using them; ScrambleID orchestrates the auth event and surfaces the right modality based on device context. Where passkeys can't reach (cross-device, shared terminals, no-mobile users, voice, agent, frontline), ScrambleID covers the gap with the same proof model.
Cross-surface verification. The voice surface cryptographically verifies the caller (defeats vishing). The people surface cryptographically verifies in-person identity (defeats sympathetic-story social engineering). Both signed. Only after both pass does a new device get registered and old keys get revoked. Help-desk-driven recovery stops being the residual ATO surface.
Pilot: install the SDK, configure the OIDC federation with your IdP, enroll a pilot cohort. Time to first authenticated user: hours to days. Production: extend to your full user base, route recovery flows across surfaces, integrate with your SIEM. Time to full production: 4-6 weeks for most B2B deployments. Phased D2C and enterprise rollouts run on quarterly cycles.
Yes. ScrambleID for the web surface is one cryptographic auth layer across all three. Enterprise apps use it for workforce login over OIDC federation with Okta, Microsoft Entra, or Auth0. B2B partner portals use it for federated partner authentication, supplier extranets, and contractor access with the same primitive your IdP already federates. Consumer apps use it for passwordless customer sign-in and account recovery across web and mobile, with One Tap Login on devices that have it and code or biometric fallbacks where they don't. Same five modalities, same WebAuthn-grade origin binding, same recovery path. No separate stacks for each audience.
Same cryptographic primitive, same identity binding, same key material. A user enrolled in ScrambleID for the web surface can authenticate to a contact-center call (voice surface), to an autonomous agent action (agent surface), or to a shared workstation (frontline surface) without re-enrolling. The control plane is unified; the audit model is unified; the user experience is consistent across every surface they touch.
On the web, the biometric approval is a person consenting.
It's how a human stays in the loop when an agent acts: you sign exactly what will run, not text an agent fed in. On the auth path, no approval, no token.
How the rail gates an actionVOICE SURFACE
When the call sounds right but isn't
Deepfake-resistant voice authentication for contact centers and helpdesks. Closes the recovery-flow vishing surface.
PEOPLE SURFACE
Verifying strangers in 5 seconds
Selective-disclosure peer-to-peer ID for in-person identity verification. The other half of the recovery story.
NON-HUMANS
Per-agent identity. Per-call signature. Zero static secrets.
Cryptographic authentication for AI agents, RPA bots, M2M services, and service accounts. The non-human half of the trust chain.
Your AI roadmap stalls where the login still phishes. Proof is how it ships.
Pilot in days. Production in weeks. One identity primitive across every browser, every device, every surface your users sign in from.
Pilot ScrambleID →