Account & security · 4 min read
Create and remove passkeys
Use device biometrics or PIN with account-owned passkey records.
Understand what a passkey signs in to
A passkey provides an account sign-in method using your browser and device authenticator, often unlocked by a fingerprint, face or device PIN. OrderMap stores an account-owned credential reference; it does not ask you to send biometric data to support. A passkey must first complete enrollment for the intended account and application origin. Opening the enrollment dialog without finishing the browser ceremony does not create a usable sign-in method. Keep another established way to sign in available while verifying a newly created credential.
Check the browser and account
Sign in to the intended account, then open Settings → Security → Passkeys. The browser needs its credential APIs and an appropriate secure origin, such as the deployed HTTPS application or supported localhost development environment. A browser or device cancellation is not a saved passkey. If the browser does not offer the authenticator you expected, review that browser's available credential options and confirm you are on the right application address. A credential created for another origin cannot be assumed to work on the current one.
Enroll and verify the new entry
Choose Create a passkey and complete the browser or device prompts. Wait until the Passkeys list refreshes and shows the newly saved credential before depending on it. The list uses a shortened identifying suffix and can display Added and Last used dates. Not used yet means no successful use has been recorded for that entry; it does not itself prove enrollment failed. When testing sign-in, retain a working signed-in session or another method so a canceled device prompt does not strand your investigation.
- Open Security → Passkeys and choose Create a passkey.
- Complete the authenticator ceremony on the intended device.
- Confirm the new credential appears in the account's list.
Identify the credential before removing it
Use the credential label and available creation or last-used details to select the old passkey. Removal makes that saved credential stop working for sign-in on every device that uses it, including a synced copy represented by the same credential. It is not merely hiding a row on the current screen. The application can block removal when it would leave no acceptable sign-in method. Establish and verify another method before trying to remove your only usable credential, rather than attempting to bypass the protection.
Confirm removal by email
Choose Remove beside the intended credential, review the confirmation dialog and select Email me a code. Enter the six-digit confirmation code sent to the account address within its ten-minute lifetime. The dialog may impose a resend countdown; wait for that control to become available rather than repeatedly opening removal requests. Codes are specific confirmation proofs, not the device PIN used by your authenticator. After successful removal, verify that the intended entry disappeared and leave other credentials in place unless you deliberately intend to remove them too.
Recover from expired or refused codes
An incorrect code can be retried within the allowed attempts when the dialog permits it. An expired, consumed or exhausted challenge needs a fresh confirmation request. The interface returns to the code-request step for those dead challenges, and reusing their digits will not succeed. If the service says email sending is not configured, removal confirmation cannot be delivered through that flow. If it says this is your only sign-in method, treat that as an account-access protection and return to establishing an alternative method.
Report authenticator failures precisely
Distinguish enrollment failure, sign-in failure and removal-confirmation failure in a support report. Include the browser, operating system, application address, step that failed and safe error text, plus the shortened passkey label if needed. A device prompt canceled by you needs a different investigation from a server refusing a saved credential. Never include the email code, a session token, device unlock PIN or credential challenge data. Real browser ceremonies on a deployed origin require their own acceptance checks; a feature being present is not proof that every device combination has been verified.