NIST SP 800-63-4 Digital Identity Guidelines

• NIST SP 800-63-4 is the authoritative digital identity guidelines publication developed under the Federal Information Security Modernization Act (FISMA) and is available free of charge.
  This publication supersedes NIST SP 800-63-3 (June 2017) and was approved by the NIST Editorial Review Board on April 28, 2025. It applies to federal information systems but not to national security systems without express approval from appropriate federal officials.
• The guidelines cover identity proofing, authentication, federation, and related assertions with both normative technical requirements and informative recommendations.
  The scope includes employees, contractors, and private individuals interacting with government information systems over networks. The guidelines define requirements for identity proofing, enrollment, authenticators, management processes, authentication protocols, federation, and assertions.
• This publication is not subject to copyright in the United States and may be used by nongovernmental organizations on a voluntary basis.
  NIST requests that patent holders disclose patent claims whose use may be required for compliance with the publication, though as of publication no such claims have been identified. NIST does not endorse any specific products or services mentioned in the document.
• The publication is consistent with Office of Management and Budget (OMB) Circular A-130 and does not supersede existing authorities of federal officials.
  These guidelines serve as the baseline for federal information security but are not intended to constrain the development or use of standards outside the scope of digital identity for government systems.

Source: Front Matter, pages 1-6

• SP 800-63-4 and its companion volumes provide technical and process guidelines for organizations implementing digital identity services.
  This publication is part of a suite that includes SP 800-63A, SP 800-63B, and SP 800-63C, together covering the complete framework for digital identity implementation.

Source: Preface and Acknowledgments, page 10

• A digital identity is unique within an online service context, but one person may hold multiple digital identities, and the real-life identity of the holder may remain unknown.
  Organizations can use anonymous or pseudonymous accounts when confidence in a person's real-life identity is not required; in other cases, digital identity establishes trust between the holder and those interacting with the service.
• Digital identity risks are dynamic and exist along a continuum, requiring outcome-based risk management approaches tailored to each organization's unique needs rather than a one-size-fits-all compliance approach.
  These guidelines define assurance levels as baseline control sets that provide a starting point and support interoperability, but organizations should tailor implementations based on their specific risk profile and circumstances.
• Digital identity risks extend beyond impacts to the service provider and must account for risks to individuals, communities, and other organizations.
  Organizations should consider how digital identity decisions affect the individuals they serve and must balance security with privacy and customer experience alongside other identity management mechanisms like call centers and in-person interactions.
• These guidelines address identity proofing, authentication, federation, and privacy requirements for credential service providers, verifiers, and relying parties as part of a comprehensive digital identity model.
  The guidance supplements the NIST Risk Management Framework and expands it to include customer experience considerations and impacts on enterprise operations, individuals, and other organizations.
• Digital identity management processes typically involve processing personal information, presenting privacy risks that must be mitigated through privacy requirements and considerations integrated into the guidelines.
  Organizations should coordinate digital identity solutions with systems and processes often outside IT teams' direct control to deliver effective, modern, and customer-driven online services.

Source: Introduction, pages 11-12

• These guidelines apply to all online services requiring digital identity assurance, regardless of whether users are the public, business partners, or government employees and contractors.
  The scope covers organizational services interacting with external users (such as public benefits or partner collaboration spaces) as well as federal systems accessed by employees and contractors. The term 'person' refers only to natural persons.
• National security systems as defined in 44 U.S.C. § 3552(b)(6) are excluded from these guidelines.
  Private-sector organizations and state, local, and tribal governments may adopt these standards where appropriate, but national security systems follow their own separate requirements.
• The Personal Identity Verification (PIV) standard FIPS 201 extends these guidelines for the federal enterprise with additional technical controls for PIV Cards and derived credentials.
  FIPS 201 and its companion publications provide specific processes for federal employees and contractors beyond what these guidelines specify.
• These guidelines address logical access to online systems, services, and applications but do not explicitly cover physical access control, machine-to-machine authentication, IoT devices, or API access on behalf of subjects.
  While the processes in these guidelines can be adapted for physical access where appropriate, the document does not provide normative requirements for these use cases.

Source: Section 1.1, pages 12-13

• Organizations must select an assurance level for each of three digital identity functions: Identity Assurance Level (IAL) for identity proofing, Authentication Assurance Level (AAL) for authentication, and Federation Assurance Level (FAL) for federation.
  These assurance levels are determined through risk assessment and are used to select controls that mitigate errors and harms occurring during identity proofing, authentication, and federation processes. Each xAL has three assurance levels.
• SP 800-63 consists of four volumes that together provide the complete framework: the main volume describing models and risk methodology, plus SP 800-63A for identity proofing, SP 800-63B for authentication, and SP 800-63C for federation.
  Each companion volume contains both normative requirements and informative guidance. Organizations use Section 3 (Digital Identity Risk Management) to understand the risk assessment process before consulting the relevant companion volumes for specific requirements at each assurance level.
• SP 800-63A specifies requirements for identity proofing and enrollment at three IALs, including credential service provider responsibilities for account management and binding authenticators.
  This volume covers both remote and in-person enrollment processes and details how credential service providers establish and maintain subscriber accounts.
• SP 800-63B provides requirements for authentication processes at three AALs and includes guidance on authenticator selection and management throughout the authenticator lifecycle.
  The volume addresses how to handle authenticator events such as invalidation due to loss or theft.
• SP 800-63C addresses federated identity architectures and the use of assertions to communicate authentication results and identity information from credential service providers or identity providers to relying parties.
  This volume ensures that federated systems properly convey verified identity and authentication information when organizations connect through federated protocols.

Source: Section 1.2, pages 13-14

