A Beginner's Deep Dive Guide to Entra Passkeys
speckx
23 points
27 comments
September 02, 2026
Related Discussions
Found 5 related stories in 54.1ms across 5,346 title embeddings via pgvector HNSW
- Passkeys were invented by engineers with zero understanding of consumer brain ksec · 485 pts · July 22, 2026 · 51% similar
- Opaque, Interoperable Passkey Records (and a Go API) gnabgib · 30 pts · July 20, 2026 · 47% similar
- (ADVANCED) Guide to not fucking up QR codes upofadown · 15 pts · August 12, 2026 · 41% similar
- Show HN: Anonymous age verification with passkey-powered encryption mikeysight · 13 pts · August 19, 2026 · 41% similar
- Automatic Key Verification meetpateltech · 22 pts · August 11, 2026 · 41% similar
Discussion Highlights (9 comments)
DylanMerigaud
Good point.
rf15
In my experience, for most basic services, Passkeys are absolute overkill: Your ability to recover your account without too much hassle usually beats having a key explicitely tied to physical hardware (even worse, your phone that you carry around in public). Besides, passkeys are also often used by companies like Microsoft to peddle their apps, because of course you have to have specific apps for it. Makes me all feel like passkeys are largely a convenient security excuse for vendor lock-in and siphoning personal information. OTP-Generators seem to be more generally applicable and less phone or company-bound.
tomjen3
For a company this may be a good idea, but for consumers this is a nightmare. It will be so easy to get locked out of your account.
VCFundedGenYer
Passkeys are a solid idea in theory - in practice they are a confusing mess. Basic users are incredibly confused by them. My recommendation still continues to be a very strong password + app based MFA.
treetalker
I sometimes consider the number of man-hours wasted every year by companies (such as Amazon and Dropbox) that repeatedly offer to convert passwords to passkeys, despite having already been declined (once, or even dozens or hundreds of times).
throw7
"Something you have"/"device bound" is not what I want if I don't control it. In the case of passkeys, I don't have access to the private key, so I consider that not controllable by me. I'm happy to be wrong if I am able to extract and import the private keys (it's what I do with TOTP now), but my understanding is designers of passkeys explicitly don't want users access to their own privkeys so they can tie them to physical objects. I get that, I don't want that. So passkeys are not something I'll ever use or useful or convenient to me.
jms703
whatever it takes to kill sms mfa.
Synthetic7346
I don't get the passkey hate in the comments. I just store it in Bitwarden, and it syncs across my phone, laptop and desktop. Has been a better experience than passwords
exabrial
Few observations about Passkeys after implementing them for a client... First, what surprised me is that during the enrollment process, the client is not required to sign a challenge and the server is not required to check it. There's some irony here. Adding this to the flow would be simple layered security, instead of complete reliance on the TLS channel. Something for the Internet Standards people to take into consideration. Next, passkeys are annoying the way most major websites use them. You can in fact, make a great login experience using passkeys, but not that way capitalone.com Google does (Sorry to pick on you two guys, but it's pretty bad). I won't even mention statefarm.com because their entire website is in a constant state of being javascriptastically broken. Websites treat Passkeys as an accessory, when really it should be the other way around. Passwords, and... sigh, sms, need to be treated as unwelcome accessories. To make a better user experience: 1: When enrolling a passkey, use the consumers name and permanent business key on your side. Something like `John Doe - PK501867` where PK501867 is an external customer identifier. 2: Lose passwords. Make this a secondary login method on your website, hidden. 3: Don't require SMS "2fA" if they use their passkey. You shouldn't be doing SMS anyway, so stop. 4: Don't use the "well known endpoints" for passkeys or anything related. It's an annoying and confusing consumer experience. Let the user initiate the login. Don't be clever. 5: Instead, just put a button called "Login with Passkey". When they click it, begin the auth flow in the browser. Use async RESTful calls with proper verbs (POST) and correct http signalling. If they authenticate, then redirect. If they don't, update the page but don't cause a navigation. This by far, keeps the browser 100% functional and follows a natural user experience. It pushes users to use their passkey.