Common Criteria Certification: A Startup Founder’s Guide

Common Criteria certification is independent proof that a lab has verified your product’s security claims against a published standard. It is not a seal that says the product is secure. In the U.S., you get it by having an accredited lab evaluate the product against a NIAP-approved Protection Profile. In Europe, you go through the EUCC scheme. Below we cover how each route works, what the process looks like, where startups get stuck, and how to decide whether it is worth it for you now.

TL;DR

• Common Criteria (ISO/IEC 15408) lets an accredited lab verify the security claims you make about your product. It verifies claims. It does not guarantee security.
• In the U.S., NIAP only accepts products that claim compliance to a NIAP-approved Protection Profile, so the old “pick an EAL” approach no longer applies.
• In the EU, the EUCC scheme has been applicable since February 27, 2025, and replaces the older national SOG-IS arrangement.
• A certificate covers the version you tested. Plan for changes to your code before you start, not after.
• Certify when a buyer, a regulation or a procurement list requires it. Otherwise, build evidence and credibility first.

Table of Contents

• What Common Criteria certification actually is
• The key terms, in plain words
• The U.S. route: NIAP and Protection Profiles
• The European route: EUCC
• Mutual recognition: one evaluation, several markets
• Keeping the certificate alive
• Is it right for your startup right now?
• Our perspective
• Where we can help
• FAQ
• Sources

What Common Criteria certification actually is

The Common Criteria for Information Technology Security Evaluation, together with its companion evaluation methodology, is the technical basis for an international agreement, the Common Criteria Recognition Arrangement (CCRA). The standard is published as ISO/IEC 15408, and the current version is CC:2022.

The logic is simple. You, the developer, state what your product does for security. That product is called the Target of Evaluation (TOE). An independent, accredited laboratory then checks those claims against the standard. A government scheme oversees the lab and issues the certificate.

The result is a chain of evidence, not a guarantee. A certificate tells a buyer that someone independent tested what you claimed. It does not tell them your product is free of flaws or right for their environment. Procurement teams in government and critical infrastructure still ask for it, because it gives them a defensible, comparable record.

The key terms, in plain words

Founders often read EALs as a universal quality ranking. They are not one. The levels describe how much assurance work was done, not how good the product is, and the market has moved toward proving conformance to a specific Protection Profile instead. NIST’s laboratory accreditation policy already reflects that shift away from generic EAL-based evaluation.

The U.S. route: NIAP and Protection Profiles

In the United States, the National Information Assurance Partnership (NIAP) runs the national scheme. Its own site states that any product accepted into evaluation must claim compliance to a NIAP-approved Protection Profile. That has a practical consequence: before anything else, you check whether an approved PP exists for your type of product.

If one does, you build your claims around it. If none fits, you have a real problem. You cannot simply choose a generic assurance level and proceed, so you may need to wait for a profile, look at a different scheme, or rethink whether certification is the right tool at all.

How an evaluation runs

NIAP describes the evaluation process in a few steps, and they are a good skeleton for your own plan:

1. Choose the Protection Profile that matches your product class.
2. Choose an approved testing lab. You contract with the lab, not with the government.
3. Draft the Security Target. You write it, possibly with help from the lab.
4. Deliver the TOE to the lab. That means the product build, documentation and access to what the evaluators need.
5. The lab proposes the evaluation to NIAP. Once accepted, the work runs under NIAP oversight and validation.
6. Approval and listing. On success, the product appears on the NIAP Product Compliant List and on the Common Criteria Portal.

We will not quote you a cost or a duration. Neither the NIAP pages nor the other sources we reviewed publish a reliable figure, and both depend heavily on product complexity, documentation quality and lab workload. Ask two or three labs for written scoping quotes against your specific PP before you put a number in a financing plan.

Why the lab work is evidence work

Evaluators will ask you to show, not to tell. Design documents, test records, vulnerability handling, build and configuration management: all of it has to be reproducible and traceable. Startups that keep clean engineering records move through this quickly. Startups that rebuild their history from memory do not.

That is also where digital forensics thinking helps. A claim backed by logs, hashes and an auditable trail is much easier to defend in front of an evaluator, a buyer or a court than a slide that says “secure by design”.

The European route: EUCC

If you sell in Europe, the picture is different. The EUCC scheme, the European Cybersecurity Certification Scheme on Common Criteria, became applicable on February 27, 2025. It is voluntary and EU-wide, and it replaces the earlier national SOG-IS approach. It defines two assurance levels, substantial and high, which map to the vulnerability assessment classes of Common Criteria.

Two details matter for a startup:

• Private certification bodies can now issue certificates. Under the old arrangement, only public bodies could. ENISA’s note on the first EUCC certificate at the substantial level, issued in July 2025 from Spain, points to a private certification body doing exactly that. More options can mean more competition on timelines and service.
• Levels replace the old EAL habit of thinking. You should map your target market’s expectations to “substantial” or “high” rather than to a number you saw in an older datasheet.

For a deeper look at how European rules interact with U.S. requirements, read our guide to NIS2 and U.S. compliance for security vendors.