• Enterprise risk management for digital identity must consider information security, fraud, privacy, and customer experience as interconnected factors affecting enterprise assets, individuals, and other organizations.
  Organizations should weigh these multidisciplinary factors together during analysis and may determine that additional measures beyond those specified in the guidelines are appropriate based on legal requirements, risk assessment outcomes, or use of compensating controls.
• Federal agencies must comply with FISMA and NIST RMF requirements, while non-federal organizations should follow comparable standards such as ISO/IEC 27001 to secure digital systems.
  The identity, authentication, and federation assurance levels in these guidelines augment but do not replace the information security controls determined under FISMA and the RMF.
• Organizations must assess and manage identity-related fraud risks in identity proofing and authentication processes, considering evolving threats and innovative anti-fraud measures available in the market.
  SP 800-63-4 enhances fraud prevention by repurposing IAL1, updating authentication threat models, providing phishing-resistant authentication options, preventing automated enrollment attacks, and preparing for new technologies like mobile driver's licenses.
• Privacy policies and system requirements must be demonstrably implemented when processing personal information, with plain language breach notifications explaining what information was released and how it was exploited.
  Organizations should reference the NIST Privacy Framework, Privacy Act of 1974, OMB guidance on privacy impact assessments, SP 800-53 privacy controls, and SP 800-122 guidance on protecting PII.
• Control tailoring enables organizations to make informed risk-based decisions about deploying technologies and processes that serve their users while adjusting baseline controls to meet customer experience needs.
  This concept allows less sensitive functions to be available at lower assurance levels to improve access without compromising security.
• Continuous improvement programs require ongoing evaluation of how well organizations mitigate risks and meet user needs through metrics and cross-functional assessment.
  This data-driven approach supports effective, modern solutions that respond to extensive user populations.
• Usability is the extent to which a system can be used to achieve goals with effectiveness, efficiency, and satisfaction, and it supports security, customer experience, and service delivery objectives.
  Digital identity systems should be designed so users can easily do the right thing, have difficulty doing the wrong thing, and can easily recover from mistakes, with usability evaluations conducted using representative users in realistic contexts.

Source: Section 1.3, Enterprise Risk Management Requirements and Considerations, pages 14-17

• Terms in CAPITALS represent normative requirements, while the same terms in lowercase do not carry normative force.
  This convention allows the document to distinguish between mandatory requirements and informative or optional guidance using capitalization as a visual marker.
• SHALL and SHALL NOT indicate strict requirements that must be followed with no permitted deviation.
  These terms specify mandatory actions or constraints that implementers must adhere to in order to conform to the publication.
• SHOULD and SHOULD NOT indicate recommended courses of action that are preferred but not strictly required.
  These terms suggest a particular approach is suitable or encouraged, but alternative approaches are permitted without violating the standard.
• MAY and NEED NOT indicate permissible courses of action within the bounds of the publication.
  These terms allow implementers discretion to choose whether to implement an option.
• CAN and CANNOT indicate material, physical, or causal possibility or capability.
  These terms describe what is possible or impossible rather than what is required or recommended.

Source: Section 1.4, page 18

• The document designates each section as either normative (mandatory for compliance) or informative (non-mandatory).
  This classification determines which requirements are binding on implementers and which sections provide background or context without creating compliance obligations.
• Section 1 (Introduction) and Section 2 (Digital Identity Model) are informative, providing foundational context rather than mandatory requirements.
  These sections introduce the document and explain general identity system concepts but do not establish requirements that must be followed.
• Section 3 (Digital Identity Risk Management) is normative, establishing mandatory requirements for risk assessment and assurance level selection.
  This is the core normative section that organizations must follow when implementing digital identity systems under these guidelines.
• The References, Appendices A, B, and C are all informative, serving as supporting material rather than establishing mandatory requirements.
  These sections provide citations, abbreviations, glossary definitions, and historical change information to aid understanding but are not binding.

Source: Section 1.5, page 18

• A digital identity model defines the roles, functions, and interactions between entities that collectively manage the lifecycle of digital identity for online services.
  The model encompasses identity proofing, authentication, federation, and other functions performed by different parties (subscribers, CSPs, RPs, and supporting entities) to establish and maintain trust in digital identity claims.
• The primary entities in a digital identity ecosystem are subscribers (users), Credential Service Providers (CSPs) that manage credentials, Relying Parties (RPs) that provide online services, and supporting entities like identity proofing services.
  Each entity has distinct responsibilities: subscribers manage their credentials and accounts, CSPs issue and maintain credentials, RPs verify identity to authorize access, and supporting entities provide specialized services like document verification.
• Three main architectural models exist: non-federated systems where the RP performs all identity functions, federated systems where identity responsibility is distributed across multiple entities, and wallet-based systems where subscribers control portable credentials.
  Each architecture offers different tradeoffs in terms of user privacy, administrative burden, credential portability, and security responsibility distribution among the involved parties.

Source: Section 2, pages 19-20

• Digital identity models vary from simple architectures that group functions under a single entity to complex models that distribute functions across multiple entities.
  The guidelines present market-available models reflecting different levels of organizational complexity and capability.
• A subject is a person who takes one of three roles depending on their position in the digital identity process: applicant (being identity-proofed), subscriber (completed enrollment or authenticated), or claimant (making an authentication claim).
  These role distinctions track the subject's progression through the identity lifecycle.
• A credential service provider (CSP) performs identity proofing, enrollment, account establishment, and authenticator binding functions.
  The CSP maintains the subscriber account as its record of the subscriber's identity, attributes, and authenticators, and may be an independent third party.
