The 12 Red Flags We Look for in a Vendor's Certified-Product Bid

A vendor sends you a single line of marketing copy. “Common Criteria EAL4+ certified.” “EUCC High.” “SESIP Level 3.” If that sentence lands in your procurement scorecard untouched, you are about to buy a security product on the strength of a checkbox. The certificate is being asked to do the work of evidence, and the bid is hoping you will let it.

This is a checklist post. It expands the twelve procurement red flags we work through on every buyer-side engagement at Nenkin Technologies AS. Each item is a pattern that has, at some point, turned what looked like a clean certified bid into a procurement that needed material rework. The examples are deliberately generic. The point is the pattern, not the vendor.

A note on where the list comes from. Co-founder Kjartan Kvassness Jaeger spent six years (2012 to 2018) as Technical Manager of the Norwegian Common Criteria certification authority and represented Norway in the Common Criteria Development Board, the SOG-IS Joint Interpretation Working Group, and ISO SC 27/WG3. He continues evaluation and certification work inside the Dutch government Common Criteria scheme through Scandicert AS. The catalogue below is what 20+ years of reading Security Targets and Evaluation Technical Reports from the certifier’s chair teaches you to look for once the same gaps keep opening up in different product categories.

For the broader reference, the Common Criteria procurement guide collects lifecycle states, contract clauses, and verification steps in one place. The companion buyer-side ST read is in reading a Security Target as a buyer. This post is the field checklist.

1. The certified TOE does not match the product SKU

The Target of Evaluation is the precise configuration that was evaluated. A certificate covers exactly the TOE named in the Security Target, almost never the whole vendor catalogue. Sibling SKUs, regional variants, optional cards, later firmware revisions: each one sits outside the certified perimeter unless a maintenance report explicitly extends assurance to it.

We have reviewed bids in which the vendor’s response cites a certificate covering firmware 2.4 on hardware model A, while the proposed delivery is firmware 3.0 on hardware model B. At face value that is an uncertified product. Either the vendor can point at the maintenance trail that extends the certificate to your SKU, or the assurance claim does not apply to what they are actually selling. There is no third option, and the procurement team is the only line of defence: the certifier cannot see into your purchase order, and the lab signed off on the SKU on the certificate, not the SKU on the quote. See how to read a Common Criteria certificate for the field-by-field walkthrough.

2. Operational environment assumptions do not match your deployment

Every Security Target lists assumptions about the world around the TOE: physical access control, trusted administrators, network isolation, key management procedures, sometimes anti-tamper conditions on the room the appliance lives in. The certificate’s claims only apply when the deployment satisfies those assumptions. Strictly. The CC standard is explicit on this; an evaluator cannot certify against a deployment they cannot see.

Take a hypothetical network appliance whose ST assumes the management interface sits on an isolated administrative network. Deployed inside a flat network reachable from a general-purpose user VLAN, the assurance claims simply do not bind. The vendor has not lied. The buyer has applied the product outside its certified envelope. Read the assumptions section of the ST and either confirm the deployment satisfies each one, or document the gap as a compensating-control requirement before signature. This is the one red flag the buyer is best placed to spot, because the buyer is the only party who knows the deployment in detail.

3. Security Target scope is narrower than the marketing claim

“EAL4-certified” in a brochure can mean the product has an EAL4 certificate covering specific modules while the rest of the feature set is explicitly excluded from the evaluation. The Security Target is authoritative; the brochure is not.

The Security Targets we have read across smart cards, network equipment, and IoT platforms tend to follow a similar pattern: the certificate covers, for example, the cryptographic module and the secure boot path, while the application layer, the management UI, and third-party integration adapters are scoped out. The vendor can truthfully say the product is EAL4-certified. The buyer who needs assurance over the application layer learns at deployment time that the certificate does not cover what they were buying it for. The check is mechanical and cheap: open the ST, read the TOE description, and confirm that each functional requirement in the procurement specification maps to a clause that places the requirement inside the TOE.

4. The certificate is in surveillance, suspended, archived, or expired status

Certificates move through lifecycle states. A product that was once certified can still be on the vendor’s marketing page well after the certificate has entered surveillance, been suspended, been archived, or has lapsed. The certificate validity reference covers the state machine: active, surveillance, suspended, archived, withdrawn, expired.

Verify the live status at procurement time, not the status at the date the marketing copy was last edited. The scheme registry is the source of truth, and the vendor’s data sheet is downstream of it by however many months. NenkinTracker mirrors and indexes the registry across CC, EUCC, SESIP, PSA Certified, EMVCo, ESA, and MIFARE, which collapses the multi-portal walk into a single lookup. A bid that quotes a certificate identifier without naming its current lifecycle state has left the buyer to do the registry work. Doing it is fine; finding out the certificate has been suspended is not.

