راهنمای Passkey و FIDO2 در Entra ID ۲۰۲۶

Q: آیا Passkey جایگزین رمز عبور میشود یا فقط MFA است؟

در Entra ID، Passkey میتواند هر دو نقش را داشته باشد. اگر سیاست Passwordless را فعال کنید و کاربر Passkey دارد، ورود کاملاً بدون رمز است و Passkey هم اثبات هویت و هم عامل دوم را در یک عمل تأمین میکند. کاربر میتواند رمز عبور خود را در My Account حذف کند، اما ابتدا حداقل یک Passkey فعال باید داشته باشد.

به‌روزرسانی: ۱۷ اوت ۲۰۲۶

Passkey در Microsoft Entra ID یک اعتبار احراز هویت مقاوم در برابر فیشینگ مبتنی بر استاندارد FIDO2/WebAuthn است که کلید خصوصی روی دستگاه کاربر (Authenticator موبایل، کلید سخت‌افزاری یا Windows Hello) نگهداری می‌شود و هیچ‌گاه از دستگاه خارج نمی‌شود. برای استقرار در سازمان، مسیر ثابت هلپ دسک این است: فعال‌سازی سیاست FIDO2، صدور Temporary Access Pass برای ثبت‌نام اولیه، ثبت Passkey در Microsoft Authenticator یا کلید سخت‌افزاری تأییدشده، الزام Phishing-Resistant MFA در Conditional Access و در نهایت پایش سیگنال‌های Sign-in logs.

Passkey در Entra ID بر پایه WebAuthn/CTAP2 است و کلید خصوصی هرگز دستگاه را ترک نمی‌کند؛ به همین دلیل در برابر فیشینگ و Replay مقاوم است.
پیش از هر ثبت‌نام Passkey باید Temporary Access Pass (TAP) با طول عمر کوتاه صادر کنید تا کاربر بدون رمز عبور بتواند وارد شود و کلید را ثبت کند.
در Authentication methods policy، Passkey (FIDO2) را فعال کنید، Enforce attestation را روشن نگه دارید و از AAGUID Allow-List برای محدود کردن مدل‌های مجاز استفاده کنید.
Microsoft Authenticator نسخه ۶.۸ به بعد روی iOS 17+ و Android 14+ از Passkey پشتیبانی می‌کند و برای اکثر کاربران گزینه پیش‌فرض است.
ورودی هلپ دسک اغلب دو خطا است: AADSTS135011 (Passkey غیرفعال یا تأییدنشده) و ناتوانی در اسکن کد QR در جریان cross-device؛ هر دو ریشه در سیاست، AAGUID یا Bluetooth دارند.
یک Fallback واقعی طراحی کنید. کاربرانی که Passkey خود را از دست می‌دهند نباید مجبور به بازنشانی حساب شوند، TAP جدید و Session Revoke راه استاندارد است.

Passkey چیست و چه فرقی با رمز عبور دارد؟

Passkey یک زوج کلید عمومی/خصوصی است که هنگام ثبت‌نام روی دستگاه کاربر ساخته می‌شود. کلید عمومی به Microsoft Entra ID فرستاده می‌شود و کلید خصوصی داخل Secure Enclave تلفن، TPM لپ‌تاپ یا حافظه امن کلید سخت‌افزاری باقی می‌ماند. در زمان ورود، سرور یک challenge می‌فرستد، دستگاه با کلید خصوصی امضا می‌کند و امضا برمی‌گردد؛ رمزی برای فیشینگ یا سرقت وجود ندارد چون هیچ سِرّ مشترکی رد و بدل نمی‌شود.

تفاوت این مدل با رمز عبور یا حتی MFA پیامکی، در سه محور دیده می‌شود. اول، اعتبار به دامنه Origin گره خورده است؛ اگر کاربر روی صفحه فیشینگ login.micros0ft.com کلیک کند، مرورگر اجازه امضای Passkey را نمی‌دهد. دوم، اعتبار غیرقابل replay است و هر ورود signature تازه‌ای دارد. سوم، حضور کاربر (User Presence) و اغلب تأیید کاربر (User Verification با بیومتریک یا PIN) به‌صورت رمزنگاشتی به سرور اثبات می‌شود. برای هلپ دسک این یعنی کاهش چشمگیر تیکت‌های «حسابم را هک کردند» و «کد پیامکی نرسید»، همان چیزی که سال‌ها پیگیرش بودیم.

معماری Passkey در Microsoft Entra ID