• A relying party (RP) provides online services and grants access based on identity assertions from a verifier or identity provider.
  RPs do not perform authentication themselves but depend on external entities to verify subscriber identity.
• A verifier confirms identity by verifying the claimant's possession and control of authenticators, checking authenticator binding to the subscriber account, and confirming the account is active.
  The verifier uses an authentication protocol to perform these identity confirmation functions.
• An identity provider (IdP) manages primary authenticators and issues identity assertions in federated architectures.
  The IdP operates on the subscriber's account information to produce assertions that relying parties use to grant access.
• The functions of CSP, verifier, and IdP may be performed by a single entity or distributed across multiple entities depending on implementation.
  Organizational boundaries do not rigidly separate these roles; implementations can consolidate or distribute these responsibilities.

Source: Section 2.1 (Overview), pages 19-20

• Identity proofing and enrollment begin when an applicant initiates the process, typically by attempting to access an online application from a Credential Service Provider (CSP).
  The CSP or its component service requests identity evidence and attributes from the applicant, either through online or in-person transaction. This marks the starting point of the identity verification workflow.
• The CSP resolves, validates, and enrolls the applicant by confirming their unique identity, verifying evidence authenticity, and validating attribute accuracy.
  Once successfully identity-proofed, the applicant becomes a subscriber and receives a unique subscriber account with one or more registered authenticators bound to it.
• Subscribers are responsible for maintaining control of their authenticators and complying with CSP policies to remain in good standing.
  This responsibility includes protecting authenticators from theft and adhering to any conditions set by the CSP for continued account validity.
• A subscriber account established at enrollment uniquely identifies the subscriber and records information about the subscriber and their bound authenticators.
  The subscriber account serves as the central record for managing the subscriber's identity and authentication credentials within the CSP system.

Source: Section 2.2, pages 20-20

• An authenticator is a means of demonstrating possession or control of one or more authentication factors in an authentication protocol.
  Authenticators enable verification that a claimant is who they claim to be by proving control over factors such as something known, something possessed, or something that is.
• Three types of authentication factors are defined: something you know (password), something you have (device with cryptographic key), and something you are (biometric data).
  Single-factor authentication uses only one of these factor types, while multi-factor authentication (MFA) combines two or more distinct factors from different categories.
• All authenticators must contain or comprise a secret based on either asymmetric key pairs or shared secrets including symmetric keys, OTP seeds, or passwords.
  Private keys in asymmetric pairs are stored on the authenticator and available only to the claimant; symmetric keys must be complex, long, and stored securely on hardware or software the subscriber controls.
• Activation secrets are passwords used locally to unlock authentication keys within an authenticator and remain within the authenticator and user endpoint.
  An example is a PIN used to activate a PIV card, which provides an additional security layer for multi-factor authentication.
• Biometric characteristics cannot be used for single-factor authentication but may serve as an authentication factor in multi-factor authentication combined with a physical authenticator.
  Biometric data such as fingerprints or facial features are not considered secrets and therefore do not meet the requirement for standalone authentication.
• Knowledge-based authentication and biometric characteristics alone are not acceptable authenticator secrets under these guidelines.
  KBA (answering secret questions) and single biometrics lack the security properties required for digital authentication as defined by these standards.
• The authentication process involves interaction between a claimant, a verifier, and a relying party to demonstrate possession and control of valid authenticators bound to the subscriber's identity.
  The claimant uses authenticators to generate output, the verifier validates it, and the relying party opens an authenticated session upon receiving a positive result.
• Well-designed authentication protocols protect the integrity and confidentiality of communication between claimant and verifier and help limit damage from attackers masquerading as legitimate verifiers (phishing).
  The nature of the protocol interaction is critical to overall system security and resilience against authentication-based attacks.

Source: Section 2.3, pages 20-22

• Federation allows the conveyance of identity and authentication information based on trust agreements across networked systems through federation assertions.
  Federation enables sharing of information between different trust domains, with processes and architectures defined in NIST SP 800-63C. OMB M-19-17 directs government agencies to support cross-government identity federation and interoperability.
• A subject can be identity-proofed once with a subscriber account used at multiple relying parties, reducing user burden and organizational costs through federated architectures.
  Federation benefits include reducing authenticators for subscribers, minimizing IT infrastructure costs for organizations, and enabling streamlined identity management architecture.
• Federation minimizes data exposed to relying parties by using pseudonymous identifiers and derived attribute values instead of copying account values to each application.
  This approach limits the full account information shared across applications, reducing privacy risks and the scope of data retention requirements.
• Federation is preferable when the relying party and identity provider are not administered together under a common security domain, though it can also be applied within a single security domain.
  Within a single security domain, federation supports benefits such as centralized account management and technical integration.
• Federation is more efficient when potential users already have authenticators at or above the required assurance level, multiple authenticator types are needed, or the organization lacks infrastructure for account management.
  Federation also applies when authenticators must be upgraded over time, multiple user communities are served, or central account lifecycle management is required.
• An organization should accept federated identity attributes when pseudonymity is required, access requires a defined attribute list, derived attributes are needed, or the organization is not the authoritative source for attributes.
  Federation is also appropriate when attributes are temporarily needed for access decisions and the organization does not need to retain the data long-term.

Source: Section 2.4, pages 23-25

• Three distinct digital identity models exist: non-federated, federated with a general-purpose IdP, and federated with a subscriber-controlled wallet.
  Each model organizes the interactions between applicants, subscribers, claimants, CSPs, verifiers, IdPs, and RPs differently to achieve identity proofing, enrollment, and authentication functions.
• In the non-federated model, a single CSP directly identity-proofs applicants, enrolls them as subscribers, and authenticates them for access to online services.
  The subscriber maintains authenticators while the CSP maintains the subscriber account and status. When authenticating, the verifier interacts with the CSP to verify the binding of identity to authenticators and obtain attributes for authorization decisions.
