FIPS, Common Criteria, and “Military-Grade”: How to Evaluate Security Claims

FIPS, Common Criteria, and “Military-Grade”: How to Evaluate Security Claims

Security buyers are flooded with labels: “FIPS,” “Common Criteria,” “certified encryption,” “military-grade.” Some are meaningful. Some are marketing. The only reliable approach is to treat these claims as verifiable statements with scopes, boundaries, and limitations.

This post explains how to interpret these terms and what questions to ask so you can compare products rationally.

Why certifications exist (and what they don’t do)

Certifications generally aim to provide independent assurance that:

  • A cryptographic module implements algorithms correctly

  • Keys are managed according to a defined security boundary

  • Certain security properties (like tamper response or role separation) are present

They do not automatically guarantee:

  • The product is secure in your environment

  • The implementation is free from all vulnerabilities

  • Your operational use won’t undermine the design

Certifications are inputs to a decision—not the decision.

FIPS: what it is, and what you should verify

FIPS typically refers to the FIPS 140 series (security requirements for cryptographic modules). Two critical points:

  1. FIPS applies to a cryptographic module, not “the whole product” in a vague sense.

  2. A claim is only meaningful if you can identify what is validated and at what level.

How to evaluate a FIPS claim

  • Ask for the exact validation identifier and the validated module name.

  • Confirm which components are inside the cryptographic boundary (e.g., secure element, firmware module).

  • Check whether the device is claiming “designed to meet” vs “validated.”

Practical interpretation

  • FIPS validation can be valuable for regulated environments and procurement requirements.

  • It does not replace threat modeling, secure firmware practices, and operational controls.

Common Criteria: what it is, and what “EAL” does (and doesn’t) mean

Common Criteria (CC) is a framework for evaluating security properties against a defined target. Key concepts include:

  • Security Target (ST): what exactly is being claimed and evaluated

  • Protection Profile (PP): a reusable set of requirements for a product category

  • EAL (Evaluation Assurance Level): how rigorous the evaluation process was

How to evaluate a Common Criteria claim

  • Ask for the Security Target and what it covers.

  • Identify whether evaluation is against a relevant Protection Profile.

  • Treat the EAL number as secondary to scope: a high EAL on a narrow target can be less useful than a modest evaluation that covers what you actually deploy.

“Military-grade”: a marketing term unless tied to specifics

“Military-grade encryption” is not a standardized certification by itself. Sometimes it loosely implies:

  • A well-known algorithm (often AES)

  • A key size (often 256-bit)

  • Possibly a ruggedized physical build

But algorithm names and key sizes alone are not a security system.

How to force clarity
When you see “military-grade,” translate it into verifiable questions:

  • Which algorithms and modes are used (e.g., AES-GCM vs AES-CBC)?

  • How are keys generated and protected?

  • What prevents brute force on the unlock factor?

  • What tamper resistance exists?

  • How is firmware integrity ensured?

If the answer is vague, the term is doing marketing work, not security work.

A practical scorecard for evaluating claims

Use a simple scorecard across five dimensions:

  1. Cryptography (what algorithms, how implemented)

    • Strong algorithms are table stakes

    • Implementation correctness and mode selection matter

  2. Key security (where keys live, how protected)

    • Can keys be extracted?

    • Is there a secure boundary?

    • Is recovery secure?

  3. Authentication and policy enforcement

    • Rate limiting and lockout

    • Admin controls and role separation

    • Default credentials avoided

  4. Device and firmware integrity

    • Secure boot

    • Signed updates

    • Vulnerability disclosure and patch discipline

  5. Operational fit and evidence

    • Inventory and provisioning

    • Cross-platform behavior

    • Audit artifacts and admin tooling

Procurement questions that cut through ambiguity

  • “What is the cryptographic boundary and what components are validated/evaluated?”

  • “Do you have a published Security Target or validation details?”

  • “How is brute force prevented at the hardware level?”

  • “Are firmware updates signed and verifiable? What is your advisory process?”

  • “What happens on tamper detection or repeated failed unlock attempts?”

  • “Can I export configuration evidence for audits?”

Bottom line

Certifications and labels can be useful—but only when you treat them as scoped claims tied to specific artifacts. If you can’t validate the scope, you can’t rely on the label. Evaluate the system: cryptography, keys, authentication, firmware integrity, and operational governance.