FIPS 140-2 revalidation terms to know: 1SUB, 3SUB, 5SUB

I received a question recently about maintaining a FIPS 140-2 certificate after changes are made to the module.  Here is some background for those not familiar with the process.

There are 5 different scenarios when making changes to a cryptographic module.  I'll cover the 3 most common.  Additional details are found in the FIPS 140-2 Implementation Guidance document, G.8.  

1SUB - Modifications are made to hardware, software or firmware components that do not affect any FIPS 140-1 or FIPS 140-2 security relevant items. The vendor is responsible for providing the applicable documentation to the CST laboratory, which identifies the modification(s).

[Mark Minnoch]  A "1SUB" (say "one-sub") is a "maintenance" or "bug-fix" activity for the Lab.  As an example let's consider the case of a vendor making source code only changes.  The Lab reviews the source code changes to determine if any of the changes were security relevant.  If the Lab agrees with the vendor that the changes are not security relevant, then a letter request is submitted to the CMVP to include the updated firmware (or software) version on the existing FIPS certificate.  

3SUB - Modifications are made to hardware, software or firmware components that affect some of the FIPS 140-2 security relevant items. An updated cryptographic module can be considered in this scenario if it is similar to the original module with only minor changes in the security policy and FSM, and less than 30% of the modules security relevant features.

[Mark Minnoch]  A "3SUB" change is commonly referred to as a "revalidation".  The Laboratory updates the previous report submission to include changes and also to confirm that the required regression testing was completed.  This is more involved than a 1SUB but typically less effort than a new validation.  The Lab considers service changes, algorithm changes, hardware changes, etc. when determining if the 30% threshold for security relevant changes is exceeded.

5SUB - If modifications are made to hardware, software, or firmware components that do not meet the above criteria, then the cryptographic module will be considered a new module and must undergo a full validation testing by a CST laboratory.

[Mark Minnoch]  A "5SUB" is commonly referred to as a "validation".  The Laboratory submits a full validation test report package and the appropriate NIST fee applies.