Check NIST 800-63B Compliance — Free Policy Checklist

When your organization's authentication security policies determine who gets access to sensitive federal data, a NIST 800-63B compliance checker gives you clear, actionable insight into exactly where your controls meet — or fall short of — the standard's technical requirements. Whether you're a government agency subject to federal compliance obligations under FISMA, a cloud service provider pursuing FedRAMP authorization, or a private enterprise voluntarily adopting the digital identity guidelines to strengthen your security posture, understanding what NIST SP 800-63B demands at each assurance level is the foundation for every remediation decision you make.

What Is NIST 800-63B and Why Does It Matter for Digital Identity Security?

A Brief History and the Authority Behind NIST Special Publication 800-63B

The National Institute of Standards and Technology (NIST) is a non-regulatory federal agency within the United States Department of Commerce, established in 1901 as the National Bureau of Standards. Its core mission spans measurement science, rigorous traceability, and the development of standards that underpin industrial competitiveness, information technology, and cybersecurity. Over more than a century, NIST has grown from focusing on physical engineering sciences to leading the development of cybersecurity standards, identity frameworks, and cryptographic specifications that govern how modern digital identity services operate.

NIST Special Publication 800-63B — formally titled Digital Identity Guidelines: Authentication and Lifecycle Management — is the authentication volume of the broader SP 800-63 suite. It defines technical requirements for credential service providers (CSP) — sometimes called a credential service provider in identity management contexts — operating remote user authentication at each of three authenticator assurance levels. The publication carries normative authority for federal systems through the Federal Information Security Modernization Act (FISMA), OMB Circular A-130, OMB M-17-12, and Executive Order 13681, which mandates multi-factor authentication for any federal release of personal information online. It is one of the most influential authentication guidelines in global information security practice.

This guideline focuses on the authentication of subjects who interact with government information systems over networks to establish that a given claimant is a subscriber who has been previously authenticated. — NIST SP 800-63B Abstract

How NIST SP 800-63B Fits Into the Broader NIST 800-63 Framework

The complete SP 800-63 suite comprises four companion volumes. SP 800-63 (the parent document) provides overarching guidance on selecting assurance levels and the overall digital identity architecture. SP 800-63A covers identity proofing and enrollment, defining three identity assurance levels (IAL1, IAL2, IAL3) that govern how rigorously an applicant's real-world identity must be verified before authenticators are bound. SP 800-63B — the subject of this page — defines the authenticator assurance level requirements for authentication and authenticator lifecycle management. SP 800-63C addresses federation and assertions, governing how identity assertions flow from an identity provider (IdP) to a relying party (RP) across a federation protocol.

The SP 800-63 framework also aligns with SP 800-53, which defines the security controls and privacy controls catalog. Verifiers operating at all assurance levels shall employ tailored security controls from at minimum the SP 800-53 moderate baseline or an equivalent federal or industry standard such as FedRAMP. Additional companion references include sp800-131a for cryptographic algorithm transitions, sp800-132 for password-based key derivation, and sp800-53 low, moderate, and high baselines for different system risk profiles.

Each section of the guidelines is labeled as either normative (mandatory for adherence — using language such as shall, shall not) or informative (advisory — using should, may). Understanding this distinction is critical when using a nist 800-63b compliance checker: failing a normative requirement is a hard gap, while failing an informative recommendation is a risk-based finding that warrants prioritization based on your organization's threat model.

NIST 800-63B Guidelines: Understanding Authenticator Assurance Levels (AAL)

The central organizing framework of NIST SP 800-63B is the authenticator assurance level system — three tiers of increasing authentication strength that determine what types of authenticators are permitted, what cryptographic requirements apply, how session management must be handled, and when reauthentication is required. Selecting the correct AAL requires a risk assessment driven by the data sensitivity and transaction risk of the system being protected. Higher AAL authentication forces malicious actors to invest far greater resources and capabilities to subvert the authentication process.

AAL1: Single-Factor Authentication Requirements and Assurance Level 1

