The Three Factors

12.0 What this chapter gives you#

1. You will be able to state the three classical factors in the words the standards use, and place almost any authenticator you meet into one of them.
2. You will be able to explain why a one-time code you read and type is still a possession proof, and name the object that is actually being possessed.
3. You will be able to tell multi-factor authentication apart from two-step verification, and say which a bank regulator will accept as strong customer authentication.
4. You will be able to test two authentication steps for independence, and spot the common case where two apparent factors collapse into one.
5. You will be able to explain why “somewhere you are” and “something you do” are signals rather than factors, and what would have to change for that to stop being true.
6. You will be able to show that phishing resistance is a separate property from factor count, using two real 2022 attacks in which the count was two and the outcome was total.
7. You will be able to state what Article 5 of the European rules means by dynamic linking, and name the attack it removes.
8. You will be able to cost an authenticator rollout with real per-unit and per-message figures as of August 2026, and defend the choice on grounds other than price.
9. You will be able to read a vendor’s claim of a “fourth factor” and say whether it is a factor, a signal, or a marketing category.

Almost everyone taught anything about logging in has been taught the same three words: something you know, something you have, something you are. It is one of the most successful teaching devices in the history of computer security. It is short, memorable, it maps onto ordinary life, and it takes a beginner from nothing to a usable mental model in about ninety seconds. This chapter will teach it to you properly, because you need it.

This chapter is also going to take it apart, because the model has four leaks, and every serious failure of two-factor authentication in the last fifteen years has come through one of them. The first is that the model counts, and counting is not measuring: two factors are not automatically twice as good as one, and in some arrangements they are barely better than one. The second is that the categories are not as separate as the words suggest, so people put things in the wrong box and then reason from the wrong box. The third is independence: the model says nothing about whether the two proofs can be broken by a single act, and very often they can. The fourth is the biggest. The model has no opinion at all about the property that decides whether an attacker on the other side of the world can walk straight through your login: phishing resistance. You can have three factors and no phishing resistance, and you will be robbed.

So the honest position, and the thesis of this chapter, is this. Something you know, something you have and something you are is the right first model and the wrong final model. Learn it, use it as a checklist, and know exactly where it leaks. The previous chapter looked at what it costs a real person when an identity system wrongly decides they are someone else; this chapter is about the machinery that makes that decision, and about the fact that the usual way of describing that machinery flatters it.

The password is the oldest and most common of these proofs, and it has a chapter of its own next, chapter 13, which covers where it came from in 1961, why it was never designed for the job it now does, and why it is still holding up the internet. Here we treat it only as one example of one factor.

The plain version#

The counter at the branch#

Imagine a bank branch in a small town, some time before computers were involved in any of this. There is a wooden counter, and behind it a clerk. Her whole job, when you walk in and ask for money out of your account, is to decide one thing: are you the person whose name is on that account, or somebody else standing in that person’s shoes.

She has three sorts of question available, and they differ in a way that matters enormously.

The first sort is about what is in your head. She can ask your account number, your mother’s maiden name, or the four-digit number you chose when you opened the account. If you can answer, that is evidence, because in principle only the real account holder was ever told it. Call this proof by knowing.

The second sort is about what is in your pocket. She can ask you to put your passbook on the counter, the little printed book the bank gave you with your account details and every deposit. She can ask for your cheque book, or the metal token the bank issued. If you can produce it, that is evidence, because the bank gave exactly one of those to exactly one person. Call this proof by having.

The third sort is about your body. She can look at your face, and if she has known you for eleven years that is evidence by itself. She can compare the signature you write now against the specimen card in the drawer, or take your thumbprint. Call this proof by being.

Those three are the whole classical model. The trade calls each a factor, which is just a word for one kind of proof. It has nothing to do with multiplication; it means a separate line of evidence.

Why the three are different in kind, not just in flavour#

The reason to sort proofs into three boxes, rather than just listing them, is that each box fails in a completely different way, and an attacker good at breaking one box is not automatically good at breaking the others.

Proof by knowing fails by copying. Knowledge is the easiest thing in the world to duplicate. If somebody watches over your shoulder while you tell the clerk your four-digit number, they now have it too, and nothing you can notice has gone missing. That is the defining weakness of the first box: it can be stolen without being taken away.

Proof by having fails by theft or by loan. If somebody takes your passbook out of your bag, they have it and you do not. That is worse in one way, because they can now walk into the branch, and much better in another, because a missing object announces itself. It also means the attacker had to be physically near you at some point, which rules out everybody on earth except the few who can get within arm’s length of you.

Proof by being fails in the strangest way of all, and this is the part most people never get told. Your face is not a secret. Your fingerprints are on the glass you just put down. Your voice is on every recording of every call you have made. A thing in the third box is not protected by being hidden, because it is not hidden. It is protected only by being hard to counterfeit in front of a suspicious inspector. And it has one property no other box has: if it is ever successfully counterfeited, you cannot be issued a new one. You can choose a new number. The bank can print a new passbook. Nobody can give you a new thumb.

So the three boxes are not flavours of one thing. They are three different games with three different rules, and asking for a proof from two boxes forces an attacker to win two games.

Two locks, or the same lock twice#

Here is the mistake this chapter exists to prevent, and it is easiest to see at the wooden counter.

Suppose the branch manager decides one question is not enough and tells the clerks to always ask two. A conscientious clerk now asks your account number, then your mother’s maiden name. She has asked two questions and doubled the number of steps. She has not doubled the security, because both answers came out of the same head, and both are written on the same sheet of paper in the same file at the same insurance office that was burgled last year. One theft, of one sheet, gets both. Two questions from the same box are, in practice, one question asked twice.

Now suppose instead she asks for your four-digit number and your passbook. That is genuinely different. A pickpocket who took your bag on the bus has the passbook but not the number. A neighbour who watched you at the counter last week has the number but not the passbook. To get past this clerk somebody has to be both, and most people are only one. That is the entire value of the three-box model. It is not that more proofs are better; it is that proofs from different boxes are hard for the same person to get.

There is a subtler version of the same mistake, and it is the one that costs real money today. Suppose the clerk asks for your number and then your passbook, but you keep the number written in pencil on the inside cover of the passbook. Two boxes, on paper. One theft, in fact. Whether two proofs are really two depends not only on which box they came from but on whether one accident takes them both. The trade has a word for this: independence. Two proofs are independent when breaking one does not help you break the other. If they are not independent, the count is a lie.

Aisha’s payment, which we will keep for the whole chapter#

Aisha lives in Dublin. On the evening of 3 March 2026, at 19:42, she sits on her sofa and tells her bank’s website to send 240.50 euro to a builder called Nowak Builders, who has just re-hung her front door. Amount 240.50 euro, payee Nowak Builders, time 19:42 on 3 March 2026.

