PP-Configuration for Enterprise Server Applications and Agent/Application Component(s)

The ST shall identify a minimum evaluated configuration: the set of TOE Components and TOE Component Instances evaluated together to demonstrate that the distributed TOE satisfies the claimed requirements. This is the minimum configuration of interest for the evaluation; it need not be the smallest deployment that could theoretically satisfy the PP-Configuration and may include redundancy needed for the claimed deployment.

The ST may separately identify named TOE Components for which additional Runtime Replica instances are permitted after evaluation. For every such component, the ST shall identify the permitted artifact and security-relevant configuration, the constraints on adding the instance, the expected additional communication relationships, and any effect on SFR allocation, interfaces, identities, trust, management, or update behavior. A permitted additional instance shall preserve the claimed SFR behavior of the corresponding TOE Component and shall not corrupt, bypass, or weaken the security functionality of components already in the TOE.

The operational guidance shall describe how to add a permitted Runtime Replica consistently with the ST. If an additional instance introduces an SFR allocation or completed operation not present in the minimum evaluated configuration, or a difference in security-relevant configuration, interface, identity, trust, platform dependency, or update behavior, the ST shall identify that difference and the evaluator shall cover the additional case. For an additional connection not present in the minimum evaluated configuration, the evaluator shall confirm that it has the security characteristics claimed for that relationship.

For a distributed TOE, the SFRs are satisfied by the TOE as a whole; however, not every SFR is necessarily implemented by every TOE Component. The ST author shall separately identify the claim condition, where relevant; component allocation; and permitted operational-environment contribution for every claimed SFR element. Every deployed TOE Component Instance shall exhibit the claimed SFR behavior allocated to its TOE Component in its identified configuration. For an All Components or Feature Dependent allocation, deployment multiplicity does not permit one instance to satisfy an allocated requirement on behalf of another instance.

The claim condition, where relevant, and component allocation are controlled by the following tables and the SFR’s operations and application notes; the ST shall not freely reclassify an SFR. At Least One Component and a permitted operational-environment contribution may be used only where the applicable table or requirement expressly permits them. Allocation shall be stated at the SFR-element level when different elements have different responsible TOE Components, update actors, or permitted platform dependencies. A Feature Dependent allocation or claim condition shall not be used to omit a TOE Component that performs the mapped function. Evaluation evidence shall cover every TOE Component, artifact, communication path, or function allocated as responsible. Evidence for one TOE Component may be reused only where the ST demonstrates that the relevant implementation, configuration, and execution context are equivalent.

For a TOE application payload executing in a Linux container, an EA whose subject is behavior of the running payload shall use the Linux-specific method defined by the base cPP and Supporting Document. This does not satisfy or make inapplicable an activity whose subject is the image or update artifact, installation or update workflow, runtime or orchestrator configuration or dependency, mounted or injected data at its source, network policy, or an externally exposed interface or protected channel. Each such activity shall be performed at the artifact, platform, lifecycle, configuration, interface, or channel layer stated by the activity.

The ST shall provide a compact trusted-update matrix for every separately versioned TOE Component and every distinct update unit or bundle. The matrix shall identify:

A central TOE service may perform update discovery for the applicable updateable TOE Components when it is mapped as the responsible component, but every changed TOE artifact shall remain covered by an authenticated or integrity-protected chain from the authorized source through verification and installation or replacement. A running-payload version query or observation of executable-change behavior may use the base cPP Linux-container method; authorized-source, signature or integrity, delivery, installation or replacement, and removal activities remain applicable at their stated lifecycle and artifact scope. Rollback, partial or rolling update, and mixed-version behavior are documentation items in this matrix; they are evaluated as functional requirements only when a completed SFR or applicable EA requires them.

SFR allocation determines which TOE Components must satisfy a requirement. Every deployed TOE Component Instance shall exhibit the claimed behavior of its TOE Component in its identified configuration. Interfaces, communication relationships, artifacts, configurations, and deployment contexts are separate Evaluation Activity coverage targets. Allocation and coverage identification shall be completed before any reuse of evaluation evidence is considered. Assignment to a class does not change the allocation category or relieve any TOE Component, identified configuration, or deployed instance from satisfying an applicable requirement.

The ST need not iterate an SFR solely because it applies to multiple TOE Components. A single completed SFR statement and common TSS description may apply to multiple TOE Components when the completed operations and claimed security-relevant behavior are the same. Different selections, assignments, or other completed operations require separate SFR iterations. Multiple deployed instances of the same TOE Component are Runtime Replicas when they meet the base cPP definition and may be represented by that TOE Component together with its permitted instance or scaling topology.

The ST shall provide concise traceability that maps every applicable TOE Component and identified security-relevant configuration, where applicable, to the claimed SFR iteration and, where evidence reuse is claimed, to a class identifier and common TSS description. The ST may identify unambiguous sets of TOE Components and configurations rather than repeat one row for every member. A compact table with columns for TOE Component and configuration or set, SFR iteration or set, class identifier, and common TSS reference is sufficient. A single class definition may list multiple SFR iterations when the member SFR Implementation Instances and equivalence basis are identical for all listed SFRs. The detailed implementation-equivalence rationale and the mapping to exact Evaluation Activity portions may be provided as separate evaluation evidence rather than repeated in the ST.

The implementation-equivalence rationale shall identify:

