Passkeys للشركات أصبحت في 2026 أكثر من “ميزة لطيفة”؛ إنها نقطة تحوّل في أمن الحسابات وتجربة الدخول معًا. في هذا الدليل على مدونة عربي تك التقنية سنبني صورة كاملة: ما هي Passkeys بدقة، لماذا تتفوّق على كلمات المرور، وكيف تنتقل شركة حقيقية—بموظفين، أجهزة متعددة، دعم فني، وتطبيقات قديمة—إلى تسجيل دخول بدون كلمة مرور دون تكسير تجربة المستخدم أو فتح أبواب جديدة للهجمات.
ما هي Passkeys بالضبط؟ ولماذا تختلف عن “أي طريقة دخول أخرى”؟
Passkeys هي “مفاتيح اعتماد” مبنية على معيار FIDO2 وواجهة WebAuthn، تعمل بمنطق التشفير بالمفاتيح العامة بدلًا من “سر مشترك” مثل كلمة المرور. الفكرة ببساطة:
- عند إنشاء Passkey لحساب ما، يتم توليد زوج مفاتيح:
مفتاح خاص يبقى داخل جهاز المستخدم (الهاتف/الكمبيوتر/المفتاح الأمني) ولا يغادره، ومفتاح عام يُخزَّن لدى الخادم (خدمة الشركة أو مزود الهوية). - عند تسجيل الدخول، يرسل الخادم “تحديًا” (Challenge)، ويقوم الجهاز بتوقيع التحدي بالمفتاح الخاص بعد موافقة المستخدم ببصمته/وجهه/رمزه المحلي.
- الخادم يتحقق من التوقيع باستخدام المفتاح العام. لا توجد كلمة مرور تُرسل عبر الشبكة، ولا “كود” يمكن سرقته بسهولة ثم إعادة استخدامه.
هذا الفرق الجوهري يجعل Passkeys مقاومة بشكل ممتاز لهجمات التصيّد (Phishing) لأن التوقيع يرتبط بالموقع/النطاق ولا يعمل على صفحات مزيفة.
مرجع معيار FIDO Alliance:
https://fidoalliance.org/
لماذا تتجه الشركات إلى Passwordless الآن؟ (وليس بعد سنتين)
لأن كلمة المرور أصبحت أضعف حل مع أعلى كلفة تشغيلية:
- التصيّد صار صناعيًا: صفحات مزيفة دقيقة، رسائل مصممة خصيصًا، وابتزاز كلمات المرور بسرعة.
- إعادة استخدام كلمات المرور ما زالت ظاهرة بشرية طبيعية حتى داخل المؤسسات.
- تكلفة الدعم الفني: إعادة تعيين كلمات المرور، قفل الحسابات، ومراجعات الأمن تستهلك وقتًا وميزانية.
- الاحتكاك: كل طبقة أمان إضافية فوق كلمة المرور غالبًا تزيد الانزعاج (خاصة رموز SMS).
Passkeys تقلب المعادلة: أمان أعلى مع خطوات أقل. وفي عالم الأعمال، هذا هو المعيار الذهبي.
كيف تعمل Passkeys على الأجهزة؟ (Platform vs Roaming)
هناك نوعان عمليًا من تجربة Passkeys داخل الشركات:
1) Passkeys المدمجة في الجهاز (Platform Authenticators)
مثل Passkeys المخزنة على iPhone عبر iCloud Keychain أو على Android عبر Google Password Manager أو على Windows عبر Windows Hello. هنا المصادقة تتم ببصمة/وجه/رمز الجهاز.
- Apple:
https://support.apple.com/ - Google Passkeys:
https://developers.google.com/identity/passkeys - Microsoft Windows Hello:
https://learn.microsoft.com/windows/security/identity-protection/hello-for-business/
2) مفاتيح أمنية خارجية (Roaming Authenticators)
مثل مفاتيح YubiKey أو مفاتيح FIDO2 أخرى تُستخدم عبر USB/NFC. هذه مفيدة جدًا للبيئات الحساسة أو لفرق الإدارة العليا والحسابات الحرجة.
الخلاصة العملية للشركات:
- للعامة: Passkeys مدمجة في الهاتف/الكمبيوتر لسهولة التبني.
- للحسابات الحساسة: مفاتيح خارجية كخيار أقوى وأوضح في الضبط.
مفاهيم مهمة قبل البدء (تمنع الأخطاء المكلفة)
Passkeys ليست “تطبيقًا” بحد ذاتها
Passkeys هي معيار وقدرة داخل أنظمة التشغيل والمتصفحات وخدمات الهوية. أنت لا “تشتري Passkeys” فقط؛ أنت تبني سياسة اعتماد وهوية.
“قابلية الاكتشاف” و”تجربة الدخول”
الكثير من مزودي الهوية يعتمدون ما يُسمى “Discoverable Credentials”، بحيث يستطيع المستخدم اختيار الحساب وتسجيل الدخول دون كتابة اسم مستخدم في بعض السيناريوهات. هذا ممتاز لتجربة المستخدم، لكنه يحتاج تصميم تدفق واضح داخل بوابة الشركة.
المزامنة بين الأجهزة… ليست سحرًا بلا ثمن
مزامنة Passkeys عبر خدمات مثل iCloud/Google تساعد الانتشار بين أجهزة المستخدم، لكنك كشركة تحتاج سياسة:
- هل تسمح بالمزامنة الشخصية على أجهزة BYOD؟
- هل تفرض مفاتيح مؤسسية/Managed؟
- ماذا عن الموظف الذي يغيّر هاتفه؟
هنا تظهر قيمة إدارة الهوية (IdP) وسياسات الأجهزة.
أين تُطبّق Passkeys داخل الشركة؟ (خريطة سريعة)
ابدأ بتقسيم نقاط الدخول إلى 4 طبقات:
- حسابات حرجة: Admin, Finance, HR, DevOps, Production.
- تطبيقات هوية مركزية: SSO/IdP (حيث تسجيل دخول واحد يفتح باقي الأنظمة).
- تطبيقات داخلية قديمة: قد لا تدعم WebAuthn مباشرة.
- بوابات خارجية: بوابة العملاء/الشركاء إن كانت ضمن عملك.
نجاح الانتقال يعتمد على البدء من “مركز الهوية” ثم التوسع.
المتطلبات الأساسية قبل مشروع الانتقال
1) مزود هوية يدعم WebAuthn/Passkeys
غالبًا ستعمل عبر واحد من هؤلاء أو ما يشبههم:
- Microsoft Entra ID (Azure AD):
https://www.microsoft.com/security/business/identity-access/microsoft-entra-id - Okta:
https://www.okta.com/ - Google Cloud Identity:
https://cloud.google.com/identity - Duo (Cisco):
https://duo.com/
ليس المطلوب تغيير مزود الهوية بالضرورة؛ المطلوب التأكد من دعم Passkeys وسياسات الإدخال والتعافي.
2) سياسة أجهزة واضحة
- أجهزة مُدارة للشركة (Managed) vs أجهزة شخصية (BYOD).
- الحد الأدنى لنُظم التشغيل والمتصفحات.
- هل ستسمح بالمفاتيح الخارجية؟ لمن؟ وكيف تُدار؟
3) خطة تعافٍ واسترجاع محسوبة
Passwordless لا يعني “لا توجد مشاكل”. ستظهر حالات: هاتف مفقود، جهاز مكسور، موظف جديد، موظف غادر، سفر بدون جهاز… ويجب أن يكون التعافي مضبوطًا كي لا يتحول إلى ثغرة اجتماعية.
خطة الانتقال خطوة بخطوة (عملية ومناسبة لشركات حقيقية)
الخطوة 1: جرد الدخول وتحديد “أول انتصار”
حدد:
- أعلى 5 تطبيقات يستخدمها الموظفون يوميًا.
- أكثر 5 حالات دعم فني تسبب تذاكر (Tickets) بسبب كلمات المرور.
- أكثر 5 حسابات حساسة.
الهدف من هذه الخطوة ليس المثالية، بل اختيار ساحة تُظهر النتائج بسرعة: تقليل تذاكر كلمات المرور ورفع الأمان دون إزعاج.
الخطوة 2: تصميم سياسة Passwordless على مراحل
اعتمد 3 مراحل بدل “انقلاب كامل”:
المرحلة A (تمكين اختياري):
Passkeys كخيار إضافي بجانب كلمة المرور وطرق MFA الحالية.
المرحلة B (افتراضي للمستخدمين الجدد):
أي موظف جديد يُسجّل Passkey أثناء الإعداد الأول.
المرحلة C (إلزام للحسابات الحساسة):
الحسابات الحرجة تتحول إلى Passkeys + سياسة قوية (مثل مفاتيح خارجية أو أجهزة مُدارة).
هذه المقاربة تمنع الصدمة وتسمح للدعم الفني بالتعلم.
الخطوة 3: إعداد تدفق التسجيل (Enrollment) بطريقة “لا تزعج”
التجربة المثالية للتسجيل يجب أن تكون قصيرة وواضحة:
- داخل بوابة الهوية: “أضف Passkey الآن”
- يطلب النظام: بصمة/وجه/رمز الجهاز
- يتم الحفظ ويُعرض نجاح التسجيل
- بعدها خيار: “إضافة Passkey ثانية” (مهم جدًا)
قاعدة ذهبية: لا تعتمد على Passkey واحدة فقط للمستخدم الذي يملك أكثر من جهاز.
تشجيع Passkey على هاتف + Passkey على الكمبيوتر يقلل حالات التعافي.
الخطوة 4: بناء سياسة تعافٍ آمنة (بدون فتح ثغرة اجتماعية)
التعافي هو المكان الذي تنهار فيه أفضل الأنظمة إذا كان ضعيفًا. الحل المتوازن غالبًا يشمل:
- Passkey بديلة على جهاز ثانٍ.
- رموز استرداد (Recovery Codes) محفوظة في مدير كلمات مرور موثوق.
- تحقق دعم فني متعدد العوامل للحالات الحرجة (ليس سؤالًا أمنيًا ساذجًا).
مدراء كلمات مرور موثوقة (للشركات أو للأفراد حسب السياسة):
- 1Password:
https://1password.com/ - Bitwarden:
https://bitwarden.com/
الخطوة 5: معالجة التطبيقات القديمة (Legacy) دون تعطيل العمل
ستجد أن بعض الأنظمة لا تدعم WebAuthn. هنا لديك حلول عملية:
- SSO أمامي (Front-door SSO):
اجعل الدخول لهذه الأنظمة عبر بوابة SSO، حتى لو بقي النظام نفسه بكلمة مرور داخلية. المهم أن “نقطة الدخول” أصبحت محمية. - وكلاء/بوابات وصول (Access Gateways):
في بعض البيئات، تُستخدم بوابات وصول أمام التطبيقات القديمة لفرض سياسات حديثة دون تعديل التطبيق. - ترقية تدريجية:
ضع جدولًا واضحًا لتحديث الأنظمة التي لا يمكن حمايتها أماميًا بشكل كافٍ.
الخطوة 6: إعداد سياسات المخاطر (Risk-based) بدل القواعد الصلبة دائمًا
ليس كل دخول متساويًا:
- دخول من جهاز مُدار داخل البلد يختلف عن دخول من جهاز مجهول في سفر.
- دخول حساب Admin يختلف عن حساب موظف عادي.
لذلك تُضبط سياسات مثل:
- السماح بـPasskeys فقط للأجهزة المُدارة للحسابات الحساسة
- طلب عامل إضافي عند تغيّر الموقع أو عند محاولة تسجيل Passkey جديدة
- إشعارات فورية للتغييرات
الخطوة 7: تدريب الدعم الفني وتحديث “لغة الشركة”
التحدي ليس تقنيًا فقط؛ هو لغوي أيضًا. بدل: “انسيت كلمة المرور”
تصبح: “فقدت جهاز المصادقة/Passkey”.
جهّز فريق الدعم بمصفوفة حالات:
- هاتف مفقود
- كمبيوتر جديد
- موظف لا يملك بصمة مفعلة
- دخول عبر جهاز مؤقت
- حساب مشترك (Shared Account) وكيف يُمنع أصلًا أو يُعالج بسياسة مختلفة
الخطوة 8: الإلزام التدريجي للحسابات الحساسة
بعد نجاح المرحلة الاختيارية:
- ألزم فرق الإدارة والمالية وDevOps أولًا.
- استخدم مفاتيح خارجية للحسابات الأعلى حساسية عند الحاجة.
- امنع SMS كمسار تعافٍ للحسابات الحرجة إذا كانت سياسة شركتك تسمح بذلك.
الخطوة 9: القياس والتحسين
بدون قياس ستبقى “مشروعًا جميلًا” لا أكثر. قِس:
- عدد تذاكر إعادة تعيين كلمات المرور قبل/بعد
- زمن الدخول (Login Time)
- معدل فشل الدخول
- محاولات التصيّد أو الحوادث المتعلقة بكلمات المرور
- رضا المستخدمين (استبيان قصير)
هذه الأرقام تُقنع الإدارة وتفتح ميزانية للتوسع.
أخطاء شائعة يجب تفاديها في 2026
الخطأ 1: جعل التعافي أسهل من الدخول
إذا كان المستخدم يستطيع تجاوز Passkeys بمكالمة هاتفية قصيرة للدعم، فأنت صنعت بابًا خلفيًا للهندسة الاجتماعية.
الخطأ 2: تجاهل سيناريوهات “الأجهزة المؤقتة”
موظف في مؤتمر أو سفر قد يحتاج دخولًا سريعًا. الحل قد يكون:
- جلسة مؤقتة عبر جهاز موثوق مع موافقة على الهاتف
- أو مفتاح خارجي يحمل معه
لا تُجبره على العودة لكلمة المرور كحل افتراضي.
الخطأ 3: السماح بحسابات مشتركة كما هي
الحساب المشترك هو كابوس في عالم Passwordless: من يملك Passkey؟ من المسؤول؟
الحل الصحيح: حسابات فردية + صلاحيات عبر أدوار (Roles) + تتبع تدقيق (Audit).
الخطأ 4: “تمكين Passkeys” دون تحسين UX
إذا لم تُصمم شاشة دخول واضحة، سيضيع المستخدم بين “Continue” و”Use a different method”.
اجعل Passkeys الخيار الأول بصريًا مع خيار بديل واضح وليس مخفيًا.
أسئلة عملية يطرحها مديرو الشركات دائمًا
هل Passkeys تلغي الحاجة إلى MFA؟
في كثير من السيناريوهات، Passkeys تُعد شكلًا قويًا من المصادقة متعددة العوامل لأنها تجمع “شيئًا تملكه” (الجهاز/المفتاح) مع “شيئًا أنت” (بصمة/وجه) أو “شيئًا تعرفه” (رمز الجهاز). لكن السياسة تختلف حسب الحساسية: قد تظل تحتاج شروطًا إضافية للحسابات الإدارية.
ماذا عن الموظفين الذين لا يرغبون باستخدام بصمة؟
يمكن استخدام رمز الجهاز المحلي بدل البصمة في معظم الأنظمة. وفي البيئات التي تمنع القياسات الحيوية، المفاتيح الخارجية خيار محترم.
هل Passkeys مناسبة للبيئات شديدة التنظيم (Compliance)؟
نعم، بشرط:
- توثيق السياسة
- وجود سجلات تدقيق
- وجود خطة تعافٍ محكومة
- تطبيق مبدأ أقل الصلاحيات
- ربط الدخول بسجلات SIEM/Monitoring إن لزم
نموذج تطبيقي مختصر لسيناريو شركة متوسطة
- الأسبوع 1: جرد التطبيقات + اختيار IdP + سياسة أجهزة
- الأسبوع 2: تمكين Passkeys اختياريًا على بوابة SSO
- الأسبوع 3: تدريب الدعم الفني + إطلاق داخلي لفرق تقنية
- الأسبوع 4: توسعة للموظفين + تشجيع Passkey ثانية
- الشهر 2: إلزام الحسابات الحساسة + مفاتيح خارجية للإدارة
- الشهر 3: دمج التطبيقات القديمة خلف SSO + تقليل الاعتماد على كلمات المرور تدريجيًا
هذا المسار يقلل المخاطر ويضمن بقاء العمل مستقرًا.
خلاصة التنفيذ في 2026
Passkeys للشركات ليست “ترندًا”؛ إنها إعادة بناء لأساس الدخول. النجاح الحقيقي لا يأتي من زر “Enable”، بل من 3 أشياء:
سياسة أجهزة واقعية، تعافٍ محكوم لا يتساهل، وتجربة مستخدم تجعل الدخول أسهل من أي وقت مضى. عند تنفيذ هذه العناصر بترتيب منطقي، ستحصل الشركة على مكسبين في وقت واحد: أمن أعلى وتكاليف دعم أقل، مع تجربة دخول لا تخلق مقاومة داخلية.
