Create a flood limit for a user which blocks that account from logging in with a new browser

Yes, isn't it relatively likely that a brute-force attack would come from a "new" browser (session)?
Then I agree that the currently approved trusted browsers should continue to work meanwhile.

I am using Yubico's Yubikey 2FA hardware tokens with the https://www.drupal.org/project/yubikey module, and have not tried the TFA module yet.

Is it possible to add alternative 2FA devices to TFA, so that for example if a second one has already been approved into the accont, then only the one that is (mis)used by the attacker(s) is blocked, but the other(s) are still working?

How about considering to actually integrate and add Yubikey as an alternative extra 2FA to TFA, also as part of solving the question at hand here in this issue?

PS. There are several "modes" of the Yubikey, one OTP by Yubico server (open-source server software, with a free running Yubico server if you dont have your own), but also a special Yubikey VIP key (VIP = Verisign Identity Protection), which is a service aquired by Symantec. Paypal is supporting VIP, so we can use the Yubikey VIP as a 2FA against Paypal, and soon now Google Accounts.

How about considering supporting the global VIP standard as an extra OR alternate second factor, so that users can choose whichever VIP-certified 2FA hardware (or mobile app) they prefer?

Edit: The suggestion is for the VIP mode, I know that the https://www.drupal.org/project/tfa_basic module allows for TOTP, and that TOTP is possible to use with Yubikey + installing a Yubico Windows software (as the Yubikey does not have battery, it needs a software function in addition to get a time stamp), but that is a bit awkward, so I am suggesting supporting VIP in addition.

Hmm. Perhaps I have missed something.
I just noticed in another issue here that the second factor token is indeed "6 digits", exactly the same as the VIP standard is using. Is this a coincidence? Is this current TFA solution compatible with Verisign Identity Protection "already"? If so, I am just making unnecessary noise here...

So let me get this straight:
The attacker already knows the user's password and is brute-force attacking one of the TFA validators (it actually makes a lot of sense to bruteforce TOTP with a static list of codes).
We discover that too many failed attempts were made and that's when some kind of security mechanism should activate, right?

Solution 1
Disabling TFA page (and still not letting the user log in) and sending a one-time link / code through e-mail which lets the user access the TFA page once makes sense to me, as it's a pretty universal solution. If that fails (or fails n times) show a link to the contact page and don't send another code (yes, that's not 100% self-service, but a reasonable compromise)? This way even if the attacker had access to the e-mail account of the user, they still need to guess the second factor right and they'd only have one (or n) shot(s) at it.

Solution 2
Trusted browsers might not be enabled on the site at all. Or the user might have disabled it. I see this is what you mean by "that would require the solution to be built into TFA". If the user reset their cookies, they'd still be blocked.

Actually since #2334971: Add uid-ip for validate flood tracking and change begin flood to just ip we kind of have the trusted browser bypass if user_failed_login_identifier_uid_only is set to TRUE. Login plugins get checked first without any kind of flood control so they can log in.
We could split that flood event (tfa_user) into 2 events though, one with only the UID and the other with the UID+IP combo. The former could have a slightly bigger threshold.
But we still need something to make this self-service if the trusted browser is not set.

Sorry I missed that tfa_user is only for code entry attempts and gets reset when TFA process starts.

What if we combine the 2 solutions? That way the user can get locked out for good only if they have no access to their e-mail AND don't have a trusted browser set.

Solution 1+2
Flood event
Create a flood event that registers the same time as tfa_begin but its identifier is the user's UID.
If the event reaches its threshold we send an e-mail. But we don't want to send the e-mail on every bruteforce attempt so we have to store when was the last time an e-mail was sent. For this a table (UID, sent, used) would suffice.

Logging in with a trusted browser
Simple. We only check if the flood has been hit after evaluating the login plugins.

One-time link
Some of the code is ready in #2481253: Allow Drush uli login command to bypass TFA, though including the last login's timestamp in the token doesn't make this kind of link one-time so that's why we need a 'used' column in the table.

The bypass page
Sets 'used' to 1 or REQUEST_TIME (latter holds more information). Shows a TFA authentication which on success redirects the user to change their password.

Drupal 7 end-of-life triage:
Drupal 7 reached end of life on January 5th.

The 7.x branches of TFA do not have any additional planned releases.

The requests in this issue do not appear to exist in the 8.x-1.x and newer branches.