A shared library name, base image, runtime, source repository, or build pipeline alone is not sufficient when component-specific code or configuration can alter the claimed behavior. The same security-relevant implementation and version, wrapper or integration behavior, build options, implementation configuration and values that affect the reused activities, role and exercised code path, cryptographic provider, and immediate platform services and interfaces relevant to the reused activities are prerequisites for class membership. Channel-specific certificates, keys, trust-anchor values, endpoint identities, addresses, and similar deployed values may differ when they do not alter the reused implementation behavior and are covered by retained interface- or channel-specific activities. When these prerequisites or the effect of a relevant peripheral difference cannot be substantiated, the affected SFR Implementation Instances may not share representative execution for that scope. Image, runtime, and orchestrator differences remain subject to their own activities; when such a difference can affect a scoped running-payload result, it is also a class-relevant difference.

Class membership shall be re-established when a member’s security-relevant implementation version, provider, wrapper or integration behavior, relevant build options, relevant configuration, relevant platform service or interface, or exercised code path changes. When reuse is claimed for an EA incorporated from a Functional Package, the rationale shall identify the package and Supporting Document version and a stable EA paragraph or test identifier.

Where permitted by the applicable Supporting Document, the evaluator may perform the explicitly identified implementation-specific portions of Evaluation Activities using one or more representative class-member SFR Implementation Instances exercised through exact deployed TOE Component Instances. Representative execution does not reduce any internal test repetition or any component-, artifact-, interface-, channel-, configuration-, topology-, deployment-, or end-to-end coverage required by the originating activity. The evaluator shall preserve a coverage mapping and separate verdict for every applicable requirement and activity.

For example, a substantiated TLS implementation used by multiple TOE Components or identified security-relevant configurations may share the complete protocol-implementation test suite only when its SFR Implementation Instances meet the base cPP Component Implementation-Equivalence Class criteria. Each distinct interface and channel remains subject to its required connection, credential, trust, identity, traffic-protection, interruption, recovery, and integration checks. TLS termination performed by an operational-environment service mesh or ingress component is an environmental dependency, not a shared TOE implementation, unless that component is explicitly included in the TOE boundary. An operational-environment termination point cannot be credited as satisfying FTP_DIT_EXT.1 or another TOE-implemented channel requirement unless the applicable SFR expressly permits platform-provided functionality.

An illustrative TOE has twelve simultaneously deployed TOE Component Instances representing five TOE Components. Each instance is an application payload container. The orchestrator, runtime, host kernel, platform ingress, platform secret store, and registry are in the operational environment. The ST identifies their dependencies using the operational-environment matrix; it does not count them as TOE Components or credit them with TOE-implemented SFRs.

The Management API, Policy Service, and Update Coordinator are assigned both Server Application and Agent Application roles because the example applies the Agent Module control model to their communication pairings. These role assignments do not imply network directionality or hosting relationships.

The ST describes five TOE Components and a permitted instance topology rather than repeating the same SFR text twelve times. Multiple instances of a TOE Component are Runtime Replicas when they meet the base cPP definition. An instance with a different image is not a Runtime Replica and shall be separately identified as a TOE Component or explicitly identified configuration, as appropriate. An instance with another difference in security-relevant values, role, interface, identity model, or relevant platform service that can affect an SFR or EA is also not a Runtime Replica and shall be represented separately in the same manner.

Runtime Replicas do not create additional Communication Relationship Types solely because there are more connections. However, when a permitted additional instance creates a connection that is not present in the minimum evaluated configuration, the evaluator shall confirm that the connection has the security characteristics claimed for that relationship. Additional SFR or EA coverage is required when an instance has a separately managed identity, trust configuration, interface, placement, failover path, completed SFR operation, platform dependency, or other difference that can affect the result.

The Update Coordinator’s own update is shown as a bootstrap or self-update artifact lifecycle in the matrix below. It is not an additional intra-TOE Communication Relationship Type unless another TOE Component Instance performs that update-control communication.

The matrix documents rollback, rolling replacement, and mixed-version behavior where supported; it does not make those behaviors functional requirements absent a completed SFR or applicable EA. Common verifier implementation testing may use a substantiated Component Implementation-Equivalence Class, but each artifact identity and every distinct delivery and verification path retain the positive, negative, and traceability coverage required by the completed selection and EA.

Suppose the Worker and Telemetry Agent use the same TLS client implementation and version, wrapper, provider, relevant configuration, code path, and platform interface. Their TLS-client SFR Implementation Instances may be placed in one substantiated class and the complete internal protocol vector suite may be executed once on selected exact TOE Component Instances exercising the representative SFR Implementation Instances. The Worker-to-Management and Telemetry-to-Management relationships still receive their separate registration, deployed credential and trust, connection, traffic-protection, interruption, recovery, and integration checks. A Management API TLS server implementation is not included in the client class merely because it uses the same library.

For Linux Running-Payload Activities, the evaluator may enter or instrument one exact deployed TOE Component Instance representing each applicable TOE Component and each of its identified security-relevant configurations, where applicable, and perform the Linux procedure in its effective execution context. The activity need not be repeated solely for additional Runtime Replicas unless the originating EA expressly requires every deployed instance. If multiple TOE Components or configurations also meet the narrower class criteria for a particular implementation-specific activity, one representative execution may be cited for those mapped SFR Implementation Instances. Image identities and signatures, update paths, runtime and orchestrator controls, mounted or injected sources, and the seven Communication Relationship Types above remain separately covered at their stated layers.