AAL1 provides basic confidence that the claimant controls an authenticator bound to the subscriber account. At assurance level 1, either password-only authentication or multi-factor authentication is acceptable, and all seven core authenticator types are permitted. Authenticators used at AAL1 shall use approved cryptography — meaning approved cryptographic techniques and algorithms — though the implementation need not be validated under FIPS 140. Communication between the claimant and verifier shall occur over an authenticated protected channel (e.g., HTTPS with TLS). For verifiers operated by or on behalf of federal agencies, cryptography at AAL1 shall be validated to FIPS 140 Level 1.

For reauthentication, a definite session duration limit shall be established — should be no more than 30 days at AAL1. An idle period threshold (30 day reauthentication) may be applied but is not required at this level. At AAL1, verifiers should make multi-factor authentication options available and encourage their use, even though only a single factor is strictly required. Verifiers should also make multi-factor authentication options available at AAL1 and encourage their use.

AAL2: Multi-Factor Authentication Requirements and Assurance Level 2

AAL2 provides high confidence that the claimant controls authenticators bound to the account. Proof of possession and control of two distinct authentication factors through secure authentication protocols is required. Approved cryptographic techniques are mandatory. At assurance level 2, either a dedicated multi-factor authenticator or a combination of two separate single-factor authenticators must be used. When combining single-factor authenticators, the combination shall include one physical authenticator — something you have — paired with either a memorized secret or a biometric comparison.

At AAL2, at least one authenticator shall be replay resistant. Authentication intent should be demonstrated from at least one authenticator. Verifiers shall offer at least one phishing-resistant authentication option at AAL2. Federal agencies shall require staff, contractors, and partners to use phishing-resistant authentication to access federal information systems. Cryptographic authenticators procured by federal agencies shall be validated to FIPS 140 Level 1. For reauthentication, the overall session duration limit should be no more than 24 hours at AAL2 (12 hour reauthentication after the idle threshold is reached), and the idle period threshold should be no more than 1 hour (30 minute inactivity before step-up is required). When the idle period expires but the overall session limit has not, the verifier may allow reauthentication using only a password or biometric in conjunction with the session secret.

AAL3: Hardware-Based Phishing-Resistant Requirements and Assurance Level 3

AAL3 provides very high confidence that the claimant controls authenticators bound to the account. Authentication at AAL3 is based on proof of possession of a cryptographic key through a public-key cryptographic protocol, combined with either an activation factor or a password. AAL3 authentication requires a cryptographic authenticator with a non-exportable private key that provides phishing resistance. At assurance level 3, permitted combinations are: a multi-factor cryptographic authenticator, or a single-factor cryptographic authenticator combined with a memorized secret or biometric. Since syncable authenticators require the private key to be exportable, they shall not be used at AAL3.

The authentication protocol at AAL3 shall be replay resistant. All authentication and reauthentication processes at AAL3 shall demonstrate authentication intent. Authenticators and verifiers at AAL3 shall be validated to FIPS 140 Level 1 overall. Hardware-based authenticators at AAL3 should resist side channel attack techniques including differential power analysis and timing analysis. The overall reauthentication session limit at AAL3 shall be no more than 12 hours (12-hour reauthentication), and the idle period threshold should be no more than 15 minutes (15-minute inactivity). Unlike AAL2, reauthentication at AAL3 carries the same requirements as initial authentication at that level.

Summary of Requirements Across All Three Assurance Levels

The following table provides a synthesized, normative summary of requirements across all three AAL tiers, derived from Section 2 of NIST SP 800-63B:

Authenticator Lifecycle Management: Enrollment to Expiration Under the NIST 800-63B Standards

Events occur throughout the lifetime of every subscriber's authenticator — from initial authenticator registration through maintenance, loss, expiration, and ultimately revocation. NIST SP 800-63B Section 4 (Authenticator Event Management) establishes normative requirements governing the entire authenticator lifecycle. CSPs shall maintain a record of all authenticators bound to each subscriber account, including the date and time of significant lifecycle events such as binding, renewal, update, and password expiration or authenticator expiration.

Post-Enrollment Binding and Activation

