# fal

Source: https://startwithidentity.com/glossary/fal/
Last updated: 2026-10-16
License: content by Start with Identity. Cite the source URL.

---

NIST 800-63C levels describing how strongly a federated login protects the assertion an identity provider (IdP) sends to a relying party (RP). FAL1: the IdP signs the assertion with approved cryptography and restricts its audience. FAL2: adds strong protection against assertion injection, limits each assertion to a single RP, and requires a trust agreement set up before the transaction. FAL3: the RP also verifies that the subscriber controls an authenticator, through a holder-of-key assertion or a bound authenticator. Defined in [NIST SP 800-63C-4](https://pages.nist.gov/800-63-4/sp800-63c.html).

FAL is the level teams forget to write down. A program can demand AAL3 at the IdP and then hand the result to every application as a bearer SAML assertion or ID token, which an attacker who steals it can replay without ever touching the hardware key. The practical line in Revision 4 sits at FAL2, where injection protection means the RP must start the federation transaction, so unsolicited IdP-initiated responses no longer qualify. FAL3 closes the replay gap the same way [proof of possession](https://startwithidentity.com/glossary/proof-of-possession/) does for OAuth tokens: the assertion is only useful alongside a phishing-resistant authenticator the user holds.

See also: [NIST 800-63](https://startwithidentity.com/glossary/nist-800-63/), [AAL](https://startwithidentity.com/glossary/aal/), [IAL](https://startwithidentity.com/glossary/ial/), [identity federation](https://startwithidentity.com/glossary/federation/), [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/)