Skip to main content

​
Presence Continuity

Presence Continuity is a Phase II capability delivered by SDK B (Presence SDK) and is not enabled by default today. Only SDK A (BotShield SDK) is generally available. Do not represent Presence Continuity as available right now.
Presence Continuity is an advanced capability that reduces repeated human verification for supported, low-impact actions while preserving full platform enforcement control. It lets a verified user pass through eligible actions without a fresh biometric prompt — without weakening the security model and without any identity crossing the partner boundary.

​
How it works

Presence Continuity has two halves, and keeping them separate is the whole design:
  • Eligibility is global. A user becomes eligible for Presence Continuity once they have established durable presence across the BotShield ecosystem — anchoring three distinct platforms (Connected Accounts) is the canonical eligibility bar. Eligibility is a property of the user, computed at the BotShield layer.
  • Consumption is local and action-scoped. Even when a user is eligible, each platform decides — per action — whether to consume continuity or require fresh presence. Continuity is never forced on a partner; it is an option the platform opts into for the specific low-impact actions where it makes sense.
This mirrors the action-scoped enforcement principle: nothing is session-wide. Each action is evaluated on its own.

​
Security guarantees

Presence Continuity never softens the guarantees a platform depends on:
  • High-impact actions always require fresh verification — payments, withdrawals, account changes, and any action a partner classifies as elevated always demand a live hardware-backed presence check, regardless of continuity state. This is locked.
  • No trust inheritance across partners — one platform’s continuity does not grant trust on another. Consumption is local.
  • Time-bound, not permanent — continuity decays as the underlying durability decays. There is no permanent reduced-friction state.
  • Device passcode still required — the device must maintain a secure lock state at all times. See Device Security.
  • No identity at the boundary — continuity changes how often a verified user is re-prompted, never what a partner learns about them. Partners still see only anonymous result states.

​
Relationship to MultiPass

In production today, the equivalent reduced-friction behavior for returning users is provided by MultiPass freshness — an active MultiPass keeps a user in a pass state within its freshness window without re-prompting. Presence Continuity (SDK B / Phase II) generalizes that behavior into a per-action capability that platforms consume selectively. See Signal Durability for the freshness mechanism that drives MultiPass today.

​
Relationship to SDK A

SDK A (BotShield SDK) does not expose Presence Continuity controls. Returning-user friction is already handled for SDK A integrators via MultiPass freshness. Continuity as a consumable, per-action capability is exclusively an SDK B / Phase II feature.

​
Coming in Phase II

Presence Continuity ships with SDK B. Contact us for early-access information.