Blogs

If you are a commercial or public-sector organization evaluating network or network security products, it is common to hear that a product is “FIPS certified” or uses “FIPS- validated cryptography” as a selling point. Sometimes commercial customers may even be told that a product is “Common Criteria validated” or “on the DoD Approved Product List,” with the implication that said product is “good enough for the intelligence community or the U.S. Army, so it’s good enough for you.”

One way in which the nature of federal certifications may arise is in the context of network security. Network security refers broadly to the architectural principles and everyday practices organizations use to mitigate risk associated with cyberattacks Potential attacks can be carried out via the network, or the network infrastructure itself could be vulnerable to attack. Commercial customers may assume that using federally certified products inherently enhances network security.

But is that actually so? Does a product having one or more federal certifications really mean that it is more secure or better than a product that does not, and should that drive commercial purchasing decisions? What, exactly, does a commercial customer get out of having a certified product?

In this article, you’ll learn what U.S. federal security certifications actually validate, what they do not guarantee, and how to assess their real value when choosing a networking solution.

First, it’s important to explain what the various federal certifications related to product security are, their relationships to one another, and what problems they’re intended to address. Understanding those key facts explains why a product’s certification status may or may not factor into a commercial purchasing decision.

Understanding U.S. federal certifications

If you are evaluating networking and network security products, you may encounter claims pertaining to a variety of certifications. How do U.S. federal certifications differ?

HPE Aruba Networking Product Trust and Assurance (PTA) deals primarily with the following federal certifications relevant to product security:

• Federal Information Processing Standard 140-3 (FIPS 140)
• Common Criteria (CC)
• Commercial Solutions for Classified (CSfC)
• DoDIN Approved Product List (DoDIN APL) (this program sunset as of July 18, 2025) and vendor Security Technical Implementation Guide (STIG) 

Federal Information Processing Standard 140

The Federal Information Processing Standard (FIPS 140) validation focuses on the correctness of cryptographic algorithms, and the resistance of the certified product or module to cryptanalysis and side-channel attacks against the security of the cryptography provided by the product. FIPS 140 validation of a product or, at the very least, proving that the product is using a validated module (such as OpenSSL) in a compliant way, is required for federal government sales. FIPS validation is assessed via licensed third-party testing labs before a final certification is provided by the government.

FIPS 140 validates cryptography correctness; it does not evaluate the overall security architecture of a networking product.

Common Criteria and Commercial Solutions for Classified

Common Criteria (CC) leverages FIPS algorithm validation of the cryptography portions of the product, then assesses the product against a set of Security Functional Requirements (SFRs), which are intended to address specific concerns enumerated in the Security Problem Definition found within a specific Protection Profile.

The related Commercial Solutions for Classified (CSfC) certification builds on Common Criteria by stating which selections must be made (or configured after the fact) for the product to be suitable for use in Top Secret environments. CC conformance is tested by licensed third-party labs before final certification is provided by the government.

Common Criteria and CSfC validate specific security claims only when products are deployed in tightly defined evaluated configurations. 

DoDIN Approved Product List (sunset in July 2025) / Vendor STIG process

The DoDIN Approved Product List (DoDIN APL) program sunset in July 2025. Going forward, U.S. military cybersecurity requirements rely on DISA-approved Security Technical Implementation Guides (STIGs) for secure configuration, and Unified Capabilities Requirements (UCR) for interoperability.

The U.S. Army has issued additional policy that Common Criteria certification also makes products eligible for purchase by Army customers.

For customers, this shift emphasizes secure deployment and configuration over simple inclusion on a static product list.

Once a STIG exists, the vendor is responsible for demonstrating that the product can be configured per the STIG, the controls function as described and the settings in the STIG allow the product to function correctly. When the DoD program buys and implements products, they verify the STIG settings apply correctly, the product works with other components, and the required standards are met. This testing does not need to be completed by a third-party lab.

STIGs define how a product should be securely configured in DoD environments, but compliance depends on correct deployment and operational validation- not third-party lab testing.

The DoDIN APL list will be maintained through the end of September 2026.  

Why do federal certifications exist?