Adding backup authenticators to an existing subscriber account — the process of binding authenticators across endpoints after initial enrollment — supports robust identity management practices. To minimize the need for account recovery, CSPs and verifiers should encourage subscribers to maintain at least two separate means of authentication — for example, a primary multi-factor OTP device paired with look-up secrets or a registered backup out-of-band device. When any new authenticator is bound, the CSP shall require authentication at the maximum AAL currently available in the subscriber account or the maximum AAL at which the new authenticator will be used, whichever is lower. The CSP shall notify the subscriber via an independent mechanism when any authenticator binding occurs — via email notification, postal notification, push notification service, or text message — to detect attacker-initiated binding events. This ensures subscribers can detect illicit binding attempts promptly. The binding code used when binding across endpoints shall be at least 40 bits in length (when combined with a subscriber identifier) or 112 bits standalone, generated by an approved random bit generator, valid only once, and valid for no more than 10 minutes.

Handling Loss, Theft, Damage, and Unauthorized Duplication

Compromised authenticators — those lost, stolen, subject to unauthorized duplication (authenticator duplication), or with activation factors no longer under the subscriber's control — shall be suspended, invalidated, or destroyed promptly following compromise detection. The CSP should provide subscribers a method to authenticate using a backup authenticator or alternative authenticator to facilitate secure compromise reporting. The consequences of not invalidating a compromised authenticator are typically more significant than the denial-of-service potential of invalidating one in error — this asymmetry informs the urgency requirements. The CSP shall invalidate authenticators promptly when an account ceases to exist, when requested by the subscriber, or when compromise is detected. Authenticator invalidation (also called authenticator revocation or termination) removes the binding between the authenticator and the subscriber account.

Authenticator Expiration and Renewal Policies

CSPs may bind authenticators that expire to subscriber accounts — authenticator expiration is permitted but not required. Password expiration follows similar principles: mandatory periodic password changes are prohibited unless compromise evidence exists. When an authenticator expires, it shall not be usable for authentication, and the CSP should indicate to the subscriber that the authentication failure is due to expiration specifically. The subscriber should bind a new or updated authenticator before an existing authenticator's expiration — authenticator renewal should conform closely to the post-enrollment binding process. The authenticator reissue process includes the CSP confirming contact addresses and, following successful use of the replacement authenticator, invalidating the expiring one. The CSP should also retrieve any authenticator that contains personal information or arrange for its erasure promptly following invalidation or expiration, supporting data minimization objectives and reducing the risk of authenticator damage to subscriber privacy.

Recovery Requirements by IAL and AAL

Account recovery — regaining control of a subscriber account after losing access to required authenticators — is supported through four recognized mechanisms: saved recovery codes (at least 64 bits from an approved random bit generator), issued recovery codes (at least six decimal digits from an approved generator, delivered via HTTPS link or optical label), use of recovery contacts (trusted associates who receive recovery codes), and repeated identity proofing. Recovery at AAL2 requires two recovery codes using different methods OR one recovery code plus authentication with a bound single-factor authenticator OR repeated identity proofing. Recovery at AAL3 for IAL3-proofed accounts additionally requires a successful biometric comparison against the sample captured during the initial attended identity proofing session. Confirmation codes sent to validate email addresses or issued as recovery codes are not authentication processes and are not subject to the prohibition on email as an out-of-band authentication channel.

Confirmation codes that are sent to validate email addresses or are issued as recovery codes are not authentication processes and not affected by the above prohibition. — NIST SP 800-63B, Section 3.1.3.1

NIST Password Policy: Complexity, Screening, and NIST Password Compliance

Few areas of NIST 800-63B have generated as much practical attention as its treatment of passwords (now formally renamed from "memorized secrets" in Rev. 4). The publication represents a fundamental philosophical shift: away from arbitrary complexity rules and mandatory periodic reset policies that research has shown to be counterproductive, and toward length-based password strength, compromised-password screening, and design choices that reduce authentication friction without sacrificing security. The nist password guidelines emphasize risk management over checkbox-style rules, ensuring password policies are grounded in real-world threat data.

Blacklisting Commonly Used and Compromised Passwords

