Skip to content

Glossary

Multi-factor authentication (MFA)

Requiring a second proof of identity beyond a password, so that a password on its own stops being enough to reach anything.

In plain terms

The door needs both a key and a face somebody recognises. Copying the key is now not enough, which is the entire idea. What it does not address is somebody who is let in politely because they asked, which turns out to be how most break-ins happen once the key stops working.

01

Why it matters

Because passwords leak constantly and in bulk, and the leak is usually somebody else's. Material reused across services means a password taken from an unrelated site becomes a working credential for yours, and no amount of complexity policy prevents that. A second factor breaks the connection between a leaked password and a usable account, which is a larger improvement than any password rule has ever delivered.

02

How it works

The factors are meant to be different in kind rather than merely two of something. Something known, something held and something inherent fail in different ways, which is where the protection comes from. Two passwords are not two factors, because one theft takes both.

The factors are not equally strong and treating them as interchangeable is the commonest mistake. A code read from a message can be intercepted or redirected by persuading a phone provider to move a number; a code generated on a device cannot be, because nothing is transmitted. Both count as a second factor and they are not the same purchase.

The strongest arrangements bind the proof to the site being visited, which is what makes them resistant rather than merely inconvenient. A code a person can read aloud can be read aloud to the wrong person; a proof that only responds to the genuine address cannot be relayed to a fake one, because the fake address is not the one it answers to.

It stops helping once the session exists. A session held after successful authentication is a credential in its own right, and anything that steals it arrives already inside. This is why the honest description is that the control protects the front door rather than the building.

Recovery is where it is usually undone. Every arrangement needs a route back for somebody who has lost their device, and that route is a second way in by definition. An organisation with strong factors and a helpdesk that resets them on a phone call has a control whose real strength is the phone call.

What a second factor stops, and what walks past it

What a second factor stops, and what walks past itSetting these beside each other is worth doing because the right-hand column is often described as evidence that the control is overrated, and it is the opposite. The left column used to be how accounts were taken, and it is now largely closed, which is a genuine and unusual security success. What follows from that is not disappointment but redirection: attention moved to the three items on the right, and each of them is a process rather than a technology. A session stolen after sign-in was never something a sign-in control could see. A helpdesk that resets factors on a friendly phone call is a documented route past every factor in use, and it exists because losing a device is common and support has to answer. A phone number moved to a different handset defeats one specific factor choice and not the others, which is precisely why the choice of factor is worth a conversation rather than a checkbox. The useful conclusion is that once the control is in place, the interesting questions stop being technical and become questions about recovery, sessions and which factors are accepted.StoppedA password reused from anotherbreach.A password guessed or sprayed.A password taken by a fakesign-in page.Arrives past itA stolen session, alreadyauthenticated.A helpdesk reset on request.A phone number moved tosomebody else.The left column is why thecontrol is worth having and ithandles all of it. The rightcolumn is not a list of exoticattacks; it is where the effortmoved once the left columnstopped working.
Setting these beside each other is worth doing because the right-hand column is often described as evidence that the control is overrated, and it is the opposite. The left column used to be how accounts were taken, and it is now largely closed, which is a genuine and unusual security success. What follows from that is not disappointment but redirection: attention moved to the three items on the right, and each of them is a process rather than a technology. A session stolen after sign-in was never something a sign-in control could see. A helpdesk that resets factors on a friendly phone call is a documented route past every factor in use, and it exists because losing a device is common and support has to answer. A phone number moved to a different handset defeats one specific factor choice and not the others, which is precisely why the choice of factor is worth a conversation rather than a checkbox. The useful conclusion is that once the control is in place, the interesting questions stop being technical and become questions about recovery, sessions and which factors are accepted.
03

Seen in the wild

  • Requiring a second factor on the account that administers an assistant deployment, not only on individual users.

    ChatGPT
  • Checking that a search tool's administrative access sits behind the same requirement as everything else.

    Glean
  • Protecting the account that holds an automation platform's stored credentials, which can reach every connected system.

    Make
04

Common misconceptions

People assume

Having it switched on means accounts are protected.

In fact

It means a leaked password alone is not enough. A stolen session, a helpdesk reset and a redirected phone number all arrive past it, so the question is which factors are accepted and how somebody recovers, not whether the setting is on.

People assume

All second factors are broadly equivalent.

In fact

They fail in different ways. A transmitted code can be intercepted or redirected; a code generated on a device cannot be, because nothing travels; a proof bound to the site cannot be relayed to a fake one at all. The differences are larger than the shared label suggests.

05

Questions

Where does this matter most for AI tools?
On the administrative accounts rather than the individual ones. An automation platform or a search deployment holds stored credentials reaching many connected systems, so the account that configures it is worth considerably more to an attacker than any single person's login to the same product.
Does it replace having good passwords?
It removes most of the consequence of a bad one, which is a different thing from replacing them. The realistic reading is that password quality stopped being the interesting variable once reuse became universal, and the second factor is what made that acceptable rather than alarming.
What is the weakest part of a typical setup?
Usually recovery. Every arrangement needs a way back for somebody who has lost their device, and that route is a second way in by construction. Where it is a helpdesk call with no verification, the real strength of the control is the helpdesk call.
06

Key takeaways

  • It breaks the link between a leaked password and a usable account.
  • Two passwords are not two factors; the kinds have to differ.
  • Transmitted codes, generated codes and site-bound proofs are not equivalent.
  • Recovery is a second way in, and usually the weakest part.
08

Tools that use this

  • ChatGPT

    Protecting the account that administers a deployment, not only users.

  • Glean

    Whether administrative access sits behind the same requirement.

  • Make

    The account holding stored credentials reaches every connected system.

Last checked August 2026

All glossary terms