Skip to main content
Commerce Security Authority
Category: Authentication Methods

NIST SP 800-63B

Also known as: SP 800-63B, NIST Special Publication 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management, 800-63B
Simply put

NIST SP 800-63B is a U.S. government guideline that sets out how organizations should verify that people logging into digital systems are who they claim to be. It describes different levels of confidence in an authentication and covers how login credentials, such as passwords and authentication devices, should be managed over their lifetime. It is one part of a larger NIST series on digital identity and focuses specifically on the authentication step rather than on identity proofing or federation.

Formal definition

NIST SP 800-63B, a volume within the NIST SP 800-63 Digital Identity Guidelines series, specifies process and technical requirements for authentication and authenticator lifecycle management, addressed primarily to credential service providers (CSPs) supporting remote user authentication over open networks. It defines requirements at three Authentication Assurance Levels (AAL1, AAL2, AAL3), covering authenticator types, permitted combinations for single- and multi-factor authentication, use of approved cryptographic techniques, and lifecycle processes such as binding, renewal, and revocation. It exists in multiple versions—including the 2017 edition (with updates) and a later 4 revision developed in 2024—and requirement wording and structure differ across editions, so readers should confirm details against the specific published version they are relying on. As a general-purpose digital identity guideline it is distinct from payment-specific standards such as PCI DSS, PCI PIN, or PCI 3DS, though its authentication concepts may inform multi-factor authentication controls referenced by those standards.

Why it matters

Authentication is the point at which a digital system decides whether to trust that a person is who they claim to be, and weaknesses at this step can undermine every downstream control. NIST SP 800-63B matters because it provides a structured, widely referenced framework for how authentication should be performed and how the credentials behind it should be managed over their lifetime. By defining graduated Authentication Assurance Levels (AAL1, AAL2, AAL3), it helps organizations match the strength of authentication to the risk of the system being protected, rather than treating all logins as equivalent.

For teams working in payment security, the guideline is significant as a general-purpose reference that can inform how multi-factor authentication and authenticator lifecycle controls are designed. It is not a payment standard and does not replace PCI DSS, PCI PIN, or PCI 3DS, but its concepts—such as permitted authenticator combinations, use of approved cryptographic techniques, and requirements for binding, renewal, and revocation—may help teams reason about the authentication controls those standards reference. Because authentication is only one layer, SP 800-63B is intended to strengthen the login step and does not by itself address identity proofing, federation, or transaction-level fraud.

A practical reason the standard demands care is that it exists in multiple editions, including a 2017 edition with updates and a revision 4 developed in 2024, and requirement wording and structure differ across versions. Relying on outdated language or assuming a control maps cleanly from one edition to another can create gaps, so practitioners should confirm details against the specific published version they intend to follow.

Who it's relevant to

Credential Service Providers and Identity Teams
SP 800-63B is written primarily for credential service providers (CSPs) that support remote user authentication over open networks. Teams responsible for issuing, binding, renewing, and revoking authenticators can use it to align their processes with defined Authentication Assurance Levels and to structure lifecycle management. They should confirm which edition applies to their obligations, since requirements differ between the 2017 edition with updates and the revision 4 developed in 2024.
Security Engineers Designing Authentication
Engineers building or evaluating login systems can use the AAL1, AAL2, and AAL3 levels to match authentication strength to system risk and to determine acceptable authenticator combinations and use of approved cryptographic techniques. Because the guideline addresses authentication rather than identity proofing or federation, engineers should treat it as one layer and pair it with controls for other risks.
Compliance and Risk Officers in Payments
Compliance and risk teams working under PCI DSS, PCI PIN, or PCI 3DS may find SP 800-63B a useful general reference for reasoning about multi-factor authentication and authenticator lifecycle controls. It is a distinct, non-payment guideline and does not substitute for those standards; officers should map any concepts they adopt back to the specific requirements of the applicable payment standard and version.
Fraud and Account Protection Analysts
Analysts focused on account takeover can use the framework to understand how stronger authentication assurance levels are intended to raise the difficulty of unauthorized access. SP 800-63B strengthens the login step and may help reduce certain attack paths, but it does not by itself address transaction-level or card-not-present fraud, so it should be considered alongside other detection and prevention controls.

Inside SP 800-63B

Authenticator Assurance Levels (AAL)
A tiered model (AAL1, AAL2, AAL3) describing the strength of the authentication process, where higher levels require more robust authenticators and resistance to specific attacks. The appropriate level depends on the risk of the transaction or system being protected.
Authenticator types
Categories of authentication factors, such as memorized secrets (passwords), look-up secrets, out-of-band devices, single-factor and multi-factor cryptographic devices, and one-time password devices. Each has distinct security properties and usage requirements.
Memorized secret guidance
Recommendations for handling passwords, including checking new passwords against lists of known-compromised or commonly-used values, and de-emphasizing arbitrary composition rules and mandatory periodic rotation in favor of length and screening.
Verifier requirements
Controls the party validating an authenticator should implement, such as securely storing secrets using appropriate hashing and salting, rate-limiting failed attempts, and protecting authentication channels.
Session management
Guidance on establishing, maintaining, and terminating authenticated sessions, including reauthentication intervals, session binding, and handling of session secrets.
Relationship to PCI DSS authentication controls
NIST SP 800-63B is a U.S. federal digital identity guideline that is separate from PCI DSS. Some PCI DSS authentication and multi-factor authentication expectations align conceptually with 800-63B, but the two are distinct documents governed by different bodies, and PCI DSS requirements should be confirmed against the current published standard.

