Security and Connectivity for IoT Devices


Federal Information Processing Standards (FIPS) 140-3 Validation

Home / FIPS Validation for IoT Security and Connectivity

Partnering with Experts in FIPS Validation

The Allegro Cryptography Engine (ACE™) provides FIPS validated cryptography that is engineered for the unique demands of resource-constrained IoT devices and related applications. Reach out to learn more about this solution and other FIPS validated solutions.


The Federal Information Processing Standards (FIPS) were established to ensure the security of data. As the amount of data being produced every day continues to increase, with estimates of 463 exabytes (EB) being created globally by 2025, the need to securely transmit and store data becomes more pressing. Cryptography is utilized to secure embedded trust in IoT devices, applications, and ecosystems, minimizing the risks and liabilities associated with data breaches. Embedded trust and cryptographic security are crucial for satisfying the requirements of the Federal Information Processing Standards (FIPS) and safeguarding data.

Cryptography and Encryption

Understanding data security and FIPS validation requires an understanding of cryptography and encryption. In the distant past, cryptography and encryption would have been considered the same. However, cryptography has recently evolved into a broader study involving the science of concealing communications and applying different types of technology in different situations. Encryption is the process of encrypting and decrypting data. Historically, encryption has been done through a cipher, which is a form of covert coding used to secure communication.


The larger study and science of concealing communication.


The different ways you can encrypt and decrypt data.


How Do Cipher’s Relate to Cryptography and Encryption?

Ciphers are a form of encryption that have been used for thousands of years. One of the early examples was an ancient Egyptian cipher from roughly 100 BC known as Caser’s Cipher, named after Julius Caesar. This cipher relied on a simple substitution and a shift of three, where a letter would shift three positions (‘A’ would become ‘D’, and ‘B’ would become ‘E’ and so on,) to encrypt the military information that Julius wanted to send to his generals in the field. This type of substitution cipher was later modified to utilize a key that identified how the characters were shifted (the first character is shifted by three, the next character is shifted by seven, the next character is shifted by five, etc.) While the concept of a key is the same in modern encryption, the creation and utilization of keys is now based heavily upon advanced mathematical principles.

What are FIPS?

 FIPS stands for Federal Information Processing Standards, which are developed by the National Institute of Standards and Technology (NIST). NIST is a United States federal agency that is a leader in creating critical measurement solutions and promoting equitable standards. NIST uses existing standards where possible, and if no standard exists for their requirements, they will create one. In the case of information security, NIST via the FIPS standards, specify a range of security requirements for cryptographic modules, including physical security requirements, implementation of the cryptographic algorithm, and the design and operation of cryptographic modules.

What are FIPS 140-2 and 140-3?

FIPS 140-1, FIPS 140-2, and FIPS 140-3 are standards created by NIST that define the security requirements for cryptographic modules used in computer and telecommunication systems. FIPS 140-1 was released in 1994 and defined four security levels along with 11 sets of criteria and requirements. FIPS 140-2 was released in 2001 reflecting updates in technology and other applicable standards. FIPS 140-3 was ratified in 2019, and the transition to this standard from FIPS 140-2 is an ongoing process. This third version includes many updates and strong links to ISO documentation, which are standards that have been implemented worldwide. All modules with FIPS 140-2 validation will expire and go to the historical list in September 2026. FIPS 140-3 is predicted to be available well before this date.

What is a Cryptographic Model?

A cryptographic module can be thought of as single unit with a defined security boundary that implements various security functions including cryptographic algorithms. Modern cryptographic modules often implement multiple cryptographic algorithms via software, firmware, hardware or a hybrid mix of each. Each module is defined by a security boundary and a security policy that defines the operating characteristics of the module. The security policy acts much like a set of instructions and identifies what is to be evaluated for FIPS, the operating environment and other operational and configuration components. Once a module has passed FIPS validation the security policy acts as an engineering and design artifact and documents the operation and configuration of the module. Security policies for all validated modules are public and can be found on the NIST website.

Why are FIPS Requirements Important?

Cryptography is extremely critical for securing and protecting data and maintaining privacy. It is often complex and requires a unique skill set, especially when implemented in resource constrained environments like embedded systems and IoT applications.  The combination of dramatic increase in data creation with ubiquitous connectivity has driven the risk for a data breach to unprecedented levels. The proper implementation and utilization of cryptography is the foundation for all countermeasures that reduce data exposure and therefore risk.

FIPS validation provides an independent assurance that cryptography works as designed and intended. To receive a FIPS validation, your module must go through extensive testing to ensure it works properly. There is a growing acceptance and requirement for FIPS validation in various application environments, including the medical and financial industries in addition to government related projects.

How To Achieve FIPS Validation

To achieve FIPS 140-3 certification, a cryptographic module must be independently tested and evaluated by an accredited testing laboratory to ensure that it meets specified security requirements.

A FIPS validation requires assessment of the combined cryptographic module, its configuration, and the operating environment (OE). As a vendor looking to get a cryptographic module validated, you can work with one of 13 laboratories in North America and NIST to receive a FIPS validation.

You must submit your cryptographic module to a laboratory for testing and reporting. The lab will generate a documentation package that is sent to NIST for review before providing you with a module coordination with comments on specific aspects of the module and changes to be made. You may need to go through multiple sets of module coordination revisions before receiving validation from NIST. Once you have met all the criteria for FIPS validation a certificate is issued, and your security policy will be published on the NIST website. This is a time-consuming process with a typical timeframe of nine months or up to two years. There is a backlog with the most recent FIPS 140-3 validation which has caused some delays with certifications.