Her bank does two things before it moves the money. It asks her to prove she is Aisha, and it asks her to confirm that this payment is the one she meant to make. The three-box model does not tell you that those are two different questions.

To prove she is Aisha, she types her password, which lives in her head, then opens her bank’s app on her phone, unlocks it with her thumb, and reads a short number off the screen, which she types into the website. On the face of it that is a textbook piece of two-factor authentication. Something she knows, the password. Something she has, the phone. Even something she is, the thumb.

Hold that picture. We will come back to it three times, each time it will look slightly worse, and by the end you will be able to say which parts were real proof and which were theatre.

The stranger outside the branch#

One last piece of the plain picture, and it is the piece the three boxes leave out entirely.

A man stands on the pavement outside the branch in a very good copy of the bank’s uniform, at a very good copy of the bank’s counter, set up in the doorway of the shop next door. You walk up to him because it looks right. He asks your account number, your mother’s maiden name, and to see your passbook, and copies the number off the front. Then he walks into the real branch and gives the real clerk everything you just gave him.

Count the factors. You used knowledge and possession: two boxes, two genuinely independent proofs. And you have been robbed, because neither proof cared who was asking. Knowledge can be repeated by whoever hears it, and the number off a passbook by whoever reads it.

Now imagine a different arrangement. Instead of a passbook, the bank gave you a small machine that works only when plugged into the bank’s own counter and refuses to produce anything at a counter it does not recognize. The man on the pavement can ask all he likes; the machine sees the wrong counter and stays silent. Nothing you can be persuaded to say will help him, because the proof is not made of things you can say.

That property, the proof refusing to work for the wrong asker, is called phishing resistance, and it is separate from how many boxes you used. You can use all three boxes and have none of it. You can use one box and have all of it. If you take one thing from this chapter, take that.

Where the plain version stops being true#

The count is not the score#

The plain version quietly encourages you to think that authentication strength is a number, and that the number is the count of factors. One is weak, two good, three better. That is not even approximately true.

The honest version: factor count is a category check, not a measurement. It tells you an attacker must solve more than one kind of problem. It says nothing about how hard those problems are, whether one act solves several at once, or whether the attacker can simply ask you for the answers.

Consider two systems. System A requires a password and a hardware security key that will only sign for the real site. System B requires a password, a security question, and a six-digit code by text message. System B has three steps to System A’s two, and is far easier to defeat. We will see the receipts later: a phishing crew in 2022 harvested 9,931 sets of credentials and 5,441 one-time codes from over 130 organizations, and the codes did not slow them at all, because a relayed code is as good as a stolen one for the sixty seconds that matter.

The boxes leak into each other#

The plain version presents three clean boxes. Real authenticators sit across the boundaries, and arguments about which box a thing belongs in decide whether a bank complies with the law.

A one-time code is the standard example. It arrives on your phone, you read it, it is briefly in your head, and you type it, so by any everyday account it is something you know. The European Banking Authority looked at exactly this in its opinion of 21 June 2019 and came to the opposite conclusion: a code that provides evidence of possession does not also count as a knowledge element. The code is not the secret; it is a witness that you held the object containing the secret. We will do this properly in the technical half.

A password manager is another. Your bank password is something you know in the sense the standard means. If it lives only in a manager on a device you own, protected by a key you never memorized, then in practice the bank is testing something you have, and the real knowledge factor has moved to the manager’s master password, one layer down.

The honest version: the three boxes describe the property being tested, not the route the evidence travelled. Ask what the attacker would have to obtain to reproduce this proof forever, not what the user’s fingers did.

Two proofs on one device may be one proof#

At the counter, the passbook with the number pencilled inside the cover was an obvious blunder. On a phone it is invisible, and it is everywhere.

Go back to Aisha. If she reads the password out of a password manager on the same phone, and the code out of an authenticator app on that same phone, and both are released by the same thumbprint on the same sensor, then one event, an attacker holding her unlocked phone, produces both proofs. The count says two. The physics says one.

This is not an edge case; it is the default configuration of most consumer banking, and European law addresses it directly. Article 9 of the 2018 rules on strong customer authentication is titled “Independence of the elements”, and its second paragraph exists because both elements are usually on the same phone. It requires providers to mitigate the risk of that multi-purpose device being compromised, through separated secure execution environments and mechanisms to confirm the software has not been altered.

The honest version: two factors on one device are still two factors under the standards, provided the device isolates them properly. Whether a given phone does that is an engineering claim about that phone, not something you get free by counting.

Something you are is not a secret, and cannot be reissued#

The plain version treats the three boxes as equals. They are not, and the third is peculiar in three ways at once.

It is not secret. Your face is public. Your fingerprints are on every door handle you touch. A knowledge factor is compromised when disclosed; an inherence factor was never undisclosed.

It is not exact. A password either matches or it does not. A fingerprint never matches in the sense a string matches; it scores. Every biometric system has a threshold, and moving it trades one failure for the other: let more strangers in, or lock more rightful owners out. Chapter 11 dealt with what that second failure does to a person’s life. Here the point is narrower: an inherence factor carries an error rate by construction, and a serious standard writes that error rate down. The current American federal guideline does, and we will quote the number.

It cannot be reissued. If a database of password hashes leaks, everyone changes their password and life continues. If a database of raw fingerprint images leaks, nobody can change their fingerprints, and those people are exposed for life to any system that trusts a fingerprint without checking it came from a living finger in front of a sensor.

The honest version: inherence is best understood not as a proof of identity to a remote server, but as a local key that unlocks a possession factor sitting in your hand. That is what your phone actually does, and it matters more than any other single fact about biometrics.

The attacker does not have to steal a factor, only to borrow it#

The plain version invites you to think about theft: someone gets your password, someone takes your token. Modern attacks mostly do not steal anything. They borrow.

An attacker standing between you and your bank for ninety seconds does not need your password afterwards. They need it now, once, to open one session, and they need your one-time code now, once, inside its thirty-second window. Nothing goes missing in a way you would notice. Everything is used, at speed, and discarded.

This is why factor count fails as a summary. Counting measures how many things an attacker must acquire, and borrowing attacks do not acquire, they relay. The only defence that survives a relay is a proof bound to the identity of the party asking for it, and to the specific thing being authorized. Those two bindings have names: phishing resistance, and, in European payments law, dynamic linking. Neither appears anywhere in “something you know, something you have, something you are”.

The honest version: the three-factor model was designed in 1980 for terminals and dial-up lines, where the threat was an impostor turning up with the wrong credentials. It was not designed for a world where the impostor stands between you and the real service in real time. It is still useful. It is simply answering a question that is no longer the hardest one.

