“Substantial” or “High”: Which EUCC Assessment Route Is the Product Requesting?
Choose an EUCC assurance level from intended use and risk, then confirm whether the ITSEF and certification body are competent for the product and route.
Signals to watch
- A named ICT product and version are approaching a procurement, release or certificate decision
- The requester says substantial or high but cannot yet connect the level to intended use, risk and a security target
- A proposed ITSEF or certification body may not have the competence or high-level authorisation needed for the product scope
Do not quote EUCC “high” merely because a buyer asked for the stronger-sounding label. First choose between substantial and high from the product’s exact target of evaluation, intended use and associated risk. Then make a second choice: whether the proposed Information Technology Security Evaluation Facility (ITSEF) and certification body are competent—and, for high, authorised—for that product scope and evaluation route. If either fork is unresolved, quote preliminary scoping rather than a certificate outcome.
This is the decision facing an EUCC conformity-assessment provider business-development lead who follows authorised Telegram groups used by ICT hardware vendors, software security teams, Common Criteria specialists, ITSEFs, certification bodies and European cybersecurity procurement teams. “Need EUCC high before the bid closes” is an urgent fragment, not a complete request. Seeing it one day late may mean missing the tender clarification, evaluator shortlist or a scarce planning slot with a suitably authorised provider. Seeing it early does not prove the product is eligible, the speaker controls its evidence or a certificate can be delivered by the requested date.
Definition: EUCC certifies one bounded ICT product
The European Common Criteria-based Cybersecurity Certification Scheme (EUCC) is the first EU cybersecurity certification scheme adopted under the Cybersecurity Act framework. ENISA describes EUCC as a voluntary scheme for certifying information and communications technology (ICT) products such as hardware, software and components. It uses Common Criteria, the security-evaluation framework reflected in ISO/IEC 15408, together with the Common Evaluation Methodology reflected in ISO/IEC 18045.
The assessed object is not “our platform” in the abstract. The request needs a target of evaluation: the exact product and version, including the boundary that will be described in the security target. The security target states the product’s security problem, objectives and requirements. Intended use matters because Regulation 2024/482 requires the applicant’s assurance-level reasoning to relate to the risks associated with that use.
EUCC does not certify an organisation’s whole security programme or establish compliance with every other EU law. It supplies a defined third-party assessment and certificate for the stated ICT product and assurance scope.
First fork: does the risk basis support substantial or high?
The names are not a maturity ladder that sales can choose for prestige. Regulation (EU) 2019/881, Article 52, distinguishes assurance levels by the degree of confidence and the sophistication of the attack considered. The EUCC implementing regulation turns those levels into a Common Criteria evaluation route and requires the certification body to assess whether the applicant’s selected level is commensurate with the intended-use risk.
| Same product question | Substantial route | High route |
|---|---|---|
| Risk claim | Seeks confidence against actors with limited skills and resources, following the scheme’s substantial-level requirements | Seeks confidence against skilled actors with significant skills and resources, under the additional high-level conditions |
| Vulnerability analysis | Maps to AVA_VAN 1 or 2 under the applicable Common Criteria assurance package | Maps to AVA_VAN 3, 4 or 5; levels 4 and 5 also trigger the scheme’s additional technical-domain, protection-profile, state-of-the-art or exceptional-authority conditions |
| Assessment provider | Accredited ITSEF evaluation and accredited certification body competent for substantial | ITSEF and certification body need the additional national-authority authorisation and scope required for high |
| Commercial output | Proposal based on the bounded product, security target, evidence and substantial evaluation path | Proposal only after the high route, technical capability, authorisation and sensitive-information handling can be evidenced |
This table is a sales scoping aid, not a certification decision. Evaluation Assurance Level (EAL) numbers and EUCC assurance levels are related through the declared assurance package, but they are not interchangeable labels. Do not convert “we used EAL4 before” into “EUCC high” without checking the current scheme, augmentation, AVA_VAN component and product scope.
When substantial is the defensible starting hypothesis
Substantial is a plausible starting route when the intended-use risk, security target and selected assurance components support that level, and when the requester is not relying on a technical-domain or protection-profile condition that moves the evaluation elsewhere. The evidence still has to survive third-party evaluation. “Substantial” does not mean self-assessment, a questionnaire-only review or an abbreviated certificate.
When high is worth investigating
High is worth investigating when the intended use and risk analysis support resistance against more capable attackers, the assurance package fits the scheme, and an authorised route exists. Technical domains and ENISA’s state-of-the-art documents can impose product-category-specific methods and tools. Their current scope must be checked.
Second fork: can these assessment bodies perform this route?
After selecting a provisional level, stop comparing labels and compare provider competence. EUCC separates testing from certification. The ITSEF performs security-evaluation activities; the certification body reviews the evaluation and handles the certification decision. The scheme requires these roles to operate independently even when they belong to the same conformity-assessment body.
For substantial, confirm that the ITSEF and certification body hold the relevant accreditation and are competent for the intended evaluation. For high, Regulation 2024/482 adds authorisation by the national cybersecurity certification authority. The published competence must cover the required assurance level, highest AVA_VAN level and, where applicable, technical domain. A laboratory’s experience with Common Criteria or an older national scheme is useful context, not proof that its current EUCC authorisation covers this product.
Ask for the official listing or notification, legal entity, role, accredited and authorised scope, technical domain, highest AVA_VAN capability and availability. A valid high authorisation for a smart-card technical domain does not automatically cover unrelated software.
Example: the buyer asks for “high” before a procurement deadline
Consider this illustrative composite thread; it is not a customer message or evidence of a real project:
“Buyer put EUCC high in the security annex. Bid questions close tomorrow.”
“Product is the new gateway build. We have an old CC report but the security target is still being updated.”
“Can the lab we used last time issue the EU certificate?”
The first fork is unresolved. The group has not identified the exact gateway build, intended deployment, risk rationale, security target or requested assurance components. “High” may be binding or shorthand; the provider must clarify it.
The second fork is also unresolved. The old report may provide reusable evidence, but it does not establish the laboratory’s current EUCC role, high authorisation or technical-domain competence. Freeze the evaluation target, recover the buyer’s wording, map existing evidence and verify the assessment bodies.
If those records support substantial while the tender truly requires high, the result is not “close enough.” The buyer must clarify or the product route must change. If the risk basis supports high but no appropriately authorised provider or methodology is available for the product and date, the honest answer is that the requested delivery cannot yet be quoted.
Key facts to keep in the proposal
- EUCC is voluntary under the certification framework; a procurement contract or another legal instrument may still make a particular certificate commercially necessary.
- The scheme uses third-party conformity assessment only. It separates ITSEF evaluation from certification-body review and decision.
- The applicant supplies the intended-use and risk analysis supporting its selected assurance level; the certification body assesses the appropriateness of that choice.
- State-of-the-art documents specify evaluation methods, techniques and tools for relevant assessment scopes and must be checked in their current versions.
- High assurance adds authorisation and peer-assessment arrangements beyond accreditation; competence must be verified for the actual scope.
- A certificate is tied to the identified product, version, security target and scope. Later changes may require impact analysis, maintenance or reassessment.
The adjacent CRA conformity-assessment article explains when a cybersecurity certification scheme can matter to a Cyber Resilience Act route; it does not make every CRA product an EUCC candidate. For evidence that originated under radio-equipment requirements, use the EN 18031, RED and CRA source-routing analysis instead of treating one report as a universal certificate file.
When the group fragment becomes a sales-ready request
Move the request into an assessment conversation when the exact product and decision date are known, the security target or protection-profile route can be named, the intended-use risk supports a provisional assurance level, and candidate assessment bodies have plausible competence for that route. Offer preliminary scoping when those records are recoverable but incomplete. Do not quote a certificate when “high” is an unsupported adjective, multiple versions are mixed together, or the requested provider’s competence cannot be verified.
TOP Prospect can identify and group these fragments in Telegram groups that the user deliberately connects and is authorised to access, preserve their original text, source and time, remove duplicates and explain why a dated request deserves earlier human review. It cannot choose an assurance level, inspect confidential product evidence, verify an assessment body’s authorisation, reserve an evaluator, contact the poster or promise certification. The business-development lead must confirm all of those facts with the requester and official records.
If authorised-group discovery itself becomes part of the service discussion, review the current TOP Prospect plans. The platform can make the two unresolved forks visible; only the applicant and competent assessment bodies can close them.
FAQ
Is EUCC high assurance always better than substantial?
No. The applicant must relate the chosen level to the product’s intended use and associated risk, and the certification body assesses whether that level is appropriate. A higher label without the matching risk basis and evaluation route is not a better scope.
Can a supplier self-assess under EUCC?
No. Commission Implementing Regulation (EU) 2024/482 allows only third-party conformity assessment under EUCC, with evaluation by an ITSEF and certification by a certification body.
Can every EUCC certification body issue certificates at high assurance?
No. High-assurance certification requires accreditation plus authorisation by the national cybersecurity certification authority, and the notified competence must cover the relevant scope. The associated ITSEF also needs the required high-level authorisation.
What should be known before asking for an EUCC quote?
Name the exact product and version, target of evaluation, intended use, risk analysis, security target or protection profile, requested assurance components, relevant technical domain, expected decision date and proposed ITSEF and certification-body route.
Frequently asked questions
Is EUCC high assurance always better than substantial?
No. The applicant must relate the chosen level to the product’s intended use and associated risk, and the certification body assesses whether that level is appropriate. A higher label without the matching risk basis and evaluation route is not a better scope.
Can a supplier self-assess under EUCC?
No. Commission Implementing Regulation (EU) 2024/482 allows only third-party conformity assessment under EUCC, with evaluation by an ITSEF and certification by a certification body.
Can every EUCC certification body issue certificates at high assurance?
No. High-assurance certification requires accreditation plus authorisation by the national cybersecurity certification authority, and the notified competence must cover the relevant scope. The associated ITSEF also needs the required high-level authorisation.
What should be known before asking for an EUCC quote?
Name the exact product and version, target of evaluation, intended use, risk analysis, security target or protection profile, requested assurance components, relevant technical domain, expected decision date and proposed ITSEF and certification-body route.
Sources and further reading
- Commission Implementing Regulation (EU) 2024/482 establishing EUCC, current consolidated text, accessed 12 August 2026
- ENISA: EU Cybersecurity Certification Scheme on Common Criteria (EUCC), accessed 12 August 2026
- Regulation (EU) 2019/881, EU cybersecurity certification framework, accessed 12 August 2026
How a Signal worth attention is found
See how Top Prospect finds and organizes Signals worth checking, keeps the original Telegram context, removes duplicates, and helps you decide what to review first. You decide whether to follow up and what to do next.
