Common Criteria

The Common Criteria for Information Technology Security Evaluation (abbreviated as Common Criteria or CC) is an international standard (ISO/IEC 15408) for computer security certification. It originated from three standards: ITSEC, CTCPEC, and TCSEC.

Common Criteria is a framework in which computer system users can specify their security functional and assurance requirements. Vendors can then implement and/or make claims about the security attributes of their products, and testing laboratories can evaluate the products to determine if they actually meet the claims.

To obtain a certification, organizations can go through the National Information Assurance Partnership's (NIAP) Common Criteria Evaluation and Validation Scheme (CCEVS). The NIAP is a U.S. government initiative to meet the security testing needs of both information technology consumers and producers and is operated by the National Security Agency (NSA).

The Evaluation Assurance Level (EAL1 through EAL7) of an IT product or system is a numerical grade assigned following the completion of a Common Criteria security evaluation.

To achieve a particular EAL, the computer system must meet specific assurance requirements. Most of these requirements involve design documentation, design analysis, functional testing, and/or penetration testing. The EAL number assigned to a certified system indicates that the system completed all requirements for that level.

In some cases, the evaluation may be augmented to include assurance requirements beyond the minimum required for a particular EAL. Officially this is indicated by following the EAL number with the word augmented and usually with a list of codes to indicate the additional requirements. As shorthand, vendors will often simply add a "plus" sign (as in EAL4+) to indicate the augmented requirements.

What is Common Criteria?

The Common Criteria for Information Technology Security Evaluation (Common Criteria) defines a language for defining and evaluating information technology security systems and products. The framework provided by the Common Criteria allows government agencies and other groups to define sets of specific functional and documentation assurance requirements (known as a Protection Profile or Security Target) they expect the product to meet. The Common Criteria also provides evaluation laboratories with procedures for the evaluation of products or systems against the specified requirements.

Why do I need Common Criteria?

There are several reasons to obtain certification:

Improve product security – A Common Criteria evaluation provides an independent review and analysis of a product’s or system’s security against a defined set of requirements (the Protection Profile or Security Target) for that product type or system type. The independent evaluation serves to improve, measure, and validate the product or system’s strength. For example, Common Criteria may uncover any product vulnerabilities before that version is released, avoiding costly corrections in the field. Common Criteria also examines the security and repeatability of the development practices the company followed to develop the product. Many companies that pursue Common Criteria evaluation see improvements in the documentation for development practices as well.

Sustain competitive advantage - As more vendors validate products, Common Criteria becomes an important requirement to enter or maintain a foothold in the security marketplace. Many vendors use Common Criteria as a market discriminator, even when marketing to non-government clients such as the financial industry.

Comply with other industry standards - Many best practices call out ways to ensure that data is protected. Common Criteria can also aid in compliance with best practices that do not name Common Criteria specifically. See Common Criteria Federal Directives page for examples of such standards.

Sell to the US Government -