The technical version#

The three factors as the standards write them#

Two families of definition carry legal and contractual weight, one American and one European. They agree on the substance and differ on the vocabulary.

The American family is NIST Special Publication 800-63B. The current edition is SP 800-63B-4, “Digital Identity Guidelines: Authentication and Authenticator Management”, published on 31 July 2025, superseding the revision issued in June 2017 with updates through 2 March 2020. Its glossary is blunt: “The three types of authentication factors are something you know, something you have, and something you are.” Multi-factor authentication is “an authentication system that requires more than one distinct type of authentication factor for successful authentication.” The words doing the work there are “distinct type”.

A warning about section numbers, because older material will trip you up. In the 2017 revision, section 5 was “Authenticator and Verifier Requirements”, with authenticator types at 5.1.1 through 5.1.9. In the 2025 revision that material moved to section 3, the types run 3.1.1 through 3.1.7, and section 5 is now “Session Management”. Both numberings are correct about their own edition; this is a specification detail, not a change of policy.

The European family is Directive (EU) 2015/2366, the second Payment Services Directive, adopted on 25 November 2015. Its Article 4, point (30), defines strong customer authentication as “an authentication based on the use of two or more elements categorised as knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is) that are independent, in that the breach of one does not compromise the reliability of the others, and is designed in such a way as to protect the confidentiality of the authentication data.”

Read that definition slowly. It does four things the slogan does not: names the categories, insists on two or more elements, requires independence and defines it, and protects the confidentiality of the authentication data. The slogan gives you only the first.

Those three examples need filling out. Knowledge, in the standards, means a memorized secret. SP 800-63B-4 section 3.1.1 calls it a password, having dropped the older term “memorized secret” used in the 2017 revision. The European Banking Authority, in its opinion of 21 June 2019 on the elements of strong customer authentication, listed at paragraph 32 what it accepts: “a password, a PIN, knowledge-based responses to challenges or questions, a passphrase and a memorised swiping path”. Note the last one. The pattern you draw to unlock an Android phone is knowledge, not inherence, because what is tested is the shape you memorized, not the hand that drew it.

Possession means control of a specific object holding a secret you cannot extract: a hardware token, a smart card, a phone with a key in its secure element, or a SIM card. Every authenticator type in the American taxonomy is built on it, from look-up secrets at section 3.1.2 and out-of-band devices at 3.1.3 through to multi-factor cryptographic authenticators at 3.1.7. The “multi-factor” ones are a possession factor plus a local activation step.

Inherence means a biometric characteristic. The EBA opinion at paragraph 19 gives the widest official list I know of: “retina and iris scanning, fingerprint scanning, vein recognition, face and hand geometry”, and then “keystroke dynamics”, “the angle at which the PSU holds the device” and “the PSU’s heart rate”. PSU means payment service user. Behavioural measurements are inside inherence, not beside it, and that drafting decision is why “something you do” is not a fourth factor in Europe.

Where the list came from, and what it was actually for#

The earliest crisp statement of the three-factor list in a published standard that I can point to is FIPS PUB 83, “Guideline on User Authentication Techniques for Computer Network Access Control”, issued by the National Bureau of Standards, part of the United States Department of Commerce, on 29 September 1980. Its section 1.2 says that the privately held information used to verify a claimed identity “may exist in one of the following forms: (1) Something KNOWN to the individual. (2) Something POSSESSED by the individual. (3) Something ABOUT the individual.” The capitals are in the original. The National Bureau of Standards became NIST in 1988, so this is the direct ancestor of SP 800-63B.

Look at that title again. In 1980 the problem was a person at a terminal on a dial-up or leased line trying to get onto a mainframe, and the threat was an impostor turning up with credentials they should not have. There was no browser, no third-party website, and no plausible way to insert a convincing fake of the mainframe between the user and the real machine. The classification was built for a world whose only question was whether the claimant held the right evidence.

Four years later the possession factor got its defining product. Kenneth P. Weiss founded Security Dynamics Technologies in 1984 and filed United States patent 4,720,860, “Method and apparatus for positively identifying an individual”, on 30 November 1984; it was granted on 19 January 1988 and assigned to Security Dynamics. The patent describes generating non-predictable codes from a fixed secret combined with a time-based variable, which is what a SecurID token does: a possession factor that proves possession by displaying a number. Security Dynamics acquired RSA Data Security in April 1996 and later took the RSA Security name. By June 2011 the BBC reported an estimate of around 40 million SecurID tokens in circulation worldwide.

The open standards followed much later. RFC 4226, “HOTP: An HMAC-Based One-Time Password Algorithm”, was published in December 2005, and RFC 6238, “TOTP: Time-Based One-Time Password Algorithm”, by D. M’Raihi, S. Machani, M. Pei and J. Rydell, in May 2011 as an Informational RFC, extending HOTP to a time-based moving factor. Neither is on the IETF standards track.

The point of this history is not nostalgia. The model dates from a threat environment in which relaying an authentication in real time was not a realistic attack, and its silence about that attack is a period feature, not an oversight.

Four questions that decide whether something is a factor#

Vendors propose new factors constantly. A candidate is a genuine authentication factor only if it answers yes to all four of these questions.

Can it be enrolled and revoked? Without a way to destroy and replace the record, you cannot recover from compromise. Passwords and hardware keys pass easily; inherence passes awkwardly, since you cannot revoke a face, only its enrolment record.

Is it under the subscriber’s exclusive control? “Exclusive” is the load-bearing word in the European definition: possession is “something only the user possesses”. A shared office badge fails. A postal address fails, because anyone who lives there can read the letter. A phone number fails more than most people realize, because a mobile network operator can move it, which is the whole basis of the SIM swap attack.

Does the verifier get a fresh, unforgeable proof each time? An authenticator returning the same value on every use is a knowledge factor pretending to be a possession factor, because after one observation the attacker can replay it. This is why the European Banking Authority concluded at paragraph 28 of its 2019 opinion that the card details and card security code printed on a payment card cannot constitute a possession element for the approaches currently observed in the market. A card is an object you possess; the static numbers printed on it are not evidence that you possess it.

Is it independent of the other factor in use? That is a property of the pair. If your one-time codes arrive in the email account whose password you just used as the first factor, you have one factor.

Somewhere you are is a signal, not a factor#

“Somewhere you are” is the most frequently proposed fourth factor. It fails the second and third questions above, and fails them badly.

