--- url: 'https://www.corbado.com/blog/passkeys-sca-compliance' title: 'What SCA Requirements Mean for Passkeys (SCA & Passkeys III)' description: 'Explore how synced and device-bound passkeys meet SCA compliance in our latest blog, detailing their roles in secure online banking authentication.' lang: 'en' author: 'Vincent Delitz' date: '2024-04-15T19:51:20.306Z' lastModified: '2026-03-25T10:42:41.385Z' category: 'Passkeys Strategy' --- # What SCA Requirements Mean for Passkeys (SCA & Passkeys III) ## Overview: Strong Customer Authentication with Passkeys - Device-Bound vs. Synced Passkeys - Analysis of [PSD2](https://www.corbado.com/blog/psd2-passkeys) & SCA Requirements - [PSD3](https://www.corbado.com/blog/psd3-psr-passkeys) / [PSR](https://www.corbado.com/blog/psd3-psr-passkeys) Implications for Passkeys ## 1. Introduction: What SCA Requirements Mean for Passkeys After having analyzed, the differences between device-bound and synced passkeys in the first part of our series, and the specific requirements of SCA in the second part of our series, we now combine the two fields and work on the application and real-life conclusions for banks, fintechs and financial institutions. In the following, we will focus on a scenario where SCA applies to the use case of accessing online [banking](https://www.corbado.com/passkeys-for-banking) accounts. The goal is to find out the real-life legal applicability of passkeys. We start by taking a look at typical SCA architectures of banks today, learn why device-binding has been around for a while and how passkeys could serve as the next step in user authentication. ## 2. Current SCA Architecture of Online Banking Applications The European [banking](https://www.corbado.com/passkeys-for-banking) system for consumers can widely be divided between traditional banks with stationary branches and neo-banks that have evolved as app-first fintechs / banks that often do not have a desktop website or branches for [banking](https://www.corbado.com/passkeys-for-banking). | | **Traditional Banks** | **Neo-Banks** | | ------------------- | ---------------------------------------------------------------------- | --------------------------------------------------------------- | | Primary User Device | Desktop | Native App | | Primary Username | Account number Username | Mobile number | | First Factor | PIN or Password | SMS TAN (sometimes + PIN) | | Second Factor | SMS TAN Native App Push Notification eTAN / ChipTAN PhotoTAN / QR-Code | Native App Push Notification Public / Private Keypair | | Additional HW | eTAN / ChipTAN Generator PhotoTan / QR-TAN (optional) | - | | Recovery | In-Person Via Mail Post Offline / Online Identification | Security Password Selfie-Ident with Email Online-Identification | The array of authentication options has evolved considerably, but many traditional banks still rely on easily phishable knowledge factors as the primary security measure (e.g. PIN or password), which can give potential attackers access to user accounts. This [vulnerability](https://www.corbado.com/glossary/vulnerability) may allow them to circumvent further security layers, e.g. by exploiting less secure methods like SMS TAN for fraudulent purposes. For second factors in traditional banking, especially when focusing on native apps, “device binding” has been the standard. When the device was reinstalled from a backup (in case of a device change), the association with the banking app was lost causing a sub-optimal UX. ## 3. Device-Binding of Banking Apps As we have outlined above, banking apps that provide the second authentication factor via a native application, through methods such as scanning a [QR code](https://www.corbado.com/blog/qr-code-login-authentication), Photo-TAN, or receiving or generating a one-time passcode (OTP), user accounts are bound to a this specific mobile device. ### 3.1 Why are Banking Apps Device-Bound? The fundamental process of utilizing a native application as a second authentication factor involves generating a public/private key pair. This pair is then linked to the user's account on the provider's side by submitting the public key to the provider. This submission often occurs during the completion of the initial identification process or service registration, usually as part of the recovery mechanism mentioned earlier. The native application retains the private key to sign future challenges, one-time passcodes (OTPs), or push notifications. This process effectively demonstrates that the second factor of authentication, namely "possession," is securely maintained. ### 3.2 Where and How Should Private Keys in Native Apps be Stored to Fulfill SCA Requirements? Let’s first go back to remember the statements by the regulators to gather the corresponding requirements that apply in this scenario: - Implement adequate security features and prevent unauthorized use (#EBA2019.24) - Prevent unauthorized use (RTS Article 7) The only way to ensure the credentials’ safety was to use the hardware security modules provided by the operating systems (e.g. secure enclaves, TPMs, TEEs). They ensured that the keys would never leave the mobile phone because keys stored in these operating system hardware security modules are not exportable,durable (some of the settings configurable depending on the operating system) and are therefore not included in device backups. The private key storage in the hardware security module was necessary because there was no guarantee that the device was sufficiently protected to prevent an attacker from extracting the private key from the application storage of a [native app](https://www.corbado.com/blog/native-app-passkeys) – even from its “private space”(!= hardware security module). Since mobile devices are often backed up to desktop computers and cloud services, this presents a considerable security risk. There’s no assurance that these backups and cloud copies are secured in accordance with the stringent customer authentication standards mandated by [PSD2](https://www.corbado.com/blog/psd2-passkeys) regulations. Specifically, there may be no multi-factor authentication (MFA) guarantee, no encryption, and no measures in place to prevent unauthorized access. This is also outlined in #EBA2019.26: a device binding would be necessary to actually be able to identify that this specific key pair belongs to a specific user. The device-binding therefore does not constitute a requirement in itself. It evolved as consequence of storing the private key into the hardware security module in the mobile phone as the only way to fulfill secure storage requirement. Therefore, the resulting experience was that a device loss or device change would lead to losing the device binding. | **Storing Location of Private Key** | **General** **Storage** | **Hardware Security Modules** | | ----------------------------------------------------------------------- | ----------------------- | ----------------------------- | | Private key protected from other apps | yes | yes | | Private key protected from other apps on rooted device | no | yes | | Private key protected in cloud backup (or private key is not backed up) | no | yes | | Private key backups are 2FA protected (or private key is not backed up) | no | yes | The table above clearly shows that storing the private key in a hardware security module system is without alternative, leaving developers with no opportunity to enable secure key mobility between consumer devices. ## 4. Passkeys Fulfil All Generic Authentication Requirements To find out if device-bound and synced passkeys are compliant to SCA, lets go through all necessary steps and requirements we have laid out above in our definitions. Let’s first start with generic things that apply to both passkey types (device-bound & synced). - **✅ Two authentication factors (PSD2 Directive):** Passkeys authentication with [user verification](https://www.corbado.com/blog/webauthn-user-verification) enabled has two factors: The passkey is comprised of a public/private key pair and the private key is stored inside the hardware security module of the device (first factor: possession-based). Additionally, [biometric authentication](https://www.corbado.com/blog/passkeys-biometric-authentication) is required (second factor: inherence-based). In case of biometrics failure or unavailabilty, a PIN / password (alternative second factor: knowledge-based) is required. - **✅ Two distinct authentication categories (EBA):** Passkeys combine possession with inherence or knowledge and therefore fulfil this requirement. - **✅ Two independent authentication factors (EBA):** Both factors are independent of each other and a breach of one of the factors does not risk the breach of the other. - **✅ Allowed form of biometrics are used in inherence factors (EBA):** Passkeys usually use fingerprint or face scanning on mobile devices which both are allowed forms of biometrics in inherence factors. Moreover, technological advancement is adding new identifications with increasing security (e.g. Apple’s Optic ID which authenticates the user’s iris). - **✅ Low probability of biometrics going wrong (EBA):** Biometric information on mobile devices never leave the device, they are protected in dedicated chips. Also the sensors have a probabilities in the area of 1:1.000.000 to wrongly identify the actual owner of the device. They quickly fall back to requesting the PIN in case biometrics go wrong. The PIN on the other side is protected by exponentially increasing waiting times on wrongly entered codes. Passkeys fulfil, all general requirements to constitute an authentication process that is SCA-compliant. For possession factors via apps & private-public cryptography, the EBA has provided some additional requirements that have to be checked (#EBA2019.24-26), which we will do in the following paragraphs. ## 5. Possession Factor Analysis: Passkey Linking to Device or User The last requirement that needs to be checked is that the passkey is safely associated with the user, there is proof of possession, and that the private key is securely stored with mitigation measures. Let’s go through them one by one: - **✅ Association with the user (EBA):** In our case the keypair is safely associated with the user. This is done by registering the public key with the service provider. - **✅ Proof of actual use of the possession (EBA):** In the case for passkeys, that’s quickly answered as fulfilled, as we create a cryptographically verifiable signature that can only be generated from somebody who is in possession of the private key (and PIN / biometrics). - **❓ Secure key store (EBA):** Two core questions emerge when analyzing the compliance of passkeys with the secure key store requirement: - **Prevent unauthorize use**: Is the private key stored securely with mitigation measures to prevent unauthorized use? - **Prevent replication:** Do we have measures in place to prevent the replication of the elements by an attacker? **Now we have reached the important distinction point between device-bound passkeys and synced passkeys.** ## 6. Why Synced Passkeys are SCA-Compliant Although They Are Not Device-Bound Passkeys in general are always stored in the hardware security module as we have discussed in the beginning of the article. Their only difference is the key-portability with cloud syncing. ### 6.1 Analysis of Differences in Key Storage and Portability Let’s unpack the differences by adjusting our table from above to include a column for device-bound and a column for synced passkeys. The core question we want to answer with this analysis is: **What are the security differences between device-bound passkeys and synced passkeys?** | **Security Feature** | **Device-Bound Passkeys** | **Synced Passkeys** | | ------------------------------------------------------ | ------------------------- | ------------------- | | Private key stored in hardware security module | yes | yes | | Private key protected from other apps | yes | yes | | Private key protected from other apps on rooted device | yes | yes | | Private key protected in cloud backup | not backed up | yes | | Private key backups are 2FA protected | not backed up | yes | | Private key available on multiple devices | no | yes | The main difference is that the private keys will be part of backups and can be access from multiple devices. **For device-bound passkey we can therefore conclude that the secure storage requirements are fulfilled**. The consequences of the storage architecture is that they can only ever be used on one device. To answer the question whether synced passkeys satisfy the secure key storage requirement, we have to take a look at the technology behind the synchronization feature. ### 6.2 Analysis of the Security of Synced Passkeys Google and Apple have spent significant effort on designing a secure ecosystem for passkeys. We will analyze in-depth the implementation and efforts of Apple, but most of the design principles apply equally to Google. **Which steps are needed to use synced passkeys on Apple devices with iCloud (prevent unauthorize use)?** The following requirements need to be fulfilled to sync passkeys across Apple devices via the [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain) 1. **New OS version:** The device runs on [iOS](https://www.corbado.com/blog/webauthn-errors) 16+, iPadOS 16+, macOS 13+ or tvOS 16+ 2. **Enabled passcode:** The device’s passcode needs to be set (then, the device is protected and locally encrypted). 3. **Enabled [2FA](https://www.corbado.com/blog/passkeys-vs-2fa-security):** [Two-factor authentication](https://www.corbado.com/blog/passkeys-vs-2fa-security) needs to be enabled for the iCloud account by either adding a verifying mobile phone number or hardware [security key](https://www.corbado.com/glossary/security-key) (multiple numbers & security keys can be added). 4. **Enabled Keychain:** The Apple [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain) needs to be enabled. After making sure these steps are fulfilled, iCloud accounts essentially conform to SCA automatically. The first factor of authentication is the iCloud account’s password, and the second factor is an SMS TAN / hardware [security key](https://www.corbado.com/glossary/security-key). With the activation of the [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain), all devices that need to be part of the synced Keychain must be enrolled either with another device or with [2FA](https://www.corbado.com/blog/passkeys-vs-2fa-security). Subsequently, all keys generated within this iCloud account are synced securely, ensuring that private keys never leave any device unencrypted. They can only be securely synced from one [secure enclave](https://www.corbado.com/glossary/secure-enclave) to another. **How can access to the iCloud Keychain be restored prevent replication)?** In case the user needs to restored access to their iCloud Keychain, there can be two scenarios depending if other connected / trusted devices are available. - **Scenario 1: Other trusted devices available:** Access on a new device can be restored by logging into the iCloud account and then additionally confirming the new device on a connected / trusted device. - **Scenario 2: No other trusted devices are available:** - **Use the escrow contact & recovery code:** There are two methods to additional methods to protect the data. You can add an escrow contact that will confirm recovery together with you or you store a recovery code at a secure, physical location which you can use to restore your account. - **Last resort:** To prevent loss of access, the iCloud Keychain can be restored with the Apple iCloud Keychain escrow functionality (!= escrow contact from above), but there is a strong process in place that protects the last resort backup. The following steps are required to be done in this process: - Successful login with iCloud account password and second factor - Provision of last used device passcode on any of the user’s devices Note the following: - After 3-5 wrong attempts the escrow record is locked. - Apple customer support needs to be contacted for more attempts - After a total number of 10 wrong attempts the escrow record is deleted unrecoverable - During all attempts it is cryptographically guaranteed that Apple cannot read the device’s passcode or the stored private keys The escrow data are stored in [government](https://www.corbado.com/passkeys-for-public-sector)- / enterprise-level HSM lusters separated from other iCloud / phone backup records. This means that accessing the last resort escrow requires three factors (Password, second factor SMS OTP / [security key](https://www.corbado.com/glossary/security-key) and passcode). **What happens with my passkeys when the device is stolen (prevent unauthorized use)?** In case a device holding passkeys is stolen, we need to distinguish two scenarios: - **Scenario 1: Device’s passcode is not known to the theft:** Devices that use passkeys are protected with the passcode that is a prerequisite to enabling passkeys (see above). Therefore, all apps and passkeys are protected by it. Unlocking via brute-force attempts is also not possible due to delay when trying wrong passcodes. - **Scenario 2: Device’s passcode is known to the theft:** In case the device is stolen and the passcode has been observed before by the theft, passkeys and traditional banking apps that rely on biometrics are at risk equally, because [device biometrics](https://www.corbado.com/blog/passkeys-local-biometrics) always fall back to the passcode. In an effort to further protect devices from theft after having eyewitnesses entering of the passcode, Apple has introduced “Stolen Device Protection” which protects the Keychain (and other critical functionality) by never falling back to passcode in unknown locations (away from home/work) thereby making use impossible. We can see that there is considerable effort to protect information inside mobile phone in case of theft, but are the information safe with Apple? **Can Apple access my passkeys (prevent unauthorized use of third-parties)?** Let’s analyze if Apple has access to a user’s passkeys. **Answer-first: Apple has no direct access to passkeys**. Just like passwords, passkeys are encrypted and stored in the user’s iCloud Keychain, where they aren't visible to anyone (including Apple). - **How does this work technically?:** Keychain items are transferred from device to device, travelling through Apple servers, but are encrypted in such a way that Apple and other devices can't read their contents. The actual entries within the Keychain are encrypted using AES-256-GCM. Several optimizations have been applied, so that metadata can be queried fast although all sensitive information is encrypted. - **How does an escrow work?:** Apple keeps an encrypted version of your iCloud Keychain. The decryption is only possible with a passcode, which Apple does not know. The brute-force protection is embedded into the hardware security modules by Apple, they explicitly state: _“These policies are coded in the hardware security module firmware. The administrative access cards that permit the firmware to be changed have been destroyed.”_ Using Apple as example we see that there is considerable effort to protect keys, store them securely and have mitigations in place to prevent malicious use. That’s why we conclude the following: - **✅ Do synced passkeys have a secure key store:** Let’s get back to the two core questions that emerged (already above) when analyzing the compliance of passkeys with the secure key store requirement: - Is the private key stored securely with mitigation measures to prevent unauthorized use? - **Yes**. - Do we have measures in place to prevent the replication of the elements by an attacker? - **Yes**. ### 6.3 Are All Synced Passkey Providers Secure? Over 99% of all passkeys currently created as synced passkeys are stored in the cloud services of Google and Apple. There are numerous security measures in place to enhance the security of these passkeys. The industry anticipates the integration of synced passkeys for Microsoft platforms as well; currently, passkeys on Microsoft are device-bound. These three operating systems are considered First-Party [Passkey Providers](https://www.corbado.com/blog/passkey-providers), for which there should be no security concerns. [Third-Party Passkey Providers](https://www.corbado.com/blog/passkey-implementation-password-managers), such as password managers like [1Password](https://www.corbado.com/blog/1password-passkeys-best-practices-analysis) or [Dashlane](https://www.corbado.com/blog/dashlane-passkeys), integrate with platforms through APIs. The security of their storage depends on the implementation but should also be a focus for the provider since they store passwords for consumers and enterprises, often including banking accounts. There is an ongoing discussion within the industry pointing out that some password managers do not comply with the standard when verification is required. This could lead to a future where some providers might be excluded by security-focused companies. Overall [synced passkey](https://www.corbado.com/blog/device-bound-synced-passkeys) providers can be overwhelmingly considered as safe as nearly all passkeys reside within First-Party-Providers. When passkeys import/export between providers should become reality those points need to be revisited. ### 6.4 Conclusion on SCA-Compliance of Passkeys Synced passkeys with [user verification](https://www.corbado.com/blog/webauthn-user-verification) activated are secure way of multi-factor authentication that can uphold the high standards that [Strong Customer Authentication](https://www.corbado.com/faq/sca-psd2-importance) (SCA) sets, even when the passkeys are synced to the cloud. **It is important to keep in mind that with advancing technology, older assumptions, and decisions of the EBA can be reinterpreted differently**. Very conservative traditional banking institutions have adopted a strict mindset regarding “device binding”. They leave the technical advancement and user experience improvements out of sight. In the opinion from 2019 under number #24 the EBA outlines: _Article 4(30) of PSD2 defines possession as ‘something only the user possesses’. Possession does not solely refer to physical possession but may refer to something that is not physical (such as an app)_ **In a more general sense now, a synced-passkey proves possession of the “Cloud account” that lies behind the passkey – which is something the user possesses but is not physical**. Apple and Google provide enough documentation about the protection of synced passkeys in their respective cloud accounts that they can be considered SCA-compliant. Therefore, the chain of trust is not broken for the vast majority of passkeys in the consumer market. The same assumption was stated by the EBA about the security of SMS OTPs when they assumed that mobile phone network providers put in considerable efforts to protect the reliability of the mobile phone network. This leads to the conclusion that the concern is not about the actual device but about the possession of the actual SIM card, despite numerous proofs indicating that SMS is not entirely safe. For years, this stance has remained unchanged, likely due to practicality reasons. SMS OTP remains the most accepted and convenient second factor authentication option for consumers due to its portability. Given the choice, consumers overwhelmingly prefer SMS OTP over other methods (80%), even when it incurs costs. Furthermore, in our discussion, we have not really touched on the fact that passkeys are a non-phishable authentication option. This is a dimension of authentication factor quality that has not yet received the attention that it should. Finally, we want to show a final comparison of the most important dimensions when comparing the two types of passkeys. | **Dimension** | **Device-bound** | **Synced** | | ---------------------------------------------------------------- | ------------------------- | ---------------------- | | First factor | Biometrics (Inherence) | Biometrics (Inherence) | | First factor fallback | Passcode (knowledge) | Passcode (knowledge) | | Biometrics fallback allowed | yes | yes | | Low probability of biometrics false-positives | yes | yes | | Second factor | Possession | Possession | | Two distinct authentication categories | yes | yes | | Passkey association with user | yes | yes | | Proof of possession | yes | yes | | Independence of factors | yes | yes | | | | | | Possession element | Keypair | Account | | Possession storage | Hardware security module | Keychain | | Possession storage security Unauthorized-use Prevent replication | Unexportable Unexportable | MFA/HSM MFA/HSM | > **Corbado's Position on PSD2/SCA and Passkeys:** Passkeys (both device-bound and synced) > can be SCA-compliant. Each institution must own its SCA risk assessment, but the > evidence is clear: passkeys inherently provide two SCA factors - possession (private key > in hardware security module or cloud keychain) + inherence (biometric) or knowledge > (PIN). The "possession" debate is nuanced but resolvable - the industry is landing in > three approaches: (1) **Passkeys as-is** (e.g. [Revolut](https://www.corbado.com/blog/revolut-passkeys), > [Finom](https://www.corbado.com/blog/finom-passkeys)) - inherence + possession via device with private key, (2) > **Passkeys + cookie/session binding** (e.g. [PayPal](https://www.corbado.com/blog/paypal-passkeys), > Comdirect) - extra possession signal for conservative interpretation, (3) > **Cryptographic binding (DBSC/DPoP)** - hardware-bound proof of possession, strongest > guarantee. No single "correct" interpretation exists yet. An outcome-based approach to > SCA is needed - focusing on demonstrable [phishing](https://www.corbado.com/glossary/phishing) resistance > rather than rigid factor categorization. > [Dynamic linking](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) remains a separate requirement for > [payments](https://www.corbado.com/passkeys-for-payment) even with passkeys. ## 7. Recommendations for Banks, Fintechs and Financial Institutions Passkeys are the future of authentication on the Internet. Banks, fintechs and financial institutions banks should start adopting this technology by collecting passkeys from their customers. We understand that for traditional banks, the step to start implementing passkey-first authentication with synced passkeys might be a major effort, but there are other options to begin with: - **Passkeys as a First Factor Replacement for PINs/Passwords:** Passkeys can serve as a first-factor authentication method, replacing PINs and passwords, which are easily solicited from customers or left unprotected in browsers. - **Passkey-First with SMS OTP:** Using passkeys in conjunction with SMS OTPs can significantly streamline recovery processes and reduce friction in cases of device loss or change. Passkeys can be retrieved from backups, and SMS messages can be received immediately after a SIM change. Replacing the first authentication factor with an unphishable one, such as passkeys, stops many cyber-attacks at their source. Starting the integration of passkeys into banking apps and websites is also beneficial to prepare for a future where passkeys are standard and ubiquitous (this scenario will sooner or later come). In the future, new approaches to device-binding being developed by the [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance) (e.g. CMTG keys) may provide additional options for enforcing device-linking at a cryptographic level. Here are the links to the other parts of our series: - Part 1 “Device-Bound vs. Synced Passkeys (SCA & Passkeys I)" - Part 2 "Analysis of [PSD2](https://www.corbado.com/blog/psd2-passkeys) & SCA Requirements (SCA & Passkeys II)" - Part 4 "[PSD3](https://www.corbado.com/blog/psd3-psr-passkeys) / [PSR](https://www.corbado.com/blog/psd3-psr-passkeys) Implications for Passkeys (SCA & Passkeys IV)" ## 8. How Corbado makes SCA-compliant Passkey Deployment practical The analysis above shows that both device-bound and synced passkeys can satisfy SCA requirements. But proving this in production — across thousands of devices, OS versions and user behaviors — requires operational visibility that most banks currently lack. ### Mapping SCA Factor Coverage in real Time Corbado's Device Trust dashboard gives banks a live view of how their authentication methods map to [PSD2's](https://www.corbado.com/blog/psd2-passkeys) SCA factors across their entire user base. Instead of relying on theoretical compliance arguments, banks can show regulators concrete data: which SCA factors each method provides, actual success rates, average authentication duration, and whether the method is [phishing](https://www.corbado.com/glossary/phishing)-resistant. ![Corbado Device Trust Dashboard](https://www.corbado.com/website-assets/corbado_device_trust_dashboard_42ce934484.png) The dashboard shows that [device-bound passkeys](https://www.corbado.com/faq/are-passkeys-device-specific) (the "passkeys as-is" approach from our analysis) achieve 99.1% login success with possession + inherence factors and zero step-up requirements. Synced passkeys with cookie/session binding reach 98.4% success while adding an extra possession signal for banks that follow a more conservative SCA interpretation. ### Configurable Trust Policies for your SCA Risk Assessment Since no single "correct" SCA interpretation exists, Corbado lets banks configure trust policies that match their specific risk appetite and regulatory relationship. Policies control both [passkey creation](https://www.corbado.com/blog/passkey-creation-best-practices) (which devices can create passkeys) and login behavior (when [step-up authentication](https://www.corbado.com/glossary/step-up-authentication) is required). ![Corbado Trust Policy Configuration](https://www.corbado.com/website-assets/corbado_trust_policy_80ad56409f.png) For example, a bank following the "passkeys + session binding" approach can require [step-up authentication](https://www.corbado.com/glossary/step-up-authentication) for synced passkeys on new devices while trusting [device-bound passkeys](https://www.corbado.com/faq/are-passkeys-device-specific) on known devices without additional friction. Shared or kiosk devices can be blocked from [passkey creation](https://www.corbado.com/blog/passkey-creation-best-practices) entirely. This maps directly to the three industry approaches discussed in this article — letting each institution implement its chosen SCA interpretation through configuration rather than code changes.