Certification confirms a result — and increasingly, it's how trust gets explained, down to its basis and scope
From Confirming a Result to Verifying a Trust Structure
▲ img source: Generated with ChatGPT
Security certification is the process of confirming that a product meets a defined set of security requirements, then documenting that result with formal marks and paperwork. But it has always done more than that: by evaluating a product's design, implementation, and development process, certification also builds the evidentiary basis for trusting it.
That second role matters more now that quantum-driven cryptographic risk, AI-assisted attacks, advanced persistent threats (APT), and supply chain intrusions all have to be weighed together. Throughout this piece, we call that combined threat environment QAAS — Quantum, AI, APT, Supply Chain. Within QAAS, certification is no longer just a checkbox against a fixed bar; it helps clarify exactly under what conditions, and within what scope, trust was actually verified.
That distinction is central to understanding PAZI, ICTK's trust architecture built on PQC, AI, Zero-Trust, and strongID. The trust PAZI aims for needs a technical explanation backed by verifiable evidence, and it has to hold up against institutional and policy requirements too. High-assurance certification sits exactly at that intersection.
Why High-Assurance Certification Is Getting a Second Look
In a QAAS environment, attacks increasingly combine automation with long-dwell persistence. AI can automate parts of an attack chain; supply chain attacks can hijack the distribution channels of legitimate products and updates; and APTs are defined by their ability to maintain access while evading detection over extended periods — which is exactly why they demand sustained response, not a one-time fix.
In this environment, the claim "this product is secure" doesn't carry much weight on its own. What matters is what assumptions a product was designed under, and how far those assumptions have actually been verified. Security certifications and cryptographic module validations exist to answer exactly that question — each within the criteria and evaluation scope defined by its own scheme.
CC (Common Criteria) — Evaluating Design and Implementation Together
Common Criteria (CC) is the international framework for evaluating the security of IT products and systems, corresponding to ISO/IEC 15408. In practice, "CC certification" means an independent evaluation lab assesses whether a product meets the security functionality and assurance requirements defined under CC, and a certification body confirms that result. Because it gives different countries a shared basis for evaluating security, CC sees genuinely international use.
CC evaluation goes well beyond functional testing. It weighs a product's design and implementation against the threats, assumptions, and security requirements spelled out in its Security Target — not just what security functions it claims to have.
CC defines Evaluation Assurance Levels from EAL1 through EAL7. Each EAL is a bundle of assurance requirements, and higher levels demand deeper, more rigorous evaluation — more scrutiny of development practices, design documentation, testing, and vulnerability analysis. A given EAL doesn't, by itself, qualify a product for use in any particular industry; the security functionality and assurance level a deployment actually needs should be judged against the relevant procurement criteria and the evaluation's specific scope.
That distinction carries real weight in a QAAS environment. Attackers often go after the gap between implementation and operations, so it's worth confirming that design, implementation, and verification genuinely line up. But a certification result is an assurance statement about a specific, named target of evaluation under specific conditions — not a blanket guarantee against every threat that might surface in operation.
FIPS 140-3 — A Practical Trust Baseline for Cryptographic Modules
FIPS 140-3, NIST's U.S. standard for cryptographic module security requirements, evaluates the module as a whole rather than testing an individual algorithm's implementation in isolation. That distinction matters in a QAAS environment: even a strong algorithm can't hold up if the process around generating, storing, and using its keys isn't secure.
FIPS 140-3 defines four security levels, Level 1 through Level 4, with requirements getting stricter at higher levels across areas like physical security, authentication, and sensitive security parameter (SSP) management. The specifics depend on the security area and module type in question. This is already playing out in the market — Axis Communications, for one, has marketed equipment built around FIPS 140-3–validated security components to government customers. It's worth keeping the scope of what was actually validated — the cryptographic module — distinct from the security of the device as a whole.
Also worth noting: NIST's list of CMVP-approved security functions is gradually absorbing post-quantum cryptography (PQC) standards, including ML-DSA (FIPS 204). The SP 800-140C supplemental page specifically lists ML-DSA and SLH-DSA (FIPS 205) among approved functions — a sign that PQC is moving past pure standardization and into the module validation process itself. Still, it's worth separating two distinct facts: an algorithm appearing on an approved list, and an individual module implementing that algorithm actually passing validation.
KCMVP — South Korea's Cryptographic Module Validation System
KCMVP (the Korea Cryptographic Module Validation Program) is South Korea's domestic scheme for validating the safety and implementation conformance of cryptographic modules deployed on government and public networks — protecting non-classified official data carried or stored on national information and communication networks.
KCMVP splits modules into four security levels because the protection a module needs depends on the sensitivity of the data it handles and the environment it runs in. A facility with controlled physical access and one where outsiders can walk straight up to the equipment call for very different physical-security conditions. To address exactly that variation, the cryptographic module security requirements standard, KS X ISO/IEC 19790, defines four security levels, with higher levels requiring stronger protective measures built into the module itself.
The dividing line isn't algorithm strength alone — it's how rigorously the module protects its cryptographic functions and keys. Evaluation spans module specification and interfaces, roles/services/authentication, software and firmware security, the operational environment, physical security, non-invasive security, SSP management, self-tests, life-cycle assurance, and mitigation of other attacks. Here's a summary of the key differences:
KCMVP Security Levels 1–4 at a Glance
| Category | Level 1 | Level 2 | Level 3 | Level 4 |
|---|
| Nature of the level | Baseline security requirements | Stronger authentication and physical security | Stronger identity verification, physical security, and SSP protection | Highest level of protection |
| Operator authentication | No authentication mechanism required | Role-based authentication | Identity-based authentication | Multi-factor authentication |
| Access control | Services performed per role | Access per authenticated role | Access tied to verified individual operator identity | Access requiring multiple independent authentication factors |
| Physical security | Baseline physical security | Enhanced, including tamper evidence | Enhanced detection of and response to physical tampering | Enhanced detection of and response to unauthorized physical access from any direction |
| Sensitive Security Parameters (SSPs) | Baseline SSP management/protection | Stronger than Level 1 | Enhanced protection for plaintext SSP input/output, etc. | Strong protection, including zeroization of unprotected SSPs upon detecting unauthorized physical access |
| Environmental conditions | — | — | Protection (EFP) or testing (EFT) against abnormal voltage/temperature | Protection (EFP) against abnormal voltage/temperature |
| Fault induction | — | — | — | Protection against fault induction |
| Defining trait | Baseline module security | Role authentication + tamper evidence | Individual identification + tamper response | MFA + the highest level of physical/environmental protection |
Note: A "—" doesn't mean no requirements apply at that level — it means the specific enhanced requirement that defines a higher level doesn't apply there.
These level-by-level differences apply according to module type and security area, so any real deployment decision should weigh the overall security level alongside area-by-area evaluation results and operating conditions. Whether a higher level is actually warranted depends on the sensitivity of the data being protected, how accessible the equipment is, the threats anticipated, and the operating environment. Rather than mapping neatly onto a specific industry or data classification, a security level is best understood as a way to choose the protective measures a given environment actually needs.
In a QAAS environment, it matters to build a security architecture around each system's threats, operating conditions, and the sensitivity of the information it protects. Where stronger security requirements apply, it's worth evaluating whether KCMVP's higher security levels can be put to use — while still confirming the relevant procurement criteria, module type, validation scope, and operating environment for that specific system.
National vs. Commercial Cryptography — A Moment to Reassess How Each Gets Used
At the national level, which cryptographic technologies and products can be used depends on the sensitivity of the information being protected and the regulatory scheme that applies. Reassessing how these technologies get used means weighing not just the required security level and validation process, but also development and adoption timelines, ongoing maintenance, and scope of application.
A useful reference point here is the U.S. National Security Agency's CSfC (Commercial Solutions for Classified) program, which layers validated commercial products together according to defined Capability Packages to protect classified information on National Security Systems (NSS). Separately, the CNSA (Commercial National Security Algorithm) Suite is the set of approved cryptographic algorithms NSA has defined for protecting NSS, with CNSA 2.0 setting requirements for the transition to quantum-resistant algorithms. CSfC — a program for using commercial products — and CNSA — an algorithm standard — play distinct roles.
This case illustrates one approach: using validated commercial technology within a defined security architecture and regulatory framework. Whether, and how, that translates domestically has to be assessed separately, against Korea's own information classification system, security policy, and validation framework.
PAZI and High-Assurance Certification — Why They Belong Together
ICTK's PAZI Architecture is an approach that brings hardware roots of trust, cryptographic key protection, device identity, and continuous trust verification together at the architecture level. Among these, key protection and authentication are also elements CC, FIPS 140-3, and KCMVP each treat as significant — within their own respective purposes and scope.
The components presented as part of PAZI — a PUF-based (Physically Unclonable Function) hardware root of trust (HRoT), a cryptographic structure built with post-quantum cryptography (PQC) in mind, continuous attestation of trust state, and Zero-Trust paired with strong device identity (strongID) — are technical elements worth considering when designing a trust architecture. Exactly how each of these maps to a given certification's requirements has to be confirmed against the implementation and evaluation scope of the specific product or module in question.
PAZI and high-assurance certification are best understood as complementary, sitting at different layers: one a technical trust architecture, the other institutional verification. Adopting an architecture, on its own, doesn't mean certification requirements are met or a specific level has been achieved — that determination requires evaluating and validating the actual product or module.
Conclusion — In the QAAS Era, Certification Is Evidence for a Trust Structure
In the QAAS era, security certification serves as important evidence for answering one specific question: where does this system's trust actually begin, and how far has it been verified? Understanding a certification result means looking at the target of evaluation, the criteria applied, the operating conditions, and the validation scope together.
PAZI Architecture is an attempt to design that trust structure technically. Evaluation and validation under CC, FIPS 140-3, and KCMVP are separate processes that confirm whether a given implementation meets defined security requirements. When technical design and institutional validation come together, the explanation of trust itself rests on more concrete ground.
See For Yourself
☑️ Curious about ICTK's PQC- and PUF-based quantum security technology? Visit the product page.
☑️ Need guidance on certification strategy for CC, FIPS 140-3, or KCMVP? Get in touch with our team.
References
| CMO(Chief Marketing Officer), ICTK CTO(Chief Technical Officer), ICTK Director, Cisco Systems Korea Developer, SK Teletec |
Certification confirms a result — and increasingly, it's how trust gets explained, down to its basis and scope
From Confirming a Result to Verifying a Trust Structure
▲ img source: Generated with ChatGPT
Security certification is the process of confirming that a product meets a defined set of security requirements, then documenting that result with formal marks and paperwork. But it has always done more than that: by evaluating a product's design, implementation, and development process, certification also builds the evidentiary basis for trusting it.
That second role matters more now that quantum-driven cryptographic risk, AI-assisted attacks, advanced persistent threats (APT), and supply chain intrusions all have to be weighed together. Throughout this piece, we call that combined threat environment QAAS — Quantum, AI, APT, Supply Chain. Within QAAS, certification is no longer just a checkbox against a fixed bar; it helps clarify exactly under what conditions, and within what scope, trust was actually verified.
That distinction is central to understanding PAZI, ICTK's trust architecture built on PQC, AI, Zero-Trust, and strongID. The trust PAZI aims for needs a technical explanation backed by verifiable evidence, and it has to hold up against institutional and policy requirements too. High-assurance certification sits exactly at that intersection.
Why High-Assurance Certification Is Getting a Second Look
In a QAAS environment, attacks increasingly combine automation with long-dwell persistence. AI can automate parts of an attack chain; supply chain attacks can hijack the distribution channels of legitimate products and updates; and APTs are defined by their ability to maintain access while evading detection over extended periods — which is exactly why they demand sustained response, not a one-time fix.
In this environment, the claim "this product is secure" doesn't carry much weight on its own. What matters is what assumptions a product was designed under, and how far those assumptions have actually been verified. Security certifications and cryptographic module validations exist to answer exactly that question — each within the criteria and evaluation scope defined by its own scheme.
CC (Common Criteria) — Evaluating Design and Implementation Together
Common Criteria (CC) is the international framework for evaluating the security of IT products and systems, corresponding to ISO/IEC 15408. In practice, "CC certification" means an independent evaluation lab assesses whether a product meets the security functionality and assurance requirements defined under CC, and a certification body confirms that result. Because it gives different countries a shared basis for evaluating security, CC sees genuinely international use.
CC evaluation goes well beyond functional testing. It weighs a product's design and implementation against the threats, assumptions, and security requirements spelled out in its Security Target — not just what security functions it claims to have.
CC defines Evaluation Assurance Levels from EAL1 through EAL7. Each EAL is a bundle of assurance requirements, and higher levels demand deeper, more rigorous evaluation — more scrutiny of development practices, design documentation, testing, and vulnerability analysis. A given EAL doesn't, by itself, qualify a product for use in any particular industry; the security functionality and assurance level a deployment actually needs should be judged against the relevant procurement criteria and the evaluation's specific scope.
That distinction carries real weight in a QAAS environment. Attackers often go after the gap between implementation and operations, so it's worth confirming that design, implementation, and verification genuinely line up. But a certification result is an assurance statement about a specific, named target of evaluation under specific conditions — not a blanket guarantee against every threat that might surface in operation.
FIPS 140-3 — A Practical Trust Baseline for Cryptographic Modules
FIPS 140-3, NIST's U.S. standard for cryptographic module security requirements, evaluates the module as a whole rather than testing an individual algorithm's implementation in isolation. That distinction matters in a QAAS environment: even a strong algorithm can't hold up if the process around generating, storing, and using its keys isn't secure.
FIPS 140-3 defines four security levels, Level 1 through Level 4, with requirements getting stricter at higher levels across areas like physical security, authentication, and sensitive security parameter (SSP) management. The specifics depend on the security area and module type in question. This is already playing out in the market — Axis Communications, for one, has marketed equipment built around FIPS 140-3–validated security components to government customers. It's worth keeping the scope of what was actually validated — the cryptographic module — distinct from the security of the device as a whole.
Also worth noting: NIST's list of CMVP-approved security functions is gradually absorbing post-quantum cryptography (PQC) standards, including ML-DSA (FIPS 204). The SP 800-140C supplemental page specifically lists ML-DSA and SLH-DSA (FIPS 205) among approved functions — a sign that PQC is moving past pure standardization and into the module validation process itself. Still, it's worth separating two distinct facts: an algorithm appearing on an approved list, and an individual module implementing that algorithm actually passing validation.
KCMVP — South Korea's Cryptographic Module Validation System
KCMVP (the Korea Cryptographic Module Validation Program) is South Korea's domestic scheme for validating the safety and implementation conformance of cryptographic modules deployed on government and public networks — protecting non-classified official data carried or stored on national information and communication networks.
KCMVP splits modules into four security levels because the protection a module needs depends on the sensitivity of the data it handles and the environment it runs in. A facility with controlled physical access and one where outsiders can walk straight up to the equipment call for very different physical-security conditions. To address exactly that variation, the cryptographic module security requirements standard, KS X ISO/IEC 19790, defines four security levels, with higher levels requiring stronger protective measures built into the module itself.
The dividing line isn't algorithm strength alone — it's how rigorously the module protects its cryptographic functions and keys. Evaluation spans module specification and interfaces, roles/services/authentication, software and firmware security, the operational environment, physical security, non-invasive security, SSP management, self-tests, life-cycle assurance, and mitigation of other attacks. Here's a summary of the key differences:
KCMVP Security Levels 1–4 at a Glance
These level-by-level differences apply according to module type and security area, so any real deployment decision should weigh the overall security level alongside area-by-area evaluation results and operating conditions. Whether a higher level is actually warranted depends on the sensitivity of the data being protected, how accessible the equipment is, the threats anticipated, and the operating environment. Rather than mapping neatly onto a specific industry or data classification, a security level is best understood as a way to choose the protective measures a given environment actually needs.
In a QAAS environment, it matters to build a security architecture around each system's threats, operating conditions, and the sensitivity of the information it protects. Where stronger security requirements apply, it's worth evaluating whether KCMVP's higher security levels can be put to use — while still confirming the relevant procurement criteria, module type, validation scope, and operating environment for that specific system.
National vs. Commercial Cryptography — A Moment to Reassess How Each Gets Used
At the national level, which cryptographic technologies and products can be used depends on the sensitivity of the information being protected and the regulatory scheme that applies. Reassessing how these technologies get used means weighing not just the required security level and validation process, but also development and adoption timelines, ongoing maintenance, and scope of application.
A useful reference point here is the U.S. National Security Agency's CSfC (Commercial Solutions for Classified) program, which layers validated commercial products together according to defined Capability Packages to protect classified information on National Security Systems (NSS). Separately, the CNSA (Commercial National Security Algorithm) Suite is the set of approved cryptographic algorithms NSA has defined for protecting NSS, with CNSA 2.0 setting requirements for the transition to quantum-resistant algorithms. CSfC — a program for using commercial products — and CNSA — an algorithm standard — play distinct roles.
This case illustrates one approach: using validated commercial technology within a defined security architecture and regulatory framework. Whether, and how, that translates domestically has to be assessed separately, against Korea's own information classification system, security policy, and validation framework.
PAZI and High-Assurance Certification — Why They Belong Together
ICTK's PAZI Architecture is an approach that brings hardware roots of trust, cryptographic key protection, device identity, and continuous trust verification together at the architecture level. Among these, key protection and authentication are also elements CC, FIPS 140-3, and KCMVP each treat as significant — within their own respective purposes and scope.
The components presented as part of PAZI — a PUF-based (Physically Unclonable Function) hardware root of trust (HRoT), a cryptographic structure built with post-quantum cryptography (PQC) in mind, continuous attestation of trust state, and Zero-Trust paired with strong device identity (strongID) — are technical elements worth considering when designing a trust architecture. Exactly how each of these maps to a given certification's requirements has to be confirmed against the implementation and evaluation scope of the specific product or module in question.
PAZI and high-assurance certification are best understood as complementary, sitting at different layers: one a technical trust architecture, the other institutional verification. Adopting an architecture, on its own, doesn't mean certification requirements are met or a specific level has been achieved — that determination requires evaluating and validating the actual product or module.
Conclusion — In the QAAS Era, Certification Is Evidence for a Trust Structure
In the QAAS era, security certification serves as important evidence for answering one specific question: where does this system's trust actually begin, and how far has it been verified? Understanding a certification result means looking at the target of evaluation, the criteria applied, the operating conditions, and the validation scope together.
PAZI Architecture is an attempt to design that trust structure technically. Evaluation and validation under CC, FIPS 140-3, and KCMVP are separate processes that confirm whether a given implementation meets defined security requirements. When technical design and institutional validation come together, the explanation of trust itself rests on more concrete ground.
See For Yourself
☑️ Curious about ICTK's PQC- and PUF-based quantum security technology? Visit the product page.
☑️ Need guidance on certification strategy for CC, FIPS 140-3, or KCMVP? Get in touch with our team.
References
CMO(Chief Marketing Officer), ICTK
CTO(Chief Technical Officer), ICTK
Director, Cisco Systems Korea
Developer, SK Teletec