Common questions

Answers to the questions practitioners most commonly ask about SP 800-63B.

Does NIST SP 800-63B require periodic password changes, since many organizations still force expiration?
No. NIST SP 800-63B moved away from mandating routine periodic password changes for memorized secrets. It recommends against requiring changes on an arbitrary schedule and instead advises forcing a change only when there is evidence of compromise. Note that this is NIST guidance and differs from what other frameworks or contractual obligations may require; PCI DSS handles authentication under its own requirements, which vary by version and should be confirmed against the current published standard. Organizations should reconcile NIST guidance with any other standards that apply to them.
Is NIST SP 800-63B a PCI standard that governs payment authentication?
No. NIST SP 800-63B is a U.S. federal guideline published by the National Institute of Standards and Technology, part of the Digital Identity Guidelines. It is separate from PCI DSS and from other PCI standards such as PCI PIN, PCI P2PE, and PCI 3DS. While its authentication concepts can inform practices, it does not itself govern PCI compliance. Authentication requirements for payment environments are defined by the applicable PCI standard, and readers should confirm those against the current published version rather than substituting NIST terminology.
How does NIST SP 800-63B define authenticator assurance levels, and how do teams choose one?
NIST SP 800-63B describes authenticator assurance levels (AAL1, AAL2, and AAL3) that reflect increasing strength and rigor in the authentication process, with higher levels intended to reduce the likelihood of successful attacks against the authentication event. Selection is typically driven by a risk assessment of the protected resource and the impact of a compromise. The document provides criteria for each level; teams should map their risk tolerance and any external obligations to the appropriate level rather than defaulting to the highest.
What does NIST SP 800-63B say about screening passwords against known compromised lists?
NIST SP 800-63B recommends checking prospective memorized secrets against lists of values known to be commonly used, expected, or previously compromised, and rejecting matches. This is intended to reduce the risk that users choose easily guessed or already-breached passwords. Implementation considerations include how the comparison list is sourced and updated, and how matching is performed securely. Screening is one control among several and does not by itself eliminate credential-based attacks such as account takeover.
How should we approach multi-factor authentication to align with NIST SP 800-63B guidance?
NIST SP 800-63B discusses combining authenticator types drawn from different factor categories to achieve higher assurance levels, and it addresses the relative strength of various authenticators, including cautions around certain out-of-band methods. When applying this, teams should select authenticators appropriate to their target assurance level and threat model. Note that multi-factor authentication addresses the authentication event specifically and is distinct from other controls such as 3-D Secure or EMV chip authentication, which operate at different points in a payment transaction; it helps reduce but does not guarantee prevention of unauthorized access.
How do we reconcile NIST SP 800-63B guidance with PCI DSS authentication requirements in a payment environment?
The two are separate documents with independent scopes, and following one does not automatically satisfy the other. NIST SP 800-63B offers identity and authentication guidance, while PCI DSS defines authentication requirements for cardholder data environments under its own numbering and wording, which differ between versions. Teams operating in payment environments should treat PCI DSS as the governing standard for compliance, confirm the applicable requirements against the current published version, and use NIST guidance as supplemental input where it does not conflict. Where obligations differ, the more specific or more stringent applicable requirement generally governs.

Common misconceptions

NIST SP 800-63B is part of PCI DSS or is required for PCI DSS compliance.
NIST SP 800-63B is a separate digital identity guideline published by NIST and is not the same as PCI DSS. While some authentication concepts overlap and organizations may reference it, PCI DSS is governed by the PCI Security Standards Council, and applicable PCI DSS authentication requirements should be verified against the current published version of that standard.
Multi-factor authentication as described in 800-63B eliminates account takeover and authentication-related fraud.
Multi-factor authentication is intended to reduce the risk of unauthorized access, but it does not guarantee protection against all attacks. It may be bypassed through phishing, social engineering, or channel compromise depending on the authenticator types used, and it addresses only certain risks at the authentication point.
Higher Authenticator Assurance Levels should always be applied everywhere for maximum security.
The appropriate AAL is intended to be selected based on the risk of the protected resource. Applying a higher level than needed can increase user friction and cost without proportionate benefit, while too low a level may leave higher-risk functions inadequately protected; the choice involves a documented risk trade-off.

Best practices

Select the Authenticator Assurance Level based on a documented assessment of the risk associated with the system or transaction, rather than defaulting to a fixed level.
Screen new and changed memorized secrets against lists of known-compromised and commonly-used values, and favor length and screening over arbitrary composition rules and mandatory periodic rotation.
Store authentication secrets on the verifier using appropriate salting and hashing, and implement rate-limiting on failed authentication attempts to help reduce the effectiveness of guessing attacks.
Prefer phishing-resistant and multi-factor authenticator types for higher-risk functions, while recognizing that no single authenticator type eliminates all attack vectors.
Implement session management controls, including appropriate reauthentication intervals, session binding, and secure handling of session secrets.
Treat NIST SP 800-63B as a distinct reference and separately confirm any PCI DSS authentication obligations against the current published version of the PCI DSS standard, since the two are governed by different bodies and change over time.