معماری استقرار سه لایه دارد: لایه هویت (Entra ID)، لایه Authenticator (Microsoft Authenticator، YubiKey، Windows Hello) و لایه اعمال سیاست (Conditional Access). Entra ID نقش Relying Party را دارد و از طریق endpoint login.microsoftonline.com با استاندارد WebAuthn به مرورگر یا کلاینت درخواست امضا می‌فرستد. مرورگر با پروتکل CTAP2 با Authenticator صحبت می‌کند، چه Authenticator داخلی (Platform: TPM ویندوز، Touch ID مک، Face ID آیفون) باشد چه Roaming (کلید USB/NFC/BLE).

یک نکته که در بسیاری از استقرارها گم می‌شود: مسیر cross-device. اگر کاربر روی مرورگر لپ‌تاپ کورپوریت وارد می‌شود ولی Passkey فقط در Authenticator تلفن ثبت شده، مرورگر یک کد QR نمایش می‌دهد که تلفن با اسکن آن از طریق Bluetooth Low Energy (BLE) یک کانال hybrid transport باز می‌کند. اگر Bluetooth روی لپ‌تاپ خاموش باشد یا سازمان BLE را روی endpoint مسدود کرده باشد، این جریان می‌شکند و کاربر پیغام مبهم Something went wrong می‌بیند. این را از اول در معماری شبکه ببینید. برای مروری روی مؤلفه‌های سیاست، مقاله عیب‌یابی Conditional Access در Microsoft Entra پایه خوبی است.

پیش‌نیازها، رول‌ها و کلاینت‌های پشتیبانی‌شده

پیش از آنکه یک تیکت Passkey باز شود، مطمئن شوید این پیش‌نیازها برقرارند. لایسنس: Entra ID Free برای فعال‌سازی خودِ روش FIDO2 کافی است، ولی برای Conditional Access حداقل Entra ID P1 لازم است، و برای Authentication Strengths یا Registration Campaign جزو مواردی است که در P1 وجود دارد. رول ادمین: برای ویرایش Authentication methods policy رول Authentication Policy Administrator کافی است. برای صدور TAP رول Authentication Administrator (روی کاربران غیر ادمین) یا Privileged Authentication Administrator (برای همه، از جمله ادمین‌ها) لازم است.

کلاینت‌ها: Microsoft Authenticator نسخه 6.8.14 به بعد، iOS 17 یا بالاتر، Android 14 یا بالاتر (روی 13 با محدودیت کار می‌کند اما تجربه هموار نیست)، Windows 11 نسخه 23H2 با KB5031455 به بعد، macOS Sonoma 14.4 و بالاتر، Chrome 121+، Edge 121+، Safari 17+. Firefox روی macOS پشتیبانی Passkey Platform را از نسخه 122 دارد اما در ویندوز جریان Windows Hello Platform Authenticator سال‌ها عقب است. اگر ناوگان مرورگر شما Firefox on Windows است، این را در صفحه Onboarding بنویسید. کاربر باید Edge باز کند.

فعال‌سازی سیاست FIDO2 در Entra ID

در پرتال Entra به مسیر Protection → Authentication methods → Policies → Passkey (FIDO2) بروید. حالت را روی Enable قرار دهید و در تب Configure دو ستون کلیدی را تنظیم کنید. Allow self-service set up را روی Yes بگذارید تا کاربر بتواند بدون تیکت جدید کلید اضافه کند، و Enforce attestation را روشن نگه دارید. Attestation یعنی Entra ID اجازه می‌دهد فقط Authenticatorهایی که سازنده معتبری امضا کرده‌اند ثبت شوند. بدون آن، هر شبیه‌ساز نرم‌افزاری می‌تواند خود را کلید سخت‌افزاری جا بزند.

پس از فعال‌سازی، حتماً وضعیت Report-only را در جدول Authentication methods activity زیر Monitoring چک کنید. صادقانه بگویم، معمول‌ترین اشتباهی که خودم بارها دیده‌ام این است: تیم امنیت روش را فعال می‌کند اما گروه Target را All users نمی‌گذارد. یک هفته بعد که هلپ دسک پر از تیکت «چرا نمی‌توانم Passkey ثبت کنم؟» می‌شود، تازه متوجه می‌شوند فقط گروه Passkey-Pilot فعال بوده است. برای فعال‌سازی سراسری از PowerShell می‌توانید از Microsoft Graph استفاده کنید:

Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"