• In the federated model with a general-purpose IdP, a CSP identity-proofs and enrolls subscribers, but an IdP handles authentication and assertion of attributes to RPs through a federation protocol.
  The IdP maintains a view of the subscriber account and policies for releasing attributes. The RP receives an assertion from the IdP and uses the subscriber's federated identity, IAL, AAL, FAL, and other factors to make authorization decisions.
• In the wallet-based federated model, a subscriber controls a device or cloud-hosted wallet that acts as the IdP and holder of credentials.
  The CSP identity-proofs the applicant and issues attribute bundles containing subscriber attributes and verification keys to the wallet. The subscriber activates the wallet and provides assertions directly to RPs using the CSP-signed attribute bundles.
• The verifier and CSP do not always need real-time communication because digital certificates and other mechanisms allow offline verification of identity and authentication bindings.
  The logical link between verifier and CSP may be implemented as direct network communication or as application signals on the same system if the functions reside on the same platform.
• Attribute bundles in the wallet model are distinct from credentials as used in other protocols and standards.
  Attribute bundles include subscriber attributes along with the wallet's verification key or a reference to that key, issued by the CSP into the subscriber-controlled wallet.
• In federated models, RPs may establish trust relationships with CSPs through a federation authority rather than directly with wallets.
  This arrangement allows RPs to accept assertions from subscriber-controlled wallets without needing direct trust relationships with individual wallets.

Source: Section 2.5 Examples of Digital Identity Models, pages 25-30

• Digital Identity Risk Management (DIRM) assesses risks from operating an online service and risks introduced by the identity system itself, then selects controls to mitigate those risks.
  The first dimension identifies risks that could be addressed by identity controls (identity proofing, authentication, federation). The second dimension identifies risks posed by the identity system itself and informs the tailoring process to adjust controls based on privacy, usability, and threat factors.
• Relying parties must implement DIRM to determine assurance levels and tailoring for their online services; credential service providers and identity providers must design offerings that meet requested assurance levels and document any deviations in a Digital Identity Acceptance Statement.
  Federal RPs are required to execute DIRM for all online services. CSPs and IdPs may deviate from guidance but must communicate deviations to RPs and conduct an abbreviated risk assessment.
• The DIRM process consists of five sequential steps: define the online service, conduct initial impact assessment, select initial assurance levels, tailor and document assurance levels, and continuously evaluate and improve.
  While presented sequentially, the process allows for iterative cycles and revisiting earlier steps when new regulations, functionality changes, data usage changes, or threat environment shifts occur.
• Initial impact assessment identifies impacts from compromise of specific identity functions (identity proofing, authentication, federation) for each user group and determines impact categories and levels.
  Each user group is considered separately based on available transactions and permissions, and impacts are assessed against defined harms and impact categories to establish baseline security requirements.
• Tailoring modifies initially selected assurance levels, implements compensating or supplemental controls, or both, based on detailed assessments of privacy, customer experience, and resistance to current threats.
  Tailoring decisions are documented and justified in a Digital Identity Acceptance Statement that defines an implementable set of assurance levels and final controls for the online service.
• Continuous evaluation monitors performance metrics, fraud rates, user impacts, and evolving threats to determine whether selected assurance levels and controls meet mission and business needs and identifies opportunities for improvement.
  This step includes gathering information on business impacts, effects on fraud, user community impacts, and establishing documented and transparent processes for evaluation and redress.
• DIRM results for an online service may differ from FISMA impact levels because identity process failures can result in different impacts for various user groups using the same system.
  For example, a payment system with overall FISMA Moderate impact may have lower authentication and proofing impact levels for guest transactions without persistent accounts.
• Organizations SHALL execute and document each DIRM step and complete all normative mandates regardless of organization-specific processes or tools, and SHOULD consult with a representative sample of users to inform system design and evaluation.
  While organizations may adapt the DIRM approach to meet their governance and risk management practices, the core steps and outcomes are mandatory for federal systems.

Source: Section 3: Digital Identity Risk Management, pages 31-34

• The Define the Online Service step establishes the functional scope, user groups, and impacted entities that form the foundation for all subsequent DIRM process steps.
  This first step creates a common understanding of the online service's context within its broader business environment, enabling informed decisions about risk management and assurance levels in later stages.
• Organizations must document the organizational mission, business objectives, dependencies, legal and regulatory requirements, functionality, data processed, and current state of identity technologies for the online service.
  This comprehensive description ensures all critical factors influencing identity risk management are identified and documented before proceeding to impact assessment.
• User groups and impacted entities are distinct concepts that must be differentiated in the scope definition.
  User groups are sets of users granted specific access and functionality, while impacted entities include all individuals and organizations that could face negative consequences from a digital identity system failure, which may extend beyond direct users.
• Impact assessments must account for both internal users of the online service and external entities such as mission partners and communities that could be harmed by unauthorized access.
  This broader perspective ensures that the full scope of potential harms from identity system failures is considered, including indirect victims like populations affected by compromised critical infrastructure.
• Organizations must evaluate the availability of required identity evidence across all user groups to support identity proofing decisions.
  Understanding whether users can provide necessary proofing evidence informs the feasibility of assurance level requirements and helps identify potential barriers for specific user populations.

Source: Section 3.1 Define the Online Service, pages 34-37

• The initial impact assessment identifies potential adverse impacts from failures in identity proofing, authentication, and federation specific to an online service, yielding impact levels (Low, Moderate, or High) for each user group.
  Organizations should use historical data and user focus groups when conducting this assessment. The impact level for each user group is determined separately based on the transactions available to that group, allowing flexible and appropriate assurance level selection for different user populations.
