استعادة حساب الطفل ومنع الاستيلاء عليه: كيف نعيد السيطرة دون فتح باب جديد للمعتدي؟

استيلاء شخص على حساب طفل لا يعني فقط فقد كلمة المرور. قد يقرأ رسائل خاصة، ينتحل الطفل أمام أصدقائه، يغير البريد والرقم، يحصل على صور أو location history، يرسل طلبات مالية، أو يستخدم الحساب للوصول إلى أطفال آخرين لأن الأصدقاء يثقون به. الاسترداد نفسه يمكن أن يصبح نقطة خطر إذا كان رقم الهاتف بيد شخص مسيء أو كان ولي قديم يسيطر على family account. لذلك تحتاج المنصة إلى مسارين متكاملين: منع takeover قدر الإمكان، ثم recovery يثبت السيطرة بأقل بيانات ويطرد الجلسات المشبوهة ويعيد إعدادات السلامة ولا يسلم الحساب تلقائيًا لمن يملك credential واحدًا قديمًا.

كيف يحدث takeover؟

أسباب شائعة تشمل كلمة مرور معاد استخدامها، phishing، سرقة session cookie، جهاز ضائع، SIM swap، بريد استرداد مخترق، تطبيق طرف ثالث، أو شخص يعرف الجهاز والرمز. لدى الطفل أيضًا مخاطر اجتماعية: مشاركة كلمة المرور مع صديق أو شريك، أو حساب عائلي لا يفصل الأدوار. لا تبدأ من افتراض «الطفل أعطى كلمة المرور»؛ افحص القناة والوقت والجلسات والتغييرات.

credential واحد لا يساوي هوية كاملة

رقم الهاتف قد يتغير أو يُنقل، والبريد قد يكون قديمًا، والجهاز قد يكون مشتركًا. recovery الجيد يجمع إشارات متناسبة بدل الاعتماد على معلومة واحدة في الحالات عالية الخطورة. لكن لا يتحول ذلك إلى طلب عشر وثائق لكل طفل. استخدم stepped verification: الطرق الأخف للحالات العادية وتصعيدًا أكثر حماية عند تغيير كل عوامل الاسترداد أو وجود بلاغ إساءة.

كلمات المرور: لا تجعل التعقيد يدفع الطفل لإعادة الاستخدام

اتبع ممارسات حديثة مثل السماح بعبارات مرور طويلة وعدم فرض تغييرات دورية بلا سبب، ومنع كلمات المرور الشائعة والمخترقة، ودعم password managers. لا تطلب قواعد معقدة تجعل الطفل يكتب كلمة المرور في مكان مكشوف. NIST في إرشادات الهوية الرقمية الحديثة يركز على طول مناسب وقوائم block للسرية الضعيفة بدل قواعد تركيب مرهقة وحدها.

MFA للحسابات الصغيرة

وفر MFA بطرق تناسب العمر والسياق: authenticator، passkey، security key، أو إشعار موثوق. SMS أفضل من كلمة مرور وحدها في حالات كثيرة لكنه أضعف أمام SIM swap وبعض الهجمات. لا تجعل MFA يعتمد دائمًا على هاتف ولي إذا كان الطفل يحتاج استقلالًا أو توجد مخاطر أسرية. وفر recovery codes أو بديلًا محميًا بطريقة مفهومة.

Passkeys: تقلل phishing لكن recovery يبقى مهمًا

passkeys تقلل خطر phishing لأنها مرتبطة بالخدمة والجهاز أو مدير الاعتماد، لكنها لا تمنع فقد الجهاز أو سوء إدارة family account. اشرح للطفل أين تُحفظ passkey وكيف ينقلها أو يلغيها، وراجع الأجهزة المرتبطة. لا تقدم passkey كحل يلغي الحاجة لمسار recovery أو session management.

الجلسات: كلمة المرور الجديدة لا تكفي دائمًا

بعد استرداد الحساب، اعرض الأجهزة والجلسات النشطة مع وقت وموقع تقريبي عند الحاجة، واسمح بتسجيل الخروج من الكل أو من جهاز محدد. revoke tokens القديمة عند تغيير أمني مهم. لا تعرض location دقيقًا قد يكشف معلومات للمعتدي إذا ما زال داخل الحساب. استخدم وصف جهاز ووقت يساعد الطفل على التعرف دون تفاصيل تقنية معقدة.

إشعار التغييرات الحساسة

