> more due to the configuration setup in your instance

The obvious question here is, why does it have a configuration that allows an accidental or absent-minded employee to let in a hacker? Other authentication apps such as Symantec VIP does not use notifications, so the employee does not respond to a notification, instead he proactively starts the app to get a numeric code. Less convenient than saying Yes to a notification, but more secure.

The trade off here is that many non tech organisations make MFA at all a political difficulty. I've sat in on several meetings about how we can reduce the difficulty of using Microsoft MFA, with people talking about preinstalling it on people's phones and of course, "let's do away with MFA" comes up quite often.

Many of those orgs looked into RSA tokens in years gone by. The only reason that MS auth got through when those devices were summarily rejected from ever being used, was the convenience.

The security industry needs to be careful here. Too much "Microsoft MFA is bad" and I'm certain many companies will simply revert to password-only, in much the same experience we had with SMS based MFA being bad and as such, web apps going live that simply didn't support MFA.

I work with a few older employees. Its takes them longer to focus on the words on the screen and to read them (presbyopia happens). It takes longer to get into an app and read a code out. By the time they are ready the code is already changing in the app. It is much easier for them to touch an acknowledgement. We want security but we do not want to make security an impossible barrier for folks that need a little extra time (for whatever reason).

Semi related: apps which display TOTP tokens should start their timer when the user opens the app (so the code doesn't change 5s after opening the app). The server in the backend is checking the previous+next N tokens anyways since the server needs to account for clocks not being 100% synchronized.

Unless the authenticator app was already open, in which case skipping to the next token should be possible on demand.

Alternatively, we just found the semantic use case for the <marquee> tag: a properly calibrated scrolling ticker would give readers the clear option (regardless of initial phase) to start reading the newest token or continue reading an older one, as the ideal selection may evolve unexpectedly based on distractions.

The code is valid for another full minute, typically, after it's rotated for a new one. This isn't much of a valid reason to prefer notification-based 2FA.

It is not obvious to everyone that a code may still be valid after its gone from your screen. You cannot use the first 3 digits from one code and the last 3 from another, so you start over when you don't have all 6 digits before the code changes on you.

Different strokes for different folks. I care to have folks be successful.

This sounds like an education issue; if you were to say "wait until the code changes, then go for it", they have thirty seconds to read and type six digits.

If this still doesn't work for them, perhaps a hardware token they can tap might be a better solution.

TBF the code still being valid doesn’t help much if the user hasn’t memorized and/or finished typing it all.

Sitting next to some family members, they really can’t remember more than one or two letters at a time, and will peck and hunt each of it. Except if they were typing the last digit, the code disappearing from screen is basically the end of it for them.

In cases like these, I tell them "wait until the code changes, then go for it", so that they have thirty full seconds to read and type six digits.

If this still doesn't work for them, perhaps a hardware token they can tap might be a better solution.

There certainly are people for whom "a full minute" is not sufficient - accessibility is important.

If you were to tell them "wait until the code changes, then go for it", they would have thirty seconds to read and type six digits.

If this still doesn't work for them, perhaps a hardware token they can tap might be a better solution.

The problem with giving options regarding security is that sometimes the people who are responsible for setting up those, forget about "convenience versus security", or they get pressured by other groups to "forget" about that balance, and makes a lapse of judgement.

We could, by laws and software, enforce a certain standard of security for organizations. The question is how liable you should be for that. Would have to consider many variables like size of company, importance of information and such.