Thanks for your response. But initially this restriction did not exist. The question is why?
Accounts that were created at that time, don’t have any other 2FA methods and there is no problem with that.

Any explanation?

It’s always been the case that to add a security key, you need an authenticator app or SMS number configured—we haven’t changed anything there. This was true way back when we added support for FIDO U2F in 2015, and now with our support for WebAuthn:

  <a href="https://github.blog/2019-08-21-github-supports-webauthn-for-security-keys/#the-future-of-authentication-secure-and-easy-to-use" target="_blank" rel="noopener" title="06:11PM - 21 August 2019">The GitHub Blog – 21 Aug 19</a>

GitHub supports Web Authentication (WebAuthn) for security keys

The WebAuthn standard for security keys is making authentication as easy as possible. Now you can use security keys for second-factor authentication on GitHub with many more browsers and devices.

Est. reading time: 2 minutes

Removing this requirement and making security keys a primary method of authentication is certainly something we’re thinking about but, for now, keep your app or SMS number nearby.

but you’ll need to add an authenticator app or SMS number as your primary method, first

A problem is that GitHub’s documentation often doesn’t mention this. The interface is confusing, and the policy is confusing too.

Removing this requirement and making security keys a primary method of authentication is certainly something we’re thinking about

Context here is in regards to second-factor authentication.

For instance, I currently don’t have (or want) a phone line. WiFi is everywhere I go. The Authenticator apps I’m familiar with require an SMS channel. It’d sure be nice if GitHub directly supported second-factor security with WebAuthn devices (like Yubikeys, embedded system chips, etc) without a traditional telephone line.

There isn’t a foundational technical problem preventing GitHub’s support. And since GitHub generates one-time-use recovery codes, there isn’t really user lockout experience problem with it either. --I have my Google (banks, hosting, etc) accounts secured in this exact manor; their interfaces tend to recommend multiple hardware keys, in addition to recovery codes, but it is unusual in the industry to gate-keep webauthn.

Cheers.

The Authenticator apps I’m familiar with require an SMS channel.

TOTP 2FA does not, it doesn’t require any network connection at all after initial setup. But I agree that direct WebAuthn would be nice. 🙂

That policy will need to be changed slightly probably long term. As the Salesforce roll out of there MFA shows newer 2FA and MFA requirements breakdown for service accounts and automation accounts.

In theory Github Actions, Model Ops --anything with Continious Integration should break if its using SMS to connect. The reason I point to the Salesforce roll out, is that it a example of there One Time Password 2FA kind of failed due to confusion of the user base.

The lesson learned was that there are not factors options for users for authentication with 2FA. Not every authenticator app was supported.

What should be changed – more options for 2FA with Yubi keys not just mobile app, but location. The increase in the number of available authenticator apps and vendors especially those that allow github actions.