• Organizations must identify impact categories applicable to impacted entities, with mandatory minimum categories being degradation of mission delivery, damage to trust/standing/reputation, unauthorized access to information, financial loss/liability, and loss of life or danger to human safety/health/environmental health.
  Additional impact categories may be included based on mission and business objectives. Each category must be documented consistently across all online services offered by the organization.
• For each impact category, organizations must document potential harms to individuals, the organization, and other impacted entities, providing concrete understanding of how impacts apply to specific entities affected by the online service.
  Harms range from inability to access services and impersonation damage, to intellectual property loss, financial fraud, and physical injury depending on the impact category.
• Impact levels (Low, Moderate, or High) assign severity to potential adverse effects when an unauthorized user gains access to the online service within each impact category, with Low indicating limited adverse effect, Moderate indicating serious adverse effect, and High indicating severe or catastrophic adverse effect.
  Organizations should develop thresholds and examples for each impact level within each impact category and document these consistently to ensure common understanding of risks across the organization.
• The impact analysis must evaluate impact levels across four dimensions: user groups, impacted entities, impact categories, and impact levels, considering each user group separately because different transaction sets are available to different user groups.
  The analysis determines the level of impact for each impact category for each type of impacted entity if an intruder gains unauthorized access as a member of each user group. If no harm exists for a given impact category, the impact level may be marked as None.
• Organizations must combine impact assessment levels across impact categories and impacted entities into a single overall impact level for each user group using a documented combinatorial method consistently applied across all online services.
  Methods for combining impacts include high-water mark approach (selecting the highest impact level), weighted averaging across categories or entities, or other logic aligned with organizational mission and priorities. The final documented outcome is an effective impact level for each user group representing risks from compromise of identity management system functions.

Source: Section 3.2, Conduct Initial Impact Assessment, pages 37-42

• The effective impact level (Low, Moderate, or High) directly determines the initial assurance level selected for each user group across all three digital identity functions.
  Impact levels serve as the primary input for choosing Identity Assurance Level (IAL), Authentication Assurance Level (AAL), and Federation Assurance Level (FAL), which then determine the baseline controls from the companion volumes SP800-63A, SP800-63B, and SP800-63C.
• IAL measures the robustness of identity proofing to verify the claimed identity of an individual, with IAL1 supporting real-world existence through basic validation, IAL2 requiring more rigorous evidence collection and validation, and IAL3 requiring in-person attendance and biometric collection.
  The IAL is selected to mitigate risks from identity proofing failures, and the level increases with the need to prevent sophisticated attacks such as synthetic identity creation, evidence falsification, and social engineering.
• AAL measures the robustness of the authentication process and the binding between authenticator and individual, with AAL1 providing basic confidence through single or multi-factor authentication, AAL2 requiring two distinct factors and approved cryptography, and AAL3 requiring phishing-resistant public-key cryptography.
  AAL is selected to mitigate risks from authentication failures, and higher levels provide increasing protection against password attacks, phishing, and verifier compromise.
• FAL measures the robustness of federation processes communicating authentication and attribute information, with FAL1 providing basic protection against forged assertions, FAL2 protecting against forged and injection attacks, and FAL3 protecting against IdP compromise.
  FAL is selected to mitigate risks from federation failures, and the appropriate level depends on the type of data being accessed, IdP location, and availability of holder-of-key capabilities.
• Identity proofing is not required if the online service does not use personal information or if potential harms from self-asserted attributes are insignificant, in which case no IAL applies regardless of other assurance levels.
  Organizations must determine whether identity proofing is needed and document this decision as the first step in IAL selection, as some systems can operate effectively without any formal identity proofing process.
• For systems requiring identity proofing, initial IAL is mapped directly from impact level: Low impact yields IAL1, Moderate impact yields IAL2, and High impact yields IAL3.
  This mapping assumes that higher potential impacts of identity proofing failures should be mitigated by more rigorous assurance processes.
• For systems requiring authentication, initial AAL is mapped directly from impact level: Low impact yields AAL1, Moderate impact yields AAL2, and High impact yields AAL3.
  Legal and regulatory requirements may mandate higher authentication assurance levels; for example, Executive Order 13681 requires multi-factor authentication for systems making personal data accessible, establishing a minimum of AAL2.
• For systems implementing federation, initial FAL is mapped from impact level with a special case for high impact: Low impact yields FAL1, Moderate impact yields FAL2, and High impact requires further assessment to choose between FAL2 or FAL3.
  For high-impact federated systems, organizations must evaluate IdP compromise risk by considering data sensitivity, IdP location (internal or external), and available bound authenticators or holder-of-key capabilities.
• Baseline controls are selected from the companion volumes SP800-63A, SP800-63B, and SP800-63C based on the initial xALs chosen for each user group.
  The organization may implement controls directly or through external entities such as third-party Credential Service Providers or Identity Providers depending on the identity model architecture.
• Different assurance levels may be selected for the same user group across IAL, AAL, and FAL based on the specific risks and data access patterns of the online service.
  For example, a low-impact system may require IAL1 and FAL1 but AAL2 if personal information is accessible, or may require no IAL if identity proofing is not needed despite baseline authentication requirements.
• Organizations SHALL develop and document a governance process for selecting initial assurance levels and controls and SHALL document which identity functions are required and what assurance levels are selected for each user group.
  This documentation provides the foundation for the subsequent tailoring step and enables consistent application of assurance levels across the organization.

Source: Section 3.3, pages 42-50

