Checking WebAuthn's AT flag for proof that a passkey comes from approved hardware would give a developer the wrong answer. The specification defines it as a message-format flag. A widely shared warning about passkey lock-in misreads that detail. The error matters when judging its prediction that websites could use passkeys to control people's software.
The warning, published by Non-Functional on October 10, argues that websites could gradually restrict which software people use by demanding attested passkeys. MrKeyoor's October 12 news snapshot recorded 526 points and 295 comments for the Hacker News discussion. The discussion is evidence of developer interest. The claim about future restrictions needs to be checked against what the protocol sends and what services can require.
The security benefit survives the argument
Passkeys replace a reusable password with a credential unique to a service. The passkeys.dev explanation describes two benefits directly relevant to this dispute: servers keep public keys rather than the secret needed to sign in, and browsers and operating systems enforce which service can use a credential. A convincing imitation of a login page therefore doesn't receive the reusable password that a person might otherwise type into it.
Apple's security documentation describes what stays on each side of the connection. Registration creates a public and private key pair. The server stores the public key, while the private key stays with the user's credential system. Touch ID or Face ID can authorize its use without sending that private key to the website.
The Non-Functional essay acknowledges those advantages and describes generating a passkey with free software and sharing it with a friend. Its objection concerns the restrictions websites might impose later. That is a prediction about service policy, and the essay's examples involving X and Netflix should be read that way. They aren't announcements that either company has adopted the proposed restrictions.
The essay recommends time-based one-time passwords, usually supplied by an authenticator app, as an alternative. That choice gives up a security property. NIST's authentication guidance says manually entered one-time codes aren't phishing-resistant because an impostor site can relay a valid code to the genuine service. A short expiration window doesn't prevent that relay during the window. Developers weighing the essay's recommendation need to account for the attack it leaves possible, alongside their users' concerns about credential control.
One flag cannot establish trust
In a footnote, the essay identifies AT as the flag associated with its description of attested passkeys. WebAuthn Level 2 defines it as indicating that attested credential data is included. That data carries the new credential's identifier and public key, alongside an authenticator identifier. Whether a trusted authority vouches for the authenticator is a separate question, answered through the attestation statement and its verification.
The authentication rules require AT to be unset in ordinary login assertions. If you used it as a continuing certificate of device trust, your implementation would reject normal login messages. A field whose name contains "attested" still needs to be interpreted according to its definition.
Registration and later logins send different evidence
WebAuthn Level 3 lets a service express an attestation preference when creating a credential. The default is none. Other options request direct, indirect or enterprise attestation. Those choices affect the evidence obtained during registration. The ordinary login request instead asks for a signed response to a challenge and can require user verification.
A service that accepted a credential without provenance evidence cannot obtain that missing registration evidence simply by demanding an AT flag on the next login. It could change its policy and require users to enroll acceptable credentials again, or reject credentials using information it already retained. Those would be service decisions with consequences for users. This is the implication of the separate registration and authentication operations, rather than an automatic power granted by every passkey.
The essay also folds firmware and operating-system approval into its account of remote attestation. In Apple's 2022 introduction to passkeys, the company told developers that the new platform passkeys would not provide an attestation statement, unlike its legacy platform credentials. That is a dated statement about consumer credentials. Apple separately documents enterprise passkey attestation. Its configuration names the relying parties, meaning the services, for which the managed device may provide that evidence. The configuration applies to managed devices, with specified enrollment types. It documents an explicit enterprise policy, rather than a requirement attached to every consumer passkey.
Export already exists, with compatibility conditions
The FIDO Alliance's credential-exchange specifications cover transfers of passwords and passkeys between credential managers. That matters because the ability to use a credential on another device and the ability to move it to another provider are different operations. A manager's sync feature alone doesn't establish that you can leave the manager with your credentials.
FIDO's 2024 Credential Exchange Protocol working draft describes an importer requesting credentials and an exporter encrypting the transfer. It addresses the insecure file formats and inconsistent structures historically used to move passwords. The draft also recognizes that device policy or a destination's algorithm support can prevent some credentials from migrating. A transfer standard defines a route between providers, with conditions on what can travel.
Bitwarden's passkey help says stored passkeys are included in its JSON exports and can be imported into a Bitwarden account. It also documents direct mobile transfer through FIDO's Credential Exchange Protocol on iOS 26 and later, and Android 14 and later. Both applications must support the protocol. A user planning a move needs compatible apps at both ends.
Bitwarden's import instructions describe moving credentials from Apple's Passwords app on iOS 26 and later: select the app's export-to-another-app option, choose the passwords and passkeys, then select Bitwarden as the destination. The Android instructions start from Bitwarden's import menu. Neither flow establishes universal portability across every manager. They do establish that provider-to-provider passkey transfer is a present feature, rather than a purely theoretical answer to lock-in.
File exports have their own limitations. Bitwarden's export documentation warns that passkeys created before version 2024.3.1 include an incrementing counter. An old exported copy may be rejected if its counter no longer matches what the service expects. It also distinguishes encrypted exports restricted to the original account from password-protected exports that can be imported into another Bitwarden account. "Export available" still leaves details to inspect.
Recovery can impose a more immediate dependency
Apple says iCloud Keychain syncs passkeys between a user's devices with end-to-end encryption using keys unknown to Apple. Its recovery documentation describes recovering an escrowed keychain using the account credentials, an SMS to the registered number and the device passcode. For someone replacing a lost phone, access to that account and its recovery factors is an immediate concern.
For developers, OWASP's passkey guidance recommends that most public applications avoid attestation and authenticator-model allowlists. It also says the account's security is limited by its weakest recovery route. A service can deploy phishing-resistant login and then undermine it with a weaker reset process. OWASP also recommends allowing multiple authenticators and checking that a usable authentication or recovery method remains before the final passkey is removed. Those credential-management requirements can be implemented and tested by a development team today. They address the person who loses a phone or changes a credential provider, without assuming all users have the same hardware or recovery options.
The next useful evidence will be which managers support working transfers in both directions, and which public services actually require authenticator provenance. Bitwarden documents a transfer path, while OWASP recommends avoiding attestation for most public applications. Watch those behaviors in the products people use. A policy that rejects previously accepted credentials deserves scrutiny when it appears, with the affected devices and recovery route named.