কর্মক্ষেত্রে Passkey: Login বাধ্য করার আগে হারানো ফোনের দিনটি ভাবুন

দুপুরে payroll হবে। সকাল 8:50-এ finance lead দেখলেন, তাঁর একমাত্র enrolled sign-in device নেই। Help desk-এ বিশ্বাসযোগ্য শোনানো caller, deadline, কিন্তু agreed recovery procedure নেই। এটি কাল্পনিক ব্যবসার দৃশ্য; সব প্রতিষ্ঠানে একই ঘটনা হয়, এমন দাবি নয়।

Passkey login থেকে reusable password সরাতে পারে। কিন্তু caller সত্যিই finance lead কি না বা emergency payroll approve করতে পারবেন কি না, তা ঠিক করে না। এগুলি recovery ও business permission-এর সিদ্ধান্ত।

তাই শুধু “কর্মীরা passkey register করতে পারবেন?” নয়, জিজ্ঞাসা করুন: “হারানোর পরে সঠিক ব্যক্তি access পাবেন, impersonator পাবেন না—এটি সম্ভব?” বাধ্যতামূলক করার আগেই সেই দিনটির ব্যবস্থা করুন।

Passkey কী রক্ষা করে, কী আপনার দায়িত্বে থাকে

FIDO-র passkey overview public-key sign-in বোঝায়: service reusable password না নিয়ে private key দিয়ে তৈরি proof যাচাই করে। Local unlock biometric বা PIN দিয়ে হতে পারে।

Phishing resistance intended relying party-র সঙ্গে authentication binding থেকে আসে। Look-alike site password/one-time code-এর মতো typed passkey নিয়ে relay করতে পারে না। WebAuthn RP-ID scope ও origin validation ব্যবহার করে; একটি exact page URL-এ credential বাঁধা—এমন নিয়ম নয়।

“Phishing-resistant”-কে “phishing-proof” বলবেন না। Malware, stolen session, weak recovery, unlocked shared device বা অতিরিক্ত permission ক্ষতি করতে পারে। System leak হলে public key থাকার কারণে অন্য customer data বা session harmless হয়ে যায় না।

Key ছুঁয়ে presence বোঝানো আর PIN/biometric দিয়ে user verify এক নয়। Protected action-এর প্রয়োজনীয় authentication strength চাই, প্রযোজ্য user verification-সহ। Login হলেই সব permission নয়; payroll approval, export ও bank change-এর control আলাদা রাখুন।

প্রকৃত Risk অনুযায়ী Credential ও Backup বাছুন

Synced passkey device replacement সহজ করতে পারে; device-bound credential নির্দিষ্ট hardware-এ key রাখার requirement মেটাতে পারে। Label একা পুরো login assurance প্রমাণ করে না। নিচের comparison buying/policy aid, compliance certificate নয়।

NIST syncable-authenticator guide exported key-এর protection চায়। Synced private key protected form-এ copy হতে পারে; প্রথম device কখনও ছাড়ে না বলা ভুল।

NIST SP800-63B-4 উপযুক্ত synced authenticator AAL2-তে মানে, AAL3-তে নয়। Level মেটাতে সব applicable control লাগে; hardware key কিনলেই হয় না।

বেশি impact-এর account-এ আলাদা জায়গায় রাখা approved hardware backup ও tested recovery ভাবুন। একই sync account-নির্ভর দুটি device দুটি independent recovery system নয়। Provider account-এর recovery-ও রক্ষা করুন।

Microsoft-এর বর্তমান Entra FAQ synced copy কোন device-এ আছে, তা দেখা/নিয়ন্ত্রণে সীমাবদ্ধতা জানায়। Per-device list সব copy কভার করে ধরে না নিয়ে নিজের provider-এর control দেখুন।

পছন্দ	উপকারী দিক	যা যাচাই করবেন
Synced Passkey	Approved provider device-এ পাওয়া যেতে পারে	Provider recovery, sharing/visibility limit ও policy
Device-bound Credential	ওই credential model-এ sync হয় না	Hardware capability, user verification, compatibility ও spare
Backup/Recovery Route	হারানোর পরে legitimate access ফেরায়	Independent dependency, verification ও allowed privilege

হারানো ফোনের দিনটি আগে Rehearse করুন

Account policy-তে accepted pre-enrolled alternative credential দিয়ে শুরু করুন। Incident-এর আগে test করে মূল device থেকে আলাদা রাখুন। Approved method থাকলে সেটি দিয়ে sign in ও documented replacement করুন; unauthenticated caller-কে নতুন credential দেবেন না।

কোনও method না থাকলে account risk অনুযায়ী defined recovery নিন। NIST account-recovery guide বিভিন্ন recovery method ও notification আলাদা করে। পরিচিত গলা, manager message বা video call একা impersonation-এর বিরুদ্ধে নির্ভরযোগ্য proof নয়।

