No questions. No scripts. No fakes.

STIR/SHAKEN authenticates the calling number at the network level; ScrambleID authenticates the person on the line. They solve different problems. ScrambleID treats network-level number attestation as a context signal for account lookup, not as identity.

Device compromise is the residual threat after every other attack surface is gone. The verification is bound to the device's secure enclave: an attacker needs physical access plus the user's biometric or PIN. Lost or stolen devices are revoked through identity proofing, not by guessing security questions. Auditable, attributable, revocable.

Yes. The push rides standard mobile push infrastructure (APNs, FCM) and doesn't depend on the calling network. The speak-code fallback works on any voice line. Localization is configurable per deployment.

Yes. ScrambleID for the voice channel is one verification layer across all three. Enterprise contact centers use it for internal helpdesk calls and IT-support flows where employees authenticate before any privileged action. B2B helpdesks use it for customer-organization-to-vendor calls where the caller represents an enterprise account, with the same primitive applied to the named caller rather than the calling number. Consumer-facing call centers use it for high-value account recovery, password reset, and large-transaction verification, where deepfake voice clones and vishing are the residual attack surface. Five9, Genesys, NICE, Twilio, and Google CCAI integrations run all three contexts on the same cryptographic primitive. No deepfake survives the math regardless of who's calling.

The agent's screen shows the state explicitly: verified, not verified, in-progress, timed out. Policy decides what each state means. Typical configuration: verified callers proceed normally; unverified callers go through higher-friction identity proofing before the agent takes any account-changing action. The question isn't whether to take the call. It's what an unverified caller is allowed to do.

Days to a working pilot. Weeks to production. The IVR side is a few webhook calls (start a session, wait for confirmation, redirect the call). The mobile side is the ScrambleID app, typically embedded in your existing customer-facing app. Deep CCaaS integrations (NICE, Twilio, Google CCAI) include screen pop; without one, a few hours of work delivers the same.

Every verification produces a signed, timestamped record bound to the call session, the user account, and the registered device. Streamable to your SIEM or data lake. Persists per your retention policy. The reference architecture page covers the full audit format and compliance posture.

As a passive confidence signal, yes. Voice biometrics adds or subtracts trust from a session already verified cryptographically. Making it a layered signal rather than the load-bearing factor is what defangs deepfake risk.

Agents learn one thing: read the verified status before you speak. No new screens, no new scripts, and KBA goes away. Training delta is hours, not days. Most leaders report training time decreases overall because the failure modes (frustrated callers, agent confusion, escalations on KBA fails) disappear with the controls.

The fast path requires the app. The fallback path works without it: the IVR speaks a code, the caller enters it into a web or browser confirmation surface. Adoption climbs fast when the ScrambleID flow is embedded inside the existing customer-facing app rather than asking customers to install something separate.

ScrambleID overlays your IdP. It doesn't replace Okta, Microsoft Entra, Ping, or ForgeRock. Sessions are still issued by your IdP; policies still enforced by your authentication policy engine. What ScrambleID replaces is the brittle verification step at the moment a caller is challenged. The architecture page covers the overlay model in full.