RGN.
MarTech Architecture

WhatsApp account security: verification, passkey și recovery governance

De Razvan G. NiculaeRevizuit 2026-09-22NIC-06179

Răspuns scurt: Pentru WhatsApp account security: verification, passkey și recovery governance, controlul util nu este un checklist generic, ci o legătură verificabilă între account, device, ACCOUNT_VERIFIED și outcome-ul downstream. Sursa stabilește ce declară provider-ul; decizia operațională se închide numai după reconciliation în sistemul care deține rezultatul.

Ce documentează sursa în prezent

WhatsApp announced stronger two-step verification, additional context for calls from unknown contacts and support for multiple passkeys, while retaining end-to-end encryption as a core account-security context.

A security feature reduces or changes specific risks; it does not guarantee that an account cannot be compromised, socially engineered or recovered incorrectly.

Name the decision

Definește exact ce decizie poate schimba account și cine o deține. device trebuie să identifice obiectul asupra căruia acționezi, iar two-step state trebuie să arate dacă acel obiect este eligibil în momentul deciziei. Pentru WhatsApp account security: verification, passkey și recovery governance, o stare vizibilă în UI nu este suficientă dacă downstream system nu confirmă același obiect și aceeași fereastră temporală.

Capture source truth

Păstrează un ledger în care provider statement, local observation și external receipt sunt câmpuri diferite. Leagă passkey de source URL și retrieval time, iar recovery channel de evidence-ul observat local. Când cele două nu sunt de acord, verdictul rămâne NOT_VERIFIED; repetarea aceluiași provider statement nu produce independent evidence.

Track state movement

Modelează lifecycle-ul ca tranziții explicite, de exemplu ACCOUNT_VERIFIED → TWO_STEP_ENABLED → PASSKEY_ENROLLED. Tranziția către UNKNOWN_CALL_REVIEW trebuie să aibă un trigger și un receipt, nu doar un timestamp. Dacă unknown-caller signal se schimbă între două tranziții, păstrează ambele versiuni și marchează ce regulă a fost activă la fiecare pas.

Escalate mismatches

Routează cazurile neclare către un owner, nu către o presupunere. Un mismatch între device și passkey, un trusted device stale sau lipsa recovery channel trebuie să producă REVIEW_REQUIRED. Documentează deadline-ul, escalation path și acțiunea permisă cât timp cazul este deschis; astfel fallback-ul nu devine silent success.

Check authoritative completion

Alege sistemul authoritative pentru completion. Dacă provider-ul afișează PASSKEY_ENROLLED, verifică separat authentication event sau receipt-ul downstream înainte să închizi cazul. Reconciliation trebuie să spună ce s-a potrivit, ce a rămas pending și ce diferență de timp este acceptată între platform state și real-world completion.

Quantify staged evidence

Măsoară separat availability, attempted action, successful execution și business outcome. Pentru acest topic, compromise signal and recovery outcome poate fi un signal util, dar nu trebuie agregat automat cu account. Dacă vrei să afirmi impact, păstrează measurement window, denominator, cohort și metoda de comparație; altfel etichetează rezultatul drept observational.

Simulate breakdowns

Rulează un failure drill specific riscului documentat: A security feature reduces or changes specific risks; it does not guarantee that an account cannot be compromised, socially engineered or recovered incorrectly. Simulează cel puțin un caz de stale state, wrong identity și missing receipt. Verifică dacă sistemul intră în review, dacă owner-ul primește context suficient și dacă poate reveni la o stare sigură fără să piardă provenance.

Keep an audit packet

Review packet-ul trebuie să poată fi citit fără conversația originală: title/version, account, device, sursa, provider wording, starea ACCOUNT_VERIFIED, tranzițiile observate și verdictul final. Include și ce NU a fost verificat. Asta împiedică un reviewer ulterior să transforme un artifact static în runtime truth.

Stop on missing evidence

Oprește automat inferența când sursa se schimbă material, two-step state nu mai este eligibil, trusted device expiră, identity mapping devine ambiguu sau authentication event lipsește. Stop condition-ul nu este failure al produsului; este protecția care păstrează concluzia proporțională cu evidence-ul disponibil.

Decision discipline

Regula finală pentru WhatsApp account security: verification, passkey și recovery governance: provider capability ≠ authorized action ≠ verified execution ≠ downstream outcome. Închide cazul numai când account, device și receipt-ul pentru PASSKEY_ENROLLED pot fi reconciliate. Până atunci, păstrează uncertainty explicită și nu generaliza rezultatul către alte accounts, markets, devices sau cohorts.

Governance states

Folosește stări explicite precum:

Surse revizuite