The NIST Digital Identity Guidelines, published as Special Publication 800-63 by the US National Institute of Standards and Technology, set out how organizations should establish, authenticate and federate digital identities. They are required reading for US federal agencies and a common reference for companies, universities and governments far beyond the United States.
This guide explains how the publication is organized, the roles and concepts it introduces, what each volume covers, and how organizations outside government can apply it sensibly. It is written for new security staff, developers and curious readers who want to understand the document before opening its detailed requirements.
Why One US Publication Shapes Identity Worldwide
Many standards describe specific technologies, such as how a login protocol exchanges messages. SP 800-63 is different. It describes the whole journey of a digital identity, from first proving who someone is to logging in daily and sharing identity with other services, and it ties each stage to risk.
Because the guidance is public, free and technology-neutral, it has become a shared reference point. Vendors describe products in its terms, auditors use its levels as benchmarks, and other countries draw on its concepts when designing their own frameworks. Familiar ideas such as identity assurance levels come from it.
The guidance has also influenced everyday experiences. Its recommendations on passwords, for example, encouraged many organizations to drop forced periodic changes and complex composition rules in favor of longer passphrases and checks against known compromised passwords.
How the SP 800-63 Suite Is Organized
SP 800-63 is a suite rather than a single document. A base volume sets out the overall model and risk management process, and companion volumes go deep on each stage of the identity journey. Knowing the structure saves time when looking for a specific requirement.
- SP 800-63 (base volume): definitions, the digital identity model and the risk management process for selecting assurance levels.
- SP 800-63A: identity proofing and enrollment, including evidence, validation, verification and identity assurance levels.
- SP 800-63B: authentication and authenticator lifecycle management, including authenticator assurance levels.
- SP 800-63C: federation and assertions, including federation assurance levels.
NIST revises the suite periodically, and the latest revision expands topics such as digital wallets, fraud management and usability. Revision labels appear in document names, so readers should confirm they are working from the current version and check whether their organization has committed to a particular revision.
The Digital Identity Model and Its Roles
The guidelines describe identity using a small set of roles. An applicant is a person going through proofing. Once enrolled, they become a subscriber who holds one or more authenticators, such as a password, a passkey or a hardware security key, bound to their account.
A credential service provider, or CSP, performs proofing and manages authenticators. A verifier checks that a claimant, meaning a person trying to log in, controls a valid authenticator. A relying party is the service that depends on the outcome, such as an online benefits portal.
These roles can be combined in one organization or spread across several. In federation, an identity provider handles proofing and authentication, then sends a signed assertion about the user to the relying party. Clear roles make it easier to assign responsibilities and to describe where each control is applied.
A Risk-Based Approach Instead of a Checklist
The guidelines do not prescribe one configuration for every service. They ask organizations to assess the harm that could follow from failures in proofing, authentication or federation, then choose assurance levels proportionate to that harm. This makes the guidance flexible but also demands careful judgment.
Three sets of levels result: identity assurance levels for proofing, authenticator assurance levels for login strength and federation assurance levels for assertion security. They are selected separately. A service may need strong authentication without deep proofing, for example, when users need not reveal their real-world identity but accounts hold valuable data.
The risk process also allows tailoring. Organizations may adjust controls, apply compensating measures or accept certain risks, provided they document their reasoning. This flexibility is useful, but it means two organizations claiming the same level may implement it differently, so documentation matters for anyone relying on the result.
Proofing Guidance in SP 800-63A
The proofing volume explains how to establish that an applicant is who they claim to be. It describes resolving the identity to one unique person, validating evidence such as passports, driver’s licenses or authoritative records, and verifying that the applicant is genuinely linked to that evidence.
It defines identity assurance levels that tie evidence strength and verification methods to risk. Lower levels allow lighter checks, while the highest level calls for an attended session, with the applicant physically present before a trained proofing agent or connected through a closely controlled supervised setup. Our separate article on identity assurance levels covers these levels in more depth.
The volume also addresses practical topics such as trusted referees for people without standard documents, handling of personal data collected during proofing, and expectations for detecting fraudulent applications. These sections are useful even for organizations that do not formally claim a NIST assurance level.
Authentication Guidance in SP 800-63B
The authentication volume covers how users prove control of their accounts and how authenticators are managed over time. It is the part of the guidance most organizations encounter first, because almost every service has a login. Three themes stand out.
Passwords Done Sensibly
NIST calls passwords memorized secrets in older revisions and simply passwords in newer text. Its guidance favors sufficient length, allows long passphrases and screens new passwords against lists of commonly used or compromised values. It discourages arbitrary composition rules and routine forced changes, recommending changes when there is evidence of compromise instead.
Multi-Factor and Phishing Resistance
Higher authenticator assurance levels require multiple factors, combining something you know, have or are. The guidance increasingly emphasizes phishing resistance, meaning authenticators that cannot be tricked into working on a fake site. FIDO2 and WebAuthn passkeys and certificate-based smart cards are common examples of phishing-resistant methods.
One-time codes sent by text message, by contrast, can be relayed through a fake site, so the guidance places extra conditions on their use.
Authenticator Lifecycle
The volume also covers binding new authenticators to an account, handling loss or theft, expiry and account recovery. Recovery is a frequent weak point, because attackers target it to bypass strong logins. The guidance expects recovery processes to maintain assurance rather than falling back to weaker methods such as security questions.
Federation Guidance in SP 800-63C
Federation lets one organization authenticate a user and pass that result to another, so the user does not need separate accounts everywhere. Single sign-on across a company’s applications and signing in to a government portal with an existing trusted account are common examples.
The federation volume describes how identity providers create assertions, which are signed statements about the user’s authentication and attributes, and how relying parties should validate them. It applies to protocols such as SAML 2.0 and OpenID Connect without requiring a specific one.
Federation assurance levels reflect how well assertions are protected against tampering, replay and injection. Higher levels add requirements such as stronger protection against injected assertions and binding the assertion to an authenticator the user holds. The volume also covers privacy, including limiting the attributes shared with each relying party to what it actually needs.
Privacy, Usability and Equity Considerations
The guidelines go beyond security controls. Each volume includes considerations for privacy, asking organizations to minimize collection, explain purposes and protect data used in proofing and authentication. Biometric data receives particular attention because of its sensitivity and the difficulty of replacing it once exposed.
Usability guidance recognizes that confusing processes push people toward insecure workarounds. Clear instructions, reasonable timeouts and support for assistive technologies help users succeed without weakening security. Testing with real users, including people with disabilities, is encouraged as part of implementation.
Recent revisions place stronger emphasis on equity and access, meaning that identity processes should not unfairly exclude groups of people. This includes offering alternatives to biometric or smartphone-based methods and monitoring outcomes so that problems affecting particular populations can be detected and corrected.
Applying the Guidelines Outside Federal Agencies
For US federal agencies, the guidelines carry formal weight through government policy. Other organizations are generally free to adopt them voluntarily, though contracts, sector regulators or partners may require alignment. Many private organizations use them as a well-tested baseline rather than inventing their own rules.
- Start with the risk assessment process to select assurance levels for each service.
- Adopt the authentication guidance first, since it benefits almost every login.
- Use the proofing volume when onboarding requires knowing real identities.
- Reference the federation volume when integrating single sign-on or external identity providers.
- Document deviations and the reasons for them, so auditors and partners can understand your choices.
Organizations outside the United States may also need to follow local frameworks, such as eIDAS in the European Union or national digital identity schemes. NIST guidance can complement these, but it does not replace legal requirements, so teams should confirm obligations with the relevant authority.
Common Misreadings of the Guidelines
One frequent misreading is that NIST bans all password expiry or composition rules everywhere. The guidance recommends against arbitrary rules and routine forced changes, but it still expects changes after compromise and supports other protections. Reading single sentences out of context leads to oversimplified policies.
Another misreading treats assurance levels as product certifications. A vendor may support the controls needed for a level, but the organization operating the service is responsible for the full implementation, including processes, staff training and record keeping. Claims of compliance should always be checked against the actual setup.
A third mistake is ignoring the normative and informative distinction. Some text states requirements, often signaled by words such as shall, while other text offers explanation or recommendations. Knowing which is which helps teams separate mandatory controls from helpful context.
Using the Guidelines in Your Next Project
A practical way to start is to pick one service and walk it through the base volume’s risk process. Write down the harms that could follow from proofing, authentication and federation failures, then note the assurance levels that would address them. This exercise often reveals gaps quickly.
Next, compare the current implementation against the relevant volume’s requirements and list differences. Prioritize changes with the biggest risk reduction, such as adopting phishing-resistant authenticators for administrators or strengthening account recovery. Track progress in a simple document shared with stakeholders.
Keep watching for updates. NIST publishes drafts for public comment before finalizing revisions, and following those drafts gives early warning of changes. Pairing that awareness with local regulations keeps your identity program aligned with both the guidelines and the laws that apply to you.