5. Optional features you need are outside the evaluated configuration

Many evaluations explicitly exclude optional functionality from the TOE. Cloud sync, remote-management plug-ins, federation adapters, performance-tier accelerators, vendor-specific integration kits: any of these can sit outside the evaluated configuration while still shipping in the same SKU. From the certifier’s chair, you watch these exclusions happen during evaluation. Optional features that turned out to be hard to evaluate get carved out and the carve-out lands quietly in the ST.

The pattern that catches buyers: the procurement requirement is specifically for feature X, the ST excludes feature X from the TOE, and the bid response asserts the certificate covers the product. Both statements can be true and still leave the buyer outside the assurance perimeter for the exact reason they bought the product. Require the vendor to map each functional requirement in the specification back to a clause in the ST that places the requirement inside the TOE. If a requirement maps to an excluded feature, the certificate is not doing the assurance work the bid implies it is.

6. Composite certifications depend on a component certificate that is no longer valid

Java card platforms, applets, IoT platforms with separately certified Roots of Trust, and SESIP composite certificates depend on a chain of underlying certificates. See composite certifications for the structure. The composite claim is only as strong as the weakest in-date component. A lapsed underlying certificate quietly invalidates the composite claim without any change to the composite document itself.

Imagine an applet certificate that explicitly composes onto a specific java card platform certificate. If the underlying platform certificate has since been archived, the composite is operating outside its assurance basis even though the applet’s own certificate page still reads “active”. From the certifier’s side, you watch these chains because a lapse anywhere quietly invalidates the top. From the buyer’s side, the top-level certificate looks active and the chain is invisible. Composite chains have to be walked, not glanced at. Chain documentation lives in the Security Target and the Certification Report; live status lives in the issuing scheme’s registry; both have to agree.

7. EAL augmentations are dropped from cross-vendor comparisons

EAL4 and EAL4+ALC_DVS.2+AVA_VAN.5 look almost identical when a buyer’s evaluation matrix has a column called “Assurance Level” and a free-text cell underneath. The plus sign carries weight, and the components after it carry the actual difference in evaluation depth. See EAL augmentations for the full picture, and the dedicated post on why “EAL4” and “EAL4+” are not the same for the procurement-side argument.

When the comparison is flattened to bare EAL numbers, products that paid for the augmentations get under-credited, and products that did not get over-credited. The right specification names the augmentation, not just the level: “EAL4 augmented by AVA_VAN.5 and ALC_FLR.2 minimum” is procurement-grade; “EAL4+ minimum” is not. We rebuild bid-comparison matrices on every engagement to expose the augmented components explicitly, then weight them against the threat model.

8. Vulnerability assessment depth (AVA_VAN) is below the threat model

The AVA_VAN family runs from AVA_VAN.1 through AVA_VAN.5. Each level describes a more capable attacker the evaluator simulated against the TOE. A smart card defending against well-funded laboratory attackers needs AVA_VAN.5. A back-office product in a controlled-physical environment can live happily at AVA_VAN.2. The right level is driven by the threat, not by the vendor’s certification budget.

The red flag is mismatch, not low value per se. A payment terminal operating unattended in a retail setting and accepting AVA_VAN.2 is under-specified, because the deployment context exposes it to attackers the evaluator never simulated. An internal-network appliance demanding AVA_VAN.5 is over-specified, and will have a shorter vendor list than it needs at no real gain in residual risk. Pick the AVA_VAN level from the threat model in the operational specification, not from a generic procurement template.

9. The issuing scheme is not Certificate Authorizing under CCRA, or is consuming-only

Not every national scheme can issue mutually recognised CCRA certificates. Some are consuming-only: they accept certificates issued by Authorizing Participants but do not themselves issue mutually recognised certificates. EUCC adds another layer for EU procurements: certificates under EUCC are EU-side artefacts that interact with the CCRA framework on specific terms. See EUCC vs CCRA for the current picture and protection profiles for how cPP conformance changes recognition above EAL2.

For a buyer this matters when the procurement is cross-border, when the bid references an unfamiliar scheme, or when a national procurement framework requires a specific issuing authority. Confirm both that the issuing scheme is authorised to issue the certificate at the assurance level claimed, and that the certificate’s jurisdiction matches the procurement requirement. A perfectly good certificate issued by the wrong scheme can still leave the buyer without the recognition they assumed they were paying for.

10. Maintenance updates have not been processed after major releases

