Cisco APIC Security Configuration Guide, Release 6.2(x)

Endpoint security groups

Updated: April 17, 2026

Want to summarize with AI?

Endpoint security groups (ESGs) define security zones that can span multiple bridge domains within a single virtual routing and forwarding (VRF) instance.

An ESG is a logical collection of physical or virtual endpoints that share the same security requirements.

An ESG is associated with one VRF instance rather than one bridge domain.
Selectors classify endpoints into an ESG by attributes such as IPv4 addresses, IPv6 addresses, or endpoint tags.
Contracts enforce communication policies between ESGs.
Endpoint groups (EPGs), bridge domains, and other networking objects continue to provide the forwarding configuration.

ESG membership and policy enforcement

ESGs separate security classification from the forwarding configuration of an EPG. This separation allows one security zone to include endpoints from different bridge domains in the same VRF instance.

A selector defines the matching criteria for ESG membership.
A contract defines the traffic that can pass between ESGs.
Endpoints on external devices can be classified into ESGs and communicate through contracts across the fabric.

Contracts between an EPG and an ESG are not supported.

EPG and ESG comparison


Attribute	EPG	ESG
Association	One bridge domain	One VRF instance
Segmentation function	Forwarding and security segmentation	Security segmentation
Classification attributes	VLAN and interface bindings	IPv4 addresses, IPv6 addresses, and endpoint tags
Contract usage	Contracts between EPGs	Contracts between ESGs

Figure 1. Cisco ACI segmentation options

Traffic filtering between ESGs

ESG-to-ESG traffic filtering applies security policy independently of the bridge domains and endpoint groups (EPGs) that provide endpoint forwarding.

Endpoints from different bridge domains and subnets can belong to the same ESG.
By default, endpoints in the same ESG can communicate without an inter-ESG contract.
Endpoints in different ESGs require a contract between the ESGs to communicate.

Endpoint forwarding example

In this example, each EPG associates a VLAN with a bridge domain:


EPG	VLAN	Bridge domain
EPG1-1	10	BD1
EPG2-1	20	BD2
EPG3-1	30	BD3
EPG4-1	40	BD4

The ESG selectors group the endpoints independently of these forwarding associations:

Endpoints 192.168.1.11 on VLAN 10 and 192.168.2.11 on VLAN 20 belong to the same ESG even though they use different subnets and bridge domains.
Endpoints 192.168.3.11 on VLAN 30 and 192.168.4.11 on VLAN 40 belong to another ESG even though they use different subnets and bridge domains.

Communication policy


ESG relationship	Default communication behavior
Same ESG	Endpoints can communicate without an inter-ESG contract.
Different ESGs	A contract between the ESGs must permit the traffic.

A contract that is used by EPGs cannot be reused by ESGs. Similarly, a contract that is used by ESGs cannot be reused by EPGs.

Figure 2. ESGs aggregate endpoints from different subnets

Traffic filtering between an external network and an ESG

Outside-to-ESG traffic filtering uses a contract relationship between an L3Out external EPG and an ESG.

The L3Out external EPG provides or consumes the contract.
The ESG consumes or provides the corresponding contract.
From the L3Out perspective, a contract relationship with an ESG operates similarly to a contract relationship with an application EPG.

External connectivity

The L3Out external EPG is represented by the l3extInstP managed object. Associate the required contract with the external EPG and the ESG to permit matching traffic between them.

Figure 3. ESG connectivity through an L3Out external EPG

External subnet membership

Beginning with Cisco Application Policy Infrastructure Controller (APIC) Release 6.1(4), an ESG can represent external subnets and endpoints in addition to internal subnets and endpoints.

You can create an ESG that contains only external subnets and endpoints.
You can create an ESG that contains both internal and external subnets or endpoints.

Figure 4. External subnets in ESGs beginning with Cisco APIC Release 6.1(4)

ESG implementation

An ESG associates endpoints in one VRF instance with a common security policy.

Selectors determine which endpoints in the VRF instance belong to the ESG.
The ESG is available on the leaf switches where its associated VRF instance is deployed.
Contracts between ESGs create security rules in the policy content-addressable memory (CAM) of the applicable leaf switches.

VRF and forwarding behavior

The VRF instance can use ingress or egress policy enforcement.
All bridge domain subnets in the associated VRF instance are installed as static routes to the spine proxy on every leaf switch where the VRF instance is present.
Endpoint groups (EPGs) remain responsible for forwarding configuration, including VLAN bindings on leaf switch interfaces.

Deployment immediacy

With On-demand deployment, the fabric programs ESG contract rules on a leaf switch only after the switch learns an endpoint that matches the ESG selectors.

Beginning with Cisco Application Policy Infrastructure Controller (APIC) Release 6.1(4), you can select Immediate deployment for an ESG.

The fabric automatically enforces Immediate deployment when the ESG contains any of the following selectors:

An external subnet selector
An external EPG selector
A tag selector that matches an external prefix or subnet

For more information about configuring deployment immediacy, see 12.c .

Contract programming

Contracts between ESGs create security rules in the leaf switch ternary content-addressable memory (TCAM).

ESG contracts enforce traffic policy between security groups.
ESG contracts do not deploy subnets or other forwarding configuration.
ESG contracts do not perform route leaking.

ESG class identifier

Cisco APIC assigns each ESG a unique class identifier, which is also called a policy control tag (pcTag).

A local pcTag is unique within a VRF instance.
A global pcTag is unique across the fabric.
ESGs always use global pcTag values.

Need help?

Open a support case

(Requires a Cisco Service Contract)

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.