أرسل إشعارًا إلى القنوات القديمة والجديدة عند تغيير البريد أو الرقم أو MFA أو password أو recovery contact، مع خيار «لم أقم بهذا». لا تكشف العنوان الجديد كاملًا للقناة القديمة؛ استخدم masking. أضف delay أو review لتغييرات شديدة الحساسية في حالات خطر معروف، لكن لا تجعل التأخير يمنع طفلًا من الهروب من شخص مسيء يملك القناة القديمة.

الحساب العائلي: من هو الولي ومن هو مالك الحساب؟

افصل guardian role عن account ownership. ولي قد يدير purchase أو age settings لكنه لا يحتاج قراءة كل رسائل المراهق. عند تغير الحضانة أو الأسرة، لا تسلّم الحساب تلقائيًا لأي بالغ يثبت صلة قديمة. ضع process لتغيير guardian مع مراعاة القانون وأفضل مصالح الطفل، وخصوصًا عند وجود عنف أو أمر حماية.

ولي مشتبه به ليس قناة recovery آمنة

إذا أبلغ الطفل أن وليًا أو بالغًا مسيئًا يسيطر على الهاتف أو البريد، لا ترسل كل إشعارات الاسترداد لنفس القناة. وفر safeguarding escalation وقناة بديلة بحسب العمر والقانون. يمكن إشراك مختص أو جهة موثوقة بدل إجبار الطفل على مواجهة الشخص. هذه حالة استثنائية تحتاج حوكمة لا زرًا آليًا فقط.

الأجهزة المشتركة

على tablet عائلي أو جهاز مدرسة، لا تعتبر device possession إثباتًا كافيًا. استخدم profiles منفصلة، قفل التطبيق أو الحساب، وعدم حفظ recovery codes في متصفح مشترك. عند logout من طفل، امسح tokens والبيانات المحلية المناسبة. المؤسسة تستخدم managed accounts بدل حساب واحد لجميع الطلاب.

الجهاز المفقود

وفر مسارًا سريعًا من جهاز آخر: revoke session، تغيير credential، إلغاء passkey أو authenticator المرتبط، ومراجعة التغييرات. لا تطلب من الطفل العثور على الجهاز قبل حماية الحساب. إذا كان الجهاز يحتوي location service، افصل استرداد الجهاز عن كشف موقعه لأشخاص غير مصرح لهم.

SIM swap وتغيير الرقم

رقم الهاتف ليس هو الشخص. عند تغيير SIM أو نقل الرقم، قد تصل codes للطرف الجديد. لا تستخدم SMS وحده لتغيير كل recovery factors في حساب عالي الحساسية. عند إضافة رقم جديد، احتفظ بقناة أخرى لفترة أو اطلب خطوة إضافية. وإذا فقد الطفل الرقم نهائيًا، يجب أن يوجد مسار استرداد لا يعتمد عليه للأبد.

البريد المخترق

إذا كان البريد هو recovery root ثم اختُرق، يمكن للمهاجم إعادة ضبط عدة خدمات. شجع حماية البريد بـMFA، وافحص security events. داخل المنصة، إذا جاء reset من بريد صحيح لكن توجد إشارات takeover مثل تغيير جهاز وبلد ثم رقم، زد friction. لا تستخدم risk signal واحدًا لمنع الطفل نهائيًا؛ وفر manual review.

الدعم البشري: أكبر خطر أن يقتنع الموظف بالمهاجم

social engineering للدعم يمكن أن يتجاوز التقنية. درّب الموظف ألا يغيّر البريد أو MFA بناءً على قصة مقنعة ومعلومة عامة. استخدم script verification، سجل التغييرات، approval إضافي للحالات الحساسة، وحدودًا لما يستطيع موظف واحد فعله. لا تطلب من الطفل إرسال وثائق عبر بريد عادي.

أقل بيانات لإثبات الملكية

استخدم تاريخ إنشاء تقريبي، أجهزة سابقة، recovery method موثوق، transaction identifiers غير كاملة، أو account history وفق المخاطر. إذا احتجت وثيقة هوية في حالات استثنائية، حدد الحقول والاحتفاظ والوصول. طفل بلا وثيقة حكومية لا ينبغي أن يفقد حسابه تلقائيًا؛ وفر بدائل مناسبة للعمر والبلد.

الحساب بعد الاسترداد: لا تعُد لنفس الإعدادات الخطرة