There are two ways of measuring it. The first is network geolocation: the verifier reads the source address and consults a database mapping address ranges to places. That database is a commercial estimate, not a measurement. It is wrong for anyone on a virtual private network, wrong for mobile networks that route traffic through a handful of gateways, and wrong by hundreds of kilometres for many ordinary users. Worse, the value is chosen by the attacker, since renting a machine in Dublin costs a few euro an hour, and a proof the attacker can set to any value is not a proof.

The second is device-reported location from satellite positioning. That is far more accurate, but the report comes from software on a device the user controls, and spoofing tools for both major mobile platforms are a search away. The verifier is being told a number by the party it is trying to check. That is not evidence; it is testimony.

There is one narrow case where location genuinely authenticates: physical presence enforced by short-range physics, such as a card inserted into a specific terminal or a device held within a few centimetres of a near-field reader. There location is not asserted but constrained, and what is really tested is possession of an object that had to be in the room. The factor is possession; the location is a consequence.

What NIST does with location is instructive. SP 800-63B-4 mentions geolocation twice, both as an input to risk decisions rather than as a factor. Its general requirements give the example that “authentication from an unexpected geolocation or IP address block (e.g., a cloud service) might prompt the use of additional risk-based controls”, and section 3.2.2 on rate limiting lists “the claimant’s IP address, geolocation, timing of request patterns” among the behaviours a verifier may use to throttle. Location changes how much additional proof you demand. It is never itself the proof.

The European rules do not even offer the option. The definition of strong customer authentication names three categories and closes the list, so a provider offering “the payment came from the customer’s usual city” as one of its two elements would simply not be doing strong customer authentication.

The honest version: location is one of the most useful security signals in existence and one of the worst authentication factors in existence, and those statements are not in tension. Use it to decide how hard to push. Never use it as one of the pushes.

Something you do is inherence, or it is nothing#

“Something you do” is the other perennial candidate, covering keystroke dynamics, mouse movement, gait measured by a phone’s accelerometer, the angle at which you hold a device, and swipe pressure.

The regulator’s answer is the cleanest available: these are already inside inherence. The EBA opinion of 21 June 2019 lists at paragraph 19 “keystroke dynamics”, “the angle at which the PSU holds the device” and “the PSU’s heart rate” as things that may constitute inherence. No fourth box is needed, because the third box was always about measurements of the person, and a measurement of the person in motion is still a measurement of the person.

The same opinion draws the boundary on the other side at paragraph 20: a memorized swiping path is not inherence but knowledge. If what is stored is the shape, it is a secret. If what is stored is the dynamics of the hand that drew it, it is a biometric. The same gesture lands in either box depending on what you measure.

So the real question is not “is this a fourth factor” but “is this inherence good enough to be one of the two elements”. As of August 2026 the honest answer for most deployments is no, for three separable reasons.

First, the error rates. Behavioural systems are tuned for continuous, low-friction risk scoring, where a wrong answer only nudges a score. Used as a hard element they would have to meet the same bar as a fingerprint sensor: SP 800-63B-4 section 3.2.3 requires a false match rate of one in 10000 or better for all demographic groups, the proportion of impostor comparisons wrongly accepted. Published behavioural systems generally do not claim that.

Second, enrolment and revocation. Your typing rhythm changes when you are tired, injured, using a different keyboard, or holding a baby. There is no clean enrolment and no clean revocation.

Third, and decisively, NIST forbids standalone use anyway: “Biometrics SHALL only be used as part of multi-factor authentication with a physical authenticator”. A behavioural biometric alone is never a compliant element, however good it is.

Separate the claims carefully. That behavioural signals improve fraud detection when combined with other signals is established fact, and every large bank uses them. That a behavioural biometric can serve as one of the two independent elements of strong customer authentication is, as of August 2026, a marketing claim in most cases where you will hear it. Research on continuous authentication is serious; the products sold on the back of it are usually risk engines in a factor’s coat.

Multi-factor and two-step are not the same claim#

Here is the distinction regulators care about, as sharply as I can state it. Multi-factor authentication means two or more elements drawn from different categories. Two-step verification means two sequential challenges, which may or may not come from different categories. Every multi-factor scheme is two-step. Not every two-step scheme is multi-factor.

The naming is not accidental. When Google launched its consumer offering on 10 February 2011, in a post titled “Advanced sign-in security for your Google account”, it called the feature 2-step verification and described it as requiring “the powerful combination of both something you know, your username and password, and something that only you should have, your phone”. The name says two steps; the description claims two factors. In that configuration it was both.

Now the schemes that are two-step and not multi-factor. A password followed by a security question is two knowledge elements. A password followed by “which of these three addresses have you lived at” is two knowledge elements, one sitting in a credit file. A password followed by a code emailed to an address protected by the same password is one factor with extra steps.

The American banking regulators worked through this in public. The Federal Financial Institutions Examination Council issued “Authentication in an Internet Banking Environment” in 2005, pushing banks beyond single-factor logins. On 29 June 2011 it issued a supplement stating that “certain types of device identification and challenge questions should no longer be considered effective controls”. Six years of practice had shown that much of what banks counted as a second factor was a second step: browser cookies were counted as possession, though a cookie is copyable and so knowledge at best, and challenge questions were counted as a second factor when they are the same factor twice. On 11 August 2021 the FFIEC replaced both documents with “Authentication and Access to Financial Institution Services and Systems”, which supports layered security and “underscores weaknesses in single-factor authentication” while noting that “multi-factor authentication or controls of equivalent strength can more effectively mitigate risks”.

The European rules make the same distinction structurally rather than by warning. Article 4 of Commission Delegated Regulation (EU) 2018/389, the regulatory technical standards for strong customer authentication, requires that the two or more elements “result in the generation of an authentication code”. One code, derived from elements of different categories. If your scheme produces two independent yes answers rather than one code, you have built something the article does not describe.

Two-step is not a term of abuse; it is a reasonable description of a user experience. It is simply not a security claim, and much confusion comes from using it as though it were.

Independence, and the multi-purpose device#

Independence is what turns a count into a claim. Article 9 of Commission Delegated Regulation (EU) 2018/389 is titled “Independence of the elements” and reads, in full:

"Payment service providers shall ensure that the use of the elements of strong customer authentication referred to in Articles 6, 7 and 8 is subject to measures which ensure that, in terms of technology, algorithms and parameters, the breach of one of the elements does not compromise the reliability of the other elements.

Payment service providers shall adopt security measures, where any of the elements of strong customer authentication or the authentication code itself is used through a multi-purpose device, to mitigate the risk which would result from that multi-purpose device being compromised.

For the purposes of paragraph 2, the mitigating measures shall include each of the following: (a) the use of separated secure execution environments through the software installed inside the multi-purpose device; (b) mechanisms to ensure that the software or device has not been altered by the payer or by a third party; (c) where alterations have taken place, mechanisms to mitigate the consequences thereof."