• Tailoring is a structured process to modify initially selected assurance levels and implement compensating or supplemental controls based on detailed risk assessments of privacy, customer experience, and threats.
  Tailoring enables organizations to align assurance levels with their specific context, users, and threat environments while remaining flexible. Organizations must complete the tailoring assessments but are not required to modify initial assurance levels as a result.
• Organizations must establish and document a tailoring process that follows a documented governance approach and records all decisions, modified assurance levels, and control modifications in a Digital Identity Acceptance Statement.
  The tailoring process must justify and document all risk-based modifications to initially assessed assurance levels. Organizations should establish a cross-functional team with subject-matter experts in privacy, customer experience, fraud, and other relevant areas.
• Privacy, customer experience, and threat resistance are the minimum assessment areas required during tailoring to identify unintended consequences of the initial assurance level selection.
  Privacy assessments should leverage existing Privacy Threshold Analysis or Privacy Impact Assessment as inputs. Customer experience assessments must ensure controls do not create undue burdens or barriers. Threat resistance assessments examine specific known and potential threats, threat actors, and tactics within the operational environment.
• A compensating control is a management, operational, or technical control implemented in lieu of a normative (SHALL) control when an organization cannot implement the baseline control or when risk assessment indicates it sufficiently mitigates risk.
  Compensating controls must address the same risks as the baseline control they replace. Organizations must document the compensating control, rationale for deviation, comparability to the baseline control, and any resulting residual risks. CSPs and IdPs must communicate compensating controls to all potential relying parties.
• Supplemental controls may be added to strengthen baseline controls and address specific threats in the operational environment not covered by baseline controls.
  Examples include requiring additional identity evidence due to high fraud prevalence, restricting authentication to phishing-resistant methods, or implementing risk-scoring analytics for re-proofing. All supplemental controls must be assessed for impacts using the same factors as tailoring and documented.
• The Digital Identity Acceptance Statement documents the complete results of the DIRM process and must include initial impact assessments, initially assessed assurance levels, tailored assurance levels with rationale, and all compensating and supplemental controls.
  Organizations must prepare a DIAS for each online service they manage and each external online service they use. CSPs and IdPs must prepare a DIAS if they deviate from normative guidance. Federal agencies should include this information in their information system authorization packages.
• The final implemented assurance levels do not need to be uniform across all functions and may vary based on the online service functions, impact assessment outcomes, and tailoring process results.
  Different components of an online service can operate at different assurance levels based on their specific risks and operational context, allowing for tailored and flexible implementations that align with organizational risk management objectives.

Source: Section 3.4, Tailor and Document Assurance Levels, pages 50-56

• Organizations SHALL implement a documented continuous evaluation and improvement program that collects performance metrics and user feedback to address capability gaps and keep pace with threats and technology changes.
  The program must include metrics collection, data sources, and timely action processes. Regular assessment of program effectiveness SHOULD occur to ensure outcomes are achieved and issues are resolved promptly.
• Organizations SHALL monitor the evolving threat landscape and regularly assess the effectiveness of security and fraud detection measures against current threats and tactics.
  This ensures that identity systems remain resilient as attackers and fraud methods evolve, and that defensive measures keep pace with emerging risks.
• Evaluation inputs SHALL include integrated CSP and IdP functions, customer feedback mechanisms, threat intelligence, fraud trends, and results from customer experience and privacy assessments.
  RPs must document metrics and reporting requirements for any integrated identity service partners to ensure vendors understand expectations and can provide necessary data.
• Organizations SHOULD track recommended performance metrics across proofing, authentication, fraud, and customer experience categories, but are not limited to the provided table and should implement metrics based on specific system needs.
  Table 4 provides examples including pass rates, fail rates, abandonment rates, authentication failures, confirmed fraud, help desk calls, and redress requests. Additional metrics can be identified using frameworks like SP 800-55V2.
• Data sources for metrics may reside outside the identity program, requiring coordination with customer service teams and other organizational units to collect identity-related information.
  Customer service representatives often have substantial information on complaints and concerns; organizations must actively coordinate to extract relevant identity management system issues from these sources.
• Metrics SHOULD be analyzed to assess performance across different user populations using proxy data such as geographic region, age, or zip code while minimizing collection of additional personal information.
  This supports customer experience outcomes by identifying performance deviations across supported communities without requiring unnecessary personal data collection.

Source: Section 3.5, pages 56-60

• Redress processes must be designed to be fair, transparent, easy for legitimate claimants to navigate, and resistant to exploitation, as service failures and disputes are inevitable in normal operations.
  Different populations experience the same issues with varying degrees of harm, so redress approaches must account for disproportionate impacts on vulnerable individuals and communities. Organizations must plan proactively for these issues rather than react after they occur.
• RPs and CSPs must establish a documented, accessible, and trackable issue handling process with clear instructions on a public-facing website that all individuals can use to convey grievances and seek redress.
  This process is a mandatory requirement that ensures visibility and usability across diverse populations. The instructions must be easy to locate and understand so legitimate claimants can navigate the system without difficulty.
• RPs and CSPs must implement a dedicated issue handling function with impartial evidence review, additional evidence collection procedures, and expeditious issue resolution with documented governance roles and responsibilities.
  This dedicated function ensures consistent, fair treatment of grievances rather than ad-hoc handling. A documented governance model clarifies who is responsible for each step of the process.
• RPs and CSPs must make human support personnel available to intervene and override algorithmic outputs in issue adjudication.
  This requirement prevents algorithmic systems from making final decisions without human review, ensuring that edge cases and contextual factors can be properly considered.
• RPs and CSPs must educate support personnel on issue handling procedures, available redress avenues, and service access alternatives.
  Well-trained support staff can better serve users and provide effective solutions. Education should cover both procedural knowledge and awareness of alternative paths to access services.
