Crosswalk version: 0.1 (Working Draft) Publication date: 2026-07-01 Canonical URL (planned): https://spec.attestto.com/ieal/crosswalks/nist-800-63 Editors: Eduardo Chongkan (Attestto) License: Creative Commons Attribution 4.0 International (CC-BY 4.0) Referenced specification: IEAL v0.1 Referenced standard: NIST SP 800-63-4, final publication dated 2025-07-31, DOI 10.6028/NIST.SP.800-63-4
This crosswalk is informational. It is authored by Attestto and describes how Attestto’s Identity Evidence Assurance Level (IEAL) specification relates to controls in the United States National Institute of Standards and Technology (NIST) Special Publication 800-63-4 series (Digital Identity Guidelines).
This crosswalk is not endorsed by NIST. Attestto has not participated in the NIST 800-63-4 publication process (both the Initial Public Draft comment window of 2022-12-16 to 2023-04-14 and the Second Public Draft comment window of 2024-08-21 to 2024-10-08 are closed as of the publication date above).
Nothing in this crosswalk constitutes a certification claim. Formal certification of an implementation against NIST SP 800-63-4 requires assessment by an authorized NIST-approved assessor. IEAL levels are Attestto’s specification and do not confer NIST Identity Assurance Level (IAL), Authenticator Assurance Level (AAL), or Federation Assurance Level (FAL) status.
Where this crosswalk references specific sections of NIST SP 800-63-4, the reader is directed to the authoritative source at pages.nist.gov/800-63-4.
References
The IEAL specification defines a compositional model for identity evidence assurance across three axes (Capture, Algorithm, Storage) and combines them into composite levels L0 through L6. Many prospective adopters, particularly in regulated procurement contexts, ask a natural question:
“How does IEAL relate to NIST SP 800-63-4?”
This document answers that question. It maps each IEAL axis and composite level to the corresponding NIST controls and identifies the areas where IEAL extends NIST guidance to cover architectural concerns NIST intentionally leaves to implementer policy.
The crosswalk does not modify either specification. IEAL and NIST SP 800-63-4 remain independently governed documents.
NIST SP 800-63-4 was finalized on 2025-07-31 and consists of a base document and three companion volumes. Section references throughout this crosswalk refer to the final publication.
| Document | Scope | Canonical URL |
|---|---|---|
| SP 800-63-4 (base) | Definitions, model, risk assessment, applicability | https://pages.nist.gov/800-63-4/sp800-63.html |
| SP 800-63A-4 | Enrollment and Identity Proofing (IAL) | https://pages.nist.gov/800-63-4/sp800-63a.html |
| SP 800-63B-4 | Authentication and Authenticator Management (AAL) | https://pages.nist.gov/800-63-4/sp800-63b.html |
| SP 800-63C-4 | Federation and Assertions (FAL) | https://pages.nist.gov/800-63-4/sp800-63c.html |
Community engagement channels (informational, for adopters wishing to comment on future revisions):
[email protected]NIST SP 800-63-4 base §2.4 introduces a Subscriber-Controlled Wallet model (Figure 5) alongside the traditional identity-provider-mediated model. In the Subscriber-Controlled Wallet model:
This is the W3C Verifiable Credentials three-party model, formally adopted into NIST vocabulary in the 2025-07-31 final publication.
IEAL is designed to fit inside this model. The IEAL claim schema (IEAL v0.1 Section 8) is intended to be included in attribute bundles issued to a Subscriber-Controlled Wallet. IEAL classifies the assurance strength of the underlying identity evidence, not the wallet or the presentation protocol.
Consequence for procurement: an adopter that has selected NIST SP 800-63-4 as its identity-guidance baseline can require IEAL-classified evidence in the attribute bundles it issues or accepts without leaving the NIST model.
The IEAL Capture axis grades the cryptographic attestation of the capture environment.
| IEAL Capture value | Description (IEAL v0.1 §4) | NIST 800-63-4 correspondence |
|---|---|---|
| C0 — Untrusted client | No cryptographic attestation of the capture platform | NIST 800-63A §4 permits unattested captures at IAL1 subject to other proofing controls. NIST does not grade capture-environment attestation independently. |
| C1 — Software-attested mobile | Platform-level attestation from OS vendor, bound to a session nonce | Consistent with NIST 800-63B §3.2.4 (Attestation). NIST requires ≥112-bit signed attestations but treats attestation as an abstract concept and does not name Play Integrity or App Attest as products. WebAuthn attestation is normatively referenced. |
| C2 — Hardware-attested mobile | As C1, with the attestation bound to a hardware-protected key (StrongBox, Secure Enclave) | Consistent with NIST 800-63B §§3.2.11 and 3.2.12 (hardware-protected key storage in TPM, TEE, or Secure Element). NIST does not require the capture platform to carry an attestation, but where an attestation is provided, the requirements for cryptographic strength apply. |
Whitespace filled by IEAL: NIST 800-63-4 does not grade capture-environment attestation as an independent axis. IEAL provides the grading.
The IEAL Algorithm axis grades Presentation Attack Detection (PAD) strength.
| IEAL Algorithm value | Description (IEAL v0.1 §5) | NIST 800-63-4 correspondence |
|---|---|---|
| A0 — None | No PAD or liveness verification | Below NIST biometric-verification controls |
| A1 — Active challenge (basic) | Scripted pose sequence, blink prompt, or similar, without additional anti-spoof measures | Not sufficient for the normative PAD requirement in NIST 800-63A §3.13 |
| A2 — Active challenge (hardened) | A1 plus randomized challenge, real eye-aspect-ratio blink detection, screen/moiré detection, and 3D head-pose estimation | Represents an implementer’s good-faith effort toward the NIST 800-63A §3.13 PAD requirement but is not sufficient without formal ISO/IEC 30107-3 certification |
| A3 — PAD Level 1 | ISO/IEC 30107-3 Level 1 PAD certification by an iBeta or NVLAP-accredited laboratory | Consistent with the normative requirement in NIST 800-63A §3.13 (ProofBios), which requires conformance to ISO/IEC 30107-3:2023 with an IAPAR (Imposter Attack Presentation Accept Rate) below 0.07. A3 certification provides the pathway that satisfies this NIST requirement. |
| A4 — PAD Level 2 | ISO/IEC 30107-3 Level 2 PAD certification by an iBeta or NVLAP-accredited laboratory | Exceeds the minimum NIST 800-63A §3.13 requirement. Additional NIST controls apply: 800-63B §3.2.3.2 requires PAD SHALL for facial verification, SHOULD for iris and fingerprint. Voice-based biometric comparison is prohibited by NIST 800-63B §3.2.3. |
Alignment: The IEAL Algorithm axis A3 and A4 values are aligned with the specific normative PAD requirement in NIST 800-63A §3.13. Implementers targeting NIST-aligned identity proofing at IAL2 with the Biometric verification pathway are required to reach at minimum A3.
The IEAL Storage axis grades where the subscriber-controlled witness resides and how it is protected.
| IEAL Storage value | Description (IEAL v0.1 §6) | NIST 800-63-4 correspondence |
|---|---|---|
| S0 — None | No witness retained beyond the artifact | NIST 800-63A does not require post-proofing witness retention in all cases. Depending on the identity-proofing pathway, retention may be required for IAL3 (on-site attended proofing with biometric sample retention). |
| S1 — OS-managed secret store | Key material or witness in Keychain, DPAPI, or Secret Service, with OS-mediated authorization | Consistent with NIST 800-63B §3 authenticator-storage baseline for AAL1 and AAL2 |
| S2 — Hardware-protected key store | Key material in TPM, TEE, Secure Enclave, StrongBox, or equivalent hardware-backed key store | Required by NIST 800-63B §§3.2.11 and 3.2.12 for non-exportable private keys at AAL3. Implementations at S2 satisfy the NIST authenticator-storage requirement. |
| S3 — External hardware token | Key material on external hardware security token (FIDO2, smart card) | Consistent with NIST 800-63B AAL3 cryptographic-hardware requirements. NIST 800-63B additionally requires that syncable authenticators SHALL NOT be used at AAL3. Implementations at S3 (external, non-syncable hardware) satisfy this constraint. |
| S4 — Multi-party recovery | Threshold multi-party approval (for example, Shamir 2-of-3) for witness release | Not directly addressed by NIST 800-63-4. NIST 800-63B addresses authenticator management and recovery but does not require or grade threshold-based multi-party recovery constructions. |
Whitespace filled by IEAL: NIST 800-63-4 does not grade the location of subscriber-controlled evidence storage as an independent axis, nor does it grade multi-party recovery constructions. IEAL provides both.
Consistency: Storage axis value S2 satisfies the specific NIST 800-63B non-exportable-private-key requirement at AAL3. Storage axis value S3 additionally satisfies the NIST prohibition on syncable authenticators at AAL3.
The following table shows the approximate correspondence between IEAL composite levels (IEAL v0.1 §7) and NIST assurance levels. This table is informational.
| Composite IEAL | Capture | Algorithm | Storage | Approximate NIST correspondence |
|---|---|---|---|---|
| L0 | C0 | A0 | S0 | Below IAL1 and below AAL1 |
| L1 | C0 | A1 | S1 | Approximately IAL1 with AAL1 or AAL2 authenticator |
| L2 | C0 | A2 | S2 | Between IAL1 and IAL2, with AAL2 authenticator |
| L3 | C1 or C2 | A2 | S2 | Approaching IAL2. Capture attestation exceeds NIST minimum for IAL2; Algorithm axis A2 does not meet the ISO/IEC 30107-3 PAD normative requirement for the Biometric verification pathway. Suitable for the Non-Biometric or Digital Evidence pathways of NIST 800-63A §4.2. |
| L4 | C1 or C2 | A3 | S2 | IAL2 with the Biometric verification pathway satisfied. Storage axis S2 satisfies the AAL3 non-exportable-private-key requirement, though IAL2 does not require AAL3. |
| L5 | C1 or C2 | A4 | S2 | IAL2 with additional controls. Algorithm axis A4 exceeds the NIST 800-63A §3.13 PAD minimum. Storage axis S2 satisfies AAL3 storage. |
| L6 | C2 | A4 | S2 required, S3 required for release, S4 required for multi-party operations | Subset of IAL3 controls. NIST 800-63A requires IAL3 to be an on-site attended proofing session with CSP retention of a biometric sample. IEAL L6 does not mandate on-site attendance and therefore does not fully satisfy IAL3. It does satisfy the strongest NIST 800-63B authenticator-storage constraints (AAL3, non-syncable, hardware-bound). |
Caveat on IAL3: NIST 800-63A requires IAL3 to be an on-site attended proofing session. IEAL L6 permits remote proofing with hardware-attested mobile capture and multi-party co-signature. Implementers requiring formal IAL3 status must additionally satisfy the on-site attendance requirement, which IEAL does not preclude but does not itself provide.
NIST SP 800-63C §4.6.1.3 (Runtime Decision) requires that identity providers obtain positive confirmation from the subscriber before releasing attributes to a relying party, and prohibits conditioning the identity service on unrelated processing consent.
IEAL treats per-event consent as normative for access to retained witnesses (IEAL v0.1 §14). Specifically, IEAL requires that:
Consistency with NIST: The IEAL per-event-consent requirement is consistent with NIST 800-63C §4.6.1.3 and extends it to cover access to retained biometric witnesses in Subscriber-Controlled Wallet architectures, a case that NIST §4.6.1.3 addresses generally but not specifically for retained biometric evidence.
NIST SP 800-63C §3.12.1 names the following attribute-bundle formats as acceptable for federation assertions:
IEAL v0.1 §9 defines the carriers for IEAL claims. All three of the NIST-named formats are acceptable carriers for IEAL claims:
| NIST-named format | IEAL carrier support |
|---|---|
| W3C Verifiable Credentials | IEAL v0.1 §9.2 |
| SD-JWT | IEAL v0.1 §9.2 |
| ISO/IEC 18013-5 mDoc | Not explicitly listed in IEAL v0.1 §9.2 but permitted under the same subsection. Formal mDoc carrier profile deferred to a future revision. |
IEAL additionally permits embed-first carriers where the identity evidence is associated with an existing document container (PDF signature dictionary, C2PA manifest, XMP metadata). NIST 800-63-4 does not address embedded IEAL-equivalent claims in existing document containers directly, so the embed-first carrier pattern is an IEAL extension beyond NIST-named formats.
The following concerns are addressed by IEAL but not graded as independent axes by NIST SP 800-63-4:
These are the areas where an IEAL claim adds machine-verifiable detail beyond what a bare NIST IAL/AAL claim conveys.
The following NIST controls are out of scope for IEAL v0.1:
Implementers seeking NIST-aligned identity architectures should treat IEAL as an evidence-classification supplement, not a replacement for the NIST 800-63-4 controls above.
For procurement authorities requiring NIST SP 800-63-4 alignment, this section provides illustrative guidance on how IEAL levels typically map to NIST pathway choices. Adopters must conduct their own risk assessment per NIST 800-63 base to select appropriate levels for their specific operations. Nothing in this section is a normative procurement template.
How IEAL levels typically map to NIST pathway choices (informational only):
The IEAL levels named above are illustrative examples of levels an adopter might choose. They are not a normative procurement template. Adopters bear full responsibility for confirming that their specific interpretation of NIST SP 800-63-4 aligns with their chosen IEAL levels and their risk profile. This crosswalk supports that analysis but does not conduct it.
| Version | Date | Change |
|---|---|---|
| 0.1 | 2026-07-01 | Initial Working Draft. Anchored to NIST SP 800-63-4 final publication of 2025-07-31 (DOI 10.6028/NIST.SP.800-63-4). |
| 0.1.1 | 2026-07-01 | Audit pass — soften A3 IAPAR alignment claim from “meets” to “provides the pathway that satisfies”; remove unverified section-number references (§4.3.3 for IAL3, §4.5 for 63B recovery, §3 for 63 base risk methodology, §3.10 for 63A fraud); rewrite §10 procurement clause from RFC 2119 SHALL-based template to explicit informational guidance to reduce risk of verbatim use. |
End of crosswalk v0.1 Working Draft.