Three things follow. Independence is defined negatively and precisely: breach of one element must not compromise the reliability of the others. It is a conditional statement you can test, not a preference for variety. The regulation explicitly contemplates both elements on one device, because the drafters knew that in 2017 most European retail banking authentication would happen on a smartphone; they did not ban it, they required isolation. And the isolation is named: a separated secure execution environment means a trusted execution environment or secure element, a part of the device with its own processor state that the main operating system cannot read, holding the key.

Here is what independence failure looks like drawn out.

Aisha's phone, one device, two "factors"

  +--------------------------------------------+
  |  Screen unlock: thumbprint or 6-digit PIN   |
  +--------------------------------------------+
       |                              |
       v                              v
  +-------------------+      +---------------------+
  | Password manager  |      | Authenticator app   |
  | holds the bank    |      | holds the TOTP seed |
  | password          |      |                     |
  +-------------------+      +---------------------+
       |                              |
       +-------------+----------------+
                     v
        One unlocked phone yields both proofs.
        Factor count says 2. Attacker effort says 1.

Compare that with the arrangement the regulation is asking for.

Isolated arrangement on the same phone

  +-----------------------------------------+
  | Normal world: browser, mail, apps       |
  |   password typed or auto-filled here    |
  +-----------------------------------------+
                    |  request to sign
                    v
  +-----------------------------------------+
  | Secure element / trusted execution env  |
  |   private key, never leaves; signs only |
  |   after a fresh local user check        |
  +-----------------------------------------+

  Malware in the normal world takes the
  password. It cannot extract the key.

The second picture is stronger, and not because there are two categories. Compromising the normal world does not yield the key, so the conditional in Article 9 paragraph 1 still holds. The independence comes from hardware isolation, not from the taxonomy.

Now the common independence failures, in rough order of the losses they cause. The first is the shared channel. If the reset link for your password and the one-time code both arrive at the same mailbox, that mailbox is the only real factor. Every account recovery flow is an authentication flow, usually a weaker one, and it is the flow attackers actually use.

The second is the telephone number. An SMS code is a possession proof of the SIM card, and a SIM card can be moved to another handset by the operator on a phone call. The United States Internet Crime Complaint Center published the arithmetic on 8 February 2022: from January 2018 to December 2020 it received 320 SIM swapping complaints with adjusted losses of approximately 12 million dollars, and in 2021 alone 1,611 complaints with adjusted losses of more than 68 million dollars. The possession factor did not get weaker; the market for defeating it got organized.

The third is the shared secret store. If the verifier keeps the seed that generates your one-time codes, a breach of the verifier compromises the possession factor of every user at once. In March 2011 RSA disclosed an intrusion into its own systems affecting SecurID; by that June it was offering token replacement, against an installed base the BBC put at around 40 million tokens. A possession factor whose secret exists in two places is only as strong as the weaker place.

The fourth is the shared human. Both factors can be talked out of you by one phone call from someone claiming to be the bank, and no category separation defends against a single social engineering event.

Possession proved by knowledge: why an OTP is still possession#

This is where the plain model most often gets misapplied, so we will do it slowly.

A one-time password is a short number, typically six digits, generated from a shared secret and a moving value. In RFC 4226 the moving value is a counter; in RFC 6238 it is the current time divided by a time step, with 30 seconds recommended as the default. The code is computed with HMAC, a keyed hash, then truncated. RFC 4226 requires at least six digits and permits seven or eight, so six is a convention, not a requirement of the standard.

Here are the published test vectors from RFC 6238 Appendix B, for SHA-1 mode with the ASCII shared secret “12345678901234567890”. These are the RFC’s own values, not a bank’s.

Secret (ASCII): 12345678901234567890
Mode: SHA1, 8 digits, 30-second step

 Unix time    UTC time              T (hex)            TOTP
 ---------    -------------------   ----------------   --------
        59    1970-01-01 00:00:59   0000000000000001   94287082
1111111109    2005-03-18 01:58:29   00000000023523EC   07081804
1111111111    2005-03-18 01:58:31   00000000023523ED   14050471
1234567890    2009-02-13 23:31:30   000000000273EF07   89005924
2000000000    2033-05-18 03:33:20   0000000003F940AA   69279037

Look at the second and third rows. Two seconds apart, and the code is completely different, because the gap crossed a 30-second boundary.

Now the conceptual question. Give Aisha the fourth row, so the number on her screen is 89005924. When she types it into her bank’s website, is she proving knowledge or possession?

She is proving possession, because the code is not the secret. The secret is the twenty-byte seed, which she has never seen and could not memorize. The code is a witness: a value only something holding that seed could have produced, worthless thirty seconds later. Knowing a thousand past codes does not let you produce the next one, because HMAC does not work that way. The code proves that at that moment the claimant had access to the object containing the seed.

The regulator says this in as many words. The European Banking Authority’s opinion of 21 June 2019 states at paragraph 25 that evidence of possession could be provided through a one-time password, and at paragraph 35 that “an OTP that contributes to providing evidence of possession would not constitute a knowledge element”. You cannot count the same code twice. Typing it is the delivery mechanism for a possession proof, not a knowledge factor.

The same opinion contains the sharpest line in the document, about SMS. The possession element in an SMS one-time code is not the message and not the handset; it is the SIM card associated with the mobile number. That is uncomfortable, because it tells you who else can hold your possession factor: anyone who can persuade a mobile network operator to issue a replacement SIM.

The honest version: an OTP is a possession proof whose strength is exactly the strength of the binding between the code and the object. Where the object is a hardware token or a secure element, the binding is strong. Where it is a SIM card administered by a call centre, the binding is as strong as that call centre’s worst afternoon.

There is a second honest version underneath, and it matters more. An OTP is a possession proof against an offline attacker and no proof at all against a real-time one. If the attacker sits between you and the bank while you authenticate, they do not need the seed. They need the eight digits for the next twenty seconds.

Phishing resistance runs at right angles to factor count#

Two properties are orthogonal when knowing one tells you nothing about the other. Factor count and phishing resistance are orthogonal in exactly that sense, and this is the most valuable idea in the chapter.

NIST defines the property carefully. In the glossary of SP 800-63B-4, phishing resistance is “the ability of the authentication protocol to prevent the disclosure of authentication secrets and valid authenticator outputs to an impostor verifier without reliance on the vigilance of the claimant”. Read the last clause twice. A control that works only if the user notices something is not phishing resistance. Training is not phishing resistance. A warning banner is not phishing resistance.

Here is what a relay attack does to a two-factor login.