• RPs and CSPs must implement a process for support personnel and technologies to report and address major barriers and grievances that end users face.
  This creates a feedback loop where frontline staff can escalate systemic issues beyond individual cases. Such information helps identify patterns of harm or design problems.
• Organizations must incorporate findings from issue handling into continuous evaluation and improvement activities and assess redress mechanism integrity with controls against identity fraud.
  This ensures that redress insights drive system improvements over time. Organizations must also guard against attempts to exploit redress processes for fraudulent purposes.
• Organizations should test new redress practices with users before adoption to avoid unintended consequences that may undermine redress goals.
  User testing helps identify whether a practice actually serves its intended purpose and does not create new barriers or harms for certain populations.

Source: Section 3.6, pages 60-62

• Organizations must establish consistent mechanisms for information exchange between teams responsible for identity, cybersecurity, fraud detection, privacy, and threat intelligence.
  Coordination enables complete protection of business capabilities and continuous improvement. For example, payment fraud data can reveal compromised accounts, while threat intelligence can identify new attack techniques affecting identity processes.
• Organizations should extend information-sharing mechanisms to external stakeholders and identity service providers where feasible.
  External data exchange may be complicated by regulations or policy, but establishing mechanisms through contractual and legal frameworks should be considered to support effective collaboration.
• All data collected, transmitted, or shared by identity service providers must undergo detailed privacy and legal assessment.
  Either the entity generating the data (such as a credential service provider) or the relying party receiving the service must perform this assessment to ensure compliance.
• Coordination with functional teams should occur throughout the risk management process and operations life cycle.
  Integration at all stages of identity system operations and improvement leads to better outcomes, with specific fraud mitigation requirements detailed in companion volumes SP800-63A, SP800-63B, and SP800-63C.

Source: Section 3.7, pages 61-62

• All uses of AI/ML in identity systems must be documented and disclosed to organizations that rely on these systems, including relying parties making access decisions based on the information.
  CSPs, IdPs, and verifiers using integrated AI/ML technologies are required to communicate this to all RPs that depend on their systems for access control decisions.
• Organizations using AI/ML must provide detailed information about their models to entities relying on their technology, including training methods, datasets used, update frequency, and algorithm testing results.
  This transparency requirement ensures that downstream users understand how the AI/ML systems work and have visibility into their performance and reliability.
• Organizations using or relying on AI/ML systems in identity contexts should implement the NIST AI Risk Management Framework to evaluate introduced risks.
  This is a best practice recommendation (SHOULD) rather than a strict requirement, providing guidance on assessing potential negative outcomes from AI/ML deployment.
• All organizations using AI/ML systems or relying on such services must perform and document privacy risk assessments for personal information processed by these systems.
  This mandatory requirement ensures that privacy impacts from AI/ML processing are systematically identified and recorded.

Source: Section 3.8, pages 62-63

• NIST SP 800-63 is part of a multi-volume suite including separate standards for identity proofing, authentication, and federation.
  References to SP 800-63A, SP 800-63B, and SP 800-63C show that the digital identity guidelines are organized as a coordinated set of publications covering different aspects of identity systems.
• Multiple NIST risk management and security frameworks inform the digital identity guidelines.
  The references include NIST SP 800-37r2 (Risk Management Framework), SP 800-30r1 (Risk Assessments), SP 800-53r5 (Security Controls), and NIST Privacy Framework, establishing the normative and informative foundations for identity risk management.
• Federal law and executive policy establish requirements for identity security and privacy in government systems.
  References to FISMA, the Privacy Act of 1974, 44 U.S.C. 3552, Executive Order 13681, and OMB memoranda M-03-22 and M-19-17 show that these guidelines implement statutory and presidential mandates for federal information security and identity management.
• Technical standards for cryptography, PKI, and transport security are referenced for implementation details.
  RFC 5280 (X.509 certificates), RFC 8446 (TLS 1.3), and RFC 9325 (TLS recommendations) provide technical specifications that identity systems must follow for secure communications and credential management.
• AI and ML risk management guidance is integrated into the digital identity framework.
  The reference to NIST AI Risk Management Framework (NIST AI 100-1) reflects requirements in the guidelines for documenting and assessing risks from artificial intelligence and machine learning used in identity systems.
• Privacy engineering and PII protection are established as formal considerations in identity system design.
  References to NIST IR 8062 (Privacy Engineering) and SP 800-122 (PII Protection) indicate that privacy must be addressed systematically throughout identity proofing, authentication, and federation processes.
• Usability and human-system interaction standards inform identity system design requirements.
  The ISO/IEC 9241-11 reference on usability definitions and concepts shows that user experience is a measured factor alongside security in identity system evaluation.

Source: Pages 64-66

• Appendix A provides a comprehensive reference list of symbols, abbreviations, and acronyms used throughout NIST SP 800-63-4.
  This appendix serves as a lookup resource for readers to quickly understand the meaning of technical terms and acronyms that appear in the digital identity guidelines document.
• Key identity and authentication acronyms include IAL (Identity Assurance Level), AAL (Authentication Assurance Level), and FAL (Federation Assurance Level).
  These three assurance level terms are central to the risk management framework and control selection process described in the normative sections of the guidelines.
• Common technology and protocol acronyms referenced include SAML, OIDC, JWT, PKI, TLS, and OAuth-related standards for federated identity and secure communications.
  These standards define how identity assertions are created, transmitted, and validated in modern federated digital identity systems.
