> ## Documentation Index
> Fetch the complete documentation index at: https://docs.botshield.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Presence Continuity

> A Phase II capability that reduces repeated verification for low-impact actions while preserving full platform enforcement control.

# Presence Continuity

<Warning>
  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)](/sdk/overview) is generally available. Do not represent Presence Continuity as available right now.
</Warning>

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](/concepts/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](/concepts/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](/concepts/signal-durability) for the freshness mechanism that drives MultiPass today.

## Relationship to SDK A

[SDK A (BotShield SDK)](/sdk/overview) 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](https://botshield.ai/pricing) for early-access information.

## Related

* [Presence Anchors](/concepts/presence-anchors) — deprecated; the durable-trust model is now MultiPass + Verified Signal
* [Signal Durability](/concepts/signal-durability) — the MultiPass freshness mechanism available today
* [Human Presence](/concepts/human-presence) — core presence concepts and Census result states
* [Device Security](/concepts/device-security) — hardware-backed security requirements
* [SDK Overview](/sdk/overview) — current API architecture