Real-time relay ("attacker in the middle")

  Aisha            Fake site             Real bank
    |                  |                     |
    | password ------> |                     |
    |                  | password ---------> |
    |                  |    <---- "send OTP" |
    | <---- "enter code"                     |
    | 89005924 ------> |                     |
    |                  | 89005924 ---------> |
    |                  |    <--- session set |
    |  <-- "error, try later"                |
    |                  |                     |
  Aisha sees a glitch. Attacker has a session.

Nothing there required breaking a factor. Both worked perfectly, proving that Aisha knew her password and held her phone. They did not prove she was talking to her bank, because neither contained any statement about who was asking.

Two real cases from the same fortnight in 2022 make the point better than any argument.

On 25 August 2022 the security firm Group-IB published its analysis of a campaign it named 0ktapus. The attackers sent text messages pointing at fake single sign-on pages, and Group-IB counted 9,931 sets of user credentials and 5,441 one-time codes captured from over 130 targeted organizations between March 2022 and late July 2022. The kit simply showed a second page asking for the two-factor code and forwarded both to the attackers. Every one of those victims was using two-factor authentication, and every one was phished.

On 9 August 2022 Cloudflare published its own account of the same style of attack. Over one hundred text messages went out, at least 76 employees confirmed receiving them, and three entered their credentials on the fake page. The attack still failed, and Cloudflare’s explanation is the cleanest statement of the mechanism in public writing: the attackers could relay a time-based code, because “the employee would then enter the TOTP code on the phishing site, and it too would be relayed to the attacker”, but not a hardware security key, because the key is bound to the origin of the site asking.

That binding is where phishing resistance physically lives. In the Web Authentication protocol the browser constructs a small block of data that is signed along with the challenge.

{
  "type": "webauthn.get",
  "challenge": "b3E4c1RmVDlwWkE",
  "origin": "https://bank.example",
  "crossOrigin": false
}

The authenticator signs over that block. The origin field is filled in by the browser from the address bar, not by the page, so a phishing site at a lookalike address gets a signature naming the lookalike address, and the real bank rejects it. The credential is also scoped at creation time to a relying party identifier, so the authenticator will not produce a signature for a site outside that scope. The user’s vigilance is not involved at any point, which is what the NIST definition demands.

The empirical evidence for the size of the effect is unusually good. On 17 May 2019 Google published joint research with New York University and the University of California, San Diego, on how much different login challenges prevent account takeover.

All three challenge types blocked 100 per cent of automated bots. The interesting column is the last: against a targeted attacker an SMS code left roughly one in four attacks succeeding. Google reported in the same research that no user relying exclusively on security keys fell victim to targeted phishing during the study. Its internal experience points the same way: on 23 July 2018 Krebs on Security reported that none of Google’s more than 85,000 employees had been successfully phished on work accounts since early 2017, when the company began requiring physical security keys.

There is also a large-scale measurement of the value of any multi-factor at all, and it is the counterweight to everything critical this chapter has said. Microsoft researchers, in “How effective is multifactor authentication at deterring cyberattacks?”, published in May 2023 by Lucas A. Meyer and colleagues, reported that multi-factor authentication cuts the risk of compromise by 99.22 per cent across the whole population studied and by 98.56 per cent where credentials had already leaked. Weak second factors are still enormously better than none. The argument here is not that SMS codes are worthless, but that they are the wrong place to stop.

The current NIST position reflects the shift. SP 800-63B-4 requires that “verifiers SHALL offer at least one phishing-resistant authentication option at AAL2”, the middle of its three authentication assurance levels, and at the highest level that “the cryptographic authenticator used at AAL3 SHALL have a non-exportable private key and SHALL provide phishing resistance”. That is a standard dated 31 July 2025, not a vendor recommendation.

Dynamic linking: binding the proof to the payment#

Phishing resistance binds the proof to the party asking. Dynamic linking binds it to the thing being authorized. They are two halves of one idea, and European payments law wrote the second half down first.

Article 5 of Commission Delegated Regulation (EU) 2018/389 is titled “Dynamic linking”. Its first paragraph requires four things at once for remote electronic payments:

1. The payer is made aware of the amount of the payment transaction and of the payee.
2. The authentication code generated is specific to the amount of the payment transaction and the payee agreed to by the payer when initiating the transaction.
3. The authentication code accepted by the payment service provider corresponds to the original specific amount and to the identity of the payee agreed to by the payer.
4. Any change to the amount or the payee results in the invalidation of the authentication code generated.

The second paragraph adds that the confidentiality, authenticity and integrity of the amount and payee must be protected throughout all phases of the authentication, including the information displayed to the payer. The third handles card transactions that block an exact amount, and batches, where the code is specific to the batch total and the specified payees.

Apply that to Aisha. Without dynamic linking her one-time code is a general-purpose ticket saying “the holder of the seed approved something at 19:42”, and an attacker relaying her login can spend it on any payment they like. With dynamic linking the code is computed over the payment details, so it says “the holder of the seed approved 240.50 euro to Nowak Builders at 19:42” and is useless for anything else.

Without dynamic linking

  displayed to Aisha:  "Enter your code to log in"
  code covers:         nothing about the payment
  attacker can spend:  any amount, any payee

With dynamic linking

  displayed to Aisha:  Pay EUR 240.50 to NOWAK BUILDERS
  code covers:         amount 240.50 + payee identity
  attacker can spend:  EUR 240.50, to Nowak Builders,
                       which is what Aisha wanted anyway

That is why the wording about what is displayed matters. The protection collapses if the screen says one thing and the code covers another, which is the failure mode of a bank app showing “Confirm login” while the code it generates authorizes a transfer. The regulation forbids that by requiring the integrity of the information displayed to the payer through all phases.

Article 4, just before it, defines the authentication code and imposes limits worth knowing. The code shall be accepted only once. No information about the elements may be derived from its disclosure, knowledge of previous codes must not allow new ones to be generated, and the code must not be forgeable. Failed attempts must not reveal which element was wrong. Consecutive failed attempts before blocking shall not exceed five, and the inactivity period after which an authenticated payment account session is closed shall not exceed five minutes.

The regulation was adopted on 27 November 2017, published in the Official Journal on 13 March 2018, and applied from 14 September 2019. It was amended once in a way worth noting, by Commission Delegated Regulation (EU) 2022/2360 of 3 August 2022, which changed the exemption for account information access. As of August 2026 the 2018 rules are still the operative law: the successor package, the third Payment Services Directive and the Payment Services Regulation, reached provisional political agreement between Council and Parliament on 27 November 2025 and was still in formal adoption in mid-2026. [UNVERIFIED: the final application date of the PSD3 and PSR package, which had not been fixed in adopted text as of August 2026]