• Authentication and verification acronyms include MFA (Multi-Factor Authentication), OTP (One-Time Password), KBA (Knowledge-Based Authentication), and KBV (Knowledge-Based Verification).
  These terms describe different authentication mechanisms and verification approaches used to establish subscriber identity during authentication.
• Biometric and device-related acronyms include FMR (False Match Rate), FNMR (False Non-Match Rate), PAD (Presentation Attack Detection), and TEE (Trusted Execution Environment).
  These terms relate to biometric authentication quality, security against spoofing attacks, and secure hardware-based credential storage.
• Privacy and governance acronyms include PIA (Privacy Impact Assessment), SORN (System of Records Notice), and SAOP (Senior Agency Official for Privacy).
  These terms relate to privacy compliance and organizational roles responsible for managing privacy in digital identity systems.

Source: Appendix A, pages 67-71

• A glossary section provides standardized definitions of digital identity terminology used throughout SP 800-63-4, with some definitions changed from previous versions.
  The glossary emphasizes that many identity terms lack a single consistent definition across the industry, warranting careful attention to the specific definitions provided in this appendix for use within these guidelines.
• Core identity system entities include the credential service provider (CSP) that performs identity proofing and authenticator binding, the identity provider (IdP) that creates assertions in federation, and the relying party (RP) that accepts those assertions.
  These three parties form the foundation of digital identity architecture, with the CSP responsible for establishing subscriber identity, the IdP conveying authentication information, and the RP consuming that information to grant access.
• Authentication involves a claimant proving possession and control of authenticators bound to a subscriber account through defined authentication protocols using one or more factors.
  Authentication factors are categorized as something you know, something you have, or something you are, and multi-factor authentication requires more than one distinct type of factor for successful authentication.
• Assurance levels measure the strength of identity processes: identity assurance level (IAL) conveys confidence in claimed identity, authentication assurance level (AAL) describes authentication strength, and federation assurance level (FAL) describes federation transaction processes.
  These three xALs form the core risk management framework for determining appropriate security controls based on the potential impact of compromised identity or authentication.
• Federation allows conveyance of identity and authentication information across networked systems through federation protocols, with assertions containing authentication events and optional identity attributes.
  Federation enables single sign-on and reduces the need for multiple authenticators across services while allowing IdPs and RPs to establish trust agreements governing their interactions.
• Identity evidence is information or documentation supporting real-world existence of a claimed identity, requiring both validation (confirming authenticity and accuracy) and verification (confirming applicant ownership).
  Evidence may be physical, such as a driver's license, or digital, such as a mobile driver's license or assertion, and must support the identity proofing process.
• Derived attribute values assert limited identity attributes without containing the full attribute value, such as stating 'older than 18' instead of the actual date of birth.
  This privacy-preserving approach allows RPs to obtain needed information for authorization decisions without requiring disclosure of sensitive personal data.
• Compensating controls are alternative controls to normative requirements based on an organization's mission, risk tolerance, and considerations for privacy, usability, and customer experience.
  Tailoring allows organizations to adjust baseline assurance level controls while maintaining security objectives appropriate to their operational context.
• Phishing resistance is the authentication protocol's ability to prevent disclosure of authentication secrets to an impostor verifier without reliance on user vigilance.
  This represents a higher security standard than traditional password-based authentication by designing protocols that protect against impersonation of legitimate verifiers.
• A protected session encrypts messages between participants and protects integrity using session keys, and is authenticated if one or both parties prove possession of authenticators during the session.
  Sessions represent the persistent interaction between a subscriber and an endpoint following successful authentication and are bound by session secrets that prove association with the authentication event.

Source: Appendix B: Glossary, pages 72-84

• SP 800-63-1 updated the original standard to reflect current authenticator technologies and restructured it to present a better digital identity architectural model with additional technical requirements for CSPs, protocols, and assertions.
  This first update modernized the guidance by incorporating emerging authenticator technologies and clarifying how identity systems should be architected.
• SP 800-63-2 made limited updates focused mainly on identity proofing processes, specifically to enable use of professional credentials and reduce reliance on postal mail for remote level 3 credential issuance.
  This was a narrowly scoped revision addressing practical barriers to identity verification rather than wholesale changes to the standard.
• SP 800-63-3 was a substantial overhaul that introduced separate assurance levels for authentication (AAL), identity assurance (IAL), and federation (FAL) to allow independent treatment of authentication strength and identity confidence.
  This major revision recognized that organizations need different assurance levels for different components, supporting use cases like strong pseudonymous authentication.
• SP 800-63-3 expanded the scope from a single authentication document to a four-document suite and renamed the guidance to Digital Identity Guidelines to reflect broader coverage of identity proofing and federation.
  The restructuring acknowledged that digital identity encompasses more than just authentication and set a modular approach for future expansion.
• SP 800-63-3 changed terminology from 'token' to 'authenticator' to eliminate confusion with tokens used in assertion technologies and made other updates including account recovery requirements and removal of email as an out-of-band channel.
  These terminology and technical changes reflected evolving security practices and threat understanding.
• SP 800-63-4 substantially reorganized the guidance with expanded security, privacy, and customer experience considerations and introduced a new user-controlled wallet federation model.
  This version reflects increased adoption of digital wallets and the need to address multiple risk dimensions beyond security alone.
• SP 800-63-4 expanded the digital identity risk management process to define protected online services, user groups, and impacted entities, with more descriptive introduction and additional assessment capabilities.
  The enhanced DIRM process provides organizations with clearer methodology for understanding and protecting their specific identity systems.
• SP 800-63-4 added new requirements for performance metrics, redress processes, and guidance on artificial intelligence and machine learning in digital identity services.
  These additions address continuous improvement, user fairness, and emerging technological considerations in identity systems.

Source: Appendix C, pages 85-86