Mutual recognition: one evaluation, several markets

The CCRA is the reason an international startup can consider certifying once. A product certified in one member country can have that certificate recognized by other members. Canada’s national authority explains the arrangement on its Common Criteria page. It can reduce redundant testing.

Recognition has limits. Which certificates a given buyer accepts, and up to which assurance level, depends on the member’s rules and the buyer’s procurement policy. Before choosing a scheme, ask your target customers which certificates they will actually accept. In the U.S. in particular, the PP requirement shapes what is useful to a federal buyer.

Keeping the certificate alive

Most founders plan for the evaluation and forget the maintenance. A certificate applies to the version that was tested. If your team ships weekly, a certified build can be out of date within a month.

The CCRA addresses this with Assurance Continuity, a recognized approach to maintenance, re-evaluation and re-assessment. In short, for changes that do not touch the core security baseline, you can document the impact rather than start over. Larger changes may require a re-evaluation.

Three habits make this manageable:

• Freeze a certified branch. Keep a hardened release line separate from your fast-moving main branch.
• Classify changes. Write a simple rule for which changes touch security functions and which do not.
• Keep the paper trail current. Impact analyses are far easier to write the week of the change than a year later.

Is it right for your startup right now?

Certification is a market-entry tool as much as a technical one. Use these questions before you commit.

Does a named buyer or rule require it? Government, defense and critical-infrastructure deals often do. If a prospect has put it in writing, the case is strong. If you only hope it will impress someone, it is weak.

Does a Protection Profile exist for your product? In the U.S. this can decide the question on its own.

Is your product stable enough? A product that changes architecture every quarter will struggle to hold a certificate.

What else could earn the same trust faster? Depending on your buyer, you might first need a different credential, such as a cloud authorization or a maturity model. Our overview of FedRAMP and CMMC basics for foreign cybersecurity vendors covers the two most common ones. For the broader picture, see our U.S. compliance checklist for foreign cybersecurity startups.

Other product security certifications to know

Common Criteria is one of several routes, and they overlap less than people assume. Cryptographic modules are generally evaluated under a separate program, a point NIAP’s FAQ touches on. For connected devices and IoT, the standards landscape is moving toward harmonization. The Connectivity Standards Alliance tracks product security work in this area, and AI and IoT founders should watch how Common Criteria lines up with standards such as IEC 62443 and ETSI EN 303 645.

Our perspective

We are an accelerator focused only on digital forensics for cybersecurity and AI startups, so we look at certification through one lens: evidence. Common Criteria works because it turns a claim into something an independent party can check. That is the same reason forensic-grade evidence matters to buyers.

We see two mistakes in founders. The first is treating certification as a badge to buy before the product is ready. The second is the opposite: ignoring formal evidence until a large buyer asks for it and the deal is already slipping. The better path is to build evidence habits early: reproducible builds, tamper-evident logs, clear documentation of what the product does and does not do. Then certification, if you need it, is a packaging exercise instead of a rescue mission.

The other half of the work is translation. An evaluator, a procurement officer and an investor each want a different version of the same story. Part of our job is helping founders tell it in business terms without losing the technical truth.

— Thiago Vieira

Where we can help

If you are a non-U.S. company weighing certification as part of a U.S. launch, or a U.S. company looking at Europe, our Soft Landing program combines structured market entry, compliance and local setup, and introductions to potential partners. You can also read our U.S. market entry checklist for cybersecurity startups to see where certification fits in the sequence. We do not run evaluations ourselves. We help you decide what to pursue, in what order, and how to present it to buyers and investors.

FAQ

What is the difference between Common Criteria and EUCC?

Common Criteria is the international standard and the mutual recognition arrangement. EUCC is the EU certification scheme built on that standard. It has applied since February 27, 2025, and offers substantial and high assurance levels. A certificate under it is issued within the European framework rather than a national one.

Can I choose any assurance level in the U.S.?

Not in the way older guides suggest. NIAP only accepts products into evaluation that claim compliance to a NIAP-approved Protection Profile. Your first task is to find the profile that matches your product class and build your claims on it.

Does certification mean my product is secure?

No. It means an independent lab verified the claims you made, for a specific version, under defined conditions. Buyers value it as a chain of evidence, but it is not a guarantee against vulnerabilities.

What happens when I update my product?

A certificate covers the tested version. For changes that leave the core security baseline intact, the Assurance Continuity process lets you document the impact instead of redoing everything. Bigger changes can require re-evaluation, so ask your lab early which changes trigger which path.

Sources

• Common Criteria for Information Technology Security Evaluation
• laboratory accreditation policy
• any product accepted into evaluation must claim compliance to a NIAP-approved Protection Profile
• evaluation process
• EUCC scheme
• first EUCC certificate at the substantial level
• Common Criteria page
• maintenance, re-evaluation and re-assessment
• tracks product security work

Recommended

• ISO 27001 for Startups: Build the Lean ISMS Procurement Demands
• SOC 2 vs ISO 27001 for Startups: Map Once, Choose by Buyer