Skip to main content
Cisco Meraki Documentation

Adaptive Policy Overview

Meraki branded green tag graphics


This document covers Adaptive Policy at a fairly high level and is intended to be a primer to the configuration and troubleshooting documents that are linked in the Additional Resources Section below. 

Traditional network security has been founded on the use of IP based access controls. As businesses evolve to an increasing online presence the need for network security has never been more important for maintaining business continuity. Cisco Meraki has always provided a robust approach to securing network access whether it be through the use of ACLs and/or through Group Policies. These group policies however become difficult to scale with organizations that continue to evolve and expand. 

As networks grow and the user base and devices multiply in number, traditional security policies become cumbersome and often nearly impossible to enforce due to sheer scale.

How do we solve the scalability problem?

Scaling networking platforms can occur in a number of ways including adding more hardware resources, optimizing software, and enhancing configuration and deployment capabilities through orchestration. These enhancements can improve scaling up to a point, but in the end administrators are still focused on what IP can talk to what IP using which services. While we continue to take steps to further IP policy orchestration and handling, Meraki is also taking advantage of a few of the components of the Cisco TrustSec architecture through a new feature-set called Adaptive Policy. This feature utilizes Security Group Tags (SGTs) to provide granular, IP agnostic security policy and identity propagation that is compatible with many other Cisco technologies.

Support and use of SGTs gives Meraki the ability to share and learn the identity of a source of traffic, enforce policy based on SGTs, and provide a similar experience across Cisco solutions.

Adaptive Policy Architecture

Adaptive Policy has three key components: 

  • Identity classification and propagation 

    •  A tag that is applied to frames from a source device and acts as an identity or grouping for a user/device

  • Security policy definition 

    • A policy comprised of a source tag, destination tag, and the permissions between them

  • Policy deployment and orchestration

    • An engine that implements the policy on supported network devices 

Adaptive Policy leverages inline traffic tagging to provide the source’s group identity to the next hop in the path. Similar to 802.1q trunking, inline tagging adds an ether-type before the IP header of the packet. The specific ether-type that is added in this process is called Cisco MetaData (CMD). Within the CMD header, the Security Group Tag (SGT) identifies the group that the source belongs to.


Figure 1 - Frame Layout

Netowkr Frame layout which includes Security Group Tag (SGT) within the CMD header

Inline tagging encapsulates every packet from a source. The encapsulation is maintained on a per-hop basis from the network device the source is connected to, to the network device the destination is connected to. The policy is enforced at the network device the destination is connected to.

For micro-segmentation policies, each hop must support preserving and propagating the CMD header. Switches that do not support CMD encapsulation may be able to still forward the tagged packets if the switch is operating in an L2 only capacity. This however means that any client / endpoints connected directly to the non-CMD capable switch will not be classified correctly with an Adaptive Policy Group (SGT) and micro-segmentation policy enforcement will not be performed.

Figure 2 - Design constraints

Design constraints: correct and incorrect design examples for CMD supported encapsulation


Figure 3 - Per Hop tag propagation

Per hop tag propagation including Meraki SGT tag

Security Policy Definition

Once the Adaptive Policy tags are defined in Dashboard the actual policy can be written and applied to the network infrastructure. Below is a visual representation of a simple security policy allowing and denying specific devices' and users' communication.


Figure 4 - Policy Visualization

Simple security policy allowing and denying specific devices' and users' communication including IT admins, internal services, IoT, infrastructure devices and employees

Policy Structure 

Structurally the security policy consists of classifying and defining the allowed behavior for the classifications.


The security policy itself is broken down into 3 components:

  1. Source group (SGT)

  2. Destination group (SGT)

  3. Permissions between the groups 


The permissions are also broken down into 3 different potential permissions of:

  1. Allow all - the default permission for all tag relationships and permits all traffic (ipv4 and ipv6)

  2. Deny all - dashboard defined permission that blocks all traffic (ipv4 and ipv6)

  3. User defined “Custom ACL

Policy Configuration

With all of the components created the next step is to define a policy. The default Adaptive Policy permission is “allow all” until the tag to tag relationship is overridden with a specific configuration. All policies are defined in one direction. This means that to effectively block all communications between two tags, the administrator must configure the policy in both directions. The application of a policy is as simple as selecting the source group tag, the destination group tag, and then applying a permission such as Allow or Deny, or selecting custom.

Figure 5 - Policy between Two Tags

Dashboard configuration of adaptive policy between two tags

Policy Deployment and Enforcement

Once the policy is defined and applied, every network in the organization with Adaptive Policy will pull down the updated security policy for use. Before Adaptive Policy is enabled there are a few requirements that need to be met as outlined below.

Adaptive Policy Requirements

Adaptive Policy has a few requirements for the feature to be enabled on a network including specific hardware and software revisions. On top of hardware and software there are a few licensing requirements to meet including: 

  • Advanced licensing on all MX/Z3+ (Advanced or SD-WAN), MR, and MS in a network when in a Per-Device Licensing organization

  • Advanced licensing organization-wide on MX/Z3+ (Advanced or SD-WAN), MR, and MS390/C9300-M when in a Co-Termination licensed organization

For more information on Per-device licensing please refer to the following documentation: Meraki Per-Device Licensing Overview

Hardware Requirements:
  • MS390 / C9300-M: all models

  • MR: all Wifi5 wave 2, Wifi6, and Wifi6E MR and CW access points. 

  • MX/Z3+: all models capable of running MX18+ firmware (MX84 is not supported due to hardware limitations)

Software Requirements:
  • MS390: 14 + (latest stable release is recommended)

  • C9300-M: CS15-21-1+  (latest stable release is recommended)

  • MR: 27 +  (latest stable release is recommended)

  • MX/Z3+: 18.1 + 