# Enable Passkey (FIDO2) for all users, keep attestation on
$body = @{
  '@odata.type'       = '#microsoft.graph.fido2AuthenticationMethodConfiguration'
  state               = 'enabled'
  isSelfServiceRegistrationAllowed = $true
  isAttestationEnforced            = $true
  keyRestrictions     = @{
    isEnforced   = $false
    enforcementType = 'allow'
    aaGuids      = @()
  }
  includeTargets = @(
    @{ id = 'all_users'; targetType = 'group'; isRegistrationRequired = $false }
  )
} | ConvertTo-Json -Depth 6

Invoke-MgGraphRequest -Method PATCH `
  -Uri 'https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/Fido2' `
  -Body $body -ContentType 'application/json'

صدور Temporary Access Pass برای بوت‌استرپ ثبت‌نام

یک کاربر جدید که هنوز هیچ روش MFA ندارد نمی‌تواند وارد myaccount.microsoft.com شود تا Passkey ثبت کند (پارادوکس مرغ و تخم‌مرغ). راه استاندارد Microsoft برای شکستن این حلقه، Temporary Access Pass است: یک کد زمان‌دار عددی که یک بار (یا چند بار در پنجره تعیین‌شده) به‌جای هر MFA پذیرفته می‌شود. کاربر با TAP وارد پرتال My Sign-Ins می‌شود، Passkey ثبت می‌کند، TAP سوزانده می‌شود و از آن پس تنها با Passkey وارد می‌شود.

پیش از صدور، مطمئن شوید در Authentication methods → Temporary Access Pass این روش برای گروه هدف فعال است. طول عمر پیش‌فرض ما یک ساعت است و Usage را روی One-time می‌گذاریم. برای Onboarding کاربر Remote که ممکن است ثبت‌نام را در دو مرحله انجام دهد، Multi-use با طول عمر ۸ ساعت هم پذیرفتنی است. صدور از پرتال ساده است: صفحه کاربر → Authentication methods → Add authentication method → Temporary Access Pass. برای اسکریپت‌ گروهی از Graph API:

# Issue a one-time, 60-minute TAP for a new joiner
$upn = '[email protected]'
$user = Get-MgUser -Filter "userPrincipalName eq '$upn'"

$tapBody = @{
  '@odata.type'     = '#microsoft.graph.temporaryAccessPassAuthenticationMethod'
  lifetimeInMinutes = 60
  isUsableOnce      = $true
} | ConvertTo-Json

$tap = Invoke-MgGraphRequest -Method POST `
  -Uri "https://graph.microsoft.com/v1.0/users/$($user.Id)/authentication/temporaryAccessPassMethods" `
  -Body $tapBody -ContentType 'application/json'

Write-Host "TAP for $upn : $($tap.temporaryAccessPass) (expires $($tap.lifetimeInMinutes) min)"

کد را از طریق کانال Out-of-Band (تماس صوتی تأییدشده، ایمیل شخصی ثبت‌شده در HRIS یا تحویل حضوری) به کاربر بدهید. هرگز TAP را در همان چت Teams که ممکن است روزی نقض بشود نفرستید.

ثبت Passkey در Microsoft Authenticator

مسیر کاربر بعد از TAP این است: باز کردن aka.ms/mysecurityinfo، وارد شدن با UPN و TAP، کلیک روی Add sign-in method → Passkey in Microsoft Authenticator، اسکن کد QR که صفحه نمایش می‌دهد با اپ Authenticator روی تلفن، تأیید بیومتریک (Face ID، Touch ID، بیومتریک اندروید) و انتخاب Save. Passkey با نامی مثل «Passkey (iPhone 15)» در فهرست روش‌ها ظاهر می‌شود. تا اینجا در سناریوی سالم ۹۰ ثانیه بیشتر طول نمی‌کشد.

مواردی که در تیکت‌های واقعی هلپ دسک ما خراب می‌شوند: کاربر Microsoft Authenticator را با حساب مصرفی (Outlook.com) پر کرده و هنگام Add device account، اپ به‌جای Enterprise account، حساب شخصی را انتخاب می‌کند. راهنما اینجا واضح باشد. یا کاربر Bluetooth تلفن را خاموش کرده و در حین Sync اولیه پیغام Timeout می‌گیرد. یا Authenticator نسخه قدیمی است. روی iOS اگر کاربر یک سال به‌روزرسانی نکرده باشد، منوی «Add passkey» اصلاً نمایش داده نمی‌شود. یک اسکریپت intune-based چک نسخه Authenticator را برای شما ساده می‌کند.

