How Sure Are You

48.0 What this chapter gives you#

1. You will be able to explain why one “security level” cannot describe identity confidence, and name the three things it tries to compress.
2. You will be able to state what IAL, AAL and FAL mean in NIST SP 800-63, and what each of levels 1, 2 and 3 requires.
3. You will be able to say what the 2025 revision of SP 800-63 changed, with its date, and which old assumptions it broke.
4. You will be able to describe the eIDAS levels low, substantial and high, name the regulation defining them, and say why no official mapping to NIST exists.
5. You will be able to describe the United Kingdom framework, its levels of confidence and protection, and why they are a third and different scale.
6. You will be able to run a digital identity risk assessment using the five impact categories and the impact-to-level rule, and defend the answer.
7. You will be able to specify step-up and re-authentication behaviour per level, in protocol terms rather than adjectives.
8. You will be able to state the assurance of a federated assertion separately from that of the person, and read an identity token to see what it claims.

Every identity system eventually has to answer a question that sounds simple and is not: how sure are you? A bank wants to know before it moves money, a hospital before it shows a record, a government before it pays a benefit. The honest answer is never “yes” or “no”. It is always a degree, and always a degree of several different things at once.

The instinct of most engineers is to reach for one number: a security level, a trust score, a tier. One number is easy to store, easy to compare, easy to argue about in a meeting. It is also wrong, and the standards bodies of three continents have independently reached the same conclusion: you need at least three numbers, they move independently, and collapsing them destroys exactly the information you needed.

This chapter is about those numbers: the American scales published by the National Institute of Standards and Technology in SP 800-63, the European scales written into law by the eIDAS Regulation, and the British scales in the trust framework now run by the Office for Digital Identities and Attributes. All three describe the same reality and none of them line up, and knowing precisely how they fail to line up is one of the more useful pieces of professional knowledge in this field, because sooner or later somebody will ask you to accept a foreign credential and you will have to say what it is worth. We will build the idea from a doorway and a notebook, break the analogy honestly, then rebuild it in the exact vocabulary of the specifications, and end by running one service through all three frameworks to watch the answers diverge.

The plain version#

A building, a book and a gate#

Picture a block of flats. Two hundred homes, one entrance, one desk at that entrance, one guard on duty at a time. Behind the desk there is a book, and when somebody moves in, the office writes their name in it along with the flat they live in. Three separate things then go on in that building, and people mix them up constantly.

The first happens once. On the day you move in, somebody in the office decides how much work to do before writing your name in the book. They might ask for your passport and lease, look at your face, and telephone your old landlord. They might glance at a printed letter. They might take your word for it. Whatever they do, they do it once, and the care they took is baked into the book forever.

The second happens every day. You come home at eight in the evening, and the guard has to decide whether the person at the desk is the person in the book. He might know your face, ask for a card, or make you press a thumb on a reader. This is a completely different decision from the first, made by a different person, with different tools, at a different moment.

The third happens when you are not there. A plumber turns up and says he is expected at flat 402. The guard knows neither of you, so he relies on a message: a chit you wrote, a phone call from the office, or a note the plumber carries. The guard is now trusting a piece of paper about a person rather than a person, and how much that paper is worth is a third and separate question.

The whole idea of this chapter, in one sentence: those are three different questions, they can be answered with three different amounts of care, and there is no honest way to squash them into one answer.

Three residents, three different shapes of sureness#

Let us grade each question light, normal or heavy. These grades are ours, invented for teaching; the real ones come later and are more precise.

Priya moved in five years ago with her passport, her lease and a utility bill. The office checked her face against the passport photograph, photocopied everything, and rang the managing agent: a heavy touch on the first question. But five years have passed, the guards have changed twice, and the current guard simply recognizes her and nods her through, with no card and no code: a light touch on the second. She has never sent anyone in her place, so the third question has not come up.

Rahul moved in last week. The agent emailed his name and flat number and the office wrote it in the book, with nobody looking at a document: a light touch on the first question. But the building has just installed a new gate, so Rahul was handed a numbered fob and a four-digit code, and the gate needs both: a heavy touch on the second. He has already sent a delivery rider up with a message typed into the building’s app: a normal touch on the third.

Mrs Fernandes has lived here for twenty years. Her name went into the book before anybody now working there was hired, and nobody knows what was checked. She has no fob and no code, but her son always signs her in, and the guard writes that in a visitor register, in pen, with the time.

Now consider what a single number would hide. Asked to give Priya “a safety score out of three”, you might average to two. That average is a lie in both directions: it hides that her identity was checked beautifully, and it hides that anybody of her rough build could walk past the desk tonight.

An attacker does not attack the average#

Imagine two people who want to get into flat 402. The first wants to pretend to be a resident who does not exist, so that he can collect the parcels that arrive for a made-up name. He attacks the book. He does not care how good the gate is; once his invented name is in the book, the gate will let it through, because the gate’s job is to match a face to the book, and his face genuinely matches the entry he created.

The second wants to get into Priya’s actual flat. He does not attack the book at all, because Priya’s entry is real and correct. He attacks the gate: he waits until the guard is busy, walks in behind a resident, and goes up.

Two attackers, two completely different weak points, one building. A single number cannot tell you which of them you are protected against. Three numbers can. And you fix them separately: stricter move-in checks do nothing to stop the man who follows Priya through the door, and a thumb reader on the gate does nothing to stop the invented resident.

The honest version: even three numbers is a simplification, because the real weak point in that building is usually the guard’s willingness to be helpful, and no scale measures that.

Different errands need different amounts of care#

The building does not need the same care for everything. Collecting a small parcel needs almost nothing: if the wrong person takes a pair of socks, the harm is an annoyance and a refund. Getting into the lift lobby needs a decent gate check but almost no book check, because what matters is that the person is a resident of some kind, not which one. Being given a spare key needs both done heavily, because you are handing over control of somebody’s home. And changing the bank account that the building’s maintenance refund is paid into needs all three done heavily. That last errand is the one attackers actually want, because it is where the money is, and it is almost always the one whose rules were written by somebody thinking about parcels.

Two things fall out of that table and carry all the way into the real standards. First, the three columns move independently: the lift lobby row is light on the book and normal on the gate, and any system that forces the three to be equal is either wasting effort in one column or taking risk in another. Second, the right level is decided by what goes wrong, not by how important the service feels. “Change bank details” is a small, dull form, and it is the most dangerous button in the building. Importance is measured in harm, not in prestige.

Sureness is a claim somebody makes, and it can be checked#

The last plain idea turns this from a nice metaphor into engineering. When the guard writes “resident, checked fob and code, 20:14” in the register, he is not describing a feeling. He is making a claim, in writing, that a particular procedure was carried out at a particular time. The building’s owner can audit that line. An insurer can demand to see it. A court could subpoena it. The word the standards use for this is assurance, and the important thing about it is not that it is a number but that it is a claim, tied to a written rule, which somebody outside your organization can check. A feeling cannot be audited. A graded claim can.

The honest version: the register does not prove the guard did what he wrote. It proves he wrote it. All assurance frameworks have this gap between the recorded claim and the physical truth, and every one tries to close it with independent audit rather than better paperwork.

