Security is not a feature.
It is the foundation.

Passkey-only: purpose, retention and return to password login

Prepared operating-policy addition, 8 October 2026. This describes the intended contract for the approved rollout; it does not assert that the remaining functions are already available or grant legal, release or activation approval.

During passkey-only, existing native and imported password verifiers are blocked and retained solely for a possible return to password login. They remain in their original storage; no separate password archive is created. Retention is not an additional recovery method and never authorizes a password-only bypass.

The original recorded activation starts a 30-day period of exactly 720 hours. A bounded automatic deletion process removes the retained old verifiers from active storage from the end of that period only while the same activation remains enabled. Saving or retrying an enabled policy does not extend it. If an older activation has no evidenced start, its age is unknown; deployment time is not used to invent a deletion deadline.

Switching passkey-only off before deletion makes surviving original verifiers usable again under the normal account and authentication checks. A later genuine activation starts a new period. Switching off never restores deleted password material or revoked sessions and tokens. Deletion ends the old-password return path; access through passkeys and configured recovery remains.

A user with a currently usable passkey and configured recovery can request deletion of their own old password at any time within this retained-password contract. After policy OFF, this requires proof that the unchanged password stock predates the original activation; new OFF passwords or unproven history are refused. An authorized tenant admin can deliberately remove retained verifiers early while passkey-only is active, with audit. The irreversible effect on the password return path is explained beforehand and requires explicit confirmation. This process does not silently remove the only current login factor outside the retained-password contract.

New accounts created through a passkey-only path receive no password. New tenants still start with passkey-only disabled; enabling it remains an explicit tenant decision subject to readiness checks.

Separate, restricted deletion records contain account and tenant identifiers, comparison identifiers for removed verifiers and original activation and deletion metadata, not reusable password verifiers. They prevent removed material being accepted again even after account deletion. These are personal security records, not anonymous data. The prepared technical implementation has no automatic expiry or deletion process for these records. The 720-hour period for old password verifiers is not a claim that these records are erased at the same time; their purpose and retention must be assessed separately before release.

Deleting active database rows does not immediately remove copies from existing encrypted backups; those copies follow the actual backup-retention policy. A restore must remain isolated from authentication and writers until original deletion records, activation state and revocations have been reconciled. Restoring a complete old backup that discards the deletion history cannot be made safe by the cleanup worker alone. It must not silently reactivate deleted verifiers or revoked sessions and refresh tokens.

The intended session rules end all other user sessions and refresh tokens after recovery setup, and all non-passkey sessions and tokens in the tenant on opt-in. Returning the policy to off does not revive them. Only Tuurio performs an application rollback: commit policy off, stop affected writers, end the specifically affected sessions, then restore the recorded prior application image. A backup restore and an application-image rollback are different operations.