One last honest note. Dynamic linking protects the payment. It does not protect the login, and it does nothing about an attacker who takes over the session afterwards and gets the victim to approve a fresh, correctly linked payment. It makes a relayed code useless for a different payment. It does not make a socially engineered payment less of a payment.

Biometrics: the factor that cannot be reissued#

Inherence deserves its own treatment because almost everything people believe about it is a half-truth.

Start with the vocabulary. A biometric system does not match; it compares and scores against a threshold. False match rate, FMR, is the proportion of impostor comparisons wrongly accepted. False non-match rate, FNMR, is the proportion of genuine comparisons wrongly rejected. Moving the threshold trades one against the other; you cannot reduce both by policy, only by building a better system.

SP 800-63B-4 sets the bar in section 3.2.3: “The biometric system SHALL operate with an FMR of one in 10000 or better for all demographic groups.” The final clause is the demanding part, because an aggregate figure can hide a system that performs well on most of a test population and badly on a minority, and NIST’s own 2019 report NISTIR 8280 on demographic effects in face recognition is why that clause is there. The 2017 revision set the bar at one in 1000; the 2025 revision raised it tenfold.

The same section carries the requirement that decides how biometrics may be used at all: “Biometrics SHALL only be used as part of multi-factor authentication with a physical authenticator.” A fingerprint is never a factor on its own in a compliant system. It activates something you have.

That is exactly what your phone does, and the distinction between the two possible designs is the most consequential thing here.

In the local match design, the biometric template never leaves the device. The sensor compares the presented finger or face against a template held in the device’s secure hardware, and if it matches, that hardware releases the use of a private key. What goes to the bank is a signature, so the bank never sees, stores or leaks anything biometric. This is how Apple’s Touch ID and Face ID work with passkeys, and how Android’s equivalent works.

In the server match design, a measurement of your body is sent to a server which compares it against a stored template. Now the server holds a database of biometric templates, the network carries biometric data, and a compromise of either is permanent for every enrolled person.

The honest version: when people say “I log in with my face”, they almost always mean local match, in which the factor sent to the server is possession of a device holding a private key and the face is a local activation gesture. Calling that biometric authentication is loose but harmless. Calling a server match design by the same name is dangerous.

Vendor figures are worth quoting with their caveats attached. Apple’s Face ID Security Guide of November 2017 states that “the probability that a random person in the population could look at your iPhone X and unlock it using Face ID is approximately 1 in 1,000,000 (versus 1 in 50,000 for Touch ID)”, and immediately qualifies it: “the probability of a false match is different for twins and siblings that look like you as well as among children under the age of 13, because their distinct facial features may not have fully developed”. Those are an implementation detail of one product line and a vendor claim, not a standard, and they describe a random stranger rather than a determined attacker with a mask and a budget.

The European rules on inherence are shorter and less numerical. Article 8 of the 2018 regulation requires providers to mitigate the risk that inherence elements are uncovered by unauthorized parties, and requires devices and software to have a “very low probability of an unauthorised party being authenticated”. No number is given, which is a deliberate difference in style: NIST writes a threshold, the European regulation writes an outcome and leaves the threshold to supervisors.

The authenticator table, and how to read it#

Here is the summary the chapter has been building towards. Prices are in United States dollars as of August 2026, from the vendors’ own list prices, and cover hardware or messaging only; they exclude helpdesk, replacement and enrolment costs, which in most organizations exceed the unit price.

And the cost side, kept separate so cells stay short.

Four notes, because a table without notes misleads.

First, the Twilio figure. Twilio’s published United States pricing as of August 2026 is 0.0083 dollars per outbound message segment plus a carrier fee of between 0.0035 and 0.005 dollars, giving a delivered cost of roughly 0.0118 to 0.0133 dollars per segment. For a service sending two codes a month to a million users, that is near 280,000 dollars a year in messages alone, before dearer international traffic. Hardware keys at 29 dollars each for the same million users is 29 million dollars once. The keys last years and the messages never stop, but keys also get lost, and a lost key costs a helpdesk interaction and a replacement.

Second, “phishable” in the first table means phishable by a real-time relay, now a commodity capability rather than an expert one. A one-time code is not phishable in the sense that the attacker learns a reusable secret, but in the sense that the attacker gets a session.

Third, push approval prompts have their own failure mode. A prompt saying only “approve or deny” can be defeated by sending it repeatedly until the user taps approve to make it stop. Number matching, where the site displays a number the user must type into the prompt, removes the accidental approval and weakly binds it to a session. It does not bind the approval to an origin, so a relay showing the user the correct number on the fake page still works.

Fourth, the “origin bound” entries are the only rows where the mechanism, rather than the user, refuses the attack, which is why they are worth their price.

Now finish Aisha’s payment. She typed a password from her head and a code from her phone: one knowledge element and one possession element, and the thumbprint was not a third factor at all but the local activation of the possession factor, exactly as SP 800-63B-4 section 3.2.3 contemplates. Two elements from two categories, so this is multi-factor and not merely two-step. Whether it was independent depends on whether the password came out of a manager on the same unlocked phone. It had dynamic linking only if the app screen showed her “240.50 euro to Nowak Builders” and the code was computed over those values, which under Article 5 it must for a remote payment in the European Union. And it had no phishing resistance at all, because both proofs were things she could be persuaded to type into the wrong window.

Replace the code with a passkey on the same phone and three of those four judgments improve at once: the possession proof becomes a signature over the origin, the relay stops working, and the count stays at two. That is the practical lesson of the chapter. Do not add a factor. Add the property the factors do not have.

12.98 Common wrong ideas#

Wrong: Three factors are stronger than two, and two are stronger than one. Right: Factor count is a category check, not a strength measure, and a password plus an origin-bound security key beats a password plus a security question plus an SMS code, because what stops the common attack is phishing resistance rather than step count.

Wrong: A one-time code you read and type is something you know. Right: The code is a single-use witness that you held the object containing the seed, and the European Banking Authority stated at paragraph 35 of its opinion of 21 June 2019 that an OTP contributing to evidence of possession does not also constitute a knowledge element.

Wrong: Two-factor authentication and two-step verification mean the same thing. Right: Two-step means two sequential challenges of any kind and multi-factor means elements from different categories, so a password followed by a security question is two-step and single-factor, which is why the FFIEC supplement of 29 June 2011 said certain challenge questions were no longer effective controls.

Wrong: Having both factors on my phone is cheating and does not count. Right: It counts under both NIST and European rules provided the elements are isolated, which is why Article 9 of Regulation (EU) 2018/389 requires separated secure execution environments and integrity checks on multi-purpose devices; the arrangement fails when one compromise yields both.