We will now give these three questions their proper names. The book question becomes identity assurance. The gate question becomes authentication assurance. The note question becomes federation assurance. Everything else is detail, and the detail is where the money is.

Where the plain version stops being true#

Three is the minimum, not the truth#

Three is what the major frameworks settled on, and that convergence is real. But three is a floor, the smallest number that stops the worst mistakes, not a claim that identity confidence has exactly three dimensions. RFC 8485, “Vectors of Trust”, published by the IETF in October 2018 and edited by Justin Richer with Leif Johansson, used four components, splitting what NIST calls authentication into C for primary credential usage, meaning how strong the thing you hold is, and M for primary credential management, meaning how carefully it was bound to you, rotated and revoked; P covers proofing and A covers assertion presentation. A vector looks like “P1.Cc.Ab”, read as a set rather than a ladder. That fourth component matters: a hardware key posted to an address nobody verified, replaceable by a helpdesk that asks for a date of birth, is a strong credential with weak management, and in the NIST scales it can carry the same label as one issued properly.

The honest version: the number of scales is a design choice about how much detail a purchasing decision can carry, not a discovery about nature.

The scales are not a ladder, and level 3 is not “better”#

The plain version used light, normal and heavy, which sounds like a ladder you climb until the budget runs out. Higher levels are not strictly better; they are strictly more exclusionary. Every step up the identity scale demands more documents, and the people without those documents are disproportionately the poor, the young, the recently arrived, the homeless and the very old. SP 800-63-4 says this explicitly, requiring organizations to assess the harms of the identity system itself, including harms to access and equity, not only the harms an attacker could cause. A service that picks the highest level “to be safe” has moved harm from a hypothetical fraudster to a real applicant who cannot get a passport.

Higher levels cost more in ways that are not money. On-site attended proofing needs premises and staff. Hardware authenticators need logistics and a replacement process, and that process becomes the new weakest point. A twelve-hour session limit at the top level means a nurse on a fourteen-hour shift re-authenticates mid-shift, which sounds trivial until you consider what she is doing at the time.

“High” in one country is not “high” in another#

The plain version implied one shared meaning for heavy. There is none. The European Union’s top level is called high, the United States’ top identity level is IAL3, and the United Kingdom’s is very high. These three words do not describe the same procedure, do not require the same evidence, and were written by different bodies for different legal purposes. Worse, the frameworks slice the problem in different places: eIDAS gives one level to a whole electronic identification scheme, covering enrolment, means management, authentication and organizational governance together; NIST gives three independent levels to three functions; and the United Kingdom gives one scale to identity checking, a separate scale to authenticators, and certifies organizations by role rather than certifying a level at all.

There is no official cross-mapping between eIDAS and NIST. Vendors publish mapping tables and they are useful working approximations, but no standards body or regulator has adopted one, and an unadopted mapping has no legal weight when a regulator asks why you accepted a foreign credential.

A level describes a process, and it does not stay fresh#

A level states what procedure was followed, never whether the answer is correct: two providers at the same level can have order-of-magnitude different false acceptance rates, which is why SP 800-63-4 asks for measured fraud rates rather than reliance on the level chosen. The level also says nothing about age. According to the building’s book, Priya’s entry is exactly as strong today as it was five years ago. In reality it is much weaker: she may have moved out, died, sold the flat, or changed her name. Every identity assurance level describes a moment in the past, and no framework puts a freshness figure on the front of the scale. Authentication assurance has a clock built in, because sessions expire and re-authentication is required. Identity assurance has none: a credential proofed to the second level in 2019 still claims the second level in 2026, and the only thing between that claim and reality is whatever account monitoring the provider chose to run.

The honest version: the timestamp is the missing column in every published assurance scale, and mature systems bolt it on privately as an account age and account health signal that has no standardized name.

A claim about a person and a claim about a message are different animals#

The building’s third question felt like a minor extra. In real deployments it is the one that gets forgotten and the one that gets exploited. When a service outsources login, it receives a message saying “this person authenticated, and here is who they are”, and that message has its own security properties, separate from the person’s. It can be signed or unsigned, replayed, injected into somebody else’s session, or issued by an identity provider that has itself been compromised, in which case every claim inside it is a fiction no matter how carefully the original enrolment was done.

Most designs specify the identity level and the authentication level and simply never mention the third scale, so it defaults to whatever the software library does. That default is usually a signed bearer assertion with no injection protection, which is the bottom rung. A service can therefore claim the second identity level and the second authentication level while transporting both claims over a mechanism at the first federation level, which means an attacker who can inject an assertion gets everything the careful proofing bought, for free.

The technical version#

From one number to three: 2003 to 2019#

The single-number model was official United States policy for fifteen years, and understanding why it was abandoned is the fastest route to what replaced it. On 16 December 2003 the Office of Management and Budget issued Memorandum M-04-04, “E-Authentication Guidance for Federal Agencies”, defining four Levels of Assurance numbered 1 to 4. An agency ran a risk assessment, arrived at a level, and that single ordinal determined everything: how the person was proofed, what credential they were issued, and how it was used. NIST published the technical companion, SP 800-63, “Electronic Authentication Guideline”, in 2004, revised as SP 800-63-1 on 12 December 2011 and SP 800-63-2 on 29 August 2013. The same shape appeared internationally: ISO/IEC 29115:2013, “Entity authentication assurance framework”, also defined four levels; as of August 2026 it remains published but moved to stage 90.92, “International Standard to be revised”, in May 2024, with a revision under development as ISO/IEC CD 29115.2.

The ordinal broke for a specific reason. Level 3 required both a rigorous identity proofing process and a cryptographic credential. But there are legitimate services that need a strong credential and almost no proofing, and others that need careful proofing and only a moderate credential. A pseudonymous forum for a sensitive support group wants strong authentication and deliberately weak identity linkage. A one-off entitlement payment wants careful proofing and a credential used once. The ordinal forced these into the same box.

NIST broke the ordinal in SP 800-63-3, published June 2017 with an errata update of 2 March 2020. Its section 5.2 introduced three scales in place of one and stated that the guideline “does not recognize the four LOA model previously used by federal agencies and described in OMB M-04-04”. Policy followed two years later: OMB Memorandum M-19-17, “Enabling Mission Delivery through Improved Identity, Credential, and Access Management”, of 21 May 2019, rescinded M-04-04 along with M-05-05, M-06-18, M-11-11 and the October 2011 memorandum on externally issued credentials. It states that “the concept of LOA as a single ordinal that drives implementation-specific requirement is retired”, and directs agencies to implement SP 800-63-3 “and any successive versions”.

SP 800-63-3: the three scales as first written#

SP 800-63-3 defined three scales of three levels each and gave them names that are now standard vocabulary worldwide. The definitions below are the wording of its section 5.2, current from June 2017 until withdrawal on 1 August 2025.