Levels of FIPS Validation

There are four levels of FIPS validation. Level one being the lowest, which involves algorithm testing to ensure they are implemented correctly along with appropriate configuration and a security policy that outlines how to use it. Level two employs role-based authentication, which confirms that the entity that uses the module has been authenticated and has the appropriate privileges to be able to use the module. At this level, the module must prove it is tamper-evident so that you can easily confirm if the software, hardware, or firmware has been tampered with. You will also narrow the operating environment to a specific environment that is approved by Common Criteria, which is a sister organization to the FIPS Organization at NIST. At level three, you enter identity-based authentication, which requires the authentication of specific people who have the authority to be able to use the module or specific algorithms within the module. This level also includes tamper resistance and physical and logical Critical Security Perimeters (CSP) storage. Level four is the highest level that encompasses testing of tamper active countermeasures that ensure a module will self-destruct when it is tampered with in any way.

Types of FIPS Validation: 5SUB, 3SUB, and 1SUB

There are essentially three different types or levels of effort needed for a FIPS validation: 5SUB, 3SUB, and 1SUB. However, there is also a whole document called an implementation guidance, from NIST, that goes through various scenarios that are specifically identified for these types of validation.

The 5SUB involves full validation of the module with all documentation and testing since its conception and can take 18-24 months. A 3SUB includes additional security relevant changes to verify that the module is secure after changes to hardware, software, or firmware components have been made. If more than 30% of the module has changed, the 5SUB process must be repeated. Once the module has gone through the 5SUB and 3SUB validation processes, 1SUB validation can be completed, which includes non-security relevant changes such as maintenance or bug fixes. 1SUB validation also includes rebranding, where an existing module can be renamed and receive validation for use under a new brand using the existing documentation kit. The validation process can be started from scratch by completing the full 5SUB validation process, or a hybrid approach can be taken if a FIPS module closely meets the needs and only minor changes are required. 1SUB is typically done for rebranding or adding an operating environment to the module.

FIPS Terms: FIPS Validated V.S. FIPS Compliant

FIPS validation is a process where a module undergoes NIST testing to ensure it meets specific boundary requirements, follows a defined security policy, passes algorithm testing, and meets the latest NIST implementation guidelines. FIPS compliance is not synonymous with the proper use of NIST-approved algorithms. It only means that a single element of the system has undergone FIPS validation, not necessarily that the entire module has been independently evaluated for proper use in the operating environment. “Compliance” is a loose term, and it is important to ensure that a module has undergone validation, not just compliance. Furthermore, just because a module is validated does not guarantee it is being used correctly. The security policy for the module should be followed to ensure it produces the intended results.

Cryptographic Supply Chain & Societal Impact

The cryptographic supply chain is a collaborative effort between industry, academia, and government to share ideas and research. The National Institute of Standards and Technology (NIST) plays a key role in this process by identifying leaders in the field of quantum cryptography and working with them to understand how to best utilize this technology. Industry companies also contribute to the supply chain by providing peer-reviewed research on cryptography and its applications, including post-quantum cryptography and lightweight cryptography. Academia focuses on studying the societal implications of cryptography and how it can be applied in different contexts. The government’s role in the supply chain is to ensure that the technology meets their needs, often through the use of industry standards. Investments in cryptography by governments around the world have a significant impact on many aspects of society.

The Allegro Cryptographic Engine Listed as a CMVP Module in Process by NIST

Allegro is pending review for FIPS 140-3 validation from NIST for the Allegro Cryptography Engine – ACE™. Allegro has been added to the Modules in Process List (MIP), which highlights the modules that the NIST Cryptographic Module Validation Program (CMVP) is actively...

Allegro Joins The Medical Device Software Development Summit

As a leading provider of embedded software solutions, Allegro is pleased to announce its attendance at the Medical Device Software Development Summit 2023. This event is set to take place in Boston, Massachusetts, from May 16th to May 18th, 2023. The Medical Device...

Nielsen Case Study: IoT Device Security for A Multi-Billion Dollar International Company

IoT device security is especially important for a huge, multi-national company like Nielsen, to ensure their data is legitimate and accurate.

Best Practices for Managing IoT Related Risks

Allegro’s “Best Practices” document addresses the topic of IoT security related risks by taking a closer look at Critical Requirements and Functional Implementation.

7 Key Elements of Proactive IoT Security

All types of Internet of Things (IoT) devices are under attack. They are routinely recruited as unwitting members of botnets used for Distributed Denial of Service (DDOS) attacks, hosting various malware, and extracting sensitive data. Why are hackers drawn to these...

Open Source Issues in Mergers and Acquisitions

Open Source Issues in Mergers & Acquisitions In a merger or acquisition in which a technology company is the target, the target company’s software is often a material – and perhaps even the principal – asset of the deal. Often, this software was developed using...
Our Resources

Let’s Talk IoT Security

Implementing IoT device security can be a challenge. Let us help you by sharing our proven framework for integrating a proactive security approach into your design. Click the button below to schedule a one-on-one web conference to discuss your security needs.

Download Allegro’s Playbook

  • This field is for validation purposes and should be left unchanged.

Contact Us Today

  • This field is for validation purposes and should be left unchanged.