Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Secure .gov websites use HTTPS
A lock ( ) or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.

FAQs: Frequently Asked Questions

Here are some answers to common questions submitted to CSRC. Additionally, many projects have FAQs that have more technical and details questions and answers.

Jump to:

General Questions

Yes. The NIST Cybersecurity and Privacy Program offers several mailing lists to keep you informed.

  • Main Publications List: You can subscribe to receive immediate announcements regarding new publication drafts, final releases, and updates to NIST cybersecurity standards and guidelines.
  • Project-Specific Lists: We also host dedicated mailing lists for individual programs, projects, and initiatives (such as the Cybersecurity Framework, NCCoE projects, and NICE).

How to Subscribe: To join and view the full directory of available newsletters and announcement lists, please visit our NIST Mailing List Subscription Page.

If you cannot locate a specific Draft SP discussed at a workshop, please consider the following steps:

  • Check the Drafts Page: All officially released drafts are listed on the CSRC Draft Publications page.
  • Verify Publication Status: If it isn't listed, the document likely hasn't been formally released for public comment yet. We recommend contacting the workshop presenter or technical lead directly for a status update.
  • Stay Informed: The best way to track new releases is to subscribe to our email mailing lists. We send notifications to the Draft and SP lists as soon as a document is published.

Because registration processes vary by event, you will need to register directly through the specific event's information page. You can find upcoming workshops on the following calendars:

Next Steps:

  1. Locate your desired event on one of the pages above.
  2. Follow the specific registration instructions or links provided on that event's page.
  3. If you have questions or encounter issues, reach out to the point of contact listed on that specific event page.

Thank you for helping us maintain the accuracy of our publications. You can report errors or typos using one of the following methods:

  • Contact the Document Team Directly: Open the publication and look for the specific project contact email address. This is typically located within the first 3 to 5 pages.
  • Email the CSRC Inquiries Team: Send an email to [email protected].

What to include in your email: To help us resolve the issue quickly, please include the document series and number, the page number where the error occurs, and a brief description of the issue.

Back to Top

Cryptographic Algorithm Validation Program (CAVP)

The validation process depends entirely on whether the algorithm is NIST-approved or not:

  • NIST-Approved Algorithms: If the algorithm is listed in SP 800-140C or SP 800-140D, you can test it informally or seek formal validation. (See Q2 below)
  • Non-NIST-Approved Algorithms: If the algorithm is not listed in those standards, fewer validation options are available. (See Q3 below)

There are two options available, depending on your business and compliance needs:

  • Option 1: Informal Validation (For Testing/Development)

    If you do not need an official certificate, you can test your implementation informally. Use the ACVTS Demo Server or download pre-generated vector sets directly from the ACVP GitHub repository.

  • Option 2: Formal Validation (For Compliance/FIPS Validation)

    If you require an official validation listing on the CSRC Algorithm Validation pages, you must contract an NVLAP-accredited testing laboratory. The laboratory will guide you through the official testing process using the production Automated Cryptographic Validation Test System (ACVTS).

The CAVP generally cannot validate custom or non-approved algorithms. Cryptographic algorithms require extensive peer review to ensure public trust and security. However, there are a few exceptions:

  • Limited ACVP Testing: The CAVP offers test vectors for a very restricted selection of non-NIST-approved algorithms. You can check the current ACVP algorithm list to see if your algorithm is supported.
  • Criteria for Future Inclusion: For the CAVP to adopt and test a new algorithm, it cannot be a custom, proprietary design. It must be published in an existing standard by a recognized standardization body (such as the IETF or IEEE) and should impact FIPS cryptographic modules.

Want to submit a new algorithm? NIST selects new cryptographic algorithms for standardization through open, public competitions. You can track or participate in these efforts on our NIST Cryptographic Standards and Guidelines page.

You can reach the Cryptographic Algorithm Validation Program (CAVP) Team directly by emailing [email protected].

Tip: To help the team address your inquiry efficiently, please include any relevant details in your email, such as the specific algorithm name, standard document (e.g., SP 800-140C), or ACVTS testing project name.

For comprehensive resources, documentation, and updates, please visit the official project pages:

  • CAVP Project Home Page: Access program overviews, testing metrics, and general announcements.
  • Detailed CAVP FAQs: View an expanded list of frequently asked questions regarding algorithm testing, ACVTS, and validation policies.