Identity Assurance Level, abbreviated IAL, describes the identity proofing process: how carefully the provider established that a real person exists and that the applicant is that person. At IAL1, “attributes, if any, are self-asserted or should be treated as self-asserted”. No proofing is required at all. At IAL2, “either remote or in-person identity proofing is required”, with attributes verified using at minimum the procedures in SP 800-63A. At IAL3, “in-person identity proofing is required”, and identifying attributes must be verified by an authorized representative of the credential service provider through examination of physical documentation. Supervised remote proofing, meaning a live attended session with strong physical controls at the applicant’s end, counted as in-person.

Authenticator Assurance Level, abbreviated AAL, describes how confident we are that the person presenting themselves right now controls the authenticator bound to that account. AAL1 “provides some assurance that the claimant controls an authenticator registered to the subscriber”, and requires single-factor authentication using a wide range of technologies. AAL2 “provides high confidence”, and requires proof of possession and control of two different authentication factors through a secure authentication protocol. AAL3 “provides very high confidence”, and is “based on proof of possession of a key through a cryptographic protocol”, with a hardware-based authenticator and verifier impersonation resistance.

Federation Assurance Level, abbreviated FAL, describes the strength of the assertion passed from an identity provider to a relying party. FAL1 “permits the RP to receive a bearer assertion from an identity provider”, signed by the identity provider using approved cryptography. FAL2 “adds the requirement that the assertion be encrypted using approved cryptography such that the RP is the only party that can decrypt it”. FAL3 “requires the subscriber to present proof of possession of a cryptographic key referenced in the assertion along with the assertion itself”, with the assertion both signed and encrypted.

Note the shape of that FAL ladder: signature, then encryption, then holder-of-key. Remember it, because the 2025 revision moved the middle rung somewhere else entirely.

SP 800-63-4: what changed, and when#

NIST published SP 800-63-4, “Digital Identity Guidelines”, as a final document on 31 July 2025, cover date July 2025, digital object identifier 10.6028/NIST.SP.800-63-4, and withdrew SP 800-63-3 the following day. The revision is a four-volume suite of the same date: SP 800-63-4 for the risk framework and level definitions, SP 800-63A-4 for identity proofing and enrolment, SP 800-63B-4 for authentication and lifecycle management, and SP 800-63C-4 for federation and assertions. The definitions moved to section 3.3.2 and were rewritten, and the family abbreviation is stated in the text: “When described generically or bundled, these guidelines will refer to IAL, AAL, and FAL as xAL.”

The new wording reads: “IAL1 supports the real-world existence of the claimed identity and provides some assurance that the applicant is associated with that identity”; “IAL2 requires collecting additional evidence and a more rigorous process for validating the evidence and verifying the identity”; and “IAL3 adds the requirement for a trained CSP representative (i.e., proofing agent) to interact directly with the applicant”. For authentication: “AAL1 provides basic confidence that the claimant controls an authenticator that is bound to the subscriber account”, AAL2 “provides high confidence”, and “AAL3 provides very high confidence”. For federation: “FAL1 provides a basic level of protection for federation transactions and supports a wide range of use cases”, “FAL2 provides a high level of protection ... and additional protection against various attacks”, and “FAL3 provides a very high level of protection”.

The change that matters most is the first. IAL1 in 2017 meant no proofing; IAL1 in 2025 means real proofing establishing that the claimed identity exists in the world. The revision describes this as repurposing IAL1 to combat identity theft and identity-related fraud, with requirements to prevent automated attacks against enrolment. A service documented as IAL1 under the old text, doing nothing at all, is not IAL1 now. It is off the bottom of the scale.

The other substantive changes, taken from the revision’s own framing and from the change logs of the companion volumes:

Phishing resistance became a first-class requirement: SP 800-63B-4 section 2.2.2 states that at AAL2 “Verifiers SHALL offer at least one phishing-resistant authentication option”, and at AAL3 the cryptographic authenticator itself must provide it. Syncable authenticators, meaning passkeys whose private key material is copied between a user’s devices through a synchronization service, were given a normative appendix of their own, Appendix B of SP 800-63B-4; they are permitted at AAL2 and prohibited at AAL3, because AAL3 requires a key that cannot be exported from its hardware.

Password rules were rewritten. SP 800-63B-4 requires passwords used as a single factor to be a minimum of 15 characters and passwords used alongside another factor a minimum of 8, and removes composition rules requiring mixtures of character classes. A category of restricted authenticators was introduced, covering out-of-band authentication over the public switched telephone network, which in practice means one-time codes sent by SMS or read out by an automated voice call; verifiers are directed to consider risk indicators before using it.

Federation gained the concept of a trust agreement, meaning the documented set of relationships, permitted assurance levels, attribute handling and retention terms between the parties, and a new architecture in which the identity provider is a wallet under the subscriber’s control. The risk framework was rebuilt from a decision tree into a five-step process, and the impact categories cut from six to five and reworded.

Identity assurance in detail#

SP 800-63A-4 defines the machinery behind IAL, grading the evidence, the way the session is conducted, and what is done with the evidence.

Evidence strength has three tiers, in sections 2.3.1 through 2.3.3: FAIR, STRONG and SUPERIOR. FAIR evidence must carry the person’s name, a reference number or biometric, security features, and must be validatable. STRONG adds a requirement that the issuing source operate under written procedures with recurring oversight by a regulatory or publicly accountable institution, and must carry a facial image or other biometric plus cryptographic or physical security features. SUPERIOR must be cryptographically protected so its attributes can be verified through a digital signature, must have been issued through an attended enrolment, and must carry a facial image or biometric.

Proofing types, in section 2.1.3, are four, formed from two independent choices: remote or on site, attended by a human proofing agent or not. That gives remote unattended, remote attended, on-site unattended and on-site attended. Naming all four separately is a 2025 improvement, because an automated kiosk in a government office is a different risk profile from a video call with a trained agent, and the old vocabulary could not say so.

The requirements combine. At IAL2, section 4.2.2 requires two or more pieces of STRONG evidence, or one SUPERIOR, with all core attributes validated against authoritative or credible sources. At IAL3, section 4.3.2 requires one piece of SUPERIOR evidence plus at least one biometric characteristic, in an on-site attended session. [UNVERIFIED: the exact evidence combination stated for IAL1 in SP 800-63A-4 section 4.1, where two readings returned inconsistent wording and the sentence should be taken directly from the published text before it is quoted.]

For comparison, the 2017 text at IAL2 permitted two pieces of STRONG evidence, or one STRONG plus two FAIR, and at IAL3 two pieces of SUPERIOR, or one SUPERIOR plus one STRONG. The practical consequence either way is that the top identity level is not something you buy from a vendor and switch on. It needs a physical location, a trained person and a biometric capture, so almost no consumer service operates at IAL3, and those that do are issuing physical credentials at the same time.

Authentication assurance in detail#

SP 800-63B-4 defines AAL. Each level fixes which authenticator types are permitted, whether phishing resistance is required, what cryptographic validation applies, and how long a session may last before the person must authenticate again.

AAL1 permits a single factor and a wide range of types: memorized secrets, look-up secrets, out-of-band devices, one-time password devices and cryptographic devices, single-factor or multi-factor. AAL2 requires two distinct factors, either one multi-factor authenticator or a memorized secret or biometric combined with a physical authenticator, and the verifier must offer at least one phishing-resistant option even if it also offers others. AAL3 requires a hardware-based cryptographic authenticator that is phishing resistant and whose private key cannot be exported, either one multi-factor cryptographic device or a single-factor one used with a memorized secret or biometric; syncable authenticators are excluded.