All IT security products purchased by the US Government for National Security Systems, which handle classified and some non-classified information, are required to have Common Criteria certification under the Committee for National Security Systems Policy No. 11 (CNSSP #11). In addition, the Department of Defense 8500 directive and instructions (8500.1 and 8500.2) both indicate that DoD systems should be composed of evaluated products. The use of validated products aids DoD agencies with system level accreditations. As a result of this directive many government agencies, especially the DoD, write Common Criteria certification into their RFPs.

Also, the NIST Special Publication 800-23 directive contains guidelines for Federal organizations concerning the purchase or procurement of IT products. It states that products must be evaluated, and provides direction for selecting the appropriate level of certification.

Sell to international governments - The Mutual Recognition Agreement (MRA), signed by 26 countries; specifies that Common Criteria evaluations performed in one country (up to assurance level 4) are honored in all other participating countries. Several countries, including Russia and Italy, promote Common Criteria validation as criteria for government purchase of new products. Germany enacted legislature requiring Common Criteria for digital signatures. France has a regulation recommending the use of Common Criteria evaluations for public administration. Common Criteria is now a NATO standard. The Australian Defence Signals Directorate (DSD) requires that Commonwealth Government agencies purchase products from their Evaluated Products List as described in the Australian Communications-Electronic Security Instruction 33 (ACSI 33), which specifies ITSEC and Common Criteria evaluated products.

Each of these documents may be downloaded from our Common Criteria Documents and Federal Directives pages.

Which countries participate in the Mutual Recognition Agreement?

There are currently 26 countries that have signed the MRA: Australia, Austria, Canada, Czech Republic, Denmark, Finland, France, Germany, Greece, Hungary, India, Israel, Italy, Japan, Republic of Korea, Republic of Singapore, Malaysia, the Netherlands, New Zealand, Norway, Pakistan, Spain, Sweden, Turkey, the United Kingdom, and the United States. Additional countries are invited to sign the MRA as participation with Common Criteria increases. Common Criteria is also widely accepted among countries in the EU as well as Russia and the eastern bloc countries, regardless of whether they are part of the MRA. Please visit our Common Criteria Links page for links to these countries’ websites.

Where can I find a copy of the Common Criteria?

Download PDF’s of all three sections of the Common Criteria here:

Part 1: Introduction and general model Part 2: Security functional components Part 3: Security assurance components Download the Common Evaluation Methodology, which explains what actions the lab will take to validate your products assurance here.

What is a scheme?

An evaluation scheme (scheme) is an organization that acts as the validating authority for a Common Criteria validation. The scheme is responsible for issuing accreditation to evaluation laboratories in the country in which they reside, and provides an evaluation validator who observes to make sure that the product meets requirements. In evaluation circumstances that require clarification, the evaluating lab or developer may submit an Observation Report (OR) to the scheme and they respond with the official interpretation of the issue in question.

The scheme is also ultimately responsible for issuing the Common Criteria Validation certificate and stating that a product vendor has completed the validation process. Each scheme maintains its own list of validated products. Visit our Common Criteria Links page for links to schemes in other countries.

What are EALs?

The Common Criteria defines a concept of a package, which is a grouping of requirements that are either Functional or Assurance groupings.

The Common Criteria defines seven assurance packages called Evaluation Assurance Levels (EALs) each building on each other from one to seven. Each list contains a minimal set of Assurance Requirements to be met to obtain that EAL.

Some purchasers will confuse EALs with functional testing. However, EALs do not correspond to any product or system functionality; they merely provide a statement of the degree of rigor involved in the evaluation of the product or system. A higher assurance level does not necessarily mean a more secure product or greater security functions than a lower EAL.

What is a Protection Profile?

A Protection Profile (PP) is a document that is written for a particular group of IT products (i.e. Firewalls, Virtual Private Networks, etc.). The PP provides specific threats, assumptions, and functional requirements that are applicable for that specific IT product type. When a PP is generated, it is created according to a specific Evaluation Assurance Level (EAL). Products claim “conformance” to a PP by fulfilling all the functional and assurance requirements called out by the PP.

A product may also augment a PP by adding additional threats, assumptions, and requirements; as long as all of the requirements in the PP are satisfied, the product can still claim conformance. For example, if a product is conforming to a PP rated at EAL2, the product must satisfy all the functional requirements stated in the PP and pass the evaluation steps required at Evaluation Assurance Level 2. The product could claim to augment the requirements in the PP by selecting a higher assurance level and being evaluated at EAL4, which is a superset of the EAL2 assurance requirements.

A Protection Profile contains a set of Functional and Assurance requirements for a product or system written to be implementation independent. The product categories that published Protection Profiles presently cover include:

Switches and routers Firewalls VPNs Remote access Operating systems Biometrics Tokens Smart cards Certificate management Key recovery Databases IDS Role-based authentication What is a Security Target?

A Security Target contains a statement of the requirements for which a specific product or system under evaluation must conform; written to be implementation dependent. A Security Target can be authored to conform (meet all the functional and assurance claims) to a Protection Profile or it can be authored to simply state the security functional requirements that the product offers and the assurance levels for the evaluation.

A Protection Profile is similar to a Request For Proposal(RFP) that specifies what the requirements are, for that case of products, while the Security Target is similar to a Response to the RFP because it details how the specific product or system address the RFP’s requirements.

What are the Seven Corsec Common Criteria Certification Milestones?

There are seven milestones that must be met in order to receive Common Criteria certification:

Learn about the Common Criteria (Common Criteria) process. Corsec’s Common Criteria Planning Package can help you do this in a short amount of time. Determine which (if any) Protection Profiles you will be validated against. Ensure your product meets the requirements specified in the selected Protection Profile(s). Develop a Security Target that details how your product or system meets requirements. Produce all the Common Criteria-required Assurance documentation. Submit the product and documentation to an accredited testing laboratory. Receive certification from the appropriate scheme (validation body). Corsec Security can help you achieve each of these milestones and receive certification.

How long does the evaluation take?

There are many factors that determine the length of the evaluation process, such as which Protection profile (PP) the product is tested against, which Evaluation Assurance Level (EAL) you seek, the state of your product or system documentation, back logs at the lab and scheme.

Products testing for lower EALs may complete the validation process in 6-9 months; others may take 12 –24 months.

How much does the evaluation cost?

There are seven factors that affect the cost of your evaluation effort:

Each evaluation lab has its own testing fees. Preparation of the assurance document submission packages. The quality and organization of your documentation. Modification of your product to meet government requirements. Any government validation fees. (The US scheme does not charge for its services, however other local validation bodies do charge for their time). The level of evaluation for which you apply (EAL 1-7 for Common Criteria). The complexity of your product. Each evaluation lab has its own fee structure. Many charge by the hour, which adds up quickly during the inevitable communications over the course of the testing process. Corsec can perform price negotiation with the lab as part of your complete Common Criteria evaluation package.

One effective way to control costs during your Common Criteria evaluation is to incorporate evaluation considerations before designing the product. Making changes afterwards to comply with government requirements can be costly. Corsec is highly experienced in analyzing product designs before they get to the lab to ensure they pass the testing stage.

Existing product documentation also affects the price of Common Criteria validation. Document preparation costs vary depending on the quality and content of the product documentation, as well as the preparer’s familiarity with Common Criteria requirements and the evaluation of the vendors’ class of products. Corsec can prepare all your Common Criteria documentation for you, freeing up your engineers to tackle other important projects.

There is a great deal of documentation required for Common Criteria evaluation, even at lower Assurance levels, and become more complex at higher EAL levels. Preparing documents correctly the first time saves money because it cuts down on lab fees.

The highest costs are your costs which come from internal resources tied up in the validation process: engineers who manage the process, documentation and communications with the lab and scheme, and time spent on product redesigns.

These costs pale in comparison to the cost of evaluation delays and lost opportunities due to stalled evaluations, not to mention the cost of losing market share to a competitor who attains validation first.

How do I select an Evaluation Assurance Level?

If you seek validation against a specific Protection Profile, this step may already be completed for you. Many Protection Profiles specify the Evaluation Assurance Level required for conformance. Additional factors can also affect your decision. Individual customers may require a higher level of assurance than defined by a Protection Profile.

You may encounter an augmented or “+” evaluation; many times demonstrated as “EAL2+” or “EAL4+.” The “+” indicates that the product vendor has completed all Assurance requirements at the Assurance Level, PLUS at least one requirement that is above or not part of the assurance requirements specified for that Assurance Level.

If you wish to have your certification internationally recognized, the Assurance Level must not be greater than EAL 4 and cannot include any other assurance requirements that are not part of the EAL structure. The international agreement of acceptance is defined in the Common Criteria Recognition Agreement.

Base your choice of assurance level on what your customers want, what your competitors are already doing, how soon you need to complete the certification, and your budget. The higher the level, the more time and money required. Corsec can help you determine which EAL level makes the most sense for your sales strategy.

Do I need to test against a Protection Profile (PP)?

No, a product or system is tested against the requirements written in a Security Target, which may not conform to a Protection Profile. The Common Criteria only specifies that the product or system be validated against a Security Target; it is within the Security Target author’s discretion whether to have that Security Target conform to a Protection Profile.

How do I get on the In-Evaluation list while pursuing Common Criteria?

Because of the significant amount of time required to achieve Common Criteria, many companies choose to participate in the voluntary In-Evaluation list posted on the NIAP website. Inclusion on the in-evaluation list proves to customers that vendors are in the evaluation process and committed to achieving validation. Be aware that your inclusion on the list alerts competitors of your certification plans; for that reason some companies choose not to be included on the list.

If you decide to be included on the In-Evaluation list, it is important to understand that addition to the list takes time. You must prove that you’re doing actual work in order to be posted on this list. Corsec has great success in facilitating quick addition to this list by following and monitoring these steps:

Perform a product assessment against the Common Criteria requirements Develop a Security Target (ST) for that specific product Submit ST to evaluation lab for review Evaluation lab creates Evaluation schedule (EAP). Evaluation lab submits ST and EAP to the scheme (NIAP in the US). NIAP assigns a government validator to the project within two weeks. The validator reviews ST and the EAP. If the documents are acceptable, the evaluator schedules kick off meeting to begin the project. Corsec attends kick off meeting with the client, evaluation lab and government validator to answer questions and confirm that the project proceeds smoothly. Only after the kickoff meeting will NIAP consider adding a vendor to the in-evaluation list. The vendor must then demonstrate that consistent progress is made in order to stay on the list.

From wikipedia

The Common Criteria for Information Technology Security Evaluation (abbreviated as Common Criteria or CC) is an international standard (ISO/IEC 15408) for computer security certification. It is currently in version 3.1 revision 4.

Common Criteria is a framework in which computer system users can specify their security functional and assurance requirements (SFRs and SARs respectively) through the use of Protection Profiles (PPs), vendors can then implement  and/or make claims about the security attributes of their products, and testing laboratories can evaluate the products to determine if they actually meet the claims. In other words, Common Criteria provides assurance that the process of specification, implementation and evaluation of a computer security product has been conducted in a rigorous and standard and repeatable manner at a level that is commensurate with the target environment for use.

Common Criteria is used as the basis for a Government driven certification scheme and typically evaluations are conducted for the use of Federal Government agencies and critical infrastructure.

Key concepts
Common Criteria evaluations are performed on computer security products and systems.


 * Target Of Evaluation (TOE) – the product or system that is the subject of the evaluation.

The evaluation serves to validate claims made about the target. To be of practical use, the evaluation must verify the target's security features. This is done through the following:


 * Protection Profile (PP) – a document, typically created by a user or user community, which identifies security requirements for a class of security devices (for example, smart cards used to provide digital signatures, or network firewalls) relevant to that user for a particular purpose. Product vendors can choose to implement products that comply with one or more PPs, and have their products evaluated against those PPs. In such a case, a PP may serve as a template for the product's ST (Security Target, as defined below), or the authors of the ST will at least ensure that all requirements in relevant PPs also appear in the target's ST document. Customers looking for particular types of products can focus on those certified against the PP that meets their requirements.


 * Security Target (ST) – the document that identifies the security properties of the target of evaluation. It may refer to one or more PPs. The TOE is evaluated against the SFRs (see below) established in its ST, no more and no less. This allows vendors to tailor the evaluation to accurately match the intended capabilities of their product. This means that a network firewall does not have to meet the same functional requirements as a database management system, and that different firewalls may in fact be evaluated against completely different lists of requirements. The ST is usually published so that potential customers may determine the specific security features that have been certified by the evaluation.


 * Security Functional Requirements (SFRs) – specify individual security functions which may be provided by a product. The Common Criteria presents a standard catalogue of such functions. For example, a SFR may state how a user acting a particular role might be authenticated. The list of SFRs can vary from one evaluation to the next, even if two targets are the same type of product. Although Common Criteria does not prescribe any SFRs to be included in an ST, it identifies dependencies where the correct operation of one function (such as the ability to limit access according to roles) is dependent on another (such as the ability to identify individual roles).

The evaluation process also tries to establish the level of confidence that may be placed in the product's security features through quality assurance processes:


 * Security Assurance Requirements (SARs) – descriptions of the measures taken during development and evaluation of the product to assure compliance with the claimed security functionality. For example, an evaluation may require that all source code is kept in a change management system, or that full functional testing is performed. The Common Criteria provides a catalogue of these, and the requirements may vary from one evaluation to the next. The requirements for particular targets or types of products are documented in the ST and PP, respectively.


 * Evaluation Assurance Level (EAL) – the numerical rating describing the depth and rigor of an evaluation. Each EAL corresponds to a package of security assurance requirements (SARs, see above) which covers the complete development of a product, with a given level of strictness. Common Criteria lists seven levels, with EAL 1 being the most basic (and therefore cheapest to implement and evaluate) and EAL 7 being the most stringent (and most expensive). Normally, an ST or PP author will not select assurance requirements individually but choose one of these packages, possibly 'augmenting' requirements in a few areas with requirements from a higher level. Higher EALs do not necessarily imply "better security", they only mean that the claimed security assurance of the TOE has been more extensively verified.

So far, most PPs and most evaluated STs/certified products have been for IT components (e.g., firewalls, operating systems, smart cards). Common Criteria certification is sometimes specified for IT procurement. Other standards containing, e.g., interoperation, system management, user training, supplement CC and other product standards. Examples include the ISO/IEC 17799 (Or more properly BS 7799-1, which is now ISO/IEC 27002) or the German IT-Grundschutzhandbuch.

Details of cryptographic implementation within the TOE are outside the scope of the CC. Instead, national standards, like FIPS 140-2 give the specifications for cryptographic modules, and various standards specify the cryptographic algorithms in use.

More recently, PP authors are including cryptographic requirements for CC evaluations that would typically be covered by FIPS 140-2 evaluations, broadening the bounds of the CC through scheme-specific interpretations.

History
CC originated out of three standards:


 * ITSEC – The European standard, developed in the early 1990s by France, Germany, the Netherlands and the UK. It too was a unification of earlier work, such as the two UK approaches (the CESG UK Evaluation Scheme aimed at the defence/intelligence market and the DTI Green Book aimed at commercial use), and was adopted by some other countries, e.g. Australia.
 * CTCPEC – The Canadian standard followed from the US DoD standard, but avoided several problems and was used jointly by evaluators from both the U.S. and Canada. The CTCPEC standard was first published in May 1993.
 * TCSEC – The United States Department of Defense DoD 5200.28 Std, called the Orange Book and parts of the Rainbow Series. The Orange Book originated from Computer Security work including the Ware Report, done by the National Security Agency and the National Bureau of Standards (the NBS eventually became NIST) in the late 1970s and early 1980s. The central thesis of the Orange Book follows from the work done by Dave Bell and Len LaPadula for a set of protection mechanisms.

CC was produced by unifying these pre-existing standards, predominantly so that companies selling computer products for the government market (mainly for Defence or Intelligence use) would only need to have them evaluated against one set of standards. The CC was developed by the governments of Canada, France, Germany, the Netherlands, the UK, and the U.S.

Testing organizations
All testing laboratories must comply with ISO 17025, and certification bodies will normally be approved against either ISO/IEC Guide 65 or BS EN 45011.

The compliance with ISO 17025 is typically demonstrated to a National approval authority:
 * In Canada, the Standards Council of Canada (SCC) under Program for the Accreditation of Laboratories (PALCAN) accredits Common Criteria Evaluation Facilities (CCEF)
 * In France, the Comité français d'accréditation (COFRAC) accredits Common Criteria evaluation facilities, commonly called Centre d'évaluation de la sécurité des technologies de l'information (CESTI). Evaluations are done according to norms and standards specified by the Agence nationale de la sécurité des systèmes d'information (ANSSI).
 * In the UK the United Kingdom Accreditation Service (UKAS) accredits Commercial Evaluation Facilities (CLEF)
 * In the US, the National Institute of Standards and Technology (NIST) National Voluntary Laboratory Accreditation Program (NVLAP) accredits Common Criteria Testing Laboratories (CCTL)
 * In Germany, the Bundesamt für Sicherheit in der Informationstechnik (BSI)
 * In Spain, the National Cryptologic Center (CCN) accredits Common Criteria Testing Laboratories operating in the Spanish Scheme.

Characteristics of these organizations were examined and presented at ICCC 10.

Mutual recognition arrangement
As well as the Common Criteria standard, there is also a sub-treaty level Common Criteria MRA (Mutual Recognition Arrangement), whereby each party thereto recognizes evaluations against the Common Criteria standard done by other parties. Originally signed in 1998 by Canada, France, Germany, the United Kingdom and the United States, Australia and New Zealand joined 1999, followed by Finland, Greece, Israel, Italy, the Netherlands, Norway and Spain in 2000. The Arrangement has since been renamed Common Criteria Recognition Arrangement (CCRA) and membership continues to expand. Within the CCRA only evaluations up to EAL 4 are mutually recognized (Including augmentation with flaw remediation). The European countries within the former ITSEC agreement typically recognize higher EALs as well. Evaluations at EAL5 and above tend to involve the security requirements of the host nation's government.

As of September 2012, a majority of members of the CCRA produced a vision statement whereby mutual recognition of CC evaluated products will be lowered to EAL 2 (Including augmentation with flaw remediation). Further, this vision indicates a move away from assurance levels altogether and evaluations will be confined to conformance with Protection Profiles that have no stated assurance level. This will be achieved through technical working groups developing worldwide PPs, and as yet a transition period has not been fully determined.

List of Abbreviations

 * CC: Common Criteria
 * EAL: Evaluation Assurance Level
 * IT: Information Technology
 * PP: Protection Profile
 * SAR: Security Assurance Requirement
 * SF: Security Function
 * SFR: Security Functional Requirement
 * SFP: Security Function Policy
 * SOF: Strength of Function
 * ST: Security Target
 * TOE: Target of Evaluation
 * TSP: TOE Security Policy
 * TSF: TOE Security Functionality
 * TSC: TSF Scope of Control
 * TSFI: TSF Interface

Requirements
Common Criteria is very generic; it does not directly provide a list of product security requirements or features for specific (classes of) products: this follows the approach taken by ITSEC, but has been a source of debate to those used to the more prescriptive approach of other earlier standards such as TCSEC and FIPS 140-2.

Value of certification
Common Criteria certification cannot guarantee security, but it can ensure that claims about the security attributes of the evaluated product were independently verified. In other words, products evaluated against a Common Criteria standard exhibit a clear chain of evidence that the process of specification, implementation, and evaluation has been conducted in a rigorous and standard manner.

Various Microsoft Windows versions, including Windows Server 2003 and Windows XP, have been certified, but security patches to address security vulnerabilities are still getting published by Microsoft for these Windows systems. This is possible because the process of obtaining a Common Criteria certification allows a vendor to restrict the analysis to certain security features and to make certain assumptions about the operating environment and the strength of threats faced by the product in that environment. Additionally, the CC recognizes a need to limit the scope of evaluation in order to provide cost-effective and useful security certifications, such that evaluated products are examined to a level of detail specified by the assurance level or PP. Evaluations activities are therefore only performed to a certain depth, use of time, and resources and offer reasonable assurance for the intended environment.

In the Microsoft case, the assumptions include A.PEER: "Any other systems with which the TOE communicates are assumed to be under the same management control and operate under the same security policy constraints. The TOE is applicable to networked or distributed environments only if the entire network operates under the same constraints and resides within a single management domain. There are no security requirements that address the need to trust external systems or the communications links to such systems."

This assumption is contained in the Controlled Access Protection Profile (CAPP) to which their products adhere. Based on this and other assumptions, which may not be realistic for the common use of general-purpose operating systems, the claimed security functions of the Windows products are evaluated. Thus they should only be considered secure in the assumed, specified circumstances, also known as the evaluated configuration.

Whether you run Microsoft Windows in the precise evaluated configuration or not, you should apply Microsoft's security patches for the vulnerabilities in Windows as they continue to appear. If any of these security vulnerabilities are exploitable in the product's evaluated configuration, the product's Common Criteria certification should be voluntarily withdrawn by the vendor. Alternatively, the vendor should re-evaluate the product to include application of patches to fix the security vulnerabilities within the evaluated configuration. Failure by the vendor to take either of these steps would result in involuntary withdrawal of the product's certification by the certification body of the country in which the product was evaluated.

The certified Microsoft Windows versions remain at EAL4+ without including the application of any Microsoft security vulnerability patches in their evaluated configuration. This shows both the limitation and strength of an evaluated configuration.

To receive Common Criteria EAL4+ certification the solution must be tested by an authorized certification organization, such as OCSI, the Italian information security certification organization. The first product to receive EAL4+ certification for a server-side digital signature solution is CoSign by ARX, which was tested using a Hardware Security Module (HSM) appliance with two-factor authentication.

Criticisms
In August 2007, Government Computing News (GCN) columnist William Jackson critically examined Common Criteria methodology and its US implementation by the Common Criteria Evaluation and Validation Scheme (CCEVS). In the column executives from the security industry, researchers, and representatives from the National Information Assurance Partnership (NIAP) were interviewed. Objections outlined in the article include:


 * Evaluation is a costly process (often measured in hundreds of thousands of US dollars) – and the vendor's return on that investment is not necessarily a more secure product
 * Evaluation focuses primarily on assessing the evaluation documentation, not on the actual security, technical correctness or merits of the product itself. For U.S. evaluations, only at EAL5 and higher do experts from the National Security Agency participate in the analysis; and only at EAL7 is full source code analysis required.
 * The effort and time necessary to prepare evaluation evidence and other evaluation-related documentation is so cumbersome that by the time the work is completed, the product in evaluation is generally obsolete
 * Industry input, including that from organizations such as the Common Criteria Vendor's Forum, generally has little impact on the process as a whole

In a 2006 research paper, computer specialist David A. Wheeler suggested that the Common Criteria process discriminates against Free and Open Source Software (FOSS)-centric organizations and development models. Common Criteria assurance requirements tend to be inspired by the traditional waterfall software development methodology. In contrast, much FOSS software is produced using modern agile paradigms. Although some have argued that both paradigms do not align well, others have attempted to reconcile both paradigms. Political scientist Jan Kallberg raised concerns over the lack of control over the actual production of the products once they are certified, the absence of a permanently staffed organizational body that monitors compliance, and the idea that the trust in the Common Criteria IT-security certifications will be maintained across geopolitical boundaries.

Alternative approaches
Throughout the lifetime of CC, it has not been universally adopted even by the creator nations, with, in particular, cryptographic approvals being handled separately, such as by the Canadian / US implementation of FIPS-140, and the CESG Assisted Products Scheme (CAPS) in the UK.

The UK has also produced a number of alternative schemes when the timescales, costs and overheads of mutual recognition have been found to be impeding the operation of the market:


 * The CESG System Evaluation (SYSn) and Fast Track Approach (FTA) schemes for assurance of government systems rather than generic products and services, which have now been merged into the CESG Tailored Assurance Service (CTAS)
 * The CESG Claims Tested Mark (CCT Mark), which is aimed at handling less exhaustive assurance requirements for products and services in a cost and time efficient manner

In early 2011, NSA/CSS published a paper by Chris Salter, which proposed a Protection Profile oriented approach towards evaluation. In this approach, communities of interest form around technology types which in turn develop protection profiles that define the evaluation methodology for the technology type. The objective is a more robust evaluation. There is some concern that this may have a negative impact on mutual recognition.

In Sept of 2012, the Common Criteria published a Vision Statement implementing to a large extent Chris Salter's thoughts from the previous year. Key elements of the Vision included:
 * Technical Communities will be focused on authoring Protection Profiles (PP) that support their goal of reasonable, comparable, reproducible and cost-effective evaluation results
 * Evaluations should be done against these PP's if possible; if not mutual recognition of Security Target evaluations would be limited to EAL2