بعد recovery نفّذ safety reset: راجع password/passkey/MFA، sessions، connected apps، privacy، location، phone discovery، blocked users، groups، payment methods، forwarding، recovery contacts. لا تغير كل preferences الاجتماعية بلا إذن؛ ركز على security and safety controls ووضح للطفل ما تغير.

Connected apps وOAuth

المهاجم قد يضيف تطبيقًا أو token يستمر بعد تغيير كلمة المرور. اعرض قائمة connected apps والصلاحيات ووقت الإضافة، واسمح بالإلغاء. revoke high-risk tokens تلقائيًا بعد confirmed takeover. لا تجعل تطبيقًا تعليميًا أو لعبة تحصل على access دائم للبريد أو الملفات أكثر من الغرض.

API keys والبوتات للحسابات الإبداعية

المراهق الذي يدير bot أو قناة قد يملك tokens أو integrations. لا تعرض secrets في واجهة support أو export. عند takeover، rotate keys وwebhooks. هذه الفئة أقل شيوعًا لكنها مهمة للحسابات المتقدمة. وفر توثيقًا مبسطًا لا يفترض أن كل طفل مستخدم عادي.

انتحال بعد فقد الحساب

حتى بعد استعادة الحساب قد يكون المهاجم أنشأ حسابات مزيفة أو أرسل رسائل للأصدقاء. وفر impersonation report وربطًا بالحالة الأصلية. يمكن إشعار contacts الذين تلقوا رسالة احتيالية من الحساب خلال فترة محددة إذا كان ذلك متناسبًا ومتاحًا، دون نشر تفاصيل حساسة عن الطفل.

المحتوى الذي نشره المهاجم

راجع posts وDMs وstories وads وuploads التي حدثت خلال فترة takeover. لا تحذف كل history تلقائيًا قبل أن يعرف الطفل ما حدث أو قبل حفظ ما يلزم لحالة حماية. اعطِ أدوات batch لإزالة محتوى غير مصرح به. إذا نشر المهاجم مادة غير قانونية من الحساب، لا تفترض أن الطفل هو الفاعل؛ افحص session provenance.

المدفوعات والمشتريات

راجع cards وwallet وin-app purchases وgift transfers. جمد وسائل الدفع عند confirmed takeover ووجه الأسرة لمسار dispute. لا تجعل استرداد الحساب مشروطًا بسداد معاملة احتيالية. سجل transaction IDs من دون عرض بيانات بطاقة كاملة لفريق الحماية.

المدرسة والمركز

إذا الحساب مؤسسي، يستطيع admin reset لكن يجب ألا يقرأ المحتوى الخاص بلا سبب. استخدم SSO وMFA للموظفين والطلاب المناسبين، وoffboarding فوريًا. عند takeover لطالب، افصل الحساب عن directory مؤقتًا إذا كان يرسل رسائل للآخرين ثم أعده بعد التحقق. لا تنشئ كلمة مرور مشتركة للصف لتسهيل الدعم.

البلطجة بين الأقران وسرقة الحساب

قد يأخذ زميل هاتف الطفل أو يعرف كلمة المرور وينشر باسمه. تعامل معها كحادث حماية وتنمر لا «مزحة تقنية». استعد الحساب، أزل المحتوى، وثق الضرر، وطبّق سياسة المدرسة. لا تجبر الطفل على مشاركة كلمة مروره مع المعلم لإثبات الحادث.

المعتدي داخل علاقة

مراهق قد يشارك credentials مع شريك ثم يستخدمها الأخير للسيطرة بعد الانفصال. لا تلوم الطفل. غيّر factors، revoke sessions، راجع shared albums/location/password managers، وافصل accounts. إذا توجد تهديدات أو نشر صور، فعّل مسار الإساءة المناسب. recovery يجب أن يدعم الخروج من السيطرة الرقمية.

Account recovery abuse كوسيلة stalking

طلبات reset المتكررة قد تكشف جزءًا من البريد أو الرقم أو ترسل إشعارات مزعجة. لا تكشف إن كان حساب طفل موجودًا عند إدخال email إذا لا حاجة. rate-limit، استخدم generic responses، وراقب abuse. لا تجعل recovery endpoint أداة للبحث عن حسابات الطلاب أو تأكيد رقمهم.

Rate limits لا تمنع الطفل الحقيقي

