As someone who specifically works on second factor auth and enrollment... this article is pretty in line with what I see day to day. The authentication part is

As someone who specifically works on second factor auth and enrollment... this article is pretty in line with what I see day to day. The authentication part is "easy" because verifying possession of a private key is well understood, and there are various mature physical means of preventing the private key from being read directly. Stuff like on-board TPM's in phones and laptops, smartcards, and Yubikeys (and similar keys) all implement interfaces that can do encryption operations using the private key on the device so that the private key is hardware-protected. Of course, if you're an engineer working on said hardware protection, I'm sure this problem is anything but "easy," but from my perspective it's great that someone else has abstracted that problem for me! Enrollment though... I lose sleep over enrollment. At any substantial scale, say, 10,000 users, how do you mitigate what a malicious insider in the enrollment process can do? How do you make sure the enrollment service is itself secure? You have to plan an entire operational playbook just for recovery because if your enrollment system goes down, worst case you lock everyone out. (Goes without saying that the system going down should not default-allow...) And everything you do to lock down the enrollment system is also something that slows down your ability to modify/update/repair the enrollment system. It's not impossible, but it's currently very tricky to get right. I think U2F is one of the most user friendly approaches we've seen in a long time from a usability perspective that still maintains a relatively clean security model.