Note: If the network is a combined network please ensure both MR and MS are on their respective required firmware versions as mentioned above.

MX version 18.1 only supports preserving and propagating SGTs over AutoVPN on NAT mode MXs. Support for VPN concentrator mode MXs will come at a later release. Classification of untagged traffic and policy enforcement on MX will also come at a later release. Please see this article for more information: MX Adaptive Policy Configuration Guide

Once all of the above requirements have been met, the administrator would need to navigate to Organization > Adaptive policy > Networks and enable the feature set on the network.


Figure 6 - Policy Deployment

Policy deployment graph showing the configuration is saved and stored in the Meraki cloud and Meraki deployed branches

Policy Enforcement Workflow

Understanding policy enforcement and the manner in which tag based policies are enacted is one of the most important topics in designing and building an Adaptive Policy network. Once the adaptive policy tags are created, adaptive policy enabled, and clients are classified with their relevant tags, the next step is for policy to be enforced. The one key policy aspect to understand in a tag based network is:

In an Adaptive Policy network, the policy is enforced at the destination network device. This creates a highly scalable policy framework as the network device only needs to worry about the tags of the clients that are directly attached to it and not of the IP prefixes. This does however come with some fairly rigid requirements for micro-segmentation including end to end support of the CMD encapsulation. This is why from a wired networking perspective, the only Meraki switch to support Adaptive Policy at launch is the MS390. 

The diagram in Figure 2 below shows one of the main reasons why the tag enforcement is done at the destination. In an adaptive policy network the means of identity propagation is through the data-plane and so to enforce policy the network device needs to understand the source AND destination tag. 


Figure 7 - Adaptive Policy tag enforcement

Adaptive Policy tag enforcement traffic flow from source to destination


Note: If there is a hop in between Adaptive Policy enabled appliances that does not support CMD encapsulation, micro-segmentation policy will NOT function as expected and will rely on using (if defined) Prefix to SGT mapping as a last resort method of classification. 

Example Use Cases 

Adaptive Policy has many potential use cases and can be implemented to cover a number of requirements including meeting PCI compliance, device quarantining, IoT device security, and more. Let’s take a look at a few of these in greater depth.

PCI Compliance Scope Reduction

Example documentation of TrustSec for PCI scope reduction: Cisco TrustSec for PCI Scope Reduction—Verizon Assessment and Validation


PCI compliance has a number of requirements to meet, however one of the most difficult traditionally has been securing PCI devices from the rest of the network. Instead of segmenting with VLANs and firewalls, using adaptive policy this can be done with simply applying a PCI tag to the PCI devices, and blocking PCI from communicating with Non-PCI devices as depicted in the graphic below.


Figure 8 - Example Policy for PCI

Traffic flow for an example PCI compliance policy

Device Quarantine

Many environments utilize a Network Access Control (NAC) service such as Cisco ISE to perform posture compliance and remediation. Part of the remediation process is to quarantine the endpoint in question until either the posture has been determined as compliant or non-compliant where remediation needs to take place. 


The most common way to perform remediation is to assign the client to a remediation VLAN, and/or assign the user an ACL to their authentication session to limit their access to required services for remediation. This however can prove difficult to maintain as VLAN changes are disruptive to wired clients and ACLs as usual can become daunting as things grow. Instead, using adaptive policy with change of authorization, Cisco ISE can send a re-auth request and send a different SGT value for the client in question. This will be nearly transparent to the end user while being able to reduce the potential impact on the rest of the network by simply changing the SGT assigned. 


An example of using tags to quarantine a device along with a number of other components is Cisco’s solution called Rapid Threat Containment. Adaptive Policy can be utilized to perform the segmentation aspect that TrustSec would in a traditional network. Historically however this solution combines Cisco ISE, Secure Network and Cloud Analytics (formerly Stealthwatch), TrustSec, AMP for Endpoints, and even Firepower Threat Defense to control misbehaving clients and users access based on behavior on the network. For more information please see: Cisco Rapid Threat Containment


Figure 9 - Device quarantine

Traffic flow for an example device quarantinne policy

IoT Device Security

One of the easiest use-cases to outline surrounds the ongoing threat that IoT devices impose on networks. IoT devices are rarely maintained with security patches and have been utilized as dDoS endpoints as well as mechanisms to spread malware into larger organizations since their inception. Using Adaptive Policy, securing IoT devices is as simple as locking the IoT endpoints down to only the required communications for the platform. An example would be to deny IoT to IoT device communication while only permitting MQTT services to an IoT Server. The reduction of communication pathways for the IoT device means even if it is infected with nasty malware, the endpoint is not able to spread the problem further. 

Figure 10 - IoT Security
Traffic flow for an example IoT device/server policy

Compatibility With Other Cisco Technologies

With Adaptive Policy utilizing Cisco’s inline SGT functionality, the feature is compatible across a number of solutions including but not limited to:

  • Catalyst switching and routing (3k, 4k, 6k, 9k, ISR)

  • ASR and CSR

  • Sourcefire Next Generation Firewalls / Firepower (FTD)

  • Adaptive Security Appliances (ASA)

  • Application Centric Infrastructure (ACI)

  • Datacenter switching (Nexus)

  • Software Defined Access (SD-Access)

  • 3rd-party Firewalls

For more information on which Cisco platforms support inline SGTs please see: Cisco Trustsec Compatibility Matrix

For Documentation on interoperability with Catalyst please see: Adaptive Policy and Catalyst Interoperability

For Documentation on interoperability with Cisco Identity Services Engine please see: Adaptive Policy and Cisco ISE

Additional Adaptive Policy Resources

For guides on how to configure Adaptive Policy on your network, please refer to the following:

  • Was this article helpful?