Two-factor authentication, in its early form, asked the customer to confirm a login by reference to something the customer separately held: a physical token, an SMS to a number registered to them, a code generated on a device they were known to use. The second factor was a second thing, in a separate place, that the party with the password did not have.

The forms two-factor authentication has since taken include some that are considerably less than that. A push notification to an app on the same device that is logging in. A code sent by SMS to a number that may itself have been transferred without the customer's knowledge. A 'click to confirm' message in which the only test is whether the customer presses approve.

Each of these is, on paper, a second factor. Each is treated by the provider as evidence that the request is genuine. In practice, several of them collapse into a single check that the device the customer normally uses is being used, or that the customer can be persuaded to press approve when prompted.

The result is that not all forms of two-factor authentication produce the protection their name suggests. The customer who believes they have a second factor in place may, depending on the form, have only a slight friction on what is essentially a single-factor login. The credentials, where they are also weak, do not have the back-up the customer believes them to have.

The work in this category is about understanding, for the accounts the principal relies on, what form of second factor is currently configured, and whether it is the kind that produces meaningful additional protection or the kind that primarily produces additional convenience. Where the latter, the principal can usually upgrade the configuration without difficulty. The principle is unchanged; the protection becomes real.