بعد محاولات كثيرة، قد تقفل الخدمة recovery على المهاجم والطفل معًا. استخدم cooldowns وrisk-based review وقناة support. لا تجعل lockout أيامًا بلا بديل في حادث خطر. سجل السبب ولا تطلب من الطفل إنشاء حساب جديد إذا كان القديم يحتوي هويته واتصالاته المهمة.

رسائل الاسترداد نفسها

لا تضع معلومات حساسة في subject أو SMS. اذكر أن الطلب حدث ووقتًا تقريبيًا وخيارًا آمنًا للإبلاغ عنه. الروابط قصيرة العمر وsingle-use. لا تطلب reply بكلمة مرور أو code. في العربية استخدم لغة واضحة لا مصطلحات أمنية معقدة.

التأكد من support domain

المهاجم قد يقلد رسالة الدعم. علّم المستخدم أن المنصة لن تطلب password أو MFA code عبر chat. اجعل رابط الدعم من داخل التطبيق، وverified sender حيث يمكن. لا تجعل الطفل يقرر من شكل شعار فقط. المؤسسة التعليمية توفر بوابة رسمية معروفة للاسترداد.

Recovery بعد حذف الحساب

إذا توجد فترة grace قبل الحذف النهائي، يجب ألا يستطيع شخص مسيء استعادة الحساب بسهولة من قناة قديمة بعد أن حذف الطفل الحساب للهروب. اطلب verification مناسبًا وأشعر الطفل عبر قناة جديدة إذا كانت معروفة. في حالات safeguarding يمكن أن يكون deletion final أسرع وفق السياسة والقانون، مع حفظ الحد الأدنى اللازم للبلاغ.

مقاييس المنصة

قِس takeover reports للقاصرين، recovery success، time-to-control، repeated compromise، support overrides، factor changes قبل الحادث، session revocation success، appeal، fraud after takeover، وrecovery abandonment. افصل false lockouts. لا تحتفل بنسبة recovery عالية إذا يعتمد المسار على جمع وثائق حساسة أو يعيد الحساب للمعتدي.

اختبار abuse لمسار الاسترداد

1. حاول reset بمعرفة email فقط.
2. اختبر SIM تبدلت ورقمًا قديمًا.
3. اختبر بريد recovery مخترقًا.
4. اختبر guardian قديمًا أو شخصًا مسيئًا.
5. اختبر جهازًا مشتركًا وجلسة مسروقة.
6. اختبر support social engineering بمعلومات عامة.
7. اختبر تغيير كل factors خلال دقائق.
8. اختبر revoke لكل tokens وconnected apps.
9. اختبر recovery endpoint enumeration وrate limits.
10. اختبر accessibility واللغة العربية لمسار الاسترداد.

خطة أول 30 دقيقة بعد takeover

إذا ما زال الطفل يملك وصولًا: غيّر factor قويًا، أخرج الجلسات الغريبة، راجع البريد/الرقم/MFA وconnected apps، وأوقف المدفوعات أو location sharing عند الحاجة. إذا فقد الوصول: استخدم recovery الرسمي ولا تدخل في تفاوض مع المهاجم. احفظ timestamps والرسائل المهمة. عند تهديد أو استغلال، فعّل مسار حماية موازٍ.

خلال 24 ساعة

راجع ما نشره الحساب، contacts المتأثرين، groups، payments، privacy, recovery contacts، impersonation، وأي accounts أخرى تشارك password. غيّر reused passwords في الخدمات الأخرى. لا تطلب من الطفل البقاء خارج المدرسة أو الإنترنت بلا داعٍ؛ استعادة الثقة والسيطرة جزء من recovery.

نموذج روافد المفاهيمي: دوائر استعادة السيطرة

تقترح روافد إطارًا غير متحقق: الهوية، الاعتماد، الجلسة، العلاقات، والآثار. الاسترداد لا يكتمل عند تغيير كلمة المرور؛ يجب إعادة هذه الدوائر إلى صاحب الحساب. النموذج conceptual وغير validated ويمكن اختباره عبر recurrence وtime-to-control ورضا المستخدم عن recovery.

أسئلة شائعة

المصادر والمنهجية

بُنيت الصفحة على NIST Digital Identity Guidelines الحديثة وممارسات authentication/recovery، وOWASP Forgot Password وAuthentication guidance، وCISA بشأن MFA وحماية الحسابات، وإرشادات eSafety للحسابات المخترقة والأمان الرقمي، وICO Children’s Code، وUNICEF عن أفضل مصالح الطفل وخصوصيته، وتعليق لجنة حقوق الطفل رقم 25، ومبادئ Safety by Design. تم تخصيص الإطار للقاصرين والحسابات العائلية والعلاقات المسيئة، مع عدم تحويل التحقق إلى جمع مفرط للهوية.