The session clock is the part practitioners get wrong most often, because the numbers changed in 2025. Here they are, from sections 4.1.3, 4.2.3 and 4.3.3 of the 2017 text and sections 2.1.3, 2.2.3 and 2.3.3 of the 2025 text.

The 2017 text at AAL2 required reauthentication “at least once per 12 hours during an extended usage session, regardless of user activity” and “following any period of inactivity lasting 30 minutes or longer”. The 2025 text says “A definite reauthentication overall timeout SHALL be established, which SHOULD be no more than 24 hours at AAL2. The inactivity timeout SHOULD be no more than 1 hour.”

Read the modal verbs, because they carry the whole meaning. At AAL2 the requirement to have a timeout is SHALL, mandatory, but the 24-hour figure is SHOULD, recommended with documented deviation permitted. At AAL3 the figure itself is SHALL: “At AAL3, the overall timeout for reauthentication SHALL be no more than 12 hours.” A hard ceiling at the top level and a looser recommendation at the middle level is deliberate. NIST relaxed AAL2 because the 2017 numbers were producing worse security in practice: users facing a twelve-hour ceiling and a thirty-minute idle timeout adopted workarounds more dangerous than the longer session.

At AAL2, after the inactivity timeout but before the overall timeout, reauthentication may use a single factor combined with the existing session secret. At AAL3 it may not; reauthentication uses both factors, exactly as the initial authentication did.

Federation assurance in detail, the part most designs forget#

Federation means a relying party, the service the user actually wants, delegates login to an identity provider and receives an assertion in return. The assertion is a message, and FAL grades the message. Here is the shape of the problem.

   +-----------+        assertion         +-----------+
   |  Identity |------------------------->|  Relying  |
   |  Provider |   "this is user 4f2a,    |   Party   |
   +-----------+    proofed at IAL2,      +-----------+
        ^           authed at AAL2"             |
        |                                       |
   IAL lives here                     the RP must decide
   AAL lives here                     whether to believe
                                      the message at all
        \                                      /
         \          FAL lives on this arrow   /
          +------------------------------- --+

   Three questions, three owners:
     IAL  - how well did the IdP know the person?
     AAL  - how well did the IdP check them today?
     FAL  - how well is this message protected?

The trap is that IAL and AAL are properties the identity provider asserts, while FAL belongs to the channel carrying the assertion, and only the relying party can enforce it. A relying party accepting an assertion that claims IAL2 and AAL2 over a mechanism with no injection protection has bought nothing: an attacker who can plant an assertion into another user’s session gets the full benefit of somebody else’s careful proofing. SP 800-63C-4 defines the levels in section 2, with FAL1 in 2.3, FAL2 in 2.4 and FAL3 in 2.5.

FAL1 requires the assertion to be signed with approved cryptography, restricted to a named audience, and to carry replay protection scoped to each relying party. Injection protection is recommended, not required. The trust agreement may be pre-established by the organizations or created dynamically by the subscriber during the transaction, which is the model behind ordinary consumer social login, and bearer assertions are permitted, meaning whoever holds the assertion can use it.

FAL2 adds three things. The assertion must be strongly protected against injection attacks, which in practice means the transaction begins at the relying party and that party can bind the returned assertion to the request it made. The audience must be a single relying party. The trust agreement must be pre-established, so subscriber-driven federation is out. Replay protection becomes mandatory, federated identifiers must not contain plaintext personal information, and for United States federal agencies signing keys must be protected at FIPS 140 Level 1 or higher. Assertions may still be bearer assertions.

FAL3 adds the requirement that the relying party independently verify the subscriber controls an authenticator, either through a holder-of-key assertion, where the assertion references a key the subscriber proves possession of, or through a bound authenticator presented separately. Trust agreements must be pre-established and key establishment manual. FAL3 survives a compromised identity provider, because such a provider can mint assertions but cannot produce the subscriber’s private key.

Now the change that will catch anybody working from the 2017 text. In SP 800-63-3 the difference between FAL1 and FAL2 was encryption: FAL2 meant the assertion was encrypted so only the relying party could read it. In SP 800-63C-4 the line is injection protection instead. That is a better rule, because encryption never stopped injection: an encrypted assertion planted into the wrong user’s session decrypts perfectly and is just as harmful.

The practical guidance follows. If your service is a relying party and you have never written down a FAL, you are at FAL1, whatever your provider’s marketing says. Reaching FAL2 in OpenID Connect terms means the authorization code flow, sending and checking a state value and a PKCE code challenge, validating aud against your own client identifier alone, checking nonce against the value you generated, and a written agreement with the provider rather than a self-service signup.

Putting an assurance claim on the wire#

An assurance level that lives only in a policy document is an opinion. To be operational it has to travel in the protocol, and there are three ways it does. The oldest is a registry of named profiles: RFC 6711, “An IANA Registry for Level of Assurance (LoA) Profiles”, of August 2012, let a level be named by a stable identifier rather than a locally invented string. In SAML the value goes in the AuthnContextClassRef element; in OpenID Connect it goes in the acr claim, requested with the acr_values parameter. The second way is RFC 8485’s vector, carrying several components in one string so a relying party sees the shape rather than a single rung.

The third, used by most large deployments, is a set of provider-specific identifiers. Login.gov, the United States federal public-facing identity service, has been through a full generation of this: its older values named an assurance level directly under the idmanagement.gov namespace, and its documentation as of August 2026 marks those as not recommended and kept only for legacy compatibility. The identifiers below omit their scheme prefix, which is http for the idmanagement.gov values:

Deprecated, legacy compatibility only:
  idmanagement.gov/ns/assurance/ial/1
  idmanagement.gov/ns/assurance/ial/2
  idmanagement.gov/ns/assurance/loa/1
  idmanagement.gov/ns/assurance/loa/3

Current service-level values:
  urn:acr.login.gov:auth-only
  urn:acr.login.gov:verified
  urn:acr.login.gov:verified-facial-match-required
  urn:acr.login.gov:verified-facial-match-preferred

Current authentication values:
  idmanagement.gov/ns/assurance/aal/2
  idmanagement.gov/ns/assurance/aal/2?phishing_resistant=true
  idmanagement.gov/ns/assurance/aal/2?hspd12=true

Notice the direction of travel. The names moved from abstract level numbers towards descriptions of what was done: verified, verified with a facial match, authenticated with a phishing-resistant method. That is a deliberate retreat from the ordinal, for the reason the ordinal was abandoned in 2019. A relying party asking for “level 2” asks a question whose answer will change under it when the standard is revised; one asking for “verified with a facial match” asks for a procedure.

An identity token carrying an assurance claim looks like this. The values are illustrative, the claim names are exactly those in OpenID Connect Core 1.0, and the issuer omits its scheme prefix, which is https.