Back to Top

Cryptographic Module Validation Program (CMVP)

Yes. If a federal agency requires data to be protected by cryptography, that cryptography must be validated.

To comply with the FISMA mandate, federal agencies are required to use cryptographic modules that meet FIPS 140-2 or FIPS 140-3 standards to secure their operations and assets.

Using non-validated cryptography is treated as having no protection at all, meaning your data is considered unprotected plaintext. Simply put, if cryptography is required, then it must be validated.

The rules, processes, and administrative guidelines for the CMVP are detailed in the following documents:

These manuals clearly outline the management activities, procedures, and responsibilities for all groups participating in the program.

You can start by familiarizing yourself with the core Federal Information Processing Standards (FIPS) requirements and the CMVP's overall goals. Begin with the following questions on our detailed FAQ page:

The CMVP website provides a comprehensive overview of how the program operates and addresses the security needs of both the U.S. and Canadian governments.

The only officially recognized term is validated.

Terms like "compliant," "conformant," or "certified" are not official designations under the FIPS 140 standards. If a vendor claims their product is compliant or certified, you should always ask them to provide their CMVP certificate number to prove it has been formally tested.

To verify a vendor's certificate number or to browse the complete list of CMVP validated modules, please go to the Validated Modules search page.

Visit the official Validated Modules search page and search by vendor name, module name, certificate number, or validation status.

Visit the official CMVP project page to learn more.

If you have more specific questions or need further guidance, you can also explore our comprehensive list of CMVP FAQs.

Back to Top

Risk Management Framework (RMF) and Protecting Controlled Unclassified Information (CUI)

Because NIST is a non-regulatory agency within the U.S. Department of Commerce, it does not determine, monitor, track, enforce, or certify compliance with the security requirements in NIST SP 800-171.

If your organization has questions about complying with regulatory requirements or Controlled Unclassified Information (CUI), or other specific regulations, please reach out directly to your prime contractor or your contract's federal point of contact.

For additional guidance on implementation and federal standards, visit the Protecting CUI FAQs.

NIST developed the technical guidance that serves as the foundation for SPRS self-assessments. This includes Special Publications (SP) SP 800-171, SP 800-171A, SP 800-172, and SP 800-172A.

Because NIST is a non-regulatory agency, it does not manage or oversee the Department of War's (DoW) SPRS application. NIST plays no role in SPRS procedures, score submissions, or approval processes.

For further details regarding CUI security requirements and implementation guidelines, visit the official NIST Protecting CUI Project.

NIST does not directly collect or manage assessment scores. To enter, update, or view your risk assessment score—or if you have questions about meeting self-assessment requirements—please visit the official Supplier Performance Risk System (SPRS) site.

Yes. NIST provides two primary tools to help you navigate mappings and crosswalks between NIST guidelines, including NIST Risk Management Framework (RMF) publications, and other cybersecurity and privacy standards and frameworks, including:

NIST does not offer certifications. As a non-regulatory agency under the U.S. Department of Commerce, NIST is not a certifying body. We do not issue professional certifications, nor do we endorse any programs, organizations, or third parties claiming to offer "NIST certification" for individuals or organizations.

If you have questions about demonstrating compliance with specific NIST cybersecurity guidelines for an existing contract—such as implementing the Risk Management Framework (RMF) or meeting the requirements of NIST Special Publications (like SP 800-171)—please contact your prime contractor or the relevant federal agency directly.

You can find comprehensive details, documentation, and answers to common questions by visiting the official project pages and Frequently Asked Questions (FAQs) sections on the pages listed below:

The various stages of the validation process are described at CMVP Validation Process.

Back to Top

Human-Centered Cybersecurity

The NIST Phish Scale is a method for professionals running phishing awareness training programs to provide context for their simulated phishing exercise click rates by evaluating an email's human phishing-detection difficulty. For these individuals, the NIST Phish Scale is available at no cost for academic use. To proceed, organizations must establish a research license agreement with NIST. For any commercial applications, interested companies must obtain a commercialization license. To explore licensing opportunities or initiate the process, please contact the NIST Technology Partnerships Office at [email protected].

For documentation and further details, visit the NIST Phish Scale project page.