ثبت کلید سخت‌افزاری FIDO2 (YubiKey و Feitian)

برای کارکنانی که تلفن سازمانی ندارند یا نقش حساس دارند (Domain Admin، Global Admin، Security Admin) کلید سخت‌افزاری FIDO2 استاندارد طلایی است. کلیدهایی که ما در استقرارهای واقعی جواب گرفته‌ایم: YubiKey 5 NFC، YubiKey Bio (اثر انگشت روی خود کلید)، Feitian BioPass K27 و Token2 PIN+ Bio. کلیدهای NFC-only برای iPhone عالی‌اند و کلیدهای USB-C همه‌کاره‌ترند. جریان ثبت‌نام مشابه Authenticator است: پرتال My Sign-Ins → Security key → کلید را وصل کن → PIN جدید کلید بساز → Touch → نام‌گذاری. برای مشخصات کامل خانواده کلیدها به صفحه رسمی YubiKey 5 Series مراجعه کنید.

دو نکته‌ای که در استقرار می‌سوزانند: اول، PIN کلید سخت‌افزاری با PIN Windows Hello یکی نیست و کاربر معمولاً این را اشتباه می‌گیرد. راهنمای Onboarding را با این جمله شروع کنید: «این PIN فقط برای این کلید است، هر بار که آن را می‌زنید سرور امضا می‌گیرد.» دوم، بعضی مدل‌های YubiKey فقط UV=false را پشتیبانی می‌کنند (بدون PIN، فقط touch) و در سیاست‌های سختگیرانه که User Verification را الزامی می‌کنند رد می‌شوند. قبل از سفارش انبوه، AAGUID مدل را با ماتریس Entra چک کنید.

محدودسازی مدل کلید با AAGUID Allow-List

AAGUID یک شناسه ۱۶ بایتی است که هر سازنده Authenticator به مدل خود می‌دهد و در گواهی Attestation ارسال می‌شود. با AAGUID Allow-List شما به Entra می‌گویید فقط این مدل‌های خاص اجازه ثبت‌نام دارند و هر کلید ناشناس یا Consumer-grade رد می‌شود. این تنها راه واقعی است که مطمئن شوید تیم Sales کلید ۵ دلاری بی‌نام از آمازون نمی‌خرد و آن را روی Global Admin ثبت نمی‌کند.

در جدول زیر AAGUID چند مدل رایج آمده. لیست کامل رسمی را در مستندات Microsoft Learn و مخزن passkey-authenticator-aaguids در GitHub پیدا می‌کنید:

مدل Authenticator	AAGUID	Form Factor	User Verification
Microsoft Authenticator (Passkey)	90a3ccdf-635c-4729-a248-9b709135078f	Platform (تلفن)	Biometric / PIN
YubiKey 5 NFC	2fc0579f-8113-47ea-b116-bb5a8db9202a	USB-A + NFC	Touch + PIN اختیاری
YubiKey 5C NFC	c1f9a0bc-1dd2-404a-b27f-8e29047a43fd	USB-C + NFC	Touch + PIN اختیاری
YubiKey Bio Series	d8522d9f-575b-4866-88a9-ba99fa02f35b	USB + Fingerprint	اثر انگشت روی کلید
Feitian BioPass K27	77010bd7-212a-4fc9-b236-d2ca5e9d4084	USB + Fingerprint	اثر انگشت روی کلید

برای اعمال Allow-List از Graph:

$allowlist = @(
  '90a3ccdf-635c-4729-a248-9b709135078f',  # Microsoft Authenticator
  '2fc0579f-8113-47ea-b116-bb5a8db9202a',  # YubiKey 5 NFC
  'c1f9a0bc-1dd2-404a-b27f-8e29047a43fd',  # YubiKey 5C NFC
  'd8522d9f-575b-4866-88a9-ba99fa02f35b'   # YubiKey Bio
)

$body = @{
  keyRestrictions = @{
    isEnforced      = $true
    enforcementType = 'allow'
    aaGuids         = $allowlist
  }
} | ConvertTo-Json -Depth 4

Invoke-MgGraphRequest -Method PATCH `
  -Uri 'https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/Fido2' `
  -Body $body -ContentType 'application/json'

الزام Phishing-Resistant MFA در Conditional Access

