National Information Assurance Partnership
Common Criteria Evaluation and Validation Scheme
Validation Report
for the
Juniper NFX series Network Services Platform with Junos
OS 23.4R1
Report Number: CCEVS-VR-VID11579-2025
Dated: 12/1/2025
Version: 1.0
National Institute of Standards and Technology Department of Defense
Information Technology Laboratory ATTN: NIAP, SUITE: 6982
100 Bureau Drive 9800 Savage Road
Gaithersburg, MD 20899 Fort George G. Meade, MD 20755-6982
®
TM
2
ACKNOWLEDGEMENTS
Validation Team
Swapna Katikaneni
Meredith Martinez
DeRon Graves
The Aerospace Corporation
Common Criteria Testing Laboratory
Furukh Siddique
Ruban Abinesh
Manohar Negi
Acumen Security, LLC
3
Table of Contents
1 Executive Summary............................................................................................................... 4
2 Identification.......................................................................................................................... 6
3 Architectural Information .................................................................................................... 8
3.1 TOE Description.............................................................................................................................................8
3.1.1 Physical boundary........................................................................................................................................8
4 Security Policy...................................................................................................................... 11
5 Assumptions, Threats & Clarification of Scope ............................................................... 13
5.1 Assumptions..................................................................................................................................................13
5.2 Threats...........................................................................................................................................................15
5.3 Clarification of Scope...................................................................................................................................19
6 Documentation..................................................................................................................... 21
7 TOE Evaluated Configuration ........................................................................................... 22
7.1 Evaluated Configuration..............................................................................................................................22
7.2 Excluded Functionality ................................................................................................................................23
8 IT Product Testing............................................................................................................... 24
8.1 Developer Testing.........................................................................................................................................24
8.2 Evaluation Team Independent Testing.......................................................................................................24
9 Results of the Evaluation .................................................................................................... 25
9.1 Evaluation of Security Target .....................................................................................................................25
9.2 Evaluation of Development Documentation...............................................................................................25
9.3 Evaluation of Guidance Documents............................................................................................................25
9.4 Evaluation of Life Cycle Support Activities...............................................................................................26
9.5 Evaluation of Test Documentation and the Test Activity .........................................................................26
9.6 Vulnerability Assessment Activity ..............................................................................................................26
9.7 Summary of Evaluation Results..................................................................................................................27
10 Validator Comments & Recommendations ...................................................................... 28
11 Annexes................................................................................................................................. 29
12 Security Target .................................................................................................................... 30
13 Glossary................................................................................................................................ 31
14 Bibliography......................................................................................................................... 32
4
1 Executive Summary
This Validation Report (VR) is intended to assist the end user of this product and any security
certification Agent for that end user in determining the suitability of this Information Technology
(IT) product for their environment. End users should review the Security Target (ST), which is
where specific security claims are made, in conjunction with this VR, which describes how those
security claims were tested and evaluated and any restrictions on the evaluated configuration.
Prospective users should carefully read the Assumptions and Clarification of Scope in Section 5
and the Validator Comments in Section 10, where any restrictions on the evaluated configuration
are highlighted.
This report documents the National Information Assurance Partnership (NIAP) assessment of the
evaluation of the Juniper NFX series Network Services Platform with Junos OS 23.4R1 Target
of Evaluation (TOE). It presents the evaluation results, their justifications, and the conformance
results. This VR is not an endorsement of the TOE by any agency of the U.S. Government and no
warranty of the TOE is either expressed or implied. This VR applies only to the specific version
and configuration of the product as evaluated and documented in the ST.
The evaluation was completed by Acumen Security in December 2025. The information in this
report is largely derived from the Evaluation Technical Report (ETR) and associated test report,
all written by Acumen Security. The evaluation determined that the product is both Common
Criteria Part 2 Extended and Part 3 Part 2 Extended and Part 3 Conformant and meets the assurance
requirements of the below claimed PP/PP-Modules/Package.
• PP-Configuration for Network Devices, Intrusion Protection Systems, Stateful Traffic Filter
Firewalls, and Virtual Private Network Gateways, Version 2.0 (CFG_NDcPP-IPS-FW-
VPNGW_V2.0). This PP-Configuration includes the following components:
o Base PP: collaborative Protection Profile for Network Devices, version 3.0e, dated 06
December 2023 (CPP_ND_V3.0E),
o PP-Module: collaborative Protection Profile Module for Stateful Traffic Filter
Firewalls, Version 1.4e, dated 25 June 2020 (MOD_CPP_FW_V1.4E),
o PP-Module: PP-Module for Virtual Private Network (VPN) Gateways, version 1.3,
dated 16 August 2023 (MOD_VPNGW_V1.3).
o PP-Module: PP-Module for Intrusion Prevention Systems (IPS), Version 1.0, dated
11 May 2021 (MOD_IPS_V1.0).
• Package: Functional Package for Secure Shell (SSH), Version 1.0, dated 13 May 2021
(PKG_SSH_V1.0)
The TOE identified in this VR has been evaluated at a NIAP approved Common Criteria Testing
Laboratory using the Common Methodology for IT Security Evaluation (Version 3.1, Rev. 5) for
conformance to the Common Criteria for IT Security Evaluation (Version 3.1, Rev. 5), as
interpreted by the Assurance Activities contained in the Protection Profile (PP). This VR applies
only to the specific version of the TOE as evaluated. The evaluation has been conducted in
accordance with the provisions of the NIAP Common Criteria Evaluation and Validation Scheme
5
and the conclusions of the testing laboratory in the ETR are consistent with the evidence
provided.
The validation team provided guidance on technical issues and evaluation processes and
reviewed the individual work units documented in the ETR and the Assurance Activities Report
(AAR). The validation team found that the evaluation showed that the product satisfies all of the
functional requirements and assurance requirements stated in the ST. Based on these findings,
the validation team concludes that the testing laboratory's findings are accurate, the conclusions
justified, and the conformance results are correct. The conclusions of the testing laboratory in the
ETR are consistent with the evidence produced.
6
2 Identification
The CCEVS is a joint National Security Agency (NSA) and National Institute of Standards
and Technology (NIST) effort to establish commercial facilities to perform trusted product
evaluations.
Under this program, security evaluations are conducted by commercial testing laboratories
called Common Criteria Testing Laboratories (CCTLs). CCTLs evaluate products against
PPs containing Assurance Activities, which are interpretations of Common Evaluation
Methodology (CEM) work units specific to the technology described by the claimed PP/PP-
Modules/Package.
The NIAP Validation Body assigns Validators to monitor the CCTLs to ensure quality and
consistency across evaluations. Developers of IT products desiring a security evaluation contract
with a CCTL and pay a fee for their product's evaluation. Upon successful completion of the
evaluation, the product is added to NIAP's Product Compliant List.
Table 1 provides information needed to completely identify the product, including:
• The Target of Evaluation (TOE): the fully qualified identifier of the product as evaluated.
• The Security Target (ST), describing the security features, claims, and assurances of the
product.
• The conformance result of the evaluation.
• The Protection Profile(s) to which the product is conformant.
• The organizations and individuals participating in the evaluation.
Table 1 Evaluation Identifiers
Item Identifier
Evaluation Scheme United States NIAP Common Criteria Evaluation and Validation Scheme
TOE Juniper NFX series Network Services Platform with Junos OS 23.4R1
Protection Profile • PP-Configuration for Network Devices, Intrusion Protection Systems, Stateful
Traffic Filter Firewalls, and Virtual Private Network Gateways, Version 2.0
(CFG_NDcPP-IPS-FW-VPNGW_V2.0). This PP-Configuration includes the
following components:
o Base PP: collaborative Protection Profile for Network Devices, version
3.0e, dated 06 December 2023 (CPP_ND_V3.0E),
o PP-Module: collaborative Protection Profile Module for Stateful Traffic
Filter Firewalls, Version 1.4e, dated 25 June 2020
(MOD_CPP_FW_V1.4E),
o PP-Module: PP-Module for Virtual Private Network (VPN) Gateways,
version 1.3, dated 16 August 2023 (MOD_VPNGW_V1.3).
o PP-Module: PP-Module for Intrusion Prevention Systems (IPS), Version
1.0, dated 11 May 2021 (MOD_IPS_V1.0).
• Package: Functional Package for Secure Shell (SSH), Version 1.0, dated 13 May
2021 (PKG_SSH_V1.0)
Security Target Juniper NFX series Network Services Platform with Junos OS 23.4R1Security Target,
Version 1.0
Evaluation Technical
Report
Evaluation Technical Report for Juniper NFX series Network Services Platform with
Junos OS 23.4R1 Version 1.2
7
Item Identifier
CC Version Version 3.1, Revision 5
Conformance Result CC Part 2 Extended and CC Part 3 Conformant
Sponsor Juniper Networks, Inc.
Developer Juniper Networks, Inc.
Common Criteria
Testing Lab (CCTL)
Acumen Security
Rockville, MD
CCEVS Validators Swapna Katikaneni, Meredith Martinez, DeRon Graves – The Aerospace Corporation
8
3 Architectural Information
The TOE is Juniper Networks, Inc. NFX series Network Services Platform with Junos OS 23.4R1.
The NFX series devices integrate routing, switching, and security functions on a single platform.
The devices support the definition of, and enforce, information flow policies among network
nodes, also providing for stateful inspection of every packet that traverses the network and central
management to manage the network security policy. All flow of information from one network
node to another passes through an instance of the TOE. Information flow is controlled on the basis
of network node addresses, protocol, type of access requested, and services requested. In support
of the information flow security functions, the TOE ensures that security-relevant activity is
audited, that their own functions are protected from potential attacks, and provides the security
tools to manage all of the security functions. The TOE provides multi-site Virtual Private Network
(VPN) gateway functionality, firewall functionality and also implements Intrusion Prevention
System (IPS) functionality, capable of monitoring information flows to detect potential attacks
based on pre-defined attack signature and anomaly characteristics in the traffic.
The deployment of the NFX series with Junos OS 23.4R1 TOE includes a hypervisor, which runs
a virtual machine (VM) on an NFX series hardware model:
• NFX150
o NFX150-C-S1
o NFX150-S1
o NFX150-S1E
• NFX250
o NFX250-S1
o NFX250-S1E
o NFX250-S2
• NFX350
o NFX350-S1
o NFX350-S2
o NFX350-S3
3.1 TOE Description
3.1.1 Physical boundary
The physical boundaries of the TOE is the NFX series hardware running Junos OS 23.4R1.
The Junos OS 23.4R1 software includes the KVM Hypervisor as well as the JCP and JDM
application container. Hence the TOE is contained within the physical boundary of each platform
specified in Section 1.3.3 of the ST. The TOE is delivered as a single device with the Junos OS
software installed. There are several mechanisms provided in the delivery process to ensure that
a customer receives a product that has not been tampered with, such as use of shipping labels,
well-sealed packaging and email notification containing details such as the carrier tracking
9
number, that can be compared with the ones on the received shipment. The TOE model number
can be verified through the shipping label and device front panel. The software version can be
verified by the show version command once the device is configured.
The Management platform and external syslog server are outside the boundary of the TOE.
Figure 1 below shows the general architecture for the NFX150.
Figure 1 NFX150 Software Architecture
Figure 2 below shows the general architecture for the NFX250 and NFX350.
10
Figure 2 NFX250/NFX350 Software Architecture
All the NFX devices support the installation of 3rd party VMs, but installation of 3rd party VMs
is not allowed in the evaluated configuration.
11
4 Security Policy
The logical boundary of the TOE includes the following security functionality:
Functionality Description
Protected Communications The TOE provides an SSH server to support protected communications for
administrators to establish secure management sessions and to connect to
external syslog servers.
The TOE also supports IPsec connections to provide multi-site virtual
private network (VPN) gateway functionality. The TOE requires that
applications exchanging information with it are successfully authenticated
prior to any exchange (i.e. applications connecting over SSH and IPsec).
Telnet, File Transfer Protocol (FTP), and Secure Socket Layer (SSL) are
out of scope.
The TOE includes cryptographic modules that provide the underlying
cryptographic services, including key management and protection of
stored keys, algorithms, random bit generation and crypto-administration.
The cryptographic modules provide confidentiality and integrity services
for authentication and for protecting communications with adjacent
systems.
Administrator Authentication Administrative users must provide unique identification and authentication
data before any administrative access to the system is granted.
Authentication data entered and stored on the TOE is protected. The TOE
can be configured to terminate inactive user sessions and to present an
access banner with warning messages prior to authentication.
Correct Operation The TOE provides for both cryptographic and non-cryptographic self-tests
and is capable of automated recovery from failure states.
Trusted Update The administrator can initiate update of the TOE software. The integrity
of any software updates is verified prior to installation of the updated
software using digital signatures.
Audit TOE auditable events are stored in the syslog files in the VM filesystem
and can be sent to an external log server (via Netconf over SSH).
Auditable events include start-up and shutdown of the audit functions,
authentication events, service requests, IPS events, as well as the events
listed in Table 14 and Table 15 of ST. Audit records include the date and
time, event category, event type, username, and the outcome of the event
(success or failure). Local (VM) syslog storage limits are configurable and
are monitored. In the event of storage limits being reached, the oldest logs
are overwritten.
Management The TOE provides a Security Administrator role that is responsible for:
• the configuration and maintenance of cryptographic elements
related to the establishment of secure connections to and from the
evaluated product
• the regular review of all audit data;
• initiation of trusted update function;
• administration of VPN, IPS and Firewall functionality;
• all administrative tasks (e.g., creating the security policy).
12
Functionality Description
The devices are managed through a Command Line Interface (CLI). The
CLI is accessible through local (serial) console connection or remote
administrative (SSH) session.
The Security Administrator role includes the capability to manage all NFX
services. Access to manage the device’s FreeBSD host can only be gained
through the JCP.
Packet Filtering/Stateful Traffic
Filtering
The TOE provides stateful network traffic filtering for IP-based (IPv4 as
well as IPv6) traffic, based on examination of network packets and the
application of information flow rules.
This functionality is common across all three NFX devices and involves no
cryptographic operations in terms of processing.
Intrusion Prevention The TOE can be configured to analyze IP-based (IPv4 as well as IPv6)
network traffic forwarded to the TOE’s interfaces and detect violations of
administratively-defined IPS policies. The TOE is capable of initiating a
proactive response to terminate/interrupt an active potential threat, and to
initiate a response in real time that would cause interruption of the
suspicious traffic flow.
The IPS functionality is common across all three NFX devices and involves
no cryptographic operations in terms of processing.
User Data Protection/Information
Flow Control
The TOE is designed to forward IP-based (IPv4 as well as IPv6) network
packets (i.e., information flows) from source network entities to destination
network entities based on available routing information using Virtual
Routers. This information is either provided directly by TOE users or
indirectly from other network entities (outside the TOE) configured by the
TOE users. The TOE has the capability to regulate the information flow
across its interfaces; traffic filters can be set in accordance with the
presumed identity of the source, the identity of the destination, the transport
layer protocol, the source service identifier, and the destination service
identifier (TCP or UDP port number).
Table 2 TOE Logical Boundary
13
5 Assumptions, Threats & Clarification of Scope
5.1 Assumptions
The specific conditions listed in the following subsections are assumed to exist in the TOE’s
environment. These assumptions include both practical realities in the development of the TOE
security requirements and the essential environmental conditions on the use of the TOE.
The assumptions included in Table 3 are drawn directly from the claimed PP/PP-
Modules/Package.
ID Assumption
A.PHYSICAL_PROTECTION The Network Device is assumed to be physically protected
in its operational environment and not subject to physical
attacks that compromise the security or interfere with the
device’s physical interconnections and correct operation.
This protection is assumed to be sufficient to protect the
device and the data it contains. As a result, the cPP does
not include any requirements on physical tamper
protection or other physical attack mitigations. The cPP
does not expect the product to defend against physical
access to the device that allows unauthorized entities to
extract data, bypass other controls, or otherwise
manipulate the device. For vNDs, this assumption applies
to the physical platform on which the VM runs.
A.LIMITED_FUNCTIONALITY The device is assumed to provide networking functionality
as its core function and not provide functionality/services
that could be deemed as general purpose computing. For
example, the device should not provide a computing
platform for general purpose applications (unrelated to
networking functionality).
(NOTE: following paragraph is for virtual network
devices. Please delete if the TOE is not a virtual device)
In the case of vNDs, the VS is considered part of the TOE
with only one vND instance for each physical hardware
platform. The exception being where components of the
distributed TOE run inside more than one virtual machine
(VM) on a single VS. There are no other guest VMs on the
physical platform providing non-Network Device
functionality.
14
ID Assumption
A.NO_THRU_TRAFFIC_PROTECTION1
A standard/generic Network Device does not provide any
assurance regarding the protection of traffic that traverses
it. The intent is for the Network Device to protect data that
originates on or is destined to the device itself, to include
administrative data and audit data. Traffic that is traversing
the Network Device, destined for another network entity,
is not covered by the ND cPP. It is assumed that this
protection will be covered by cPPs and PP-Modules for
particular types of Network Devices (e.g., firewall).
A.TRUSTED_ADMINISTRATOR The Security Administrator(s) for the Network Device are
assumed to be trusted and to act in the best interest of
security for the organization. This includes appropriately
trained, following policy, and adhering to guidance
documentation. Administrators are trusted to ensure
passwords/credentials have sufficient strength and entropy
and to lack malicious intent when administering the
device. The Network Device is not expected to be capable
of defending against a malicious Administrator that
actively works to bypass or compromise the security of the
device.
(The paragraph that follows is for x509v3 cert-based
authentication. If not relevant, remove)
For TOEs supporting X.509v3 certificate-based
authentication, the Security Administrator(s) are expected
to fully validate (e.g. offline verification) any CA
certificate (root CA certificate or intermediate CA
certificate) loaded into the TOE’s trust store (aka 'root
store', ' trusted CA Key Store', or similar) as a trust anchor
prior to use (e.g. offline verification).
A.REGULAR_UPDATES The Network Device firmware and software is assumed to
be updated by an Administrator on a regular basis in
response to the release of product updates due to known
vulnerabilities.
A.ADMIN_CREDENTIALS_SECURE The Administrator’s credentials (private key) used to
access the Network Device are protected by the platform
on which they reside.
A.RESIDUAL_INFORMATION The Administrator must ensure that there is no
unauthorized access possible for sensitive residual
information (e.g. cryptographic keys, keying material,
PINs, passwords etc.) on networking equipment when the
equipment is discarded or removed from its operational
environment.
A.CONNECTIONS (IPS) It is assumed that the TOE is connected to distinct
networks in a manner that ensures that the TOE security
1
A.NO_THRU_TRAFFIC_PROTECTION is still operative, but only for the interfaces in the TOE that are defined
by the Base-PP and not the PP-Module.
15
ID Assumption
policies will be enforced on all applicable network traffic
flowing among the attached networks.
A.CONNECTIONS (VPNGW) It is assumed that the TOE is connected to distinct
networks in a manner that ensures that the TOE security
policies will be enforced on all applicable network traffic
flowing among the attached networks.
Table 3 Assumptions
5.2 Threats
The following table lists the threats addressed by the TOE and the IT Environment. The
assumed level of expertise of the attacker for all the threats identified below is Enhanced-Basic.
The threats included in Table 4 are drawn directly from the claimed PP/PP-Modules/Package
specified in Section 2.2 of the ST.
ID Threat
T.UNAUTHORIZED_ADMINISTRATOR_ACCESS Threat agents may attempt to gain Administrator
access to the Network Device by nefarious means such
as masquerading as an Administrator to the device,
masquerading as the device to an Administrator,
replaying an administrative session (in its entirety, or
selected portions), or performing man-in-the-middle
attacks, which would provide access to the
administrative session, or sessions between Network
Devices. Successfully gaining Administrator access
allows malicious actions that compromise the security
functionality of the device and the network on which it
resides.
T.WEAK_CRYPTOGRAPHY Threat agents may exploit weak cryptographic
algorithms or perform a cryptographic exhaust against
the key space. Poorly chosen encryption algorithms,
modes, and key sizes will allow attackers to
compromise the algorithms, or brute force exhaust the
key space and give them unauthorized access allowing
them to read, manipulate and/or control the traffic with
minimal effort.
T.UNTRUSTED_COMMUNICATION_CHANNELS Threat agents may attempt to target Network Devices
that do not use standardized secure tunnelling
protocols to protect the critical network traffic.
Attackers may take advantage of poorly designed
protocols or poor key management to successfully
perform man-in-the-middle attacks, replay attacks, etc.
Successful attacks will result in loss of confidentiality
and integrity of the critical network traffic, and
potentially could lead to a compromise of the Network
Device itself.
T.WEAK_AUTHENTICATION_ENDPOINTS Threat agents may take advantage of secure protocols
that use weak methods to authenticate the endpoints,
e.g. a shared password that is guessable or transported
as plaintext. The consequences are the same as a
16
ID Threat
poorly designed protocol, the attacker could
masquerade as the Administrator or another device,
and the attacker could insert themselves into the
network stream and perform a man-in-the-middle
attack. The result is the critical network traffic is
exposed and there could be a loss of confidentiality
and integrity, and potentially the Network Device
itself could be compromised.
T.UPDATE_COMPROMISE Threat agents may attempt to provide a compromised
update of the software or firmware which undermines
the security functionality of the device. Non-validated
updates or updates validated using non-secure or weak
cryptography leave the update firmware vulnerable to
surreptitious alteration.
T.UNDETECTED_ACTIVITY Threat agents may attempt to access, change, and/or
modify the security functionality of the Network
Device without Administrator awareness. This could
result in the attacker finding an avenue (e.g.,
misconfiguration, flaw in the product) to compromise
the device and the Administrator would have no
knowledge that the device has been compromised.
T.SECURITY_FUNCTIONALITY_COMPROMISE Threat agents may compromise credentials and device
data enabling continued access to the Network Device
and its critical data. The compromise of credentials
includes replacing existing credentials with an
attacker’s credentials, modifying existing credentials,
or obtaining the Administrator or device credentials
for use by the attacker.
T.SECURITY_FUNCTIONALITY_FAILURE An external, unauthorized entity could make use of
failed or compromised security functionality and
might therefore subsequently use or abuse security
functions without prior authentication to access,
change or modify device data, critical network traffic
or security functionality of the device.
T.NETWORK_DISCLOSURE (FFW) An attacker may attempt to “map” a subnet to
determine the machines that reside on the network,
and obtaining the IP addresses of machines, as well as
the services (ports) those machines are offering. This
information could be used to mount attacks to those
machines via the services that are exported.
T.NETWORK_ACCESS (FFW) With knowledge of the services that are exported by
machines on a subnet, an attacker may attempt to
exploit those services by mounting attacks against
those services.
T.NETWORK_MISUSE (FFW) An attacker may attempt to use services that are
exported by machines in a way that is unintended by a
site’s security policies. For example, an attacker might
be able to use a service to “anonymize” the attacker’s
machine as they mount attacks against others.
T.MALICIOUS TRAFFIC (FFW) An attacker may attempt to send malformed packets to
a machine in hopes of causing the network stack or
17
ID Threat
services listening on UDP/TCP ports of the target
machine to crash.
T.NETWORK_DISCLOSURE (IPS) Sensitive information on a protected network might be
disclosed resulting from ingress- or egress-based
actions.
T.NETWORK_ACCESS (IPS) Unauthorized access may be achieved to services on a
protected network from outside that network, or
alternately services outside a protected network from
inside the protected network. If malicious external
devices are able to communicate with devices on the
protected network via a backdoor then those devices
may be susceptible to the unauthorized disclosure of
information.
T.NETWORK_MISUSE (IPS) Access to services made available by a protected
network might be used counter to Operational
Environment policies. Devices located outside the
protected network may attempt to conduct
inappropriate activities while communicating with
allowed public services. E.g. manipulation of resident
tools, SQL injection, phishing, forced resets, malicious
zip files, disguised executables, privilege escalation
tools and botnets.
T.NETWORK_DOS (IPS) Attacks against services inside a protected network, or
indirectly by virtue of access to malicious agents from
within a protected network, might lead to denial of
services otherwise available within a protected
network. Resource exhaustion may occur in the event
of co-ordinate service request flooding from a small
number of sources .
T.DATA INTEGRITY (VPNGW) Devices on a protected network may be exposed to
threats presented by devices located outside the
protected network, which may attempt to modify the
data without authorization. If known malicious
external devices are able to communicate with devices
on the protected network or if devices on the protected
network can communicate with those external devices
then the data contained within the communications
may be susceptible to a loss of integrity.
T.NETWORK_ACCESS (VPNGW) Devices located outside the protected network may
seek to exercise services located on the protected
network that are intended to only be accessed from
inside the protected network or only accessed by
entities using an authenticated path into the protected
network. Devices located outside the protected
network may, likewise, offer services that are
inappropriate for access from within the protected
network.
From an ingress perspective, VPN gateways can be
configured so that only those network servers intended
for external consumption by entities operating on a
trusted network (e.g., machines operating on a network
18
ID Threat
where the peer VPN gateways are supporting the
connection) are accessible and only via the intended
ports. This serves to mitigate the potential for network
entities outside a protected network to access network
servers or services intended only for consumption or
access inside a protected network.
From an egress perspective, VPN gateways can be
configured so that only specific external services (e.g.,
based on destination port) can be accessed from within
a protected network, or moreover are accessed via an
encrypted channel. For example, access to external
mail services can be blocked to enforce corporate
policies against accessing uncontrolled e-mail servers,
or, that access to the mail server must be done over an
encrypted link.
T.NETWORK_DISCLOSURE (VPNGW) Devices on a protected network may be exposed to
threats presented by devices located outside the
protected network, which may attempt to conduct
unauthorized activities. If known malicious external
devices are able to communicate with devices on the
protected network, or if devices on the protected
network can establish communications with those
external devices (e.g., as a result of a phishing episode
or by inadvertent responses to email messages), then
those internal devices may be susceptible to the
unauthorized disclosure of information.
From an infiltration perspective, VPN gateways serve
not only to limit access to only specific destination
network addresses and ports within a protected
network, but whether network traffic will be encrypted
or transmitted in plaintext. With these limits, general
network port scanning can be 8 prevented from
reaching protected networks or machines, and access
to information on a protected network can be limited
to that obtainable from specifically configured ports
on identified network nodes (e.g., web pages from a
designated corporate web server). Additionally, access
can be limited to only specific source addresses and
ports so that specific networks or network nodes can
be blocked from accessing a protected network
thereby further limiting the potential disclosure of
information.
From an exfiltration perspective, VPN gateways serve
to limit how network nodes operating on a protected
network can connect to and communicate with other
networks limiting how and where they can disseminate
information. Specific external networks can be
blocked altogether or egress could be limited to
specific addresses and/or ports. Alternately, egress
options available to network nodes on a protected
network can be carefully managed in order to, for
example, ensure that outgoing connections are
19
ID Threat
encrypted to further mitigate inappropriate disclosure
of data through packet sniffing.
T.NETWORK_MISUSE (VPNGW) Devices located outside the protected network, while
permitted to access particular public services offered
inside the protected network, may attempt to conduct
inappropriate activities while communicating with
those allowed public services. Certain services offered
from within a protected network may also represent a
risk when accessed from outside the protected
network.
From an ingress perspective, it is generally assumed
that entities operating on external networks are not
bound by the use policies for a given protected
network. Nonetheless, VPN gateways can log policy
violations that might indicate violation of publicized
usage statements for publicly available services.
From an egress perspective, VPN gateways can be
configured to help enforce and monitor protected
network use policies. As explained in the other threats,
a VPN gateway can serve to limit dissemination of
data, access to external servers, and even disruption of
services – all of these could be related to the use
policies of a protected network and as such are subject
in some regards to enforcement. Additionally, VPN
gateways can be configured to log network usages that
cross between protected and external networks and as
a result can serve to identify potential usage policy
violations.
T.REPLAY_ATTACK (VPNGW) If an unauthorized individual successfully gains access
to the system, the adversary may have the opportunity
to conduct a “replay” attack. This method of attack
allows the individual to capture packets traversing
throughout the network and send the packets at a later
time, possibly unknown by the intended receiver.
Traffic is subject to replay if it meets the following
conditions:
Cleartext: an attacker with the ability to view
unencrypted traffic can identify an appropriate
segment of the communications to replay as well in
order to cause the desired outcome.
No integrity: alongside cleartext traffic, an attacker
can make arbitrary modifications to captured traffic
and replay it to cause the desired outcome if the
recipient has no means to detect these.
Table 4 Threats
5.3 Clarification of Scope
All evaluations (and all products) have limitations, as well as potential misconceptions that need
clarifying. This text covers some of the more important limitations and clarifications of this
evaluation. Note that:
20
• As with any evaluation, this evaluation only shows that the evaluated configuration meets
the security claims made, with a certain level of assurance. The level of assurance for this
evaluation is defined within the claimed PP/PP-Modules/Package.
o PP-Configuration for Network Devices, Intrusion Protection Systems, Stateful
Traffic Filter Firewalls, and Virtual Private Network Gateways, Version 2.0
(CFG_NDcPP-IPS-FW-VPNGW_V2.0). This PP-Configuration includes the
following components:
▪ Base PP: collaborative Protection Profile for Network Devices, version
3.0e, dated 06 December 2023 (CPP_ND_V3.0E),
▪ PP-Module: collaborative Protection Profile Module for Stateful Traffic
Filter Firewalls, Version 1.4e, dated 25 June 2020
(MOD_CPP_FW_V1.4E),
▪ PP-Module: PP-Module for Virtual Private Network (VPN) Gateways,
version 1.3, dated 16 August 2023 (MOD_VPNGW_V1.3).
▪ PP-Module: PP-Module for Intrusion Prevention Systems (IPS), Version
1.0, dated 11 May 2021 (MOD_IPS_V1.0).
o Package: Functional Package for Secure Shell (SSH), Version 1.0, dated 13 May
2021 (PKG_SSH_V1.0)
• Consistent with the expectations of the PP, this evaluation did not specifically search for,
nor seriously attempt to counter, vulnerabilities that were not “obvious” or vulnerabilities
to objectives not claimed in the ST. The CEM defines an “obvious” vulnerability as one
that is easily exploited with a minimum of understanding of the TOE, technical
sophistication and resources.
• The evaluation of security functionality of the product was limited to the functionality
specified in the claimed PPs. Any additional security related functional capabilities
included in the product were not covered by this evaluation.
21
6 Documentation
The following documents were provided by the vendor with the TOE for evaluation:
• Junos OS Common Criteria Configuration Guide for NFX150, NFX250, and NFX350
Network Services Platforms (Release 23.4R1)
• Junos OS Intrusion Detection and Prevention User Guide (Published 2025-03-28)
• IPsec VPN User Guide (Published 2025-06-23)
Any additional customer documentation provided with the product, or that is available online
was not included in the scope of the evaluation and therefore should not be relied upon when
configuring or operating the device as evaluated.
To use the product in the evaluated configuration, the product must be configured as specified in
the Guidance Documentation listed above. Consumers are encouraged to download the
configuration guides from the NIAP website to ensure the device is configured as evaluated.
22
7 TOE Evaluated Configuration
7.1 Evaluated Configuration
The TOE is Juniper Networks, Inc. NFX series Network Services Platform with Junos OS
23.4R1. The NFX series devices integrate routing, switching, and security functions on a single
platform.
The deployment of the NFX series with Junos OS 23.4R1 TOE includes a hypervisor, which
runs a virtual machine (VM) on an NFX series hardware model:
• NFX150
o NFX150-C-S1
o NFX150-S1
o NFX150-S1E
• NFX250
o NFX250-S1
o NFX250-S1E
o NFX250-S2
• NFX350
o NFX350-S1
o NFX350-S2
o NFX350-S3
The following environmental components are required to operate the TOE in the evaluated
configuration:
Components Mandatory/Optional Description
Remote Management
System
Mandatory The remote management system is used
by an administrator to establish a
connection using an SSHv2 client to
configure the TOE.
Local Management
System
Mandatory The local management system is used by
an administrator to configure the TOE
over a serial console connection.
Audit Server Mandatory The audit server supports an SSHv2
client which inititates the trusted channel
between itself and the TOE for
transmission of logs using the netconf
utility.
VPN Peer Optional The VPN peer is a dedicated IPsec
interface that establishes an IPsec tunnel
with the VPN gateway of the TOE,
which supports both IKEv1 and IKEv2.
23
Components Mandatory/Optional Description
CRL Server Mandatory The CRL server, over HTTP/1.0,
supports revocation checking of
certificates used by the TOE for IPsec
tunnels.
Table 5 Required Environmental Components
7.2 Excluded Functionality
The following product functionalities are disabled in the CC-evaluated configuration of the TOE:
• Use of telnet, since it violates the Trusted Path requirement set
• Use of FTP, since it violates the Trusted Path requirement set
• Use of SSL, including management via J-Web, JUNOScript and JUNOScope, since it
violates the Trusted Path requirement set
The following product functionalities are supported by the product but not covered by the CC
evaluation and are hence expected to not be used when deployed in a CC configuration:
• Use of SNMP, since it violates the Trusted Path requirement set
• Use of the Junos or Linux root account.
• Hosting additional VMs on the TOE physical platform.
• Use of routing protocols such as OSPF, BGP and RIP.
In general, any product functionality not covered by the Protection Profile, Modules or Packages
mentioned in Section 2.2 of the ST are not covered by the CC evaluation.
24
8 IT Product Testing
This section describes the testing efforts of the developer and the evaluation team. It is derived
from information contained in ETR for Juniper NFX series Network Services Platform with
Junos OS 23.4R1, which is not publicly available. The AAR provides an overview of testing
and the prescribed assurance activities.
8.1 Developer Testing
No evidence of developer testing is required in the Assurance Activities for this product.
8.2 Evaluation Team Independent Testing
The evaluation team verified the product according to the vendor-provided guidance
documentation and ran the tests specified in the claimed PP/PP-Modules/Package listed below.
• PP-Configuration for Network Devices, Intrusion Protection Systems, Stateful Traffic Filter
Firewalls, and Virtual Private Network Gateways, Version 2.0 (CFG_NDcPP-IPS-FW-
VPNGW_V2.0). This PP-Configuration includes the following components:
o Base PP: collaborative Protection Profile for Network Devices, version 3.0e, dated 06
December 2023 (CPP_ND_V3.0E),
o PP-Module: collaborative Protection Profile Module for Stateful Traffic Filter
Firewalls, Version 1.4e, dated 25 June 2020 (MOD_CPP_FW_V1.4E),
o PP-Module: PP-Module for Virtual Private Network (VPN) Gateways, version 1.3,
dated 16 August 2023 (MOD_VPNGW_V1.3).
o PP-Module: PP-Module for Intrusion Prevention Systems (IPS), Version 1.0, dated
11 May 2021 (MOD_IPS_V1.0).
• Package: Functional Package for Secure Shell (SSH), Version 1.0, dated 13 May 2021
(PKG_SSH_V1.0)
The Independent Testing activity is documented in the AAR, which is publicly available, and is
not duplicated here.
The test configuration diagram and list of test tools and versions used during the test activities
can be found in the AAR, Section 4.
25
9 Results of the Evaluation
The results of the assurance requirements are generally described in this section and are
presented in detail in the proprietary documents: the Detailed Test Report (DTR) and the ETR.
The reader of this document can assume that all activities and work units received a passing
verdict.
A verdict for an assurance component is determined by the resulting verdicts assigned to the
corresponding evaluator action elements. The evaluation was conducted based upon CC version
3.1 Rev. (5) and CEM version 3.1 Rev. (5). The evaluation determined the TOE Name to be Part
2 extended, and meets the SARs contained in the PP. Additionally, the evaluator performed the
Assurance Activities specified in the claimed PP/PP-Modules/Package.
9.1 Evaluation of Security Target
The evaluation team applied each ASE CEM work unit. The ST evaluation ensured the ST
contains a description of the environment in terms of policies and assumptions, a statement of
security requirements claimed to be met by the Juniper NFX series Network Services Platform
with Junos OS 23.4R1 that are consistent with the Common Criteria, and product security
function descriptions that support the requirements. Additionally, the evaluator performed an
assessment of the Assurance Activities specified in the claimed PP/PP-Modules/Package.
The validator reviewed the work of the evaluation team and found that sufficient evidence and
justification was provided by the evaluation team to confirm that the evaluation was conducted in
accordance with the requirements of the CEM, and that the conclusion reached by the evaluation
team was justified.
9.2 Evaluation of Development Documentation
The evaluation team applied each ADV CEM work unit. The evaluation team assessed the
design documentation and found it adequate to aid in understanding how the TSF provides the
security functions. The design documentation consists of a functional specification contained in
the ST's TOE Summary Specification. Additionally, the evaluator performed the Assurance
Activities specified in the claimed PP/PP-Modules/Package related to the examination of the
information contained in the TOE Summary Specification.
The validator reviewed the work of the evaluation team and found that sufficient evidence and
justification was provided by the evaluation team to confirm that the evaluation was conducted
in accordance with the Assurance Activities, and that the conclusion reached by the evaluation
team was justified.
9.3 Evaluation of Guidance Documents
The evaluation team applied each AGD CEM work unit. The evaluation team ensured the
adequacy of the user guidance in describing how to use the operational TOE. Additionally, the
evaluation team ensured the adequacy of the administrator guidance in describing how to
securely administer the TOE. The guides were assessed during the design and testing phases of
26
the evaluation to ensure they were complete. Additionally, the evaluator performed the
Assurance Activities specified in the claimed PP/PP-Modules/Package related to the examination
of the information contained in the operational guidance documents.
The validator reviewed the work of the evaluation team and found that sufficient evidence and
justification was provided by the evaluation team to confirm that the evaluation was conducted in
accordance with the Assurance Activities, and that the conclusion reached by the evaluation team
was justified.
9.4 Evaluation of Life Cycle Support Activities
The evaluation team applied each ALC CEM work unit. The evaluation team found that the TOE
was identified.
The validator reviewed the work of the evaluation team and found that sufficient evidence and
justification was provided by the evaluation team to confirm that the evaluation was conducted in
accordance with the requirements of the CEM, and that the conclusion reached by the evaluation
team was justified.
9.5 Evaluation of Test Documentation and the Test Activity
The evaluation team applied each ATE CEM work unit. The evaluation team ran the set of tests
specified by the Assurance Activities in the claimed PP/PP-Modules/Package and recorded the
results in a Test Report, summarized in the ETR and AAR.
The validator reviewed the work of the evaluation team and found that sufficient evidence was
provided by the evaluation team to show that the evaluation activities addressed the test activities
in the claimed PP/PP-Modules/Package, and that the conclusion reached by the evaluation team
was justified.
9.6 Vulnerability Assessment Activity
The evaluation team applied each AVA CEM work unit. The evaluation team performed a public
search for vulnerabilities, performed vulnerability testing on 11/26/2025and did not discover any
issues with the TOE.
Details of this vulnerability analysis, including the databases searched and the search terms can
be found in Section 6 of the AAR.
The validator reviewed the work of the evaluation team and found that sufficient evidence and
justification was provided by the evaluation team to confirm that the evaluation addressed the
vulnerability analysis Assurance Activities in the claimed PP/PP-Modules/Package, and that the
conclusion reached by the evaluation team was justified.
The validators noted that the discovered vulnerabilities are not applicable to the TOE in the
evaluated configuration. The features to which the vulnerabilities are applicable are disabled by
default in the evaluated configuration. The user guidance provides the mitigation methods if the
TOE is placed outside the evaluated configuration by enabling those features.
27
9.7 Summary of Evaluation Results
The evaluation team's assessment of the evaluation evidence demonstrates that the claims in the
ST are met. Additionally, the evaluation team's test activities also demonstrated the accuracy of
the claims in the ST.
The validation team's assessment of the evidence provided by the evaluation team is that it
demonstrates that the evaluation team performed the Assurance Activities in the claimed PP/PP-
Modules/Package, and correctly verified that the product meets the claims in the ST.
28
10 Validator Comments & Recommendations
The BGP, OSPF/ISIS TE, EVPN, and VXLAN vulnerable functionalities are all outside the
scope of the evaluation and are disabled by default in the evaluated configuration. The product
has not been evaluated with these features enabled and by enabling them, the operators are
stepping out of an evaluated configuration. To fully mitigate the CVEs applicable to these
features, it is highly recommended to keep them disabled.
29
11 Annexes
Not applicable.
30
12 Security Target
Juniper NFX series Network Services Platform with Junos OS 23.4R1 Security Target v1.0
31
13 Glossary
The following definitions are used throughout this document:
• Common Criteria Testing Laboratory (CCTL). An IT security evaluation facility
accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and
approved by the CCEVS Validation Body to conduct Common Criteria-based
evaluations.
• Conformance. The ability to demonstrate in an unambiguous way that a given
implementation is correct with respect to the formal model.
• Evaluation. The assessment of an IT product against the Common Criteria using the
Common Criteria Evaluation Methodology to determine whether or not the claims made
are justified; or the assessment of a protection profile against the Common Criteria using
the Common Evaluation Methodology to determine if the Profile is complete, consistent,
technically sound and hence suitable for use as a statement of requirements for one or
more TOEs that may be evaluated.
• Evaluation Evidence. Any tangible resource (information) required from the sponsor or
developer by the evaluator to perform one or more evaluation activities.
• Feature. Part of a product that is either included with the product or can be ordered
separately.
• Target of Evaluation (TOE). A group of IT products configured as an IT system, or an
IT product, and associated documentation that is the subject of a security evaluation
under the CC.
• Validation. The process carried out by the CCEVS Validation Body leading to the issue
of a Common Criteria certificate.
• Validation Body. A governmental organization responsible for carrying out validation
and for overseeing the day-to-day operation of the NIAP Common Criteria Evaluation
and Validation Scheme.
32
14 Bibliography
The Validation Team used the following documents to produce this Validation Report:
1. Assurance Activity Report for Juniper NFX series Network Services Platform with Junos
OS 23.4R1 v1.3.
2. Common Criteria for Information Technology Security Evaluation - Part 1: Introduction
and general model, Version 3.1 Revision 5.
3. Common Criteria for Information Technology Security Evaluation - Part 2: Security
functional requirements, Version 3.1 Revision 5.
4. Common Criteria for Information Technology Security Evaluation - Part 3: Security
assurance requirements, Version 3.1 Revision 5.
5. Common Evaluation Methodology for Information Technology Security Evaluation,
Version 3.1 Revision 5.
6. Evaluation Technical Report for Juniper NFX series Network Services Platform with
Junos OS 23.4R1 v1.2.
7. Junos OS Common Criteria Configuration Guide for NFX150, NFX250, and NFX350
Network Services Platforms (Release 23.4R1)
8. Junos OS Intrusion Detection and Prevention User Guide (Published 2025-03-28)
9. IPsec VPN User Guide (Published 2025-06-23)
10. PP-Configuration:
• PP-Configuration for Network Devices, Intrusion Protection Systems, Stateful Traffic
Filter Firewalls, and Virtual Private Network Gateways, Version 2.0 (CFG_NDcPP-
IPS-FW-VPNGW_V2.0).
11. PP/PP-Modules/Package:
• Base PP: collaborative Protection Profile for Network Devices, version 3.0e, dated 06
December 2023 (CPP_ND_V3.0E),
• PP-Module: collaborative Protection Profile Module for Stateful Traffic Filter
Firewalls, Version 1.4e, dated 25 June 2020 (MOD_CPP_FW_V1.4E),
• PP-Module: PP-Module for Virtual Private Network (VPN) Gateways, version 1.3,
dated 16 August 2023 (MOD_VPNGW_V1.3).
• PP-Module: PP-Module for Intrusion Prevention Systems (IPS), Version 1.0, dated
11 May 2021 (MOD_IPS_V1.0).
• Package: Functional Package for Secure Shell (SSH), Version 1.0, dated 13 May
2021 (PKG_SSH_V1.0)
12. Juniper NFX series Network Services Platform with Junos OS 23.4R1 Security Target
v1.0