It is a Google Group forum where cybersecurity researchers, IT practitioners, and human factors experts can share ideas, discuss best practices, and find opportunities for collaboration.

You can explore current research areas, ongoing initiatives, publications, news, events, tools, and additional resources directly on the Human-Centered Cybersecurity project homepage.

Back to Top

Post-Quantum Cryptography (PQC)

Post-Quantum Cryptography (PQC) refers to cryptographic algorithms designed to secure digital communications against future attacks from both classical and quantum computers. Advancements in quantum computing threaten current public-key encryption standards — such as RSA and Elliptic Curve Cryptography (ECC) — which rely on complex mathematical problems that quantum machines could solve easily.

The goal of PQC is to implement new encryption methods that resist these emerging threats while integrating seamlessly into existing IT networks. To lead this global transition, NIST has published its principal PQC standards — including FIPS 203, FIPS 204, and FIPS 205 — to ensure data security in the quantum era.

Estimates for when a Cryptanalytically Relevant Quantum Computer (CRQC) will be capable of breaking current encryption vary across three primary timeframes:

  • Near-term (by 2030): Projected by those anticipating rapid breakthroughs in quantum hardware scaling
  • Mid-term (15-20 years): Expected by many as the time needed to solve complex engineering challenges in error correction and fault tolerance
  • Long-term (30+ years): Projected by experts who view physical scaling and fault-tolerant system assembly as multi-decade challenges

Despite timeline uncertainties, experts stress the need to prepare now to mitigate risks such as "harvest now, decrypt later" attacks.

Start by conducting a comprehensive discovery and inventory of your organization's cryptographic assets. Identifying where vulnerable algorithms are currently deployed across hardware, software, and network protocols helps prioritize high-risk systems. Organizations can use guidance from the NCCoE's Migration to Post-Quantum Cryptography Project and follow transition timelines such as in NIST IR 8547, Transition to Post-Quantum Cryptography Standards to plan for phased adoption.

Back to Top

Zero Trust Architecture (ZTA)

Zero Trust is a security concept and framework that assumes that all users and devices, whether inside or outside an organization's network, are potential threats. It requires verifying and authenticating all users and devices before granting access to resources and data.

NIST SP 800-207, Zero Trust Architecture, states that "Zero Trust (ZT) is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources. A zero trust architecture (ZTA) uses zero trust principles to plan industrial and enterprise infrastructure and workflows."

Adopting a Zero Trust Architecture is a journey that requires careful planning and execution. To get started, organizations should take the following steps:

  1. conduct a thorough discovery and inventory of their existing infrastructure
  2. establish clear access policies
  3. assess their current security capabilities
  4. identify and address any gaps in their Zero Trust policies and processes
  5. implement the necessary ZTA components
  6. validate the implementation
  7. continuously monitor and improve their Zero Trust posture to adapt to evolving threats, technological advancements, and changing regulatory landscapes

A Zero Trust security framework is built on several key pillars, including Identity Verification, Least-Privilege Access, and Micro-Segmentation, which collectively verify user and device identity, restrict access to resources, and prevent lateral movement.

Additional security measures, such as Multi-Factor Authentication (MFA), Continuous Monitoring, and Risk-Based Access Control, further enhance security by requiring multiple forms of verification, monitoring user behavior, and assessing risk.

Other essential components, including Device Health Checks, Encryption, and Analytics and Logging, verify device health, protect data, and detect potential security threats, ultimately forming a robust Zero Trust security framework that reduces breach risk and improves overall security posture.

Zero Trust is a security concept and framework, not a specific tool or technology. It's a paradigm shift in how organizations approach security, rather than a replacement for existing security tools. And so, with Zero Trust, existing security tools are reimagined to support a continuous verification model, enabling organizations to restrict access, limit lateral movement, and improve overall security posture.

Implementing any new cybersecurity strategy, including Zero Trust, may require a brief adjustment period. When Zero Trust measures—such as stronger authentication steps or routine device health checks—are first introduced, they can create initial friction if not carefully integrated. However, if properly designed according to NIST guidelines, a Zero Trust Architecture ultimately streamlines secure "anytime, anywhere" access for a hybrid workforce, balancing robust security with operational efficiency.

You can find comprehensive guidance, publications, and practical implementation examples directly on NIST's official websites.

 

Back to Top

Created October 29, 2026