فعال کردن Passkey بدون Conditional Access یعنی به کاربر گزینه داده‌اید ولی اجباری نیست. کاربر با کوچک‌ترین اصطکاک به SMS برمی‌گردد و مقاومت به فیشینگ عملاً صفر می‌شود. کار واقعی اینجا شروع می‌شود: در Conditional Access یک Policy جدید بسازید، Users را روی نقش‌های حساس (Global Admin، Security Admin، Exchange Admin) یا گروه Pilot بگذارید، Cloud apps را روی All cloud apps تنظیم کنید، در Grant، از Authentication strengths گزینه Phishing-resistant MFA را انتخاب کنید. مرجع Microsoft در مستندات Authentication Strengths جزئیات هر پروفایل را دارد.

یک استقرار واقعی که دیده‌ام: تیم امنیت این سیاست را روی همه ادمین‌ها فعال کرد ولی رول Global Reader را استثنا نکرد. یک اپراتور SOC که فقط رول Global Reader داشت نتوانست وارد پرتال Sentinel شود چون تنها Authenticator با push notification داشت. راهکار: قبل از Enforcement، حداقل دو هفته Report-only اجرا کنید و کاربران Impacted را در Sign-in log فیلتر Authentication requirement = multi-factor authentication و Applied conditional access policies ببینید. برای عمق بیشتر روی مکانیزم WHfB (که خودش نیز Phishing-resistant است)، به راهنمای استقرار Windows Hello for Business با Cloud Kerberos Trust مراجعه کنید.

عیب‌یابی رایج‌ترین خطاهای ثبت‌نام و ورود

در جدول زیر خطاهایی که در ۱۲ ماه گذشته بیشترین تیکت را باز کرده‌اند و راه‌حل عملی آن‌ها را جمع کرده‌ام. همیشه اولین قدم عیب‌یابی، جست‌وجوی Correlation ID تیکت در Entra → Sign-in logs → User sign-ins (non-interactive یا interactive) است.

کد خطا	پیغام کاربر	علت واقعی	راه‌حل هلپ دسک
`AADSTS135004`	Invalid Passkey received	قفل صفحه دستگاه غیرفعال شده یا Biometric حذف شده	کاربر قفل صفحه را دوباره فعال کند؛ در غیر این صورت Passkey را حذف و با TAP جدید بازثبت‌نام کنید.
`AADSTS135011`	Passkey used is disabled	مدل Authenticator در AAGUID Allow-List نیست یا سیاست FIDO2 برای گروه کاربر فعال نیست	AAGUID را از Sign-in log بردارید، در Allow-List بگذارید یا گروه Target سیاست را اصلاح کنید.
`AADSTS50097`	Device authentication required	Conditional Access دستگاه Compliant می‌خواهد ولی دستگاه در Intune ثبت نیست	یا Passkey را از Roaming Key استفاده کنید یا دستگاه را در Intune ثبت کنید.
`0xC03A0005`	Something went wrong (cross-device)	Bluetooth روی endpoint خاموش است یا Group Policy BLE را بلاک کرده	Bluetooth را روشن کنید یا GPO Allow Bluetooth را اصلاح کنید.
`WebAuthn: NotAllowedError`	The operation either timed out or was not allowed	Origin مرورگر با Origin ثبت‌شده Passkey مطابق نیست (مثلاً کاربر از IP رفته)	کاربر با URL کامل login.microsoftonline.com وارد شود، نه با IP یا CNAME داخلی.

یک نکته اپراتورمحور. در Sign-in logs زیر تب Authentication Details، ستون Authentication method detail AAGUID را برمی‌گرداند. اگر تیکت بازشد و کاربر نمی‌داند کدام کلید استفاده کرده، این ستون منبع حقیقت شماست. Correlation ID را در ابتدای هر تیکت ثبت کنید. این عادت را در تیم جا بیندازید. بدون آن، حل تیکت ۳۰ دقیقه‌ای می‌شود.

سناریوهای بازیابی و چک‌لیست هلپ دسک

سه سناریوی بازیابی که هلپ دسک باید Runbook داشته باشد: (۱) کاربر تلفن با Passkey Authenticator را گم کرده، (۲) کلید سخت‌افزاری خراب شده یا در سفر جا مانده، (۳) کاربر بایومتریک دستگاه را ریست کرده و Passkey بی‌اعتبار شده. در هر سه مورد الگو یکی است: تأیید هویت کاربر با کانال Out-of-Band (تماس ویدیویی با ID سازمانی، تأیید مدیر مستقیم)، حذف Passkey از پرتال Entra، بازخوانی سشن‌های فعال با Revoke sessions، صدور TAP جدید و راهنمایی ثبت‌نام دوباره.

