## 6 Limitations and Challenges in Passkeys
### Challenges
#### 6.1.1 Technical Challenges  
A significant part of the FIDO2 specification is that the private key is tied to a specific device when using passkeys. A concern that is shared across the papers covers the issue of the device storing the passkey becoming lost or damaged. In such a case, users may face difficulties accessing their accounts [6; 26; 71]. Traditional recovery mechanisms, such as security questions, do not align with FIDO2's principles of privacy and unlinkability and can therefore create barriers when recovering [26]. Backup options like recovery codes \begin{table}
\begin{tabular}{c c} \hline \hline
**Category** & **References** \\ \hline Technical & [8; 16; 26; 31; 39; 72; 77; 91; 92; 93] \\ \hline Usability & [10; 27; 45; 70; 94] \\ \hline User Perception & [7; 14; 89] \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Table overview of which papers touch upon passkey improvements with three subcategories for further specification. can undermine security if not properly managed [79]. There exist some potential solutions, one of them proposed by [26], which is the concept of multi-device credentials where the keys would be synchronized across devices using encrypted cloud storage, as already implemented today, for example, in Apple's iCloud passkeys. Another solution proposed by [6] is backup/fallback authenticators, which allow users to register multiple devices for redundancy. However, the lack of standardization concerning fallback authentication in case of, e.g., a lost or damaged device complicates the deployment, which is also one of the main usability concerns [73]. This is covered in more detail in Section 6.1.2. Despite the possible suggestions, efficient recovery mechanisms are yet to be standardized and are currently complex and costly [15]. Considering the smaller and older IT landscape, there are interoperability issues in heterogeneous environments, particularly in legacy systems [85]. Furthermore, some enterprise environments face difficulties in implementing secure configurations due to the need for hardware authenticators, which creates barriers in the authentication process [85]. Despite the ongoing effort for standardization to ensure compatibility across platforms, browsers, and devices, the lack of existing standardization makes uniform adoption across browsers, devices, and services significantly more difficult, where the compatibility efforts can cause integration issues and deployment challenges [73]. Furthermore, the problem is that integrating the existing authentication system adds another level of complexity [6]. From an adversary's perspective, these inconsistencies can sometimes even be leveraged to bypass protections, compromising users' security [29; 80]. The inconsistent implementation of passkey functionality across different browsers, such as Chromium-based browsers allowing multiple authenticators to connect during registration, potentially enables attacks. Additionally, Safari's mitigation against QR-based attacks highlights the fragmented nature in which various devices and browsers handle the FIDO2 protocols [30]. A critical timing attack on FIDO2 authenticators was discovered and mentioned by [29], where a vulnerability in key handle processing allows remote attackers to link user accounts across different services by exploiting time differences in key handle validation. Another report highlighted the potential for automated tools to assess server-side compliance with FIDO2 security goals, which could expose services to exploitation [77]. Overall, these findings underline the fact that there is a need for further standardization efforts to improve the technical security of passkeys. Due to implementation complexity and misconfigurations, FIDO2 authentication implementations may pose significant risks to the security and privacy of the authentication process. Furthermore, developers may misunderstand protocol requirements, leading to vulnerable implementations, including improper session management and reliance on incomplete libraries [77].