Saved recovery code supported হলে নিরাপদে offline, primary device থেকে আলাদা রাখুন। Allowed use ও replacement test করুন; used code স্থায়ী backup access নয়।

Help desk-কে আগে প্রতিষ্ঠিত তথ্য/channel দিয়ে documented verification, escalation ও restricted reset power দিন। Replacement enrolment রক্ষা, established channel-এ notify ও event review করুন। Risk policy চাইলে additional approval/temporary restriction দিন; payroll urgent বলে bypass বানাবেন না।

Lost device management, app credential revoke ও session revoke আলাদা কাজ। Cloud account থেকে device সরালেই business-app session সরবে না। App-এ synced credential revoke করলে তার সব copy অচল হতে পারে; একটি device delete করে অন্যগুলি invalid প্রমাণ হয় না। Identity/provider admin-এর সঙ্গে মিলে প্রতিটি control কী revoke করে test করুন।

Compromise সন্দেহ হলে replacement-এর জন্য অপেক্ষা না করে incident procedure-তে access contain করুন। Identity establish না হলে account restricted রেখে escalate করুন। Continuity-তে আগে থেকেই authorised alternate approver ও separation of duties ব্যবহার হতে পারে; locked-out user সেজে কাজ নয়।

Shared Counter-এ মানুষ ও Tablet আলাদা রাখুন

Shared terminal-এ individual account দিন; handover-এ আগের session শেষ করুন। Shared browser/provider profile-এ personal synced credential রাখবেন না, যেখানে সহকর্মী ব্যবহার করতে পারেন। OS profile, kiosk restriction, auto lock, peripheral support ও personal phone/Bluetooth allowed কি না দেখুন।

Approved hardware key বা supported cross-device sign-in সাহায্য করতে পারে, তবে actual terminal/browser test করুন। Existing POS session-এর ভিতরে short cashier PIN নিজে থেকেই WebAuthn passkey বা phishing-resistant MFA নয়। তার সীমিত purpose/permission অনুযায়ী দেখুন; high-assurance login-এর সমান নয়।

Contractor-এর নিজের scoped account, end date ও offboarding-এ access/session revoke চাই। Staff role বদলেও একই। Physical key ফেরত পেলেই হবে না, যদি app account, sync provider বা active session access দেয়।

শুধু Registration নয়, পুরো Policy নিয়ে Pilot

Supported browser/device/provider, recovery channel ও accessibility need-এর inventory করুন। Requirement এড়ানো যায় এমন সব route লিখুন: password, email link, TOTP, SMS, help-desk reset, legacy client ও persistent session। Protected route-এ strength enforce করুন; enrolment reminder একা নয়।

Supported group ও accountable owner নিয়ে শুরু করুন। High-impact role আগে দেখুন, তবে admin backup enforcement-এর আগে test করুন। Enrolment, normal login, lost device/backup, wrong-domain attempt, weak fallback, recovery impersonation, stolen session response, counter handover ও contractor removal test করুন; approved test account/environment-এ।

TOTP বা email/SMS recovery transition-এ থাকতে পারে, কিন্তু সমান phishing-resistant বিকল্প নয়। Sensitive route-এ weaker fallback একই privilege দিলে সেই method-এর exposure থাকে। Limit, monitoring ও retirement plan স্পষ্ট করুন; enrolment দিয়েই blanket upgrade বলবেন না।

Customer-এর জন্য পরিষ্কার accessible adoption ও usable recovery দিন। Checkout-এ untested enrolment demand দিয়ে চমকে দেবেন না। Business requirement ভিন্ন হতে পারে; সব account-এ একই rule না চাপিয়ে সম্পূর্ণ journey প্রমাণ করুন।

ব্যবহার ও বাকি Bypass মাপুন

শিক্ষামূলক pilot-এ 40 staff-এর 32 enrolled হলে enrolment 80%। একই 40-এর 18 জন protected app-এ password alone দিয়ে ঢুকতে পারলে আলাদা exposure 45%। Group overlap করতে পারে। বাকি account-এ weaker route নেই, কোনও সংখ্যাই তা প্রমাণ করে না।

Required method-এর successful use, device/browser failure, recovery completion/suspected misuse, lockout, active fallback permission ও support effort মাপুন। Cohort ও period লিখুন। Consumer-service benchmark দিয়ে নিজের login speed বা help-desk saving-এর promise করবেন না।

Payroll সকালে ফিরে আসি: approved spare কাজ করে, impersonation ঠেকে, session/credential contain হয় এবং unresolved legitimate case owner পায়—এই evidence-ই দরকার। Ready বলার আগে test শেষ করুন। Passkey access system-এর শক্তিশালী অংশ; recovery ও permission-ও সঙ্গে টিকতে হবে।

পর্যালোচনা: ৫ নভেম্বর ২০২৬। Anichur Rahaman StoreConsole-এর নির্মাতা। প্রতিষ্ঠান ও pilot হিসাব উদাহরণ; নিজের app ও identity provider-এর capability যাচাই করুন।