Federal certifications provide a standardized way of ensuring that commercial-off-the-shelf (COTS) products meet stated minimum-security requirements before conducting further assessment to determine whether the product provides a solution that a federal customer is looking for. By offering a pathway for COTS solutions, federal customers can have a wider range of options at a reduced cost and time to implement compared to the RFP process for custom-made solutions.

But make no mistake—all these products are, in fact, commercial solutions. Some may have been designed with government sales in mind, but for many, that was merely an afterthought.

What’s the catch?

There are a few things commercial customers need to be aware of when considering federal certification status while evaluating products. Often there are a lot of assumptions involved, which may not be relevant to the customer’s use case. This is particularly true with Common Criteria, especially around “evaluated configurations.”

A product is certified through Common Criteria by testing a specific set of claims against an approved range of selections. Often, the product must be configured in a specific way to meet the requirements, called the evaluated configuration. The evaluated configuration is often a subset of the product’s actual capabilities, either because some services are out of scope, or because the service doesn’t conform with Common Criteria requirements. Any deviation from the evaluated configuration would mean the product as configured is not actually in compliance with Common Criteria.

You can see, then, why this may not be a great selling point for commercial customers.

Additionally, what’s allowed by FIPS, Common Criteria, and CSfC in terms of cipher suites for services such as TLS or SSH, is rather restrictive compared to what might otherwise be enabled. Cryptographic ciphers built around ChaCha20, for instance, which are widespread commercially, are not approved by any government certification.

These limitations are not flaws—they reflect trade-offs made to satisfy highly specific government threat models, which may or may not align with commercial operational priorities.

What are the benefits?

Why would a commercial customer want a product that has a government certification? What value is there when purchasing decisions aren’t affected by law? Reasons to consider products that are federally certified include:

1. Cryptography in the product has been well vetted for correctness and security.
2. Anything in scope of the certification has been independently tested and proved to work, at least in accordance with the evaluated configuration
3. The released version has no public vulnerabilities against it, at the time of the certification being issued, or there is a remediation plan in place to quickly patch those vulnerabilities
4. There is a reduced likelihood that hardware and software components in the product have been manipulated by anyone in a hostile country as HPE Aruba Networking only certifies TAA-compliant SKUs
5. All other HPE Aruba Networking product security programs still apply, ranging from our ever-improving software development lifecycle to constant red-teaming via Bug Crowd

HPE Aruba Networking uses software development lifecycle and secure software development best practices for its networking and network security products to help protect organizations from unnecessary exposure to risk.

It is important to note that the core value add of having a product run through independent testing holds true whether you operate it in an evaluated configuration or not. The lab may find additional quality issues that were not part of a QA test plan, for instance, during testing.

Assessing the added value of federal certifications

Whether a commercial enterprise will get any added value out of choosing a product with one or more federal certifications is a valid question. If the product isn’t going to be operated in accordance with the evaluated configuration, then it’s a moot question. But the customer should know what the evaluated configuration is before weighing the value of certification. Luckily, that information is public.

The information necessary to make an informed decision is publicly available. For HPE Aruba Networking network and network security products, you can find details online:

• HPE Aruba Networking FIPS module validations
• HPE Aruba Networking Common Criteria compliant product list (use the filter to view specifically HPE Aruba Networking products)

When assessing if the validated or evaluated configuration of a product is going to meet your needs, you’ll want to look at the FIPS Security Policy and the CC Security Target and User Guidance all of which are publicly available on the certification listings.

Mostly, you’ll want to check on whether any functionality could potentially break your ability to manage or interoperate the product, and if so, whether you have to configure it to be in that state or if it’s like that out-of-the-box. For example, if you have older wireless clients that can’t use the restrictive set of allowed WLAN settings, then you would want to take that into consideration. Either way, you would have to forego operating in the evaluated configuration, or you would need to upgrade the wireless clients.

Key takeaways: Network security, federal certifications, and you

While various federal certifications exist to meet specific government requirements, commercial customers benefit from quality and improved baseline security of a product that has been through the certification process. However, to achieve the full value of purchasing a certified product, it must be operated in the evaluated configuration. Commercial customers need to take more care in assessing whether that evaluated configuration is going to meet other business needs of their organization.

More information on HPE Aruba Networking network security products:

• Network security for U.S. Federal Government
• Network security for government
• HPE Aruba Networking and network security products with Common Criteria and other U.S. federal certifications