صنّف الاسترداد حسب خطورة التغيير لا حسب إلحاح المستخدم فقط

ليس كل reset متساويًا. استعادة كلمة مرور من جهاز معروف مع بقاء البريد وMFA كما هما أقل خطورة من طلب يغيّر البريد والرقم وpasskey وguardian في جلسة واحدة. استخدم مستويات خطر واضحة: منخفض، متوسط، مرتفع، وحماية استثنائية. يرتفع المستوى عند تغيير عدة عوامل دفعة واحدة، جهاز أو بلد غير معتاد، takeover سابق، بلاغ إساءة، فقد كل القنوات القديمة، أو محاولة دعم بشري بعد فشل آلي متكرر. لكل مستوى متطلبات تحقق وزمن وapproval مختلفة، لكن يجب أن يبقى مسار طوارئ للقاصر الذي يحتاج الخروج من شخص مسيء. الهدف زيادة الثقة في القرار لا معاقبة الطفل لأنه فقد هاتفه أو غيّر أسرته أو بلده.

Recovery state machine بدل سلسلة روابط مبعثرة

صمّم الاسترداد كحالات يمكن تتبعها: طلب، تحقق أولي، تقييم خطر، إثبات سيطرة، إلغاء وصول سابق، إعادة إعداد العوامل، مراجعة الأثر، ثم إغلاق مع إمكانية appeal. يجب ألا يستطيع رابط قديم إعادة الحساب من حالة متقدمة إلى نقطة أضعف، وألا تقبل رموزًا أُصدرت قبل تغيير أمني جوهري. سجّل الانتقالات والسبب والفاعل الآلي أو البشري دون تخزين أسرار الاعتماد نفسها. هذا يجعل التحقيق بعد الخطأ ممكنًا ويكشف أين أعاد النظام الحساب للشخص الخطأ.

إذا كان الجهاز نفسه مخترقًا فلا ترسل إليه كل مفاتيح الاسترداد

قد ينجح الطفل في تغيير كلمة المرور بينما الجهاز يحمل spyware أو browser extension خبيثة أو session stealing malware. اسأل بطريقة بسيطة هل الجهاز مفقود أو مشترك أو يتصرف بصورة غير معتادة، ووفّر خيار تأمين الحساب من جهاز موثوق آخر. لا تجعل فحص الجهاز شرطًا تقنيًا معقدًا على الطفل، لكن اسمح بإنهاء كل الجلسات، إزالة الأجهزة الموثوقة، إعادة تسجيل passkeys، ومراجعة التطبيقات المتصلة. إذا كان حساب المدرسة أو المركز، يستطيع الفريق عزل الجلسة المؤسسية دون الاستيلاء على الحساب الشخصي.

انتقال الحساب من إدارة الوالد إلى استقلال المراهق

الحسابات التي تبدأ بإنشاء ولي قد تصبح لاحقًا حسابات يملك فيها اليافع استقلالًا أكبر. يجب أن يوجد transition واضح بدل بقاء البريد والرقم وrecovery contact للوالد إلى أجل غير محدد. عند بلوغ عمر أو مرحلة محددة، اشرح للطفل والولي ما الصلاحيات التي ستنتقل، واطلب إضافة عوامل استرداد تخص صاحب الحساب تدريجيًا. لا تفاجئ الأسرة بفصل فوري، ولا تجعل consent قديمًا سببًا لإبقاء البالغ قادرًا على استعادة حساب مراهق بعد تغير الظروف. وثّق قواعد الانتقال بحسب القانون والمنتج، واجعل safeguarding override متاحًا عند العنف أو النزاع.

الاستقلال المتطور لا يعني سرية مطلقة ولا سيطرة أبوية مطلقة

في الحسابات المخصصة للقاصرين قد تبقى أدوار قانونية أو سلامة للولي، لكن يجب فصلها عن قراءة الرسائل أو امتلاك credential الرئيسي. يمكن أن يرى الولي إعدادات عمر أو شراء دون أن يستطيع تغيير البريد السري أو استخراج المحادثات. وعند recovery عالي الخطورة، قد يحتاج النظام إشراك بالغ موثوق أو جهة مختصة وفق العمر والقانون، لكن لا ينبغي أن يكون أي بالغ مسجل تاريخيًا هو المسار الوحيد. التصميم الجيد يوازن بين حماية الطفل واستقلاله المتزايد ويجعل كل صلاحية قابلة للتفسير والمراجعة.