{
  "iss": "idp.example.gov",
  "sub": "4f2a9c1e-77b3-4d0a-9c62-8e11a5d3f004",
  "aud": "pension-portal",
  "exp": 1786000800,
  "iat": 1786000200,
  "auth_time": 1786000180,
  "nonce": "6f1c0b2a9d",
  "acr": "urn:example:acr:verified-medium",
  "amr": ["pwd", "hwk", "user"]
}

Three claims carry the assurance story. The acr claim names the authentication context that was satisfied. The amr claim lists the methods used, drawn from the registry established by RFC 8176, where pwd is a password, hwk is a proof-of-possession hardware key and user is a user-presence check. The auth_time claim is the moment the person actually authenticated, in seconds since the Unix epoch.

That third claim is the one most implementations ignore and the one that makes re-authentication enforceable. Without it a relying party cannot know whether the person authenticated four seconds ago or four days ago, and every session limit in SP 800-63B becomes unenforceable across a federation boundary.

Step-up and re-authentication, as protocol rather than adjective#

Step-up authentication is how a service that normally runs at one level demands a higher one for a particular operation. It lets a service be cheap at the door and expensive at the dangerous button. There are two protocol paths, depending on where the decision is made. At the front end, the relying party starts a new authorization request naming what it needs: in OpenID Connect that means acr_values with the required context and max_age with the maximum acceptable age in seconds of the authentication event, where max_age=0 forces a fresh authentication and prompt=login forces the identity provider to re-prompt regardless of its own session state.

If the decision is made at a resource server, behind an access token already issued, there was no standard way to signal the problem until RFC 9470, “OAuth 2.0 Step Up Authentication Challenge Protocol”, by Vittorio Bertocci and Brian Campbell, published in September 2023. It defines the error code insufficient_user_authentication and lets the resource server state what it needs in the challenge.

GET /accounts/1234/payment-instructions HTTP/1.1
Host: api.pension.example
Authorization: Bearer eyJhbGciOi...

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="insufficient_user_authentication",
  error_description="A different authentication level is required",
  acr_values="urn:example:acr:verified-high",
  max_age="120"

The client sees the challenge, sends the user back to the authorization endpoint with those values, obtains a new token whose acr and auth_time satisfy the requirement, and retries. The exchange is machine-readable, so the policy lives in the resource server next to the operation it protects rather than being duplicated into every client.

Re-authentication is the same mechanism pointed at the clock instead of the level. A resource server requiring the authentication event to be under two minutes old sets max_age="120" and checks auth_time on the token it receives. That is how the AAL session limits become real across a federation boundary.

One design note that costs organizations real money: step-up is per operation, not per session. Raising the whole session after one dangerous action leaves the user at a level they no longer need, with every subsequent request inheriting privileges justified once. The correct pattern is a short-lived elevated context tied to the specific action.

eIDAS: low, substantial, high, and what attack potential means#

Europe took a structurally different route. Regulation (EU) No 910/2014 of 23 July 2014, the eIDAS Regulation, establishes assurance levels in Article 8. Article 8(1) requires a notified electronic identification scheme to specify the levels of the means issued under it, and Article 8(2) defines three: low “provides a limited degree of confidence in the claimed or asserted identity of a person”; substantial “provides a substantial degree of confidence”; and high “provides a higher degree of confidence ... than electronic identification means with the assurance level substantial”.

Article 6 makes those levels legally operative. Where a member state requires electronic identification to access an online public service, it must recognize means notified by another member state, provided the level is equal to or higher than the service requires and the service itself uses substantial or high. Article 6(2) leaves recognition of level low to each state’s discretion. That sentence turns a technical scale into a cross-border obligation.

The technical content sits in Commission Implementing Regulation (EU) 2015/1502 of 8 September 2015, adopted under Article 8(3). Its Article 1 states that the levels “shall be determined with reference to the specifications and procedures set out in the Annex”, used to judge the reliability and quality of enrolment, electronic identification means management, authentication, and management and organisation. It adds two rules practitioners lean on constantly: “when means issued under a scheme meets a requirement listed in a higher assurance level then it shall be presumed to fulfil the equivalent requirement of a lower level”, and “unless otherwise stated in the relevant part of the Annex, all elements listed for a particular assurance level shall be met in order to match the claimed assurance level”. There is no partial credit and no averaging.

Recital 3 states that “International standard ISO/IEC 29115 has been taken into account for the specifications and procedures set out in this implementing act”, and recital 4 adds that its concepts and the specifications of the STORK large-scale pilot should be taken into the utmost account. The European scale is therefore a descendant of the same four-level family NIST abandoned, compressed to three and given legal force. Its Annex has four numbered sections matching Article 1: 2.1 enrolment, 2.2 electronic identification means management, 2.3 authentication, 2.4 management and organisation.

For identity proofing of a natural person, section 2.1.2 moves from a person who “can be assumed to be in possession of evidence recognised by the Member State” that “appears to be valid” at low, to one verified to hold evidence “checked to determine that it is genuine” at substantial, to one verified to hold photographic or biometric evidence compared against an authoritative source at high.

For the design of the means itself, section 2.2.1 requires at least one authentication factor and reasonable steps to verify sole use at low; at least two factors from different categories, designed so the means “can be assumed to be used only” by the person it belongs to, at substantial; and protection “against duplication and tampering as well as against attackers with high attack potential” at high. For issuance and delivery, section 2.2.2 moves from delivery “via a mechanism by which it can be assumed to reach only the intended person”, to delivery “only into the possession of the person to whom it belongs”, to an activation process that itself verifies correct delivery.

For the authentication mechanism, section 2.3.1 requires reliable verification of the means and its validity before releasing person identification data, secure storage, and controls making it “highly unlikely that guessing, eavesdropping, replay or manipulation by an attacker with enhanced-basic attack potential can subvert authentication”. Level substantial adds dynamic authentication and raises the attacker to moderate attack potential; level high raises it to high attack potential.

The phrase “attack potential” is the technical heart of the European scale and it is routinely read as vague English. It is not. It is a term of art from Common Criteria security evaluation and ISO/IEC 18045, where attack potential is calculated from the elapsed time an attack requires, the expertise needed, the knowledge of the target design required, the window of opportunity, and the equipment needed. Enhanced-basic, moderate and high are bands on that calculated scale. This is why eIDAS level high is genuinely difficult: it is an evaluated resistance claim, not a checklist of features.

Management and organisation, section 2.4, is where the European approach differs most: it grades the organization, not the technology. Providers must be a public authority or recognized legal entity, comply with legal requirements, demonstrate financial capability and liability cover, and maintain documented security practices. Information security management must be “effective” at low and follow proven standards or principles at substantial and high, and audits run from periodical internal at low, to independent internal or external at substantial, to independent external at high.

The successor regulation is already in force. Regulation (EU) 2024/1183, amending 910/2014 to establish the European Digital Identity Framework, was published in the Official Journal on 30 April 2024 and entered into force on 20 May 2024. It settles the wallet’s assurance level by fiat: Article 5a(11) states that “European Digital Identity Wallets shall be provided under an electronic identification scheme with assurance level high”, and Article 5a(5)(d) requires them to “meet the requirements set out in Article 8 with regard to assurance level high”. There is no wallet at level substantial. As of August 2026 member states are working towards making at least one wallet available, with the deadline falling in late 2026.

