How ScrambleID Proof composes with your identity stack.

ScrambleID layers on top of the customer's existing IdP (Okta, Microsoft Entra ID, Ping Identity, ForgeRock). The IdP remains the system of record for identity, group membership, and access policy. The directory stays. The SSO stays. Sessions are still issued by the IdP. ScrambleID adds the cryptographic authentication ceremony itself: WebAuthn or QR-based Dynamic Identifiers for Web; spoken Type Codes for Voice; device-API tokens for Frontline; People helpdesk and verifier ceremonies; Customer login flows. Non-humans (AI agents and machines) authenticate through the same Verification Service via mTLS plus signed JWT. Federation happens via OIDC or SAML 2.0. What gets replaced is the password, the OTP, the KBA, and the helpdesk verification flow that an attacker can social-engineer.

The Customer channel applies the same Verification Service primitive to consumer-facing flows: account creation, login, account recovery, high-risk transactions. The customer's IdP can be a customer-identity (CIAM) deployment of Okta, Entra External ID, Auth0, ForgeRock, or a custom CIAM stack. Federation is identical (OIDC or SAML 2.0); ceremony surfaces are identical (passkeys, WebAuthn, QR). The distinction is the IdP topology and the user-management policies, not the cryptographic shape.

The overlay placement supports gradual migration without a flag-day cutover. Customers configure ScrambleID as one of multiple authenticators in the IdP's authentication policy engine (Microsoft Conditional Access, Okta Authentication Policies, Ping Sign-On Policies, ForgeRock journeys), route specific user populations or specific applications to ScrambleID first, and progressively expand coverage. Legacy MFA continues to work for users not yet enrolled. Production cutover happens per the customer's deployment schedule, not per a ScrambleID timeline. The deployment patterns in the Learn hub document phased rollout strategies for each major IdP.

Managed cloud service. Multi-tenant by default. Dedicated single-tenant instances are available for regulated customers (financial services, healthcare, government). On-prem and air-gapped deployments are not currently offered; the platform's value depends on shared infrastructure for cross-tenant signal correlation (Overwatch risk monitoring) and rapid security updates. SDKs for iOS, Android, and Web. RESTful APIs for server-side integration. Federation via SAML 2.0 and OIDC. Sandbox tenants are available to evaluators.

No. ScrambleID never receives, stores, or processes biometric templates. Biometric unlocks happen entirely on the user's device, inside the secure enclave provided by the operating system. The biometric event releases a cryptographic key that signs an assertion. Only the signed assertion leaves the device. ScrambleID sees proof that authentication happened; it never sees the face, fingerprint, or biometric template that produced it. This is a hard architectural property, not a policy commitment.

The user re-enrolls a new device through the warm path (recovery from another enrolled device, if the customer policy allows) or the cold path (identity proofing with documented evidence per customer policy). At re-enrollment, the lost device's enrolled key is revoked; subsequent authentication attempts from the old device fail. Customer policy controls the proofing evidence required, the helpdesk involvement, and the cooling-off period before the new enrollment becomes active. The recovery and fallback playbook in the Learn hub covers the design patterns and the anti-patterns that turn re-enrollment into a new attack surface.

End-to-end authentication time is dominated by user actions (unlocking the device, tapping confirm) rather than network round-trips. Server-side verification of a WebAuthn assertion or signed Dynamic Identifier completes in tens of milliseconds. The full flow, including user interaction, typically resolves in under one second for same-device passkey login and a few seconds for cross-device QR or Voice channel verification. Customers see authentication time drop relative to prior KBA or password-plus-OTP flows; the time savings show up directly in contact center handle-time numbers and employee login completion rates.

Service availability and user-facing failure recovery are two separate concerns. Service availability: ScrambleID runs as a managed cloud service with active-active deployment across seven regions and a 99.95% contractual SLA. Failure of a single region does not take down authentication for tenants in other regions; routing shifts automatically. For the unlikely scenario of total service unavailability: customers configure graceful-degradation policies in advance, defining which authentication methods to allow during a ScrambleID outage. The recovery and fallback playbook in the Learn hub covers the threat model, the design patterns, and the anti-patterns that turn fallback into a new attack surface.

ScrambleID runs as a managed cloud service with active-active deployment across seven geographic regions (US East, US West, Canada, EU, UK, Australia/NZ, Latin America). Authentication requests route to the nearest healthy region. Tenant data is replicated across regions with strong consistency for the authentication state machine and eventual consistency for non-critical metadata. Regional failure does not require tenant action; routing shifts automatically in sub-minute time.

A public status page reports service health per region in real time. Major incidents trigger customer notifications via email and webhook to the configured incident contact. Postmortems for major incidents are published; specific timing is in the contract. SLA credits, where applicable, are applied automatically; customers do not need to claim them. The incident response process is documented in the security packet under NDA.

ScrambleID's threat model addresses the attack surface around the authentication ceremony itself: phishing in any form, AI deepfake voice cloning, SIM swap, credential stuffing, OTP intercept, helpdesk social engineering, MFA fatigue, replay, relay, and session hijacking on the verification path. Out of scope: compromise of the customer's own IdP, compromise of the customer's application servers, and physical compromise of an enrolled user device with biometric coercion. The trust model in Section 03 above defines the boundary; what ScrambleID controls, ScrambleID secures. The full threat model with attack tree analysis is available in the security packet under NDA.

ScrambleID is multi-tenant by default with logical tenant isolation enforced at every layer: the verification state machine, the database schema, the API surface, and the audit store. Tenant identifiers are bound to the verification session at issuance and verified on every subsequent operation. Cross-tenant queries are not exposed by any API. Cross-tenant Overwatch risk signals are aggregated to the tenant level only; raw events from one tenant are never exposed to another. Dedicated single-tenant deployments are available for regulated customers requiring physical isolation.

ScrambleID administrators authenticate to the platform using the same Verification Service that protects customer flows: passkeys or hardware-bound credentials, no shared secrets. Dual-control approval (Lockstep) is configurable for high-risk administrative actions like policy changes, tenant configuration, and key rotation. Every administrative action emits a tamper-evident audit record exported to the customer's SIEM. ScrambleID staff access to tenant data follows documented break-glass procedures with customer pre-authorization required.

Every authentication event, every administrative action, and every configuration change emits a structured audit record. Records include timestamp (with monotonic sequence), tenant identifier, channel, intent, request origin, verification result, ceremony type, and policy decision. Records are tamper-evident, signed, and chained. Export is available via SIEM-compatible streaming (Splunk HEC, Elastic, generic syslog) and via webhook event stream. Retention is configurable per tenant. The full event schema is documented in the API reference.

Section 04 above enumerates every standard with its spec body and implementation scope. ScrambleID primitives support NIST SP 800-63-4 AAL2 and AAL3 designs when configured per NIST guidance. The compliance mapping article in the Learn hub covers the specific NIST 800-63 and 800-53 control mappings auditors typically request.

Cryptographic primitives in the Verification Service are abstracted behind a verifier layer so algorithms can migrate without re-enrollment. ScrambleID's PQC roadmap tracks NIST PQC standardization and FIDO Alliance guidance for WebAuthn hybrid schemes. Once the FIDO2 hybrid signature scheme is finalized, it becomes the default for new enrollments. Existing enrollments migrate through scheduled key rotation.