الاستئناف عندما يرفض النظام الطفل الحقيقي

false lockout قد يعزل طفلًا عن المدرسة أو أصدقائه أو دليل إساءة مهم. وفر appeal واضحًا لا يكرر الآلية الفاشلة نفسها. إذا رفض النظام وثيقة أو جهازًا، يجب أن يستطيع reviewer استخدام إشارات بديلة ضمن سياسة مضبوطة، مع second approval للحالات الحساسة. أخبر المستخدم بما يمكن إصلاحه دون كشف قواعد الكشف التي تسهّل التحايل. قِس زمن الاستئناف ونسبة القرارات التي تغيرت وسبب التغيير؛ ارتفاع reversal rate قد يعني أن نموذج الخطر أو تعليمات الدعم غير مناسبة للأطفال.

سجل تدقيق يحمي الطفل ولا يتحول إلى أرشيف مراقبة

احتفظ بالأحداث اللازمة لفهم takeover: وقت تغيير العوامل، نوع الجهاز أو الجلسة، قرارات الدعم، إلغاء tokens، وإشارات الخطر الأساسية. لا تحتفظ بنصوص الرسائل الخاصة أو صور الطفل لمجرد أن حادث الاسترداد وقع. افصل security logs عن محتوى المستخدم، وحدد retention، وقيّد الوصول، وسجل من فتح السجل. عند طلب قانوني أو تحقيق حماية يمكن تصدير الحد الأدنى المناسب مع provenance واضح. بعد انتهاء الغرض، احذف أو لخّص البيانات وفق السياسة بدل الاحتفاظ بها بلا نهاية.

منع تكرار الاختراق بعد سبعة أيام وثلاثين يومًا

نجاح recovery في الدقيقة الأولى لا يثبت أن الحساب أصبح آمنًا. بعد سبعة أيام افحص إن كانت هناك محاولات دخول متكررة، factors عادت للتغير، connected app أعيدت إضافته، أو impersonation مستمر. بعد ثلاثين يومًا راجع repeated compromise، شكاوى contacts، المدفوعات والخصوصية، وهل استخدم الطفل عوامل أقوى أو عاد لكلمة مرور مشتركة بسبب صعوبة الاستخدام. لا ترسل رسائل تذكير تفصح عن حادث حساس على شاشة مشتركة؛ استخدم قناة آمنة وإعدادات notification مناسبة.

حماية موظفي الدعم من ضغط السرعة ومقاييس الإغلاق

إذا كوفئ موظف الدعم على إغلاق ticket بسرعة فقط فقد يتجاوز خطوة تحقق أو يعيد الحساب لشخص يروي قصة مقنعة. اجعل quality review جزءًا من الأداء، وخصص escalation queue للقاصرين والحالات الأسرية الحساسة، وامنح الموظف حق إبطاء القرار دون عقوبة عندما يرى تعارضًا. استخدم أمثلة تدريبية عن guardian abuse وSIM swap وsocial engineering، وراجع support overrides دوريًا. لا تعرض للموظف معلومات أكثر من حاجته؛ فالوصول الواسع إلى بيانات الطفل يزيد خطر الإساءة الداخلية أو الخطأ.

خطة نضج 90 يومًا لمسار استرداد القاصرين

في أول 30 يومًا احصر عوامل الاسترداد والجلسات وguardian roles ونقاط الدعم اليدوي، واختبر enumeration وreset abuse. خلال 31 إلى 60 يومًا طبّق stepped verification، session revocation موثوقًا، masking للإشعارات، ومسار safeguarding للحالات التي لا تكون فيها القناة العائلية آمنة. خلال 61 إلى 90 يومًا أضف metrics منفصلة للقاصرين، tabletop لحادث takeover، مراجعة support overrides، واختبارًا لاسترداد الحساب من جهاز مفقود ورقم متغير وبريد مخترق. لا تعتبر المشروع منتهيًا بعد الإطلاق؛ راجع recurrence والاستئناف وشكاوى الأطفال لتحديد أين ما زال النظام يعيد السيطرة للطرف الخطأ.