# Passkeys are a trap. Do not use them **URL:** https://discuss.privacyguides.net/t/passkeys-are-a-trap-do-not-use-them/41415 **Category:** General **Tags:** article **Created:** 2026-10-14T01:37:37Z **Posts:** 36 ## Post 1 by @Mxyzptlk — 2026-10-14T01:37:37Z I’d be interested to know what others think of what this article says about passkeys and whether they should actually be used. > **[Passkeys are a trap. Do not use them.](https://nonfunctional.substack.com/p/passkeys-are-a-trap-do-not-use-them)** > > Intended audience: non-technical citizens of the web --- ## Post 2 by @Sorge — 2026-10-14T01:56:18Z tl;dr: attested passkeys can be used by platforms to force users into software they wouldn’t choose themselves. We already have this kind of limitation with exactly the same services the author mentions. You can’t watch Netflix with all features just in any browser — it requires a specific DRM module. I don’t see why this is a big deal: in those cases we either use a specific browser for specific platforms or avoid platforms that demand things we don’t want to do. So on first reading it sounds like "don’t use web browsers because some websites might require one specific browser and you shouldn’t be forced to use software you haven’t chosen.” Am I missing something? --- ## Post 3 by @Menkork — 2026-10-14T02:10:07Z It seems to be a technically informed piece, but if I’m being kind, I’d call a bit of it speculation at best, or conspiracy brained at worst. And in some instances, it’s misleading, especially the on we don’t have real control over our passkeys, that attestation allows websites to inspect or prohibit arbitrary software, or that passkeys are somehow going to force everyone onto approved operating systems. There’s a pretty big leap between what the technology is capable of and what the author is suggesting will happen. --- ## Post 4 by @Sorge — 2026-10-14T02:33:27Z > it’s misleading, especially the on we don’t have real control over our passkeys It’s truly misleading. At the same time I can see where it comes from. There are edge cases with passkeys where I genuinely stop understanding what’s happening. Like why 2FA passkeys for Proton work when created in Google Password Manager but not in KeePass. Why PRF works on a device but stops when used from another device via Bluetooth, and so on. We’re probably still in the early stages of standardization, so it feels a lot less straightforward, which likely leads to this kind of conspiracy thinking --- ## Post 5 by @Natha — 2026-10-14T03:15:49Z Ah, I knew that this Substack post would pop up on our Discourse at some point. A nice read for sure, but also an audacious one (it ain’t easy attacking the supposedly new go-to authentication standard on the clear internet). Here we are then, there are definitely things to be discussed about it. As an example, I didn’t know the existence of some of the mentioned flags and mechanisms developed by FIDO for the WebAuthn API that make passkeys what they are today. Also, I get the mood in the comment sections. Like some cliché meetings could have been summarised in one email, I do agree that the post could have been shorter, while also making sure not to give the feeling of reverse-UNOing your initial critical analysis (aka what was demonised at the beginning of the article ends up becoming less evil/more positively endorsed when you’re done with your reading). By the end of the paper, it’s then not surprising that some readers feel like the whole thing only reinforced the general trust we’ve been putting so far in passkeys (me included). That being said, I think there are two things to retain from the post: 1. If you do trust your 2FA TOTP system already in place (including of course your authenticator app of choice, be it Ente Auth or else), you don’t have to be forced to switch to passkeys. This system is safe, for as long as the 2FA is a real 2FA (generated on a separate device, which can even be isolated/put offline if necessary) and still combined with a strong password (that you will, of course, save in your favourite password manager :locked_with_key:) 2. FIDO has laid down the tools that could allow some of the big ones[[1]](#footnote-171379-1) to force their users to switch to a passkey, and so enforce some remote policies that aren’t compatible with a total sovereignty and control over your credentials (that always comes with any other type of authentication system). Knowing who is a member of the FIDO Alliance, this is not a surprise for anyone. Right? :face_without_mouth: 3. I lied. There’s a third take: hail to our venerable hardware keys that still give us the same industry standard level of protection we deserve, while also being FIDO2 compliant. The good old YubiKeys are still undefeated, but if I may give a quick shoutout to a real, cheaper alternative to Yubico, here’s [token2](https://www.token2.com/). For half the price of a YubiKey, you can get a Swiss-made (gov-compliant if needed) hardware security key that works exactly like your good old YubiKeys. And their support is also top-notch. _:rainbow: Pro tip, only for the most adventurous: you can also use your hardware crypto wallet, like the [Trezor Safe 7](https://trezor.io/guides/bonus-tools/using-your-trezor-as-a-security-key-fido-2-and-u2f?srsltid=AU7gw4UMWDK5b_UN3HuI9_cluVz_ymPsdxu8pGpUNxyruoFRKLK52obN) or any other Trezor (only the Model One isn’t FIDO2 compliant), as a FIDO2/U2F security key._ _Works like a charm._ :rainbow: No, I’m not gonna start a thread on the Ledger ongoing apocalypse, that will be for another time. Just know that it’s bad. Like, really, really bad. Like, the whole EU Market may be compromised. So. To summarise: - Enjoyable read, liked the writing style and tone of the author. - Learned a few new things that went below my (our?) radar, regarding the few hypothetically problematic flags. - For now, I don’t necessarily feel in danger of being trapped in an ecosystem. I trapped myself voluntarily by joining the Apple Silicon revolution 5 years ago, and the usage of passkeys with the secured enclaves of all of my devices has been blissful so far. - Whenever possible, I always add one or two backups of my passkeys to my hardware security keys or crypto-thingy. - Remember people: back in 2018, Google erased their motto “Don’t be evil” from the preface of their of code of conduct, while retained it in the last sentence. Think what you want about this, but I would be surprised if the vast majority of us, in our community, would nowadays blindly trust any of these big tech companies. Sooo, see you on Fluxer @jonah ? Thanks to your email, I am finally back. Never meant to leave in the first place, but life was on the way and another Discourse community unexpectedly took all of my focus away for a few months. So, to everyone who was super nice to me with my very first post in the forum, thanks again for the kindness :heart: I’m looking forward to (re)start a regular activity in the community. PS: @Sorge let’s just hope that this standardisation won’t become yet another mess like, I don’t know, what happened with the introduction of the [USB-C](https://en.wikipedia.org/wiki/USB-C). “One cable to rule them all…” they said… but who knows if the inside of The cable is made of optical glass or made of thin air. Edit: adding the following quote and link, as it is a must-read. > [@shadowwwind](#): > > I recommend this response by a person that works in the standard groups (they are employed at Apple) [Ricky Mondello: "If you actually read the “Passkeys are a trap. Do…" - Hachyderm.io](https://hachyderm.io/@rmondello/117428258722253709) * * * 1. (AMAMX? Where are we with the letters these days?) [↩︎](#footnote-ref-171379-1) --- ## Post 6 by @Sorge — 2026-10-14T03:52:30Z oh, I guess there’ll be a few more years of mess. Right now I need one more backup YubiKey, but I can’t bring myself to buy it because of the coming PQC update and the mess that’ll follow: — some websites switching to the new standard while others still require old passkeys — YubiKey finding bugs in the first generations of PQC firmware and asking you to buy new ones, and so on --- ## Post 7 by @Kris — 2026-10-14T04:26:16Z > Lack of neutral advocacy A central point of criticism: The FIDO Alliance includes Big Tech, interests close to intelligence agencies, and banks – but no consumer protection organizations. In contrast to the W3C (with public interest groups and Tim Berners-Lee). The motivations of the members: Big Tech wants to sell convenience, banks want to get rid of liability, and intelligence agencies want to track. Also my feelings about this standard --- ## Post 8 by @Sorge — 2026-10-14T04:36:49Z “Including big tech” does not mean “excluding neutral advocacy”. Bitwarden, Mozilla, 1Password are there too. --- ## Post 9 by @shadowwwind — 2026-10-14T06:35:28Z I recommend this response by a person that works in the standard groups (they are employed at Apple) [Ricky Mondello: "If you actually read the “Passkeys are a trap. Do…" - Hachyderm.io](https://hachyderm.io/@rmondello/117428258722253709) > [@Kris](#): > > In contrast to the W3C (with public interest groups and Tim Berners-Lee). A vital part of the spec, WebAuth, literally is work of the W3C [FIDO User Authentication Specifications | FIDO Alliance](https://fidoalliance.org/specifications/) > [@Sorge](#): > > Bitwarden, Mozilla, 1Password are there too. And not only there, Bitwarden, 1Password and Dashlane were the driving force behind the new transfer API, which is now implemented by both Apple and Google [Credential Exchange Format](https://fidoalliance.org/specs/cx/cxf-v1.0-ps-errata-20260309.html) --- ## Post 10 by @dngray — 2026-10-14T06:41:49Z i got about 25% of the way into that “Passkeys are a trap. Do not use them” article, to the bit where they were praising TOTP. The issue is that TOTP does not have any protection against phishing. The first comment was “Holy fuck, dude, boil it down! 5000 words later, eyes glazed” which is :100: correct :laughing: Tbh, I just use a mixture of both TOTP for low security, and Yubikey for higher security situations. Would be nice to trade out the Yubikey for something better some day. I do agree though storing credentials _on_ the device, eg some sort of chip inside the phone or laptop is kinda crap if you have multiple devices, for that I only really see a security key /w NFC being a viable option. > [@shadowwwind](#): > > I recommend this response by a person that works in the standard groups (they are employed at Apple) [Ricky Mondello: "If you actually read the “Passkeys are a trap. Do…" - Hachyderm.io](https://hachyderm.io/@rmondello/117428258722253709) Which frankly is more realistic. If you want to go conspiracy [the other way why not](https://hachyderm.io/@ela@infosec.exchange/117431878916645311). :laughing: --- ## Post 11 by @shadowwwind — 2026-10-14T06:53:53Z > [@dngray](#): > > If you want to go conspiracy [the other way why not](https://hachyderm.io/@ela@infosec.exchange/117431878916645311). :laughing: That is both a hilarious response and a real possibility I vaguely remember that being a thing with anticheat software. ;D --- ## Post 12 by @Sorge — 2026-10-14T07:05:43Z > [@dngray](#): > > The issue is that TOTP does not have any protection against phishing Could you provide an example of a phishing attack with TOTP? The examples I’ve read about were so targeted that I’d probably recommend the attacker just ask me to tell them the secret directly and not bother with all that effort, --- ## Post 13 by @dngray — 2026-10-14T08:20:41Z One example would simply be a phishing page that is acting as a proxy and passes through the TOTP code to the real website. That would then give the attacker a valid session. --- ## Post 14 by @kabob3801 — 2026-10-14T22:11:57Z A rebuttal to this article has been released > **[Passkeys Are Not a Trap](https://scotthelme.co.uk/passkeys-are-not-a-trap/)** > > A post called Passkeys are a trap. Do not use them. has been doing the rounds over the last few days, making it pretty high on Hacker News, and I've had it sent to me many times with an 'is this true?' kind of vibe. It's written for --- ## Post 16 by @jonah — 2026-10-14T23:11:08Z > [@Sorge](#): > > We already have this kind of limitation with exactly the same services the author mentions. You can’t watch Netflix with all features just in any browser — it requires a specific DRM module. I mean I would certainly argue this is very problematic though. --- ## Post 17 by @Sorge — 2026-10-14T23:17:32Z Why? I don’t struggle with companies having their own rules for their clients, but I don’t know what your experience is. Upd. anyway, my point was that passkeys don’t add anything here: it’s not the case that passkeys change how things work today, so passkeys are not a trap. --- ## Post 18 by @strypey — 2026-10-15T03:48:42Z > [@Sorge](#): > > Bitwarden, Mozilla, 1Password are there too. They all count as “Big Tech” these days. Especially Mozilla. Who have been; - Predominantly funded by Goggle and other DataFarming companies since Mozilla corp was set up to receive those funds. - Pushing proprietary components and/or privacy-violating anti-features into vanilla FireFoz for almost as long. - Often partnering with dodgy companies pushing proprietary or DataFarming products or services - Bandwagon-jumping. Last week the metaverse. This week ActivityPub. This morning “AI”. Meaning they waste donated funds building all sorts of under-designed slop. Much of which gets pushed into FF while its trending, then abandoned when they jump on the next hype train. - Paying their CEOs millions of $ a year, even while they lead the organisations down these dead ends. The managements of Mozilla’s legal entities long ago pissed away the credibility the Mozilla name once carried. 1Password is [fashware](https://www.flyingpenguin.com/dhh-nazism-funded-by-1password-vp-who-wrote-honest-security/). So their involvement doesn’t inspire much confidence. BitWarden I known much less about, but they have a commercial service to sell. Also see their Wikipedia page, which links to recent articles suggesting they’ve been taken over by Business Idiots, like Mozilla, and started to move away from being fully Free Code. So their participation is neutral, at best. --- ## Post 19 by @Sorge — 2026-10-15T04:07:55Z OK, so even if for a second I try to put on your hat, it means paying DHH automatically makes you big tech. The word just means “companies I don’t like,” I guess. Besides this, even if someone agreed with every point in your post, it still doesn’t contradict the argument it tries to oppose: > “Including big tech” doesn’t mean “excluding neutral advocacy.” Bitwarden, Mozilla, 1Password are there too. ![image](https://forum-uploads.privacyguidesusercontent.com/original/3X/f/4/f4b4f15c02759beaed241a203fe79c57ad7f3bbe.jpeg) --- ## Post 20 by @dngray — 2026-10-15T06:09:05Z > [@Sorge](#): > > OK, so even if for a second I try to put on your hat, it means paying DHH automatically makes you big tech. The word just means “companies I don’t like,” I guess Which of course doesn’t include vaultwarden and using official bitwarden apps does it where does DHH get my money in that model. --- ## Post 21 by @Damariobros — 2026-10-16T20:02:22Z I’m no expert, but I’ve done a fair bit of poking around and can say pretty confidently that yeah this dude is wrong. Attestation only exists to prove that a passkey is device-bound. In other words, that it lives in secure hardware and cannot be exported or synced or backed up or copied by any means whatsoever. Passkeys enrolled in a YubiKey are always device-bound for obvious reasons, and YubiKeys do provide attestation when requested. But I don’t think that should come as a surprise to anyone. YubiCo’s attestation certificate proves that the passkey was created in a YubiKey, which is secure hardware that does not allow exports of passkeys under any circumstances. Passkeys enrolled through Azure using Windows Hello for Business on a Windows computer with a TPM can provide attestation, provided relevant policies are set. Microsoft’s attestation certificate proves that the passkey was enrolled in a TPM on an Azure-managed Windows computer with Windows Hello for Business, and the passkey is non-exportable. Also, for what it’s worth, any passkey which is enrolled through Windows Hello on a consumer PC with a TPM is always device-bound, but it provides no attestation. iOS devices can provide attestation if a password manager app with a proper configuration is used to enroll device-bound passkeys in the Secure Enclave, but there is currently no such app on the App Store that can do this, and enterprises where this is used are using their own in-house apps for it. Apple’s attestation certificate proves that a passkey was enrolled in the Secure Enclave as a non-exportable key. Because you cannot export, copy, backup, or sync such passkeys through any means whatsoever, that means that if anything happens to that device, be it going through the washer, a forgotten passcode, or a stolen phone, the passkeys are gone. This would be fine if the passkeys are optional and users are still able to sign in with a password+TOTP or email sign-in or some other sign-in method, as is currently the case for the majority of websites that have adopted passkeys, but if companies want to go full passkey-only sign-in, then synced, exportable passkeys are non-negotiable If companies started enforcing passkey-only sign-in and requiring device-bound attestation for consumers so they can’t share, sync, backup, or export their passkeys, they are ASKING for a tsunami of lockouts hitherto undreamt of. It will not end well. --- ## Post 22 by @Sorge — 2026-10-16T20:57:09Z I agree, but would add some notes — mostly to check if I’m getting this right. > Attestation only exists to prove that a passkey is device-bound. As I read it, this is practically true but technically not. Currently most synced passkey apps (Apple Passwords, Google Password Manager, etc.) send none for attestation. But technically attestation and transferability are different properties: > User Present (UP, 0x01), bit 2 is User Verified (UV, 0x04), bit 3 is **Backup Eligibility** (BE, 0x08), bit 4 is Backup State (BS, 0x10), bit 6 is **Attested Credential Data** (AT, 0x40), and bit 7 is Extension Data (ED, 0x80). From [BE and BS Flags Explained](https://mojoauth.com/blog/webauthn-be-bs-flags-synced-vs-device-bound-passkey) Practically, as I understand it, companies today still use BE in the attestation chain, because the main players, Apple and Google, [don’t handle AT data](https://developer.transmitsecurity.com/guides/user/passkey_attestation) _in their password managers_ . But I guess they use them outside their password managers (wait for it). > If companies started enforcing passkey-only sign-in and requiring device-bound attestation for consumers so they can’t share, sync, backup, or export their passkeys, they are ASKING for a tsunami of lockouts hitherto undreamt of. It will not end well. A notable example is PayPal: they prohibit device-bound passkeys for signing in, only for 2FA. Apple and Google passkeys can be used for signing in though — probably, as you said, to avoid locking out less careful users. But here’s a notable opposite example — Apple: they use apple-device-bound passkeys for signing into iCloud on the web, and no other passkey is accepted. Non-Apple device-bound passkeys can be used as 2FA but not for signing in. It seems Google does something similar: on Android they create a device-bound passkey after signing in, which is listed in account settings alongside other (non-device-bound) passkeys, but with a different icon. I think this shows that passkeys are flexible enough that companies do what they usually do. Netflix uses passkey features to protect copyrighted content, Apple does its Apple thing and keeps users inside the ecosystem. Passkeys are neutral and flexible enough to let people do whatever they want. --- ## Post 23 by @Natha — 2026-10-16T23:25:55Z > [@dngray](#): > > The first comment was “Holy fuck, dude, boil it down! 5000 words later, eyes glazed” which is :100: correct :laughing: > > Tbh, I just use a mixture of both TOTP for low security, and Yubikey for higher security situations. Yep. And, in the end, it always depends on your :sparkles: Threat :unicorn: Model :sparkles: Passkeys for the common people are a security revolution. Does it mean that it kills any alternative? Nope. It depends. > [@shadowwwind](#): > > ![](https://forum-cdn.privacyguides.net/user_avatar/discuss.privacyguides.net/dngray/48/21_2.png) dngray: > > > If you want to go conspiracy [the other way why not](https://hachyderm.io/@ela@infosec.exchange/117431878916645311). :laughing: > > That is both a hilarious response and a real possibility I vaguely remember that being a thing with anticheat software. ;D Social Engineering will never get old. And yet, educating the future generation on the subject is still an utopia. --- ## Post 24 by @ZenByte — 2026-10-17T00:07:39Z So…just in general, what’s the consensus on passkeys? If I’m already using a strong password + TOTP and a site also offers passkeys instead, should I do it or avoid it? What about passkeys vs strong password + SMS/Email 2FA? Does the answer change if I’m using my password manager for passkeys like BitWarden, Proton Pass, KeePassXC/DX, which means the passkey is available across devices? --- ## Post 25 by @hashcatHitman — 2026-10-17T00:18:12Z > [@ZenByte](#): > > If I’m already using a strong password + TOTP and a site also offers passkeys instead, should I do it or avoid it? I think the general sentiment is that synced passkeys are preferable over password + TOTP due to being more phishing-resistant (+ more resistant to user error). Non-synced passkeys (i.e. yubikeys) are a decent option for 2FA, but using them for logins is potentially risky (due to being locked out if lost/destroyed). > [@ZenByte](#): > > What about passkeys vs strong password + SMS/Email 2FA? TOTP \> SMS/Email 2FA, so… passkeys again. I don’t know if SMS is better than email or if email is better than SMS. Both sound like terrible options. But I do know that sometimes, you aren’t given any other choices. > [@ZenByte](#): > > Does the answer change if I’m using my password manager for passkeys like BitWarden, Proton Pass, KeePassXC/DX, which means the passkey is available across devices? Yeah, as above. The EFF made some articles about passkeys: - [What the !#@% is a Passkey?](https://www.eff.org/deeplinks/2023/10/what-passkey) - [Passkeys and Privacy](https://www.eff.org/deeplinks/2023/10/passkeys-and-privacy) It is, as always, best to think about these things in terms of threat models. You can also test out passkeys on these websites: - [https://www.passkeys.io/](https://www.passkeys.io/) - [https://webauthn.io/](https://webauthn.io/) --- ## Post 26 by @ZenByte — 2026-10-17T00:28:47Z Yeah, I’ve been focusing on the phishing protection of passkeys. But it still feels like it’s less secure. Before, someone would have to break into both my password manager and separate TOTP authenticator to get into my account. Now all they need is my password manager and they’re in. Sure, my password and TOTP seed could also leak from a data breach, allowing an attacker to bypass my password manager and authenticator. …but then again, every site I’ve used still allows you to login with your password even after enabling passkeys, so the threat of a data breach is still there even if I’m personally using the passkey. --- ## Post 27 by @hashcatHitman — 2026-10-17T00:33:58Z > [@ZenByte](#): > > Before, someone would have to break into both my password manager and separate TOTP authenticator to get into my account. Now all they need is my password manager and they’re in. For most people, a phishing attack is a much more likely event. It’s easy to miss, but an example of this was already posted in this thread (link is inside the rebuttal): [Troy Hunt: A Sneaky Phish Just Grabbed my Mailchimp Mailing List](https://www.troyhunt.com/a-sneaky-phish-just-grabbed-my-mailchimp-mailing-list/) Troy Hunt is the guy behind [https://haveibeenpwned.com/](https://haveibeenpwned.com/), by the way. It was really funny when it happened, finding out I was pwned via haveibeenpwned (from haveibeenpwned). > [@ZenByte](#): > > …but then again, every site I’ve used still allows you to login with your password even after enabling passkeys, so the threat of a data breach is still there even if I’m personally using the passkey. Nope! The site you’re currently using allows you to delete your password after you add a passkey. --- ## Post 28 by @ZenByte — 2026-10-17T00:35:30Z I stand corrected, every site minus 1. --- ## Post 29 by @Sorge — 2026-10-17T00:35:30Z > [@ZenByte](#): > > Does the answer change if I’m using my password manager for passkeys like BitWarden, Proton Pass, KeePassXC/DX, which means the passkey is available across devices? There are even more forks in what we can do. I was inspired by 2FAS Pass’s design, where they keep secrets on the phone but access them on desktop via an extension. And it looks like today any password manager can do the same with passkeys. In my case: — all passkeys are in a KeePass-like app on the phone — the database never leaves the phone except in encrypted backups — the database password is unique and only entered on this phone — all passkeys are used either on the phone or via Bluetooth for signing in on the laptop I prefer KeePass because there’s more control over backup encryption. But mostly any password manager can be used the same way, even Google Password Manager with E2E turned on, as long as it’s never used on another device except signing via bluetooth. I find it a kind of nice middle ground between device-bound and synced passkeys. > but then again, every site I’ve used still allows you to login with your password even after enabling passkeys Google with Advanced Protection and Microsoft with passwordless mode don’t. Apple requires a password with security keys, but never a password alone with 2FA turned on. There are also Tailscale and Discourse, which we’re using right now, other fully passwordless services. But looking at my password manager: it’s about 10% of services where I was able to replace TOTP with passkeys, and about 5% where I got a passwordless account. --- ## Post 30 by @hashcatHitman — 2026-10-17T00:51:11Z > [@Sorge](#): > > But looking at my password manager: it’s about 10% of services where I was able to replace TOTP with passkeys, and about 5% where I got a passwordless account. I just discovered this, by the way, if anyone else has been frustrated with trying to figure out which sites support passkeys and to what degree: [GitHub - ScottHelme/passkeys-directory: Open directory of websites that support passkeys — top 1M scope, no global-rank cap. Data source for whynopasskeys.com. · GitHub](https://github.com/ScottHelme/passkeys-directory) --- ## Post 31 by @Sorge — 2026-10-17T00:58:02Z Nice stats, but it’s different for privacy-focused apps. The sad fact is that privacy-focused companies copy successful mainstream services and are always a step behind. This is especially true for passkeys, since PRF wasn’t (isn’t?) well implemented in most password managers so unlike passwords, passkeys are harder to use for end2end encryption. --- ## Post 32 by @hashcatHitman — 2026-10-17T01:01:29Z Yeah, I don’t doubt it sadly. But I’m hopeful things will get better. (I do understand why Proton might not want to support passwordless login, also; they really don’t want anyone to make their login dependent on a passkey that they keep locked in Proton Pass… which… would then also depend on the same passkey) Also, what does PRF stand for? --- ## Post 33 by @Sorge — 2026-10-17T01:07:45Z > **[Passkeys & WebAuthn PRF for End-to-End Encryption (2026)](https://www.corbado.com/blog/passkeys-prf-webauthn)** > > WebAuthn PRF extension explained. Play with the Passkey PRF Demo, see OS & browser support status and learn how PRF enables end-to-end encryption Bitwarden uses it to decrypt the vault with passkeys. It’s also used by [filekey.app](https://filekey.app) (and [beta.filekey.app](https://beta.filekey.app), which looks pretty promising). And there’s [Typage](https://words.filippo.io/passkey-encryption/). Not sure I know of other successful PRF use cases in the consumer space. Also, as was said, passkeys aren’t PQC-ready, so even with these examples we can’t use them for long-lived encryption. UPD: well, PRF is used here for symmetric encryption, so encrypted data should be fine for PQC. But there’s a lot of asymmetric stuff around happening here too: like the asymmetric keys used by filekey for sharing and I don’t know much about that part. --- ## Post 34 by @Kris — 2026-10-17T03:16:31Z > 1. The “trap” would be an absurd self-shot The nightmare scenario (only “approved OS,” no LineageOS/GrapheneOS, no uBlock Origin) would lock out the majority of customers – no website operator has a financial interest in that. What a strange statement! We GrapheneOS users are not the majority at all, but a very small minority. How did the author come up with that? --- ## Post 35 by @Sorge — 2026-10-17T03:41:40Z It’s not about GrapheneOS. I think the Apple example from my previous post is the closest one: you can’t sign into iCloud with a passkey from a non-Apple device, but can with password + confirmation pop up from apple device. It’s more about Apple’s approach than about passkeys. Apple does the same thing without passkeys anyway. Another example of the same policy is that user can’t start the account recovery process from a non-Apple device. For apple it makes more sense to introduce a policy for Apple Stores to lend devices for the recovery process than allow it to be launched from a non-Apple device. ![image](https://forum-uploads.privacyguidesusercontent.com/original/3X/8/9/895b72258e1b89131292f160ea9aa7e7593f1956.png) --- ## Post 36 by @Sorge — 2026-10-17T04:09:23Z Checked it and it’s not quite what @ZenByte is talking about. In their terms “passwordless” means “can sign in without a password” but doesn’t mean “has no password at all”. Google/Microsoft/Tailscale’s true passwordless accounts where a password simply doesn’t exist and can’t leak is not the same thing