The main mistake is assuming that most of the requirements is enough. Under a NIAP protection profile, partial compliance is not acceptable. A product must satisfy every stated functional requirement, and the evaluation must be complete, scoped, and evidence-based. Missing even one required control can prevent certification.
Why Partial Compliance Fails Under Common Criteria
common criteria is not a “mostly compliant” model. Evaluations are built around a defined target of evaluation, stated security objectives, and an exact set of functional and assurance claims. If a product misses one required item, the result is not a soft pass, it is a gap in the evaluated claim set. That is why teams who treat it like a checklist often misunderstand the certification threshold.
The practical error is assuming that coverage can be inferred from intent or close equivalence. Under Common Criteria, the evaluator is not judging whether the product feels secure enough overall, but whether the submitted scope, claims, and evidence actually satisfy the profile or security target as written. For a NIAP protection profile, completeness is part of the requirement, not an optional quality marker.
What Completeness Means in a Common Criteria Evaluation
Common Criteria is structured around precision. The security target or protection profile defines what must be implemented, what assurance evidence must exist, and what the evaluator must be able to verify. That means the unit of success is the full set of stated requirements, not a percentage of them. Missing functionality, vague mappings, or unsupported assertions all break the evaluation story.
This is also why scoping matters so much. Teams often overestimate how much of the product is really inside the certification boundary, or they assume a control in one layer compensates for an omission in another. In practice, the boundary has to be explicit, the claims have to be traceable, and the evidence has to show that each required control is both present and testable.
Common Criteria also distinguishes between functional claims and assurance claims. Functional completeness answers “does the product do what the profile requires,” while assurance completeness answers “can the evaluator trust the claim through documentation, testing, and development evidence.” A team can fail either side. Incomplete test coverage, weak design justification, or missing evaluation artifacts can be just as fatal as a missing technical feature.
How Teams Misread the Certification Boundary
The most common mistake is translating internal compliance language into certification language. A product owner may say the system is “aligned” with a profile because most controls are implemented, but evaluation does not accept implied alignment. If the protection profile says a requirement exists, it must be explicitly addressed. If the security target makes a claim, the evidence must support that exact claim.
Another frequent failure is treating compensating controls as interchangeable. In ordinary compliance programmes, a team may be allowed to justify an alternate control path, but Common Criteria is much stricter about what the evaluated configuration actually includes. A missing requirement is not cured by general hardening, process controls, or an adjacent security feature unless the evaluated documents and test evidence formally account for that substitution.
Teams also underestimate traceability. The evaluator needs to see that each requirement maps to a design element, an implementation element, and evidence that proves behavior in the evaluated configuration. If the mapping is incomplete, the submission can look polished while still failing because the evaluator cannot substantiate one or more required claims.
Risk and Threat Considerations
Partial compliance creates false assurance. The biggest risk is not merely certification failure, it is believing a product has stronger security assurance than the evaluation actually demonstrates. That gap can leave unexamined attack paths, undocumented behaviors, or unsupported assumptions in the exact areas the profile was meant to control.
Failure mechanism: The product’s evaluated claim set is incomplete, so the evaluator cannot confirm that every mandatory function, test, and assurance artifact exists for the scoped configuration. The result is a broken trust chain between the stated security objective and the evidence used to support it.
Impact: Certification can be delayed or denied, release timelines can slip, and downstream buyers may inherit a product whose assurance story is weaker than expected. In regulated or procurement-driven environments, that can also force rework in documentation, implementation, and testing plans.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.29 — Information security during disruption | Common Criteria programs need disciplined evidence and scope control. |
| Recommendation — Define the evaluated boundary and retain evidence that every stated requirement is implemented and testable. | ||
| NIST SP 800-53 Rev 5 | CA-2 — Control Assessments | Evaluation completeness depends on verified control evidence, not assumed coverage. |
| Recommendation — Assess each claimed requirement against evidence and flag any unverified control as a gap. | ||
| NIST CSF 2.0 | GV.OV-01 — Oversight of cybersecurity risk management | Certification readiness depends on governance over scope, claims, and assurance evidence. |
| Recommendation — Establish governance that requires complete traceability from claims to testing artifacts. | ||
Practitioner Guidance
What to verify: Treat the protection profile or security target as the authoritative checklist, then verify every stated requirement has a direct implementation and an evidence artifact. If a requirement cannot be traced cleanly, assume it is a certification blocker until proven otherwise.
Decision rule: If the team is relying on “substantially complete” coverage, stop and convert the gap analysis into a requirement-by-requirement traceability review. For Common Criteria, partial sufficiency is not a viable certification strategy.
Practitioner takeaway: The right question is not whether the product is mostly secure, but whether the evaluated claim set is complete enough to be defensible on its own.
Related resources from NHI Mgmt Group
- What do teams get wrong when they treat NIST CSF 2.0 as a one-time compliance exercise?
- What do teams get wrong when they treat application security standards as a late-stage compliance exercise?
- What do teams get wrong when they treat identity verification as a one-time compliance task?
- What do teams get wrong when they treat AI governance as a compliance project?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