When processing a request to establish or change a password, verifiers shall compare the prospective secret against a blocklist (password blocklist, also called a password blacklist) of known commonly used, expected, or compromised values. This blacklisting passwords requirement encompasses passwords from previous security incident corpus datasets (e.g., Have I Been Pwned and similar cybercriminal dictionaries), dictionary words, context-specific words such as the service name or username, and any other common passwords that attackers are likely to try. If a chosen password appears on the blocklist, the CSP shall require the subscriber to choose a different password and shall explain the reason for rejection. Checking new passwords against compromised-credential databases — including monitoring to monitor new passwords daily — is considered the most operationally effective control in the password screening process. Password adherence to this requirement directly addresses both credential-guessing attacks and credential stuffing attacks using previously exposed credentials. The blocklist should be of sufficient size to prevent subscribers from easily landing on an attacker's top-attempt list, but should not be excessively large to the point of frustrating users trying to create memorable passwords. Password entropy considerations and the principles behind password composition blocklisting are discussed in detail in Appendix A of the publication.

Eliminating Arbitrary Complexity Rules and Expiration Policies

Verifiers and CSPs shall not impose composition rules (e.g., requiring mixtures of uppercase lowercase letters, numbers, and special characters) beyond what is enforced through blocklist screening. Research into incident corpora demonstrates that users respond to character complexity requirements in highly predictable patterns — a user told to include a number and symbol will append "1!" to a simple word, yielding a credential that satisfies the policy rules while providing minimal additional entropy. Password composition rules and arbitrary character complexity requirements shall not be imposed. Password rotation and arbitrary periodic-change requirements are likewise prohibited: verifiers shall not require subscribers to change passwords periodically unless there is evidence of actual compromise — for example, appearance in a compromised-credential database. Password resets should only be enforced when compromise evidence exists, not on arbitrary schedules. These restrictions eliminate a class of onerous controls that drive users toward predictable password workarounds such as appending numbers or cycling through variants. Password reuse patterns documented in previous incident corpuses underscore why policy-driven rotation without screening is counterproductive.

On length, the minimum password length for a memorized secret used as a standalone single-factor authentication mechanism is now 15 characters — raised from 8 characters in previous revisions — reflecting the increased threat from offline attacks. Passwords used only as part of multi-factor processes shall be a minimum of eight characters in length (eight characters). A minimum of six decimal digits applies to system-generated one-time codes in some out-of-band contexts. For maximum length, verifiers and CSPs should permit at least 64 characters (64-character maximum) to support the use of long passphrases. Accepting Unicode characters in passwords is strongly recommended — each Unicode code point counts as a single character when evaluating password length. ASCII characters, including spaces and all printable characters, should be accepted. The password-strength meter should be offered to help users make better choices. A minimum of 15 characters for single-factor passwords and a maximum of at least 64 characters creates an input space large enough to make hash-cracking computationally prohibitive when combined with proper password hashing through a salted key derivation function.

Password Hints and Knowledge-Based Security Questions

Verifiers and CSPs shall not permit the subscriber to store a password hint accessible to an unauthenticated claimant. They shall not prompt subscribers to use knowledge-based authentication (KBA) — such as challenge questions like "What was your first pet's name?" or knowledge-based query variants about personal history — when choosing passwords. Knowledge-based challenge prompts and password hints are prohibited because this information is frequently obtainable through public records, social media, or social engineering, making KBA an unreliable secondary verification mechanism. Verifiers shall allow the use of credential management software and autofill (autofill) functionality — verifiers should permit the paste function to facilitate such use. The use of a password manager is explicitly encouraged by the guidelines as it increases the likelihood that subscribers will choose stronger, distinct user-chosen passwords for each service, reducing the risk of credential stuffing. Verifiers should also offer a "display password" option — showing the entered text rather than masked text entry — allowing subscribers to confirm their entry before submission, especially important on mobile devices where accurate manual entry is more error-prone.

The limit of 100 attempts is an upper bound, and agencies MAY impose lower limits. The limit of 100 was chosen to balance the likelihood of a correct guess (e.g., 100 attempts against a six-digit decimal OTP authenticator output) versus the potential need for account recovery when the limit is exceeded. — NIST SP 800-63B, Section 3.2.2