The United Kingdom: confidence, protection, and certified roles#

Britain produced a third design, differing from both others in a way that is easy to miss: it publishes no single scale at all, but two scales and a certification scheme that certifies organizations by role rather than by level. It began as the UK digital identity and attributes trust framework, alpha version, published 11 February 2021, with an updated alpha on 2 August 2021, alpha version 2 (0.2) on 26 January 2023 and the beta (0.3) on 20 July 2023. The gamma (0.4) version was a pre-release on 25 November 2024 and final on 26 June 2025, with certification opening 1 July 2025 and beta certificates valid until 31 March 2026.

Then the framework acquired a statute. Part 2 of the Data (Use and Access) Act 2025 puts it on a legal footing and creates a register of digital verification services kept by the Office for Digital Identities and Attributes, part of the Department for Science, Innovation and Technology; those provisions came into force in December 2025. The first statutory version, renamed the UK digital verification services trust framework and numbered 1.0, was a pre-release on 3 March 2026 and final on 9 June 2026, with certification opening 1 September 2026 once the conformity assessment bodies are accredited. It introduced the UK CertifID trust mark, rewrote the data schema, added the first rules for orchestration services, and extended inclusion and accessibility requirements to all certified providers.

The framework defines five roles rather than five levels. Identity service providers prove and verify a user’s identity at a single point in time. Attribute service providers collect, create, check or share a single piece of information about a user. Orchestration service providers connect parts of the market to support secure data sharing. Holder service providers let users store and manage identity and attribute information for later reuse. Component service providers specialize in only part of a verification or authentication process. The last two are new since gamma; in beta they were subtypes inside the identity service provider role.

The levels live in two separate Good Practice Guides, both of which were renamed and version-controlled for the first time on 3 March 2026 and finalized on 9 June 2026, with their previous editions retrospectively designated version 0.4.

GPG 45, now titled “How to check someone’s identity”, grades identity checking in five separately scored parts: strength of the evidence, 1 to 4; validity, meaning whether the evidence is genuine, 1 to 4; activity history, meaning whether the identity has existed over time, 1 to 4; identity fraud, meaning fraud risk checks, 1 to 3; and verification, meaning whether the identity belongs to the person, 1 to 4. The guidance says explicitly: do not add these scores up.

Instead, named combinations called profiles are published, and meeting a profile gets you one of four levels of confidence: low, medium, high and very high. The profile names encode the level and the number of pieces of evidence, so M2B is a medium-confidence profile using two pieces of evidence.

Those five profiles all use a single piece of evidence, and reading across the table shows the design. M1A and H1A differ only in validity and verification. H1A and V1A are identical in strength, validity and verification; the whole difference is the identity fraud score, 1 for H1A and 3 for V1A. A British very high identity is a high identity with serious fraud checking bolted on, which is a different idea from IAL3, where the distinguishing feature is a trained agent in the room.

The full set runs from L1A through L3A at low confidence, M1A through M3A at medium, H1A through H3A at high, and V1A through V2A at very high.

GPG 44, now titled “How to use authenticators to protect an online service”, grades the second question, with four levels of protection: low, medium, high and very high. Low is any single low-quality authenticator. Medium is two factors from different categories of secret, token or biometric, or alternatively a single syncable authenticator, meaning a passkey, performing user verification in line with the CTAP standard. High is two factors of which at least one is a high-quality authenticator. Very high is two high-quality authenticators, in practice a high-quality token with a high-quality biometric.

Notice what that does to anyone comparing frameworks. Britain has four identity levels and four authentication levels; America has three and three; Europe has three covering both at once. Britain grades the authenticator by quality tier as well as by count, which neither of the others does in the level itself, and uniquely treats a synced passkey as sufficient on its own for medium protection. For a reference point, GOV.UK One Login, the British government’s public-facing login service, states that its journeys give a medium level of confidence under GPG 45, with low and high planned.

Choosing levels by risk#

None of this is any use without a method for choosing. SP 800-63-4 section 3 provides the best-documented one, in five steps: define the online service, in 3.1; conduct an initial impact assessment, in 3.2; select initial assurance levels and baseline controls, in 3.3; tailor and document, in 3.4; and continuously evaluate and improve, in 3.5.

The impact assessment in section 3.2.1 names five categories an organization SHALL include as a minimum: degradation of mission delivery; damage to trust, standing, or reputation; unauthorized access to information; financial loss or liability; and loss of life or danger to human safety, health, or environmental health. For each, the organization identifies the harms and who bears them, and the guidance is explicit that those harmed include individuals and communities, not only the organization. Section 3.2.2 then grades each category Low, “expected to have a limited adverse effect”, Moderate, “a serious adverse effect”, or High, “a severe or catastrophic adverse effect”.

Section 3.3 converts impact into an initial level, separately for each scale. The third row is the one to memorize.

The crucial detail is that each scale is driven by the impact of that particular function failing, not by one overall service impact. You ask three separate questions: what is the harm if we proof the wrong person into an account, if somebody else authenticates as an existing account holder, and if a forged or misdirected assertion is accepted. Those answers are frequently different, which is why there are three scales.

Step 3.4, tailoring, is where the assessment stops being mechanical. It asks the organization to weigh the risks the identity system itself introduces, covering privacy, usability and equity, and permits compensating controls, substituting for a baseline control that cannot be implemented, and supplemental controls, adding to it. It also permits the technique that solves more real problems than any other idea in the document: partitioning the service so less sensitive functions run lower. Step 3.5 then requires performance data, including fraud rates, effects on user communities, and documented processes for evaluation and redress.

The European method is different in kind. eIDAS gives the relying party no risk assessment method at all. It gives member states a notification procedure and public services a legal floor: under Article 6, a service using level substantial or high must accept notified means at that level or above. The level of a national scheme is a policy decision by the notifying state, assessed by peer review, not a per-service calculation. The British framework likewise publishes supplementary codes naming the required level for particular regulated purposes, three of which arrived with gamma as standalone publications, for digital right to work, digital right to rent, and Disclosure and Barring Service identity checks.

The honest version: only the American framework really expects you to do the risk assessment yourself, and in Europe and Britain the answer for a regulated purpose is usually already decided for you by a code or a statutory instrument. Where the American method earns its keep is in the very large space of services that no regulator has written a rule for.

A risk assessment worked end to end#

We will run one service all the way through and end with a configuration a team could implement on Monday: the online account portal of a pension administrator. The figures below are stipulated for the example so that every step has something concrete to work from; they are not measurements of any particular organization.

The portal serves 2.4 million people receiving a monthly pension averaging 1,180 units of the local currency. It offers four things: viewing the next payment date, downloading an annual statement, updating a postal address, and changing the bank account the pension is paid into. Payments run on the 25th, and an account change made before the 18th takes effect that month. Recovery of a misdirected payment succeeds in roughly one case in five, and only if reported within 30 days. Login is delegated to a national government identity provider over OpenID Connect.