Assurance continuity requires the vendor to file impact analyses and Maintenance Reports with the issuing scheme after material changes to the product. If a firmware or software major version has shipped without a corresponding maintenance record, the certificate has drifted from the live product. The certificate page may still say “active”, but the product the buyer is receiving is no longer the product that was evaluated.

The check is mechanical. List the product versions released since the certificate was issued. For each material release, ask the vendor to point at the maintenance report that extends assurance to it. If a release is unaccompanied by a maintenance filing, decide explicitly whether to accept the gap, ask the vendor to file the maintenance, or treat the procurement as buying an uncertified version of a once-certified product. None of those choices is necessarily wrong. Making the choice unconsciously, by failing to check, is.

11. Patching SLAs and re-evaluation triggers are not in the vendor contract

A certificate is a point-in-time attestation. A procurement contract binds the vendor for the lifetime of the deployment, which can run five to ten years past the original certificate date. Patching commitments, vulnerability-disclosure obligations, end-of-support dates, replacement obligations on certificate lapse, and re-evaluation triggers belong in writing before signature, not in goodwill afterwards.

We see contracts that lift the certificate identifier and the EAL into the schedule of deliverables, and then say nothing about what the vendor commits to do when a new vulnerability lands, when the certificate is suspended for surveillance, or when a major release ships without a maintenance filing. The certificate has done its job; the contract has not done its. The procurement-advisory deliverable here is a clause set that turns the certificate from a marketing claim into an enforceable assurance commitment. The Common Criteria procurement guide has the longer treatment of which clauses tend to matter.

12. Known CVEs against the certified product are not acknowledged in the vendor’s response

Public vulnerability data exists for many certified products. NVD, vendor advisories, and the issuing scheme’s own impact analyses are searchable. A bid response that does not surface relevant CVEs, or cannot describe how each is mitigated in the certified configuration, is showing the buyer something about how the vendor will handle the next vulnerability too.

The red flag is not the existence of CVEs. Every interesting product has them. The red flag is silence. A credible bid includes a CVE position: which CVEs are known against the certified product, which apply to the certified configuration, what mitigations or patches are in place, and what the vendor’s process is for new CVEs disclosed during the contract period. A vendor that engages with the question is showing you the muscle they will use when something lands during the contract. A vendor that does not is showing you the absence of one.

How to run these checks during bid evaluation

The twelve patterns do not need a formal stage gate. In practice we work through them in three passes.

The first pass is certificate-and-TOE. Look up the certificate identifier in the issuing scheme’s registry and in the NenkinTracker certifications database. Confirm the lifecycle state against the issuing scheme’s record. Read the TOE description in the Security Target and check it covers the SKU being offered. Walk the composite chain if one exists. That single pass catches red flags 1, 3, 4, 6, 9, and 10.

The second pass is fit-to-deployment. Read the assumptions section of the Security Target, the optional-feature exclusions, and the AVA_VAN level. Compare each one against the procurement specification, not against the vendor’s brochure. That catches red flags 2, 5, 7, and 8. This is the pass that requires somebody who knows the deployment in detail, which usually means a procurement engineer working with the operational team that will run the product, not procurement on its own.

The third pass is contract-and-CVE. Pull the public CVE record for the certified product, including the Nenkin CVE view for cross-scheme aggregation. Compare the vendor’s response against the contract clauses you expect: patching, maintenance, re-evaluation, replacement. That catches red flags 11 and 12.

None of the three passes requires the buyer to be a certification specialist. Each requires somebody who can read the Security Target against the procurement specification as two parallel statements of what the product is supposed to do.

How NenkinTracker helps you run the first pass

The certificate-and-TOE pass is where the buyer most often runs out of patience, because it crosses up to seven scheme portals (CC, EUCC, SESIP, PSA, EMVCo, ESA, MIFARE) with different formats, different lifecycle conventions, and different update cadences. NenkinTracker indexes and continuously refreshes all of them in one place. The certifications database supports search by vendor, product, scheme, EAL, augmentation, and lifecycle state; the expired-certificates report catches the marketing-page-versus-registry gap; and the Common Criteria Portal alternative comparison shows where the indexed view goes beyond what the public CC Portal exposes today.

If you have a bid in front of you and want an independent read before signature, that is what the procurement advisory service line is for. The deliverables, the engagement model, and the credentials behind the work are on the service page. Buyer-side only: we do not represent both sides of a transaction, do not take vendor referral fees, and do not hold exclusive distribution arrangements. The recommendation you get is the recommendation we would give if we were spending the budget.

Email [email protected] with “Procurement advisory” in the subject line. Share the product category, the deployment context, and the rough timeline, and we will come back with an honest scoping read, including whether procurement advisory is the right shape of engagement for what you are buying.