It's not built into the protocol, sure, but the device can do whatever it wants before it decides to sign something. You need to unlock my phone and SEP before Krypton signs anything, for example. But you still raise a good point: I suppose it's a good thing that we can do that with cheaper devices and safe, browser-provided UX for PIN entry.
(I would suggest that a single physical device that takes a PIN before it does some signing is still 2FA even if there is only one _communicated_ credential, but I appreciate we need better terminology for this. Other versions of this to consider: if you username + password + Duo into your SSO portal and then sign into a service with SAML, is that not 2FA? If it isn't, does using a session cookie prevent something from being 2FA? For the latter, I'd say obviously not :-) I think the "who can impersonate you" is a good line in the sand, since in the former the SSO system holds full authority in most cases.)
I completely agree with everything you said, but a U2F token that takes a PIN would be hard in the sense that it would be hard to make it cross-platform (unless the PIN pad were on the actual device or something).
(I would suggest that a single physical device that takes a PIN before it does some signing is still 2FA even if there is only one _communicated_ credential, but I appreciate we need better terminology for this. Other versions of this to consider: if you username + password + Duo into your SSO portal and then sign into a service with SAML, is that not 2FA? If it isn't, does using a session cookie prevent something from being 2FA? For the latter, I'd say obviously not :-) I think the "who can impersonate you" is a good line in the sand, since in the former the SSO system holds full authority in most cases.)