چک‌لیست هلپ دسک قبل از باز کردن تیکت Passkey: کاربر روی نسخه به‌روز Authenticator است؟ قفل صفحه دستگاه فعال است؟ مرورگر Edge/Chrome به‌روز است؟ در Sign-in logs، Correlation ID و AAGUID را دارید؟ سیاست FIDO2 برای گروه کاربر فعال است؟ Conditional Access برای این کاربر Phishing-resistant می‌خواهد؟ اگر هر یک نه بود، آنجا اولین دیوار است. با همین چک‌لیست پنج‌مرحله‌ای، MTTR تیکت‌های Passkey در تیم ما از ۳۲ دقیقه به ۹ دقیقه رسید، رقمی که در گزارش کوارترلی به مدیریت ارائه دادم و پرسنل بیشتری برای پروژه استقرار کامل بدست آوردم.

پرسش‌های متداول

تفاوت Passkey با Windows Hello for Business چیست؟

هر دو Phishing-resistant و مبتنی بر FIDO2 هستند، اما WHfB به یک دستگاه ویندوز خاص (TPM) گره خورده و ذات آن Device-bound است. Passkey در Authenticator یا کلید سخت‌افزاری قابل حمل بین دستگاه‌ها و پلتفرم‌هاست و روی iOS و macOS هم کار می‌کند. در سازمان‌های ترکیبی، معمولاً WHfB روی لپ‌تاپ کورپوریت و Passkey برای تلفن و کلید سخت‌افزاری استفاده می‌شود.

آیا Passkey جایگزین رمز عبور می‌شود یا فقط MFA است؟

در Entra ID، Passkey می‌تواند هر دو نقش را داشته باشد. اگر سیاست Passwordless را فعال کنید و کاربر Passkey دارد، ورود کاملاً بدون رمز است و Passkey هم اثبات هویت و هم عامل دوم را در یک عمل تأمین می‌کند. کاربر می‌تواند رمز عبور خود را در My Account حذف کند، اما ابتدا حداقل یک Passkey فعال باید داشته باشد.

اگر کاربر Passkey خود را گم کرد چطور دسترسی را بازگردانیم؟

ابتدا هویت کاربر را با کانال Out-of-Band تأیید کنید، سپس Passkey گم‌شده را در پرتال Entra حذف کنید، سشن‌های فعال کاربر را Revoke کنید، یک Temporary Access Pass یک‌بارمصرف با طول عمر ۶۰ دقیقه صادر کنید و کاربر با آن Passkey جدید ثبت می‌کند. هرگز رمز عبور را دوباره فعال نکنید مگر آنکه سیاست سازمان صریحاً اجازه دهد.

چرا کاربر پیغام «Passkey used is disabled» می‌بیند؟

این خطا (AADSTS135011) در اکثر موارد یعنی AAGUID کلید کاربر در Allow-List سیاست FIDO2 نیست یا سیاست FIDO2 برای گروه کاربر روی Disabled است. AAGUID را از Sign-in logs بخوانید، تأیید کنید مدل کلید مورد تأیید سازمان است و در Allow-List اضافه کنید. اگر مدل غیرمجاز است، کلید تأییدشده تحویل کاربر بدهید و Passkey قدیمی را حذف کنید.

آیا Passkey روی iPhone با حساب سازمانی Entra کار می‌کند؟

بله. Microsoft Authenticator نسخه 6.8.14+ روی iOS 17 و بالاتر Passkey سازمانی را در Secure Enclave آیفون نگه می‌دارد و از طریق cross-device flow (کد QR + Bluetooth) به لپ‌تاپ ویندوز یا مک اعتبار می‌رساند. Passkey داخل iCloud Keychain برای حساب Entra هنوز پشتیبانی نمی‌شود؛ فقط از طریق اپ Authenticator است.

Attestation در سیاست FIDO2 چیست و چرا مهم است؟

Attestation یعنی هر Authenticator با گواهی امضاشده سازنده اثبات می‌کند که کیست و از چه مدلی است. با فعال بودن Enforce attestation، Entra ID اجازه ثبت‌نام Authenticatorهای شبیه‌سازی‌شده یا Consumer-grade بی‌کیفیت را نمی‌دهد. بدون Attestation، AAGUID Allow-List بی‌معنا می‌شود چون مهاجم می‌تواند AAGUID دلخواه ارسال کند.