· CYBSER  · 3 min read

CPSTIC taxonomies 2026: a common foundation for security requirements

The CCN is harmonising requirements, threats and assets common to security products. Each family adds requirements for its own functions.

CPSTIC taxonomies 2026: a common foundation for security requirements

The CCN is updating the CCN-STIC 140 taxonomies to harmonise the security requirements, threats and assets common to most products, regardless of their family. These include identification and authentication, communication channels and credential protection.

Each taxonomy builds on this shared foundation with the functions specific to its product type. The new editions combine criteria shared by many solutions with the requirements specific to each family.

What is being harmonised

The update covers both security functions and the security problem they address:

  • Common requirements, including user identification and authentication, administration, secure channels, cryptography, updates and audit records.
  • Assets to protect, including credentials, private keys, product configuration and activity records.
  • Common threats, including unauthorised access, interception of communications and malicious updates.

For administration, different families share requirements to define roles and restrict functions to authorised users. For identification and authentication, they require users to be verified before access is granted and interfaces to be protected against brute-force authentication attempts. For communications, they require secure channels when exchanging sensitive information. For auditing, they require events to be recorded with their date and time, type, outcome and user.

These requirements are largely common across families, with small changes to fit each product. For example, the list of functions an administrator can configure, the types of user that must authenticate or the specific events recorded may change. The underlying requirement remains the same, with these details adapted to the functions of each solution.

What each family adds

Each taxonomy adds requirements tied to the functions of its family. Examples include identity management, secure information erasure and email protection, depending on the product being evaluated.

An evaluation must cover both the common requirements and those specific to the product, with all applicable requirements set out in the Security Target (ST). The annexes also distinguish ENS Medium and High categories and include traceability tables for LINCE, CICLON and Common Criteria.

Effort varies with scope

A shared structure does not mean every product takes the same effort to evaluate. The annexes give examples of the effort needed for a LINCE evaluation, with applicable modules added to these figures. Effort is expressed in person-days: one day of work by one person, rather than one calendar day.

FamilyScopeEffort (person-days)
A.5 PAMAll specified use cases and requirements35
A.5 PAMPartial coverage25
B.2 EDREndpoint protection30
B.2 EDRMobile device protection35
E.5 TLS VPNClient only25
E.5 TLS VPNServer only35
E.5 TLS VPNClient and server60

Some taxonomies, such as TLS VPN, require additional modules to be included in the evaluation. In this case, the cryptographic evaluation module (MEC) is required, although MEMeC at CL1 is also accepted as equivalent.

The updated LINCE 2001 and 2002 guides follow this approach: total effort is proposed and justified in the ST based on the product family and scope.

Where to start with your product

If you are preparing for CPSTIC inclusion, we help you adapt the taxonomy requirements to your product’s functions, interfaces and configuration. From there, we prepare the Security Target and handle your evaluation and CPSTIC inclusion.

Back to Blog