Wrong: Location is a fourth factor, sometimes called somewhere you are. Right: Location is either asserted by an attacker-controlled network path or reported by software the user controls, so it fails exclusive control; NIST treats geolocation as an input to risk-based controls, and the European definition names only three categories.

Wrong: Behavioural biometrics are a fifth factor called something you do. Right: Behaviour is a measurement of the person and sits inside inherence, where the EBA put keystroke dynamics and device-holding angle at paragraph 19 of its 2019 opinion, and to serve as an element it would have to meet the same accuracy bar as any other biometric.

Wrong: A card number with the security code from the back proves possession of the card. Right: Both values are static and printed, so reading them once yields them forever, which is why the EBA concluded at paragraph 28 that card details cannot constitute a possession element for approaches currently observed in the market.

Wrong: SMS two-factor is broken, so it is not worth turning on. Right: SMS is the weakest common second factor and should not be an only option, but Google’s 2019 research found an SMS code still blocked 96 per cent of bulk phishing and 76 per cent of targeted attacks, and Microsoft’s 2023 study measured a 99.22 per cent reduction in compromise risk overall.

Wrong: My fingerprint is sent to the bank when I log in with my thumb. Right: In the local match design used by phone platforms the template never leaves the device’s secure hardware and the biometric only releases a private key, so what reaches the bank is a signature; server-side matching designs exist and carry different risks.

Wrong: Dynamic linking is a European technicality that only affects payments. Right: It is the general principle that an authorization should be bound to the act it authorizes, written into Article 5 of Regulation (EU) 2018/389, and it is what stops a relayed approval being spent on something the user never saw.

12.99 Chapter summary in 20 lines#

1. The three classical factors are something you know, something you have and something you are, and NIST SP 800-63B-4 of 31 July 2025 defines them in those words.
2. The list first appears in a federal standard in FIPS PUB 83 of 29 September 1980, as something known, something possessed and something about the individual.
3. Each factor fails differently: knowledge is copied without being taken, possession is stolen and missed, and inherence is public, approximate and impossible to reissue.
4. Multi-factor authentication means two or more elements from different categories, while two-step verification means only two sequential challenges of any kind.
5. A password followed by a security question is two steps and one factor, and American banking regulators said so in the FFIEC supplement of 29 June 2011.
6. Directive (EU) 2015/2366 Article 4(30) builds independence into the definition of strong customer authentication: breach of one element must not compromise the others.
7. Article 9 of Commission Delegated Regulation (EU) 2018/389 repeats that requirement and then addresses the case that matters, both elements on one multi-purpose device.
8. Two elements on one phone remain two elements only if hardware isolation makes them independent, through separated secure execution environments and integrity checks.
9. A one-time password proves possession rather than knowledge, because the code is a single-use witness to holding the seed rather than the secret itself.
10. The European Banking Authority stated on 21 June 2019 that an OTP providing evidence of possession does not additionally count as a knowledge element.
11. For an SMS code the possessed object is the SIM card, which is why the FBI recorded 1,611 SIM swap complaints and over 68 million dollars of losses in 2021 alone.
12. Static values printed on a card, such as the number and the security code, cannot be a possession element, because reading them once yields them forever.
13. Location fails the tests for a factor because it is either asserted by an attacker-chosen network path or reported by software the user controls.
14. Behavioural measurements such as keystroke dynamics belong inside inherence, and would have to meet the same accuracy bar as any other biometric.
15. NIST requires a false match rate of one in 10,000 or better for all demographic groups, and forbids using a biometric except with a physical authenticator.
16. Phishing resistance is a protocol’s ability to withhold secrets and valid outputs from an impostor verifier without relying on the user’s vigilance.
17. The 0ktapus campaign reported on 25 August 2022 harvested 9,931 credentials and 5,441 one-time codes from over 130 organizations that were all using two factors.
18. Cloudflare’s account of 9 August 2022 shows the other side: three employees gave up passwords, and origin-bound hardware keys made it irrelevant.
19. Dynamic linking under Article 5 of Regulation (EU) 2018/389 binds the authentication code to the amount and the payee, so any change to either invalidates it.
20. The right conclusion is not to add a fourth factor but to add the property the three never had, a proof that refuses to work for the wrong asker.

Chapter sources: NIST Special Publication 800-63B-4, “Digital Identity Guidelines: Authentication and Authenticator Management”, 31 July 2025, sections 2.2, 2.3, 3.1.1 to 3.1.7, 3.2.2, 3.2.3 and the glossary, superseding SP 800-63B of June 2017 with updates through 2 March 2020, whose matching material sat at sections 4 and 5; FIPS PUB 83, “Guideline on User Authentication Techniques for Computer Network Access Control”, National Bureau of Standards, 29 September 1980, section 1.2; Directive (EU) 2015/2366 of 25 November 2015, Article 4 points (29), (30) and (31); Commission Delegated Regulation (EU) 2018/389 of 27 November 2017, in the Official Journal of 13 March 2018 and applicable from 14 September 2019, Articles 4 to 9, as amended by Regulation (EU) 2022/2360 of 3 August 2022; European Banking Authority Opinion EBA-Op-2019-06 of 21 June 2019 on the elements of strong customer authentication under PSD2, paragraphs 19, 20, 25, 28, 32 and 35; FIDO Technical Glossary version 2.1, review draft of 25 May 2021; W3C Web Authentication Level 2, a Recommendation of April 2021, and Level 3, a Candidate Recommendation Snapshot of 26 May 2026; RFC 4226 of December 2005 and RFC 6238 of May 2011 with its Appendix B test vectors; United States patent 4,720,860, Kenneth P. Weiss, filed 30 November 1984 and granted 19 January 1988; FFIEC “Authentication in an Internet Banking Environment” of 2005, its supplement of 29 June 2011, and their replacement of 11 August 2021, “Authentication and Access to Financial Institution Services and Systems”; Google Online Security Blog, 10 February 2011 and 17 May 2019, the latter with New York University and the University of California, San Diego; Krebs on Security, 23 July 2018; Group-IB, “Roasting 0ktapus”, 25 August 2022; Cloudflare, “The mechanics of a sophisticated phishing scam and how we stopped it”, 9 August 2022; Meyer, Romero, Bertoli, Burt, Weinert and Lavista Ferres, “How effective is multifactor authentication at deterring cyberattacks?”, Microsoft Research, May 2023; FBI Internet Crime Complaint Center announcement of 8 February 2022 on SIM swapping; Apple Face ID Security Guide, November 2017; BBC News on the RSA SecurID token replacement offer, June 2011; and Yubico and Twilio list prices checked in August 2026.