Step one, define the online service. The portal is a self-service account for existing recipients, all of whom already exist in the administrator’s records with a pension reference number, a date of birth and a bank account on file. Nobody enrols for a new entitlement here; that happens elsewhere, on paper. That distinction is the most commonly skipped question in the method, because the identity task is not “who is this person” but “is this person the individual already recorded against pension reference 88-40213”.

Step two, conduct the initial impact assessment. We take the five categories from section 3.2.1 and ask what happens when the identity system fails, once per function, because the failures differ. Below is the assessment for the change-of-bank-account function.

Two of the five come out High, so that function carries a High impact. The same exercise for viewing the next payment date returns Low in all five, because a payment date alone is not sensitive and nothing moves. One portal, two functions, two impact levels three steps apart. Any design assigning a single level to “the pension portal” will either make a widow perform an identity ceremony to see a date, or let a fraudster change a bank account behind a password.

Step three, select initial assurance levels, applying the section 3.3 rule separately to each function and each scale:

Function: view next payment date        Impact: Low
  proofing failure   -> Low      -> IAL1
  auth failure       -> Low      -> AAL1
  assertion failure  -> Low      -> FAL1

Function: change bank account           Impact: High
  proofing failure   -> High     -> IAL3
  auth failure       -> High     -> AAL3
  assertion failure  -> High     -> FAL2 or FAL3

Step four, tailor and document. Start with IAL3 for the bank change, which requires on-site attended proofing with a trained agent and biometric collection. The population is 2.4 million recipients, many over eighty, many with limited mobility, some in residential care. Requiring all of them to attend a physical location would cause a larger harm than the fraud it prevents, falling hardest on those least able to bear it, which is exactly the access harm section 3.4 tells us to weigh. So we select IAL2, achieved through remote attended proofing, and add compensating controls to close the gap: notification to the old postal address and registered email on the day of the change; a 5-day hold before the new account becomes effective; a cap on the first payment to a newly added account, with any excess held; and manual review of any account changed within 60 days of an address change. Those controls do not strengthen the proofing. They make the fraud unprofitable and recoverable, which is what the High financial impact was really about.

Next, AAL3, which requires a hardware cryptographic authenticator with a non-exportable key. Posting hardware tokens to 2.4 million pensioners is not a proposal but a fantasy. Read the requirement again, though: AAL3 needs phishing resistance and a key that cannot be exported, and a platform passkey on a modern phone, bound to that device’s secure hardware and not synchronized, meets both. A synced passkey is phishing resistant but excluded from AAL3 by Appendix B of SP 800-63B-4 because the key can leave the device. So we offer AAL3 to those who can reach it and AAL2 with compensating controls to everyone else, set by path: a device-bound passkey gets the 5-day hold; a synced passkey, or a password plus a one-time code, gets a 10-day hold and a callback to the telephone number on record; and because SMS codes are restricted authenticators under section 3.1.3.3, that path also gets the manual review.

Next, federation. The impact of an assertion failure on the bank change is High, so the rule gives FAL2 or FAL3. FAL3 needs a holder-of-key assertion or a bound authenticator and the national provider offers neither, so we take FAL2 and document what it buys and what it does not: protection against forged and injected assertions, none against a compromised identity provider. We then add the control that gap requires. A bank change is never authorized by the assertion alone; the user must also pass a check against data the identity provider does not hold, namely the last four digits of the current bank account and the exact amount of the most recent payment. That is neither proofing nor authentication but a binding check, confirming the federated identity corresponds to the pension record we think it does. Federation gives you a verified person; it does not give you the right account. This is the second thing most designs forget, right behind FAL itself.

Finally, partition the portal, as section 3.4 permits. Here is the finished configuration.

In protocol terms the base session is requested at the low context, and when the user opens the bank details form the resource server rejects the existing token and challenges for the higher context with a 120-second freshness requirement, exactly as in the step-up exchange shown earlier. The portal enforces the SP 800-63B-4 clock at each tier: 30 days overall on the AAL1 browsing session, 24 hours overall and 1 hour idle on the AAL2 session, and 12 hours overall with 15 minutes idle whenever the session is elevated, the elevated context expiring after the single operation regardless.

Step five, continuously evaluate. The administrator instruments four figures monthly: bank changes reversed within 30 days; the share of changes from accounts that also changed address within 60 days; the completion rate of the video proofing session by age band, because a falling rate among the oldest users is an access harm and not a success; and the count of users who abandoned the online change and telephoned the call centre instead, because a call centre is a parallel identity system and an unmeasured one is where the fraud will move.

Now run the same service through the other two frameworks. Under eIDAS, the question is not what the administrator should require but what the national scheme was notified at. If the government identity provider is notified at substantial, then under Article 6 a public-sector pension service using substantial or high must accept it. The administrator cannot demand something on a different axis, because the European level bundles proofing, credential design, authentication and organizational governance into one word, and the hold periods and callbacks sit outside the framework entirely. If the country has moved to the European Digital Identity Wallet under Regulation (EU) 2024/1183, the answer changes again, because Article 5a(11) requires wallets at level high, so the administrator receives a stronger credential than its assessment demanded.

Under the British framework, the administrator would specify a level of confidence from GPG 45 and a level of protection from GPG 44, and look for a provider on the register of digital verification services. The likely specification is high confidence for the bank change, met by a profile such as H1A or H2A, with high protection for the authentication. That is a fourth answer again: British high confidence is not IAL3, because it needs no trained agent in the room, and it is not eIDAS high, because eIDAS high additionally demands evaluated resistance to attackers with high attack potential and independent external audit of the organization.

Read that table carefully, because it holds the single most useful fact in this chapter. Two of the three frameworks have no scale at all for the third column. eIDAS grades the authentication mechanism but publishes no separate level for the strength of an assertion passed between an identity provider and a relying party in a domestic federation, and the British framework certifies orchestration service providers as a role but publishes no graded assertion scale either. Only NIST grades it. That is not a criticism; their architectures assume different things. But it means that if you build across these frameworks, the federation question is yours alone. Nobody will hand you a number for it, and the default your library ships with is FAL1.

A last word. Everything here assumed a human at the far end; software authenticates in far greater volume and none of these scales applies to it, which chapter 47 handles. And much of why proofing exists at all in financial services is anti-money-laundering law rather than security engineering, which chapter 49 handles.

48.98 Common wrong ideas#

Wrong: Assurance is one number, so a service can be described as “level 2”. Right: Assurance is at least three independent claims, covering how carefully the person was identified, how carefully they were checked at login, and how well the message carrying those claims is protected; NIST SP 800-63-4 grades them separately as IAL, AAL and FAL because the failures they prevent are attacked separately.

Wrong: IAL1 means no identity proofing was done. Right: That was true in SP 800-63-3, where IAL1 meant attributes were self-asserted, but SP 800-63-4 of 31 July 2025 repurposed IAL1 to require real proofing establishing that the claimed identity exists, so a service documented as IAL1 under the old text is now below the bottom of the scale.

Wrong: FAL2 means the assertion is encrypted. Right: That was the SP 800-63-3 definition; in SP 800-63C-4 the line between FAL1 and FAL2 is protection against assertion injection, single-relying-party audience restriction and a pre-established trust agreement, because encryption never prevented an assertion being planted into the wrong user’s session.