The 100-attempt limit on consecutive failed authentication attempts applies to brute-force guessing scenarios. The verifier shall implement rate limiting (throttling) that limits failed attempts — using at most 100 failed attempts before disabling the authenticator. Agencies may impose lower limits. Additional rate limiting and throttling mechanisms include requiring CAPTCHA challenges, imposing an exponential delay (starting with a 30-second delay), and employing adaptive risk-based authentication signals like IP address, geolocation, and browser metadata. These controls mitigate brute-force attack and automated credential-guessing scenarios. Account lockout after the maximum consecutive failures triggers the authenticator revocation and rebinding process. NFKC normalization (Normalization Form KC) should be applied when processing Unicode passwords before hashing — Unicode standardization ensures consistent byte representation and that NFKD normalization edge cases do not result in login failures.

Privacy Requirements and Risk Assessment for Authentication Systems Under NIST 800-63B

Core Privacy Requirements for Verifiers and CSPs

Section 7 of the guidelines provides the privacy framework for authentication system design. The verifier shall employ appropriately tailored privacy controls defined in SP 800-53 or an equivalent standard. This is a normative requirement — not merely aspirational. Privacy-by-design in authentication systems means collecting only the minimum information necessary to issue or maintain authenticators, using collected attributes only for identity services and not for secondary purposes without explicit subscriber notice and consent, and maintaining consistency (reliable assumptions about how personal information is processed) and manageability (subscriber ability to control their data). When CSPs or IdPs process attributes for purposes beyond identity services, they shall implement measures to maintain these properties commensurate with the privacy risks that arise from the additional processing. Consent to additional processing shall not be made a condition of receiving identity services. Effective risk management of authentication privacy requires evaluating both the likelihood and impact of potential harms to subscribers.

Privacy Controls and Data Minimization

Data minimization in authentication means the CSP should collect and retain only the personally identifiable information (PII) and personally identifiable information attributes genuinely necessary to issue, bind, and maintain authenticators. Biometric data collected for authentication activation shall be erased immediately after use — biometric samples and derived data shall not be retained beyond the immediate authentication or adaptation operation. The privacy risk assessment for authentication systems evaluates both the likelihood and impact of privacy problems — including privacy risks from records retention, behavioral monitoring, and attribute collection. The optional ongoing session-activity tracking capability described in Section 5.3 explicitly requires inclusion in the privacy risk assessment because of the inherent tension between fraud detection and subscriber profiling. Use limitation principles restrict the CSP to using authentication event data only for the stated identity service purpose unless they implement appropriate consent and notification measures. Subscriber consent must be meaningful — not buried in terms of service — and granular enough for subscribers to make informed decisions about attribute sharing. The concepts of consistency and manageability (from NISTIR 8062) anchor the privacy risk framework.

Redress Requirements and User Rights

The verifier and associated CSP or IdP shall provide mechanisms for redress of subscriber complaints arising from authentication processes. These redress requirements apply equally to authentication failures, incorrect account lockouts, and privacy-related complaints. Redress mechanisms shall be easy for subscribers to find and use, and the CSP or IdP shall assess mechanism efficacy in resolving complaints. Subscribers who experience authentication failure or authentication error events — particularly during reauthentication — require clear, accessible paths to resolution. Account notification requirements ensure that subscribers are alerted to significant authenticator events (binding, account recovery, invalidation) through at least two notification channels. The verifier shall also enforce records retention policies consistent with applicable laws including NARA records retention schedules, the Privacy Act of 1974, and the E-Government Act of 2002.

Agency-Specific Privacy Compliance Obligations

Federal agencies offering or using authentication services face additional obligations under federal compliance frameworks including FISMA, OMB A-130, and the Privacy Act that go beyond the baseline controls in SP 800-63B. These include conducting Privacy Impact Assessments (PIAs) for any authentication system that collects PII, publishing System of Records Notices (SORNs) when authentication event data is maintained in a Privacy Act system of records, and implementing the full SP 800-53 privacy control baseline appropriate to the system's impact level. The risk management discipline required for federal identity management programs means that authentication system owners must document their AAL selection rationale, privacy risk findings, and compensating controls in their System Security and Privacy Plans. A well-implemented nist 800-63b compliance checker supports this documentation process by mapping observed controls to specific normative requirements, helping agencies demonstrate that their authentication security posture meets both the technical and administrative obligations of federal compliance.