Category: CMMC & DIB Assessment

Protection Profile

Also known as:

Simply put

A Protection Profile is a document that describes a baseline set of security requirements intended to counter a well-defined set of threats for a particular type of technology product or system. It acts as a standardized reference used during a product's security certification, so that different products of the same kind can be evaluated against common expectations. Readers should confirm the current requirements and processes against the applicable Common Criteria and certification body documentation.

Formal definition

A Protection Profile (PP) is an implementation-independent specification defining a minimal, baseline set of security requirements targeted at mitigating well-defined and described threats for a class of products or systems. Within the Common Criteria framework (ISO/IEC 15408), a PP serves as a foundational document in the certification process, providing a reference against which a specific evaluated product (its Target of Evaluation) can be assessed. PPs may be modular, combining multiple PP modules to support certification of varying product configurations, as with some hardware security element profiles, and a PP can itself be certified to demonstrate that it is complete, consistent, and technically coherent. Note that the term Protection Profile also has a distinct usage in certain NSA/NIST contexts; practitioners should verify which framework and governing publication applies to a given evaluation, since certification schemes and profile requirements are maintained by their respective national schemes and bodies (for example, national Common Criteria schemes such as Germany's BSI) and evolve over time.

Why it matters

Protection Profiles bring consistency and comparability to product security evaluations. Without a common baseline, each vendor could define security claims on its own terms, making it difficult for acquirers to judge whether two products of the same type meet comparable expectations. By describing a minimal, baseline set of requirements targeted at well-defined threats for a class of technology, a PP lets different products, such as smart cards, embedded secure elements, or other hardware and software components, be assessed against shared expectations within the Common Criteria (ISO/IEC 15408) framework.

For compliance and acquisition personnel, PPs matter because they underpin the evidence behind a product's certification claims. When a product is evaluated, its Target of Evaluation is assessed against the relevant PP, giving buyers a defensible basis for trusting that the product addresses the intended threats. A PP can itself be certified to demonstrate that it is complete, consistent, and technically coherent, which strengthens confidence that the baseline used for evaluation is sound. Some profiles are modular, combining multiple PP modules so that a range of product configurations, from a simple smart card to an embedded secure element, can be certified against an appropriate combination of requirements.

Practitioners should be careful not to overstate what a PP or a resulting certification represents. A Common Criteria evaluation against a PP demonstrates conformance to a defined set of requirements at a point in time; it is not a guarantee of security in all deployments, nor is it automatically equivalent to authorization under other frameworks. The term Protection Profile also carries a distinct usage in certain NSA/NIST contexts, so it is important to confirm which framework and governing publication applies before relying on a given profile for an evaluation.

Who it's relevant to

Product security evaluators and certification bodies

Evaluators use the applicable Protection Profile as the reference baseline for assessing a product's Target of Evaluation under Common Criteria (ISO/IEC 15408). They should confirm which PP version and national scheme apply, since profile requirements are maintained by their respective bodies and change over time.

Product vendors and developers

Vendors seeking Common Criteria certification design and document their products to demonstrate conformance to the relevant PP. Understanding whether a profile is modular, combining multiple PP modules for different configurations, helps developers scope which requirements apply to their product.

Acquisition and procurement personnel

Those selecting technology products can use PP-based certifications to compare products of the same type against a common baseline. They should treat a certification as evidence of conformance to defined requirements at a point in time rather than a blanket assurance of security or equivalence to other authorization frameworks.

Compliance officers and ISSMs

Compliance staff mapping product certifications to organizational requirements should verify which framework governs a given Protection Profile, since the term also has a distinct usage in certain NSA/NIST contexts. Confirm the current governing publication and certification scheme before relying on a profile in a compliance determination.

Inside PP

Security Problem Definition

A statement of the threats to be countered, the organizational security policies to be enforced, and the assumptions about the operational environment for the type of product the Protection Profile addresses. This frames why the security requirements exist without specifying a particular vendor implementation.

Security Objectives

The high-level goals that address the identified threats, policies, and assumptions, typically divided between objectives met by the target of evaluation itself and objectives met by the operational environment.

Security Functional Requirements (SFRs)

Implementation-independent statements of the security behavior a conformant product must provide. In most Common Criteria-based Protection Profiles these are drawn from or defined consistently with the standardized catalog of functional components, and readers should verify the specific components against the current PP text.

Security Assurance Requirements (SARs)

The requirements describing the evaluation activities and evidence needed to gain confidence that the security functions are correctly implemented. These generally correspond to defined assurance measures rather than a product's day-to-day operation.

Conformance Claims

Statements identifying the version of the underlying evaluation standard the Protection Profile conforms to and how a Security Target or product must claim conformance to the PP. The exact conformance model can vary by PP revision and should be confirmed against the authoritative document.

Implementation-Independent Scope

A Protection Profile describes requirements for a category or class of products rather than a single named product, distinguishing it from a Security Target, which is written for a specific evaluated product.

Common questions

Answers to the questions practitioners most commonly ask about PP.

Does a Protection Profile guarantee that a product is secure once it is certified against it?

No. A Protection Profile defines a set of security requirements for a category of products, and evaluation against a PP demonstrates conformance to those specified requirements, not comprehensive security. Certification confirms that the product met the stated assurance and functional requirements under the conditions of the evaluation, but it does not mean the product is free of vulnerabilities or secure in every deployment. As with compliance generally, conformance to a Protection Profile should not be equated with operational security, and organizations must still address configuration, patching, and continuous monitoring in their own environments.

Is a Protection Profile the same thing as a Security Target?

No, and experts insist on keeping these distinct. A Protection Profile is an implementation-independent statement of security requirements for a type or class of product, typically written to be reusable by multiple vendors. A Security Target is specific to a particular product (the Target of Evaluation) and describes how that product meets its claimed requirements, which may be based on one or more Protection Profiles. In short, a PP describes what a class of products should do, while a Security Target describes what a specific product actually claims to do. Readers should confirm the exact relationship and terminology against the current governing evaluation criteria.

How do I determine which Protection Profile applies to a product I want to procure?

Identify the product's technology category and match it to a Protection Profile written for that class of product, since PPs are generally organized by product type. Consult the relevant evaluation scheme's published list of applicable and current Protection Profiles, and confirm whether a specific PP is required or preferred for your use case. Because applicability and available profiles can change, verify the current authoritative listing rather than relying on prior procurement documentation.

Can a single product be evaluated against more than one Protection Profile?

In many implementations a product's Security Target can claim conformance to more than one Protection Profile, particularly where the product spans multiple functional categories or where extended requirements apply. The specifics depend on the evaluation scheme and how the Security Target is constructed. Confirm the permitted approach and any composition rules against the current governing criteria and the applicable evaluation scheme's guidance.

Where should I look to confirm the current version of a Protection Profile before relying on it?

Consult the official publication maintained by the body responsible for the applicable evaluation criteria and scheme, since Protection Profiles are revised over time and older versions may be superseded. Do not assume a PP cited in earlier documentation is still current. Verify the profile's version, status, and applicability against the authoritative source at the time of use.

What limitations should I keep in mind when incorporating Protection Profile conformance into compliance decisions?

A Protection Profile addresses defined security requirements for a class of product and does not, by itself, satisfy broader program obligations such as those tied to CUI handling, DoD RMF authorization, or FISMA requirements for civilian systems. Conformance is one input, not a substitute for authorization, continuous monitoring, or contractual and legal requirements specific to your environment. Confirm how PP conformance maps to your particular framework obligations against current official guidance, as interpretations may vary by agency and program.

Common misconceptions

A Protection Profile is a product certification or an approval that a specific product is secure.

A Protection Profile is a technology-class specification of security requirements, not an evaluation result for any particular product. Conformance of a specific product is generally demonstrated through a Security Target and a completed evaluation, which are distinct from the PP itself. Readers should confirm the current process against authoritative sources.

Conforming to a Protection Profile means a product is compliant with, or authorized under, frameworks such as FISMA, FedRAMP, or the DoD RMF.

A Protection Profile addresses product-level security requirements and does not by itself satisfy federal civilian, defense, or national security system authorization requirements. Compliance and authorization under those distinct programs are separate determinations that must be verified against the applicable authority and current guidance.

A Protection Profile is a permanent, static document that does not change.

Protection Profiles are issued in revisions and can be updated or superseded as the underlying standard and threat understanding evolve. Practitioners should always confirm they are referencing the current applicable version rather than assuming an older PP remains authoritative.

Best practices

Identify and reference the specific version of the Protection Profile and its underlying evaluation standard, since requirements and conformance models can change across revisions.

Keep the roles of the Protection Profile and the Security Target distinct: use the PP for technology-class requirements and rely on a product-specific Security Target and completed evaluation to establish a product's conformance.

Trace each security objective back to the threats, policies, and assumptions in the Security Problem Definition to confirm the requirements remain justified for your intended use.

Do not treat Protection Profile conformance as equivalent to authorization or compliance under separate frameworks; verify any FISMA, FedRAMP, or DoD RMF obligations against their own governing authorities.

Confirm both the Security Functional Requirements and Security Assurance Requirements against the current authoritative PP text rather than relying on summaries, and avoid assuming specific components without verification.

Periodically check whether the Protection Profile you rely on has been revised or superseded, and reassess conformance claims when a newer version is published.