Wrong: eIDAS level substantial is equivalent to IAL2 plus AAL2. Right: No standards body or regulator has adopted any mapping between the two; eIDAS grades a whole scheme, including organizational governance and audit regime, in one word, and states its authentication requirements as Common Criteria attack potential rather than authenticator types, so any table equating them is a working approximation with no legal weight.

Wrong: Choosing the highest available level is the safe default. Right: Higher levels are more exclusionary rather than simply better, and SP 800-63-4 section 3.4 requires organizations to assess the harms the identity system itself causes, including to access and equity, so demanding on-site attended proofing from an elderly population moves harm from a hypothetical fraudster to real applicants.

Wrong: A high assurance level means the identity is very likely correct. Right: A level describes which written procedure was followed, not the outcome, and two providers at the same level can have order-of-magnitude different false acceptance rates, which is why step 3.5 of the SP 800-63-4 process requires continuous measurement of real fraud rates.

Wrong: Session limits are a usability setting the team can pick freely, and one set of levels applies to a whole service. Right: SP 800-63B-4 sets session limits per level, with 30 days at AAL1, a recommended 24 hours overall and 1 hour idle at AAL2, and a mandatory 12 hours with 15 minutes idle recommended at AAL3, while section 3.4 of SP 800-63-4 permits partitioning a service so that less sensitive functions run lower, with step-up under RFC 9470 raising the level for one operation.

Wrong: A federated login gives you the right customer account. Right: An assertion tells you a verified person authenticated, not which of your records they are; binding that identity to the correct local account is a separate step needing evidence the identity provider does not hold, and skipping it is a common cause of account takeover in otherwise sound systems.

Wrong: The United Kingdom uses the NIST levels. Right: Britain publishes two separate four-level scales, GPG 45 levels of confidence for identity checking and GPG 44 levels of protection for authenticators, reaches a level by meeting a named profile such as M1A rather than by scoring, and certifies organizations by role under the trust framework 1.0 published 9 June 2026, with certification opening 1 September 2026.

48.99 Chapter summary in 20 lines#

1. Assurance is not a feeling; it is a graded claim that a specified procedure was followed, auditable by somebody outside your organization.
2. One number cannot express identity confidence, because an attacker attacks the weakest of your controls rather than their average.
3. The three questions graded separately are how well the person was identified, how well they were checked today, and how well the message carrying both claims is protected.
4. The United States used a single ordinal for fifteen years under OMB Memorandum M-04-04 of 16 December 2003, and retired it in OMB Memorandum M-19-17 of 21 May 2019.
5. NIST SP 800-63-3, published June 2017 with errata of 2 March 2020, replaced that ordinal with IAL, AAL and FAL, three scales of three levels each.
6. NIST SP 800-63-4 was published as a final document on 31 July 2025, and SP 800-63-3 was withdrawn the following day.
7. The largest change in the 2025 revision is that IAL1 now requires real identity proofing, where in 2017 it meant attributes were self-asserted.
8. SP 800-63A-4 grades evidence as FAIR, STRONG or SUPERIOR, and names four proofing types from remote or on-site and attended or unattended.
9. SP 800-63B-4 requires verifiers at AAL2 to offer at least one phishing-resistant option, and excludes syncable passkeys from AAL3 because their keys can be exported.
10. Session limits are set per level: 30 days at AAL1, a recommended 24 hours and 1 hour idle at AAL2, and a mandatory 12 hours with 15 minutes idle recommended at AAL3.
11. SP 800-63C-4 moved the FAL2 boundary from assertion encryption to injection protection, single-audience restriction and a pre-established trust agreement.
12. FAL3 is the only level that survives a compromised identity provider, because it makes the relying party verify a key the subscriber controls.
13. Europe defines low, substantial and high in Article 8 of Regulation (EU) No 910/2014, with technical content in Implementing Regulation (EU) 2015/1502 of 8 September 2015.
14. The European levels rest partly on Common Criteria attack potential bands of enhanced-basic, moderate and high, and partly on graded audit requirements.
15. Regulation (EU) 2024/1183, in force since 20 May 2024, requires European Digital Identity Wallets to be provided at assurance level high, in Article 5a(11).
16. Britain grades identity checking with GPG 45 levels of confidence of low, medium, high and very high, reached by meeting named profiles such as M1A.
17. Britain grades authenticators separately with GPG 44 levels of protection, and certifies organizations by role under the trust framework 1.0 of 9 June 2026.
18. No official mapping exists between the American, European and British scales, and any table equating them is an approximation with no regulatory standing.
19. Levels are chosen from the impact of each function failing, with Low giving level 1, Moderate level 2, and High level 3 or, for federation, FAL2 or FAL3.
20. The professional answer is rarely one level for a service; it is a partitioned service with a cheap default, a documented step-up at the dangerous operations, and compensating controls wherever the mechanical answer would exclude the people the service exists to serve.

Chapter sources: NIST SP 800-63-4, Digital Identity Guidelines, 31 July 2025, DOI 10.6028/NIST.SP.800-63-4, sections 3.1 to 3.5 and 3.3.2, with its companion volumes of the same date: SP 800-63A-4 sections 2.1.3, 2.3.1 to 2.3.3 and 4.1 to 4.4; SP 800-63B-4 sections 2.1.3, 2.2.2, 2.2.3, 2.3.2, 2.3.3, 3.1.1.2, 3.1.3.3 and Appendix B; and SP 800-63C-4 section 2 and sections 2.3 to 2.5. Also NIST SP 800-63-3 of June 2017 with errata of 2 March 2020, section 5.2 and Tables 5-1 to 5-3, withdrawn 1 August 2025, with SP 800-63B sections 4.1.3, 4.2.3 and 4.3.3; NIST SP 800-63-1 of 12 December 2011 and SP 800-63-2 of 29 August 2013; OMB Memorandum M-04-04 of 16 December 2003 and M-19-17 of 21 May 2019; ISO/IEC 29115:2013, moved to stage 90.92 in May 2024 with ISO/IEC CD 29115.2 under development; Regulation (EU) No 910/2014 of 23 July 2014, Articles 6 and 8; Commission Implementing Regulation (EU) 2015/1502 of 8 September 2015, Article 1, recitals 3 and 4, and Annex sections 2.1.2, 2.2.1, 2.2.2, 2.3.1 and 2.4; Regulation (EU) 2024/1183, in force 20 May 2024, Article 5a(5)(d) and 5a(11); the UK trust framework from alpha of 11 February 2021 to gamma (0.4) of 26 June 2025 and the UK digital verification services trust framework 1.0 of 9 June 2026; Part 2 of the Data (Use and Access) Act 2025; GPG 45, How to check someone’s identity (1.0), and GPG 44, How to use authenticators to protect an online service (1.0), both 3 March 2026 updated 9 June 2026; GOV.UK One Login guidance on levels of confidence; Login.gov developer documentation as of August 2026; RFC 6711 of August 2012, RFC 8176, RFC 8485 of October 2018 by Justin Richer and Leif Johansson, and RFC 9470 of September 2023 by Vittorio Bertocci